The Finance Team Tech Stack: What CFOs Are Actually Running in 2027
Rahul Bhattacharya
Co-Founder and CTO, Adopt AIOct 19, 2026
Ask a controller what the finance team runs on and the answer is usually a list of logins. The ERP, a bank portal or three, a close-management tool if the team is big enough to have bought one, a planning tool if FP&A has its own seat, and Excel, which is where most of the actual work happens regardless of what else is on the list.
That list is not a stack, it is an accumulation. Most of it got bought one system at a time to solve one visible problem, and nobody ever bought the seams between the systems.
This guide maps each layer of a finance team's stack, states plainly what each layer does and what it still leaves for a person to do by hand, shows how the shape changes as a team grows from a founder doing it alone to a multi-entity finance function, and works through where agents genuinely change the picture.
Who this is for: CFOs, VPs of Finance, controllers, and FP&A leads at companies that already have, or are actively building, an in-house finance team. If your company has no finance hire yet and a founder is running the books directly, the stack described here is where you are headed, not where you are today.
What a finance team tech stack actually is
Nine layers carry the work, regardless of which vendor sits in each one. Vendors merge, rebrand, and add features that blur the lines between layers. The layers themselves do not move.
| Layer | What it does | Common systems | What it leaves manual |
|---|---|---|---|
| 1. ERP and general ledger | The system of record: chart of accounts, journal entries, multi-entity structure | NetSuite, Sage Intacct, Sage 100, Dynamics 365, Business Central, Yardi, QuickBooks, Great Plains | Getting source data into the ledger in the first place, and anything the ERP's own workflow does not cover |
| 2. Close and reconciliation management | Close checklists, task sequencing, reconciliation status, sign-off tracking | FloQast, BlackLine, Numeric, Trintech | Preparing the reconciliation the platform is tracking, and chasing the people who owe one |
| 3. Accounts payable | Invoice intake, approval routing, payment execution | Bill.com, Tipalti, Stampli, the ERP's own AP module | Matching to the PO, catching duplicates, and the exceptions a routing rule cannot resolve |
| 4. Accounts receivable | Invoicing, collections, cash application | HighRadius, Billtrust, the ERP's own AR module | Matching remittances to invoices, chasing overdue accounts, and short-pay investigation |
| 5. FP&A, budgeting, and planning | Forecasting, variance analysis, scenario modeling | Adaptive Insights, Vena, Planful, a planning workbook | Getting actuals out of the close and into the model on time, every period |
| 6. Treasury and cash management | Cash positioning, bank connectivity, forecasting liquidity | Kyriba, GTreasury, bank portals directly | Pulling balances across every bank and entity into one view |
| 7. Document management and banking portals | Storing statements, invoices, and supporting files; moving money through bank interfaces | SharePoint, Box, individual bank and insurer portals | Retrieving from systems the finance team does not control, filing, and extraction from whatever arrives |
| 8. The working desktop | Where the work is actually produced and reviewed | Excel, Outlook, Teams | Effectively everything. This is the production environment, not a support layer |
| 9. Security and identity | SSO, MFA, access control, audit logging | Okta, Microsoft 365 or Google Workspace, the ERP's own role-based access | Nothing client-facing, but it gates every decision above it |
Two things follow from the table, and both hold regardless of how much the team has already spent.
Every layer here has decent products in it. The dissatisfaction a finance team feels is rarely about layers 1 through 6 being badly served. The ERP posts journal entries correctly. The close platform genuinely enforces a checklist. Planning software genuinely builds a model.
The hours sit in layer 8, and in the gaps between layers. Pulling twelve months of statements out of a bank portal with no API, reformatting a subledger export so the ERP will accept it, rebuilding a variance schedule because the close export changed shape again. None of that has a product category, so it never shows up on a stack diagram and never makes the agenda when the team reviews its technology spend. It is just what the team does every close.
We cover the layer model of the close itself, and the specific reasons close automation projects stall, in the financial close automation guide. This page stays on the stack question: given those constraints, what should a finance team actually own?
How the stack changes as a finance team grows
The layer map holds at every size. What changes is who owns which layer, what the team buys first, and what breaks.
No dedicated finance hire
Typical stack: QuickBooks or a similar small-business ledger, a bank feed, Stripe or a payments processor, Excel, and the founder's own judgment for everything FP&A would otherwise own.
What works: no coordination overhead and no gap between noticing a problem and fixing it. A founder can change how the books work on a Tuesday afternoon.
What breaks first: the founder is the single point of failure for every layer, accounting and planning included, on top of running the rest of the business. The constraint is never a missing feature, it is whether anything removes hours from a founder's week inside the first few uses.
A first finance hire or a small team
Typical stack: the ERP gets a real chart of accounts and a close process, a document system replaces email attachments, and FP&A starts as a spreadsheet one person owns alongside the close.
What works: standardization starts paying for itself. A real close calendar and consistent templates turn one person's judgment into something the rest of the team can follow.
What breaks first: the same person often still owns both the close and the planning model, so neither gets the attention it needs during the two weeks a month both are due at once.
A finance team of roughly 4 to 12 people
Typical stack: the ERP is joined by a close-management layer, dedicated AP and AR tools, and a planning tool with its own seat, usually across more than one entity.
What works: specialization. The close has an owner, FP&A has an owner, and AP or AR exceptions have somewhere to live instead of an inbox.
What breaks first: overlap and seams, in that order. The close exports to a format FP&A has to reshape by hand every period. Multiple systems each hold a version of the same vendor's bill. This is also the band where the preparation bottleneck turns into a growth ceiling: the team can only onboard as many entities or as much transaction volume as its most loaded preparer can carry through close.
Multi-entity, multi-ERP finance functions
Typical stack: the above, multiplied by the number of entities and the number of companies acquired, plus a security and compliance function with its own requirements and, increasingly, an internal data or automation effort of some size.
What works: the team can run a real pilot, absorb a security review, and roll something out consistently once a decision is made.
What breaks first: consolidation and acquisition sprawl. Each acquired entity arrives with its own ERP, its own chart of accounts, and its own close habits, and reconciling that into one group close is a standing project rather than a one-time cleanup.
Where agents fit, and where they do not
Agents, in this context, are software that operates the systems a finance team already runs the way a person does, through the interface when a system publishes no API, in order to produce a work product: pull the statement, extract the figures, build the reconciliation or the flux schedule, tie it out, and hand a person the exceptions.
That is a claim about layer 8 and the seams, the part of the stack nothing else addresses. It is not a claim about replacing the ERP, the close platform, or the planning tool. The ERP still posts the entry. The close platform still tracks the checklist. What changes is who produces the input those systems have always required a person to produce.
Three questions separate a real evaluation from a good demo.
Does it reach systems with no API? Bank portals, insurer portals, and a meaningful share of legacy or client-side systems publish nothing programmatic. If an evaluation only shows integration-based connections, the systems where the team's hours are actually concentrated stay out of scope. Ask to see it run against your own bank portal, not a sandboxed demo account.
Is the output traceable? A populated reconciliation or flux schedule should carry a path back to its source, with machine-populated cells distinguishable from human ones. A reviewer who has to re-derive a number before trusting it has gained a formatting step, not capacity.
Does it produce exceptions, or output? The useful artifact is a short queue of items that need judgment, next to a completed schedule. A tool that hands back everything for review has moved the labor rather than removed it.
Where agents do not help, stated plainly:
- Deciding accounting positions. Method selection, estimates, and judgment calls stay with the people responsible for them.
- Approving payments. Payment execution is a deliberate human step, not something a finance team should want automated away.
- Vendor and customer relationships. Collections calls and vendor negotiations are relationship work, not a queue to clear.
- A broken process. If three people prepare the same schedule three different ways and none of it is written down, the first output of any automation effort is a documented process, not a time saving.
How agents actually reach the systems finance teams run
A finance team's stack includes a large share of systems that were never built to be integrated with: bank portals, insurer portals, and ERPs a company inherited through an acquisition rather than chose itself. Agents built to operate the interface, reading the screen and deciding what to do next the way a person would, reach those systems without waiting on a vendor to publish an API.
The model does not touch the numbers directly. It writes the extraction and matching logic, code a reviewer can read, and the arithmetic runs inside that code rather than inside a model's assertion. That changes what a reviewer checks: not whether a model happened to produce the right figure, but whether the logic behind it is correct, which is a question a preparer already knows how to answer.
A second pass checks the first before a person ever sees the output, the same maker-checker structure a finance team already applies to its own work. The system also remembers how a specific exception gets resolved, a recurring vendor's odd invoice format or a client's habit of paying two invoices with one wire, and proposes the same resolution the next time it appears, with the team setting how much autonomy each exception type earns.
Every workflow starts fully reviewed. As the completion rate holds against real entities and real periods, the team decides which account classes move to lighter review and which stay fully gated, and that decision stays reversible. Nobody is asking a finance team to let software run unsupervised. The review gate belongs to the team throughout.
Book a Pilot to scope this against a reconciliation or close task already on someone's desk, or start free to try it against a period you can check yourself first.
Build, buy, or co-build
Finance teams building out a stack are choosing among three paths, and the right one depends on the workflow, not on a general preference for software.
| Buy a product | Build internally | Co-build | |
|---|---|---|---|
| Who defines the workflow logic | The vendor, generalized across customers | Your own team | Your team |
| Who writes the software | The vendor | Your engineers, if the team has any | Vendor engineers working alongside your team |
| Time to first working output | Fast, if the workflow matches the product | Slow, usually slower than estimated | Fast, but needs real time from your team |
| What the team owns at the end | A subscription | Everything, including the maintenance | The agents and decision logic as the team's own |
| Fit to an unusual workflow | Poor if the workflow does not fit the product | Excellent | Excellent |
| Best when | The workflow is standard and high volume | The workflow is a durable part of how finance runs here, and it can be staffed permanently | The workflow is specific to this business and the team wants to own the result without a multi-quarter internal build |
A finance team rarely has engineers on staff, which is why co-build, not an in-house build, is usually the realistic third option: the team's own people define how the work should actually run, including the exceptions that never made it into a written procedure, and an outside team builds alongside them rather than guessing from a blank slate. What gets built stays the team's own, inspectable and exportable rather than reverting to a generic product if the relationship ends.
Auditing the stack you already have
Before adding anything, run this. It takes an afternoon and it reliably changes what a team buys next.
| System | Layer | Who owns it internally | Hours it removes per month | Hours of manual work it creates |
|---|
Fill a row per system, then look for three patterns. Systems with no internal owner, which get renewed automatically and used by almost nobody. Systems whose value is visibility rather than output, which is legitimate but worth naming honestly rather than mistaking for production capability. The right-hand column, which is the finding. Add it up. That total is the seam cost, it appears in no budget line, and it is usually larger than the next purchase under consideration.
Questions to ask before anything joins the stack
- Which layer does this perform, and which layer does it only organize? Verify the answer against the demo, not the pitch.
- Show this running on our own system list, bank portals included, not a roadmap.
- What does the output look like to a reviewer? Can they see where a number came from without re-deriving it themselves?
- What happens when it is not confident? An exception queue is the right answer. A silent best guess is a disqualifier.
- What is our baseline today, and how will we measure against it? A saving nobody can check will not survive a board meeting.
- What process changes on our side for this to produce capacity rather than just output? "Nothing" means the saving will not show up.
A short version, if you are deciding this quarter
- A finance team's stack usually has decent products in every layer and an unowned gap between them. The gap is where the hours are.
- Inventory before buying. The manual work current systems create is often larger than the purchase under consideration.
- Standard, high-volume workflow: buy a standard product. Workflow specific to how this business runs: co-build rather than guess at an in-house timeline.
- Start with the reconciliation or close task with the highest volume and the lowest variance, on the most stable entity. Baseline the hours first.
- Insist on traceable output and an exception queue. Everything else is negotiable.
Related reading
Related guides
- Financial Close Automation: A Buyer's and Builder's Guide
- Account Reconciliation: The Complete Guide
- Flux Analysis: The Complete Guide for Accounting Teams
- Accounting Automation That Survives Contact With a Real Team
Related terms
Related workflows
Related skills
Product names above are cited as category exemplars to make the layer map concrete. Inclusion is not an endorsement, and the lists are not exhaustive. Verify current product scope against your own stack rather than against this table.
