"I can't explain to my board why the AI made that decision." – CFO, $180M company
Most AI tools can't. Maximor agents can. Their agents automate journal entries, accruals, reconciliations, and reporting. And when they’re uncertain, they escalate with context before anything posts.
No black box. Every entry is traceable.
Trusted by CFOs at Sierra, Gusto, Perplexity, Eightfold, and more.
Welcome to the final part of this four-week series on Tackling CFO Tech Debt
In week one we dug into why now is the moment to tackle the tech debt sitting inside your finance function
In week two we broke down where that debt came from, and why the gap between what's possible and what's delivered has grown so large
Last week we found the real villain of the tech debt story - data quality - and explored why it may not be as big a problem as it once was
This week, we bring the series home. The focus: how the finance tech stack is changing, and how you can exploit that to start paying down your debt faster.
A World of Pain…
As we found in week two, the failure of ERP platforms to deliver on the original 'everything system' they promised left finance slowly accumulating bolt-on solutions. Each one adding a new layer of complexity and a new integration headache.
The result… most finance functions are running on a stack that looks something like this:
And this assumes you are lucky enough to have a single instance of each. The reality is more likely a recently acquired business sitting on its own ERP, with its own chart of accounts. And it’s on the other side of the country… so nobody has gotten around to integrating it yet.
So, what about the data warehouse whose job it is to bring everything together. Well… that has the door policy of an exclusive members club. Theoretically open to everyone, practically accessible to nobody (without the right connections, the right request format, and a six-week wait.)
And finally, endless spreadsheets, picking up the slack for the single version of the truth that never showed up…
The Two Chokepoints
Reflecting on everything we have covered across this series, and the reality of the typical CFO tech stack above, significant tech debt almost always traces back to one of two chokepoints.
Chokepoint one: the ERP. A system doing too many jobs, none of them well enough. The result is a poor fit between system and process, and an explosion of compensating software and spreadsheets to paper over the gaps.
Chokepoint two: the data layer. A data warehouse that is too technical, too unwieldy, and too selective about who it talks to. Leaving the intelligence and planning layers of your stack chronically starved of the data they need to function.
Let's dig into each one, and how you unblock them.
We'll start with the ERP.
An Unconscious Unbundling
We need to reframe what we expect our ERP to actually do.
I'd go further: we need to kill the term ERP altogether. Cast your mind back to what those letters stand for: Enterprise Resource Planning. If your ERP is genuinely planning resources across your enterprise, I stand corrected. For most businesses, it isn't anywhere close.
Your business is fluid, complex, and constantly changing. Your ERP is a rigid rectangle that demands the world conform to its shape. This has led to a kind of …stand off.
One that has been quietly resolved, over years, by bolting on point solutions to plug the gap. Or, the business has learned to live with the gap and absorb massive downstream inefficiencies.
In practice, this means the role of the ERP quietly shrinks to what it was probably always best at: running the GL and the sub-ledgers. The accounting system of record.
Call it an unconscious unbundling of the ‘ERP’:
But the tension doesn't disappear just because the scope has shrunk. Even if you can navigate the technology and integration challenges, there is still a hard knot underneath: the cultural expectation that the ERP is the first port of call for everything.
But, reframe the role of your ERP with a narrower scope. As the accounting system of record: GL plus sub-ledgers, nothing more, and the accounting system map looks clearer:
Specialist transactional tools plug in around it, modular by design, built to meet your business where it actually is… rather than demanding your business contort itself to fit a system. Some of these functions can still sit inside your accounting system (billing is one good example) but that becomes a conscious choice rather than a default assumption.
You ditch the one system to rule them all idea (at the transactional layer at least). And in doing so, you free yourself to build a stack that actually fits your business, your industry, and your ability to capture high-fidelity data at the source. And improve your data provenance, which is so important as we said last week.
The Conscious Unbundling of your ERP
The key questions this should raise for your own tech stack are:
What jobs, precisely, is your ERP doing today?
Is your ERP the best place for those jobs?
How expensive ($, time, and focus) would it be to change to a specialist solution?
Start with this list of all conceivable roles the ERP could be playing for your finance team. There might be edge cases, but this list should cover most businesses:
Now work through it in five steps.
Step 1 — Eliminate. Cross off anything that isn't relevant to your business. Make the list smaller. A professional services firm doesn't need manufacturing and MRP. A single-entity business doesn't need intercompany. Start with what's actually yours.
Step 2 — Map. For everything that remains, define what's serving that need today. One of three answers: your ERP, a specialist point solution, or manual, which probably means Excel.
Step 3 — RAG it. How well is it working? Green is fit for purpose. Amber is working but flawed; you've learned to live with it. Red is broken; the gap between what you need and what you have is actively costing you.
Step 4 — Grade the data provenance impact. How important is the source data from this function to your downstream reporting? This might be driven by materiality, or by how central it is to your P&L. High, medium, or low.
Step 5 — Grade the switching cost. If you decided tomorrow to move this function to a better solution, how hard would that actually be? High, medium, or low.
From this exercise, it should become clear where your ERP is (not quite) doing work it's poorly suited for. Then, you can start to prioritize how you unbundle around it.
That does two things. It improves the quality of service to finance and the business on each specific function. And it reduces the load your ERP is carrying, so when the time comes to replace it, the blast radius is dramatically smaller.
Which brings us to a sequencing decision: do you unbundle around the existing accounting system first, leaving a cleaner upgrade for later? Or do you tackle the core system of record itself before anything else?
My preference is to unbundle first. Strip away the functions that don't belong in the ERP. Shrink it down to what it was always best at. Then, when you do move it, you're moving something much smaller and much less load-bearing than what you started with.
The exception is when your ERP is so archaic it can't easily connect to anything else. No modern APIs, no clean integration points, no realistic path to plugging in specialist tools around it. If that's where you are, you may have no choice but to start with a fresh accounting system of record and build up from there.
The Starving Data Layer
Last week we broke down the data provenance problem: whether or not data gets captured at source. Now we’ll talk about data fluidity; whether data can move.
Can get from where it lives to where it needs to be, in a form that's actually usable?
The vision for the data layer over the last twenty years has been single-minded. All data, first, had to earn a seat in the data warehouse. One store. Clean. Structured. Queryable. Then everything is built on top of it: business intelligence, FP&A systems, reporting, and consolidation tools. Purpose-built tools doing specific jobs, fed by a single reliable source.
Well… it sounds nice at least.
The problem is that I have never seen a business with a complete data warehouse. There is always something that sits outside. And quite often it's not a small edge case.
It's a big bucket:
"All of our operational data lives in spreadsheets"
"Our payroll mappings are too messy, it's quicker to do it manually"
"Our legacy system doesn't have an API so IT exports a CSV every month"
The consequence then, is that every tool sitting above that warehouse is also incomplete. A Tableau/PowerBI dashboard with no operational metrics. An FP&A model with a payroll line that nobody fully trusts. A consolidation that works beautifully for two-thirds of the business and falls apart for the rest.
And when the top-down needs of the business overwhelm the gaps (which eventually it will)… that’s when the ‘workarounds’ show-up:
The final report gets stitched together manually at the top level.
Someone forces data through the warehouse via a process nobody fully understands.
A compromise gets made on accuracy or timeliness of reporting and quietly becomes the new normal.
None of these outcomes are unacceptable, however much we’ve had to accept them as normal.
The prevailing corporate (and professional advisory) view has been that this is a ‘process’ problem. A failure of the business to conform to what the systems need.
I reject that.
The warehouse was designed around a theoretical version of your business. Not the real one. And no amount of process discipline was ever going to close that gap entirely.
Where Spreadsheets Rule
Spreadsheets have endured because they are flexible. They are like water, they run downhill, fill every vacuum and seep into every crack they find.
But they have become so multi-purpose that it's easy to forget what they are actually good at.
A spreadsheet is a canvas. A canvas for analyzing and communicating numerical information. Which makes it the natural home for intelligence and decision making in finance. Finance thinks in rows and columns.
Always has. Before Dan Bricklin invented the spreadsheet, he was preparing discounted cashflows in a table format by hand.
Historically, the trade-off has been between the time and discipline it takes to build them well.
But that is changing fast. Claude for Excel and its equivalents are not perfect, but they are already very impressive, and they are improving quickly.
The end game form factor for modeling, analysis, and reporting in finance will be a tabulated canvas controlled through a chat interface. That might or might not be Excel plus Claude/Copilot. But it will look a lot like it…
The bigger question is where that canvas sources its data. And as we said last week, AI has opened the door to building a clean structured data layer on top of messy, abundant, inconsistently formatted data. Without the full weight of a human engineering project to get there first.
Which leads to my big prediction:
The FP&A platform, the consolidation layer, the BI tool, and the data warehouse will consolidate into a single AI-powered data integration layer with that canvas on top.
And this is not a fantasy. I saw something last week that is well on the way there. (I have a dedicated piece landing tomorrow to share that example.)
The Future Stack?
So let's step back and look at what the future finance tech stack actually looks like. One caveat before I share it: this is my view as it stands in March 2026. A month ago, I would have drawn it slightly differently. It’ll likely change again next month. That's how fast this is moving.
Most of what follows exists today. The rest is a short extrapolation from where things already are. But none is science fiction… I don't do hyperbole.
I see four layers, working upwards:
Layer 1 — The Transaction Layer. Where core transactions are recorded. Best of breed tools per domain. Each one doing a single job brilliantly, built to meet your business where it actually is.
Layer 2 — The Accounting System of Record. Formerly known as the ERP. Ingests structured transactions from the transaction layer. AI embedded in the accounting system organizes and standardizes metadata as transactions arrive. Removing the dependency on every upstream tool conforming to the same data model. Sub-ledgers, controls, and consolidation all live here. This is where the audit trail starts. Your accounting system; clean, focused, doing one job properly.
Layer 3 — The Data Integration Layer. Ingests accounted transactions from layer two, raw event data from layer one, and broader data from other systems across the business. AI structures messy, inconsistently formatted inputs into an organized and queryable layer. There is a fixed taxonomy and set of rules for how the business organizes and distributes information.
The integration layer defines that taxonomy and the structured query language that sits above it. Reconciliation agents operate inside this layer continuously; testing data validity, cross-checking against source transactions, and pegging disorganized data to that integration layer as it arrives. The result is what the data warehouse always promised and never delivered. And the auditability of everything above it depends entirely on the integrity of what happens here.
Layer 4 — The Intelligence Canvas. Where the valuable output happens. Financial modelling, analysis, budgeting, board packs, report preparation, self service analysis, etc. Access controlled… pulling only what it has permission to see from the integration layer. The natural language interface is trained on the taxonomy defined in layer three, so when someone asks a question in plain English, the system translates it into a controlled, auditable query. The answer is checked & traceable.
The output from layer 4 can be pushed into whatever format the business needs. A dashboard. A PDF board pack. A management report. An AI-generated video of the CEO presenting the results to the business. The presentation layer is increasingly simple and cheap. The hard work is the three layers underneath it.
A few questions you might be asking:
Where are the agents? Agents are not a layer. They are workers operating inside the layers, particularly inside layers two, and three, where reconciliation and data validation are continuous processes. If agents are working between layers to plug integration gaps, that is a sign the architecture is not doing its job.
Where is AI? Same answer. AI is not a layer. It is embedded throughout the stack at every level. It organizes metadata in layer two, structures and reconciles data in layer three, translates natural language into auditable queries in layer four. Think of it like electricity… it powers everything. You do not add it as a separate floor in the building.
What about a reporting and dashboarding layer? I considered it. There is a version of this stack with a custom presentation/reporting layer on top. But I left it out deliberately. That problem is already largely solved; Claude code, vibe-coded dashboards, AI-generated board packs. Open your LinkedIn feed on any given morning, and someone is dying to show you how to build one in five minutes. The reason credible finance professionals aren't doing this at scale yet has nothing to do with the tools. It's because there's no trusted data layer underneath them. In this stack, that problem is solved. The presentation layer becomes trivial. Which is exactly why it doesn't need its own floor.
What can you do now? Well, the precise steps will depend on your current state. But one no-regrets move is to get your data stored in one place, however messy. I wouldn't over-invest in structuring and labelling it right now unless you are already on that journey. The tools to do that work are coming quickly, and they will do it faster and cheaper than you ever could manually.
Net-Net
I'll end this series with an appeal.
In my last CFO role, I regret not moving faster on these two chokepoints. We made great progress in the end, but there was always a reason to wait a little longer or move more slowly, and that was expensive.
If you are sitting on what feels like insurmountable tech debt, that is most likely not your fault. You have been working with unfit technology and limited options for a long time. The game was rigged, as we said in week one.
But it is your problem. And the barriers to paying it down, or at least to starting, are lower than they have ever been. And will be lower again tomorrow.
For the last twenty years the incentives have pushed CFOs away from bold moves on technology. Too much career risk, and too many ways to fail publicly. I think that is changing. The next five years will belong to the CFOs who are prepared to stake their reputation on delivering transformational technology change.
Ready yourself to be one of them.
If you’re looking to sponsor CFO Secrets Newsletter fill out this form and we’ll be in touch.
:::::::::::::::::::::::::::::::::::::::::::::::::::
:: Thank you to our sponsor ::
:: Maximor ::
:::::::::::::::::::::::::::::::::::::::::::::::::::
What did you think of this week’s edition?
If you enjoyed today’s content, don’t forget to subscribe.
Disclaimer: I am not your accountant, tax advisor, lawyer, CFO, director, or friend. Well, maybe I’m your friend, but I am not any of those other things. Everything I publish represents my opinions only, not advice. Running the finances for a company is serious business, and you should take the proper advice you need.
