Somewhere in your accounting, a judgment call lives in someone's head (and only their head)

The problem isn't your team, it's a hole in your tech stack.

Maximor's Audit-Ready AI Agents plug into your existing stack. AI prepares every entry with a full audit trail. If it's uncertain, it escalates with context. Your team reviews before anything posts.

Maximor guarantees a 5-day audit-ready close in 60 days, or $50,000 back.

See what this looks like on your setup for free

🚨 Before we get started today… 🚨

I’ve got a bunch of new content on AI for finance coming soon. Can you take 1 minute to tell me your most burning question about AI for CFOs? Please use this short form to submit your questions.

Anyway … let’s dive into this week’s Playbook.

In the late 1970s, the watch market got turned upside down by the Quartz Crisis.

Until that point, wristwatches were mechanical. Tiny springs and cogs, intricately assembled, expensive to make, and - if you knew what you were doing - beautiful. The Swiss had the market cornered. 

Then came the quartz watch.

A quartz crystal, exposed to an electrical current, vibrates at exactly 32,768 times per second. That makes it roughly 30 times more accurate than a typical mechanical movement and dramatically cheaper to produce.

Quartz suddenly had the mechanical watch industry in a chokehold. Mechanical would, of course, resurge as the ultimate status symbol. An object of desire that no battery-powered device could replicate. But that was a different job. As a device for telling time accurately, the Swiss couldn't compete.

Switzerland had over 50% of the global watch market in the 1960s. By 1978, that was 24%.

So this quartz technology blindsided them out of nowhere, right?

Not quite.

The first quartz clock was built at Bell Labs in 1927. One problem: it was bulky laboratory equipment. By 1959, Seiko had a working quartz clock, but it was still ~300,000x the size of a wristwatch.

It wasn't until the late 1960s and early 1970s, when the MOS integrated circuit was developed and miniaturized batteries became viable, that a quartz wristwatch became possible.

So the Quartz Crisis wasn't triggered by a breakthrough in quartz technology at all. The science had sat latent for over four decades, ready and waiting.

Not held back by what it was, but by what hadn't yet been invented around it.

Last week, we looked at why now is the moment to tackle the technical debt sitting inside your finance function.

This week, we go deeper. We're going to close the gap between what's theoretically possible with finance technology and what's practically deliverable. And help you pinpoint exactly how the debt in your function originated.

The quartz story shows how technology doesn't move in straight lines. It moves in waves and steps. And sometimes it needs something completely unrelated to springboard a revolution.

Technology can be real for a long time before it becomes useful.

The gap between invention and adoption often isn't filled by the technology itself. A new chip, battery, or interface. Something that removes the last constraint and suddenly makes it all click.

Your finance function is sitting inside exactly this dynamic right now.

There is a significant amount of pent-up technical capability in CFO tech; tools that have been theoretically possible for years but practically stuck. Held back by data quality, by ERP architecture, by switching costs, talent, compute costs, or simply by the fact that the right adjacent breakthrough hadn't arrived yet.

So the big question is, what are those same constraints in your tech stack? And what would it take to unlock them?

To do that, we need to take a little detour and explore the history of technology in accounting and finance. Because every era of finance technology left something behind in your stack.

Don’t worry, we’ll bring it back to what it means for you and your tech stack, but first, we are going back… waaaaaay back.

Luca Pacioli is credited as the father of accounting. Pacioli was Italian, like most good things in the world. He didn't invent bookkeeping, but he codified it into a system of ledger-based debits and credits that made it transferable across businesses.

Here began the long road to ASC 842/IFRS 16.

After a night with the boys and one too many goblets of Ribolla Gialla, Pacioli decided to call the system ‘double entry’. And securing a well-earned day one smirk from every accounting student ever since.

Here he is with a buddy, widely believed to be a young Leonardo da Vinci:

When you stop to think about it, though, double-entry bookkeeping is extraordinary. A system of financial record-keeping that has persisted utterly unchallenged for over 500 years… a wonder.

A merchant would record purchases in a daybook, then transfer them to a ledger, debiting inventory and crediting creditors. Somewhere across town, their counterparty would record the exact opposite leg in a beautiful symmetry. Cash settlement gets recorded separately. Then they check and close off each entry to confirm everything is balanced. And if it didn't… they’d start again from scratch until it did.

No ‘implementation partner’ required.

Thank you, Luca.

As perfect as double-entry was, the big problem was speed. Everything had to be calculated manually. Pen and parchment…

Some tools helped - mechanical adding machines, the abacus - but it was still slow as hell…

Computerization started in the 1950s, but the machines were enormous and eye-wateringly expensive. It wasn't until calculators hit desks in the early 1960s - and pockets by the mid-1970s - that the first examples of computational power reached every accountant on the planet. 

Let’s just be grateful LinkedIn didn’t exist in the 70s…

Our merchant is still recording purchases in a daybook. But now that daybook gets handed to the company accountant, who can total the figures considerably faster before recording them in a manual ledger. Still by hand. Still backward looking. But much quicker.

Giving them more time for added value activities like pouring another desk scotch, combing their perm, or pruning the massive lapels on their (presumably) corduroy jacket.

When Harvard MBA student Dan Bricklin got fed up with re-performing monotonous calculations by hand after one single assumption changes, he had an idea for a better way.

He tracked down Bob Frankston, a computer scientist at MIT, and together they built VisiCalc, the world's first spreadsheet.

Whatever you're imagining Frankston and Bricklin might have looked like, they look even more like that than you think. Wonderful stuff:

VisiCalc crawled so Lotus 1-2-3 could walk and Microsoft Excel could run:

It unlocked not just additional computational power through cross-tabulated calculations but an entirely new discipline: predictive finance. Paving the way for forecasting. The unlock for FP&A as a function. It made forward-looking finance possible for the first time.

Our warehouse foreman is still collecting purchases by hand. But now, when that daybook reached the accountant, they could cross-tabulate volumes with prices to get to a dollar value in seconds. Produce basic variance analysis. Compare actuals to a baseline. And for the most advanced: forecast future sales volumes, model cashflow movements, run NPV calculations, and compute loan repayments.

This coincided with the rise of ‘big finance’ in the 80s and big corporate deals. This is also when the expectations of the chief accountant started to evolve into a CFO role. Despite the masses on LinkedIn who talk about this like it’s a 2026 phenomenon.

By the early 90s, computerization of core business systems had started to become commonplace. And by now, that had included the general ledger and some of the sub-ledgers, too. I didn’t call this out as an era for finance because, while it was a move forward, until the early 90s, it was mostly a digital reproduction of what they were doing by hand. Valuable but not transformative.

But there were five former IBM employees who were planning something much grander. They had founded the friendly-sounding Systemanalyse und Programmenwicklung in 1972. Or SAP for short.

They’d had a bigger vision about how they could bring the whole business (and its accounting) together via one unified system to rule them all. And when they released SAP R/3 in 1992, they created the ERP category.

This was a genuine revolution. It connected the general ledger to the sub-ledgers and the sub-ledgers to the rest of the business. Procurement, inventory, billing, payroll, etc. All talking to each other through one central brain.

Now our warehouse foreman could record purchases at a line level directly into a computer on the shop floor. Immediately notifying the accounting department of the goods receipt. And in fact, making the double entry themselves simply by recording the transaction at the source.

As you can imagine… LinkedIn was losing its mind:

But, for most companies, it didn't quite pan out that way.

Turns out it was difficult to teach your foreman to use a computer after decades of pen and paper. So they'd record the transactions they could. But the edge cases? That complicated product return issue? The new product that hadn't been added to the system yet? They left those. Finance would sort it later.

Finance, who they never saw - because the computer meant nobody had to walk the daybook up to the accounting office anymore - was drowning. More work than ever, no clean data to start with, and a board demanding payback on their ERP investment.

Finance needed a hero. Something to plug the gaps. Turns out it had been there all along, winking seductively at them from the desktop:

The theoretical promise of ERP was right. But it had been too big a leap in one go. Businesses weren't ready. And by forcing it through anyway, most ended up half pregnant. Too committed to turn back, but nowhere near the finish line either (despite what they told their board each month).

So an industry grew up around the ERP. FP&A tools, consolidation software - Anaplan, Adaptive, Cognos, Hyperion, etc. - all designed to plug into the ERP and enhance it. And of course, they all inherited the same dirty data problems from upstream. Things got messy.

This was all happening while SaaS was having a moment. Single point solutions for individual problems. A tool for travel and expenses here. A tool for contract management there. A new procure to pay or billing tool somewhere else entirely. Each one solves one thing reasonably well and creates new integration headaches.

And while businesses doubled down on data warehouses, a unified layer designed to produce a single source of the truth, the problem is that there were so many ‘truths’ it was hard to know where to look. Half of it was saved on a shared drive in a .xlsx file.

What a mess.

With a world of manual pain in finance, the technology industry arrived with yet another ‘solution’: automate all the manual work.

The big words of the moment were “digital transformation” (what… you haven't transformed your digitals yet?!) and Robotic Process Automation, or RPA.

RPAs are bots that could process manual work in a fraction of the time, working just like a human would. And powered by machine learning, they'd improve as they went. Freeing up your team to be *adjusts glasses* more strategic.

Lol… does that pitch sound familiar?

To be fair, within their lane, they genuinely worked. Supplier statement reconciliations, intercompany reconciliations, cash allocation, and bank reconciliation. The bots chewed through that kind of low-judgment, high-volume work while you slept.

But here's the problem (apart from being very expensive). They were targeted at the symptom, not the cause.

Finance people solving finance problems. So what…

The real questions were never asked. Why are there so many intercompany exceptions in the first place? Why is our first-time purchase order match rate so poor? Where are all these billing errors coming from?

Back at the warehouse, our foreman is now using scanning and barcoding systems. But the business has gotten more complicated - more SKUs, more volume, more edge cases. Inventory count variances pile up every month. Nobody quite knows why, and the spreadsheet is still god.

Every line on the spreadsheet becomes an exception when the supplier invoice lands. The business has to develop whole new processes to resolve those exceptions. Meanwhile, an accounting team is left wondering what the hell they should book. And an FP&A team that is analyzing data that doesn’t have a robust transaction-level foundation.

But it's fine… because we’ve automated the downstream consequences.

Which brings us to today. With finance teams carrying years of scar tissue on technology promises and failed implementations, the next big breakthrough came when OpenAI launched ChatGPT in Nov 2022.

The dawn of natural language processing. The capability has improved at a staggering rate in the 3.5 years since, and an industry of new applications to sit on top has exploded.

Some of those applications are being developed are for us humble CFOs.

The big question has been, is the technology truly useful for finance teams? Or is it just another evolution layering more complexity on top of a broken stack? Automation and even basic machine learning have been around for a decade, after all…

Here's where it differs.

Every previous era required clean, structured inputs to function. That was the foundational problem for thirty years. Humans had to meet the technology where it was, fill in the right fields, follow the right process, and format the data correctly.

We are really bad at that. Especially as it got more complicated.

AI inverts that contract entirely. Theoretically, it meets humans where they are. It’ll take messy human outputs - natural language, emails, invoices in forty formats, voice, photos of receipts, even CCTV footage - and transform them into structured data computers can work with. And back again.

And that’s exciting, because it creates the possibility for the technology to actually help solve the root cause problem.

Let me dream for a minute…

Back at the warehouse, our foreman receives a delivery. The supplier has sent a handwritten note instead of a formal goods receipt. Another has emailed a PDF in a format nobody has seen before. A third has WhatsApp'd a photo of the paperwork from the loading dock.

In every previous era, those three transactions would have become three exceptions, three manual interventions, and three rows on a spreadsheet somewhere, assuming the manual workaround worked at all.

AI reads all three. Understands them. Puts them in the right place in the core system. It can even read the security camera footage to flag the delivery that arrived with no paperwork and never got booked at all. And then draft the message to the procurement team telling them their supplier just dropped off a delivery without paperwork (again).

The foreman didn't have to do a thing. The technology finally met him where he was.

I can hear your cynicism from here… but I did ask you to let me dream.

But whether AI is the answer or not is not actually the point here.

Either way, most CFOs are still underwater with the weight of their tech debt. And whether AI helps or not, they need to dig themselves out.

The key point of this historical rant is that tech debt doesn't live where most people look for it. It's not your reconciliation processes or your wonky FP&A-to-ERP integration (although neither helps).

It's deeper than that. It lives at the intersection of your systems and the real world. In your core business processes.

Your tech debt lives in how faithfully your business process and tech stack reflects the reality of what you buy, what you make, and what you sell. That means master data and your core process flows: procure to pay, order to cash, inventory management, etc.

The assumption for the last two decades is that we could bend the business to conform to the rules of the system. Most businesses got 90% of the way there. But 90% is nowhere near enough to reap the downstream benefits of the tech. The only way out is addressing the last 10%.

So, let’s wrap up by bringing this back to where you are today …

You didn't think I was doing all the work, did you?

Here are a few questions to help you identify the true constraints on your tech stack and the origin of your debt. It’s not exhaustive, but it should get you thinking:

Over the next two weeks, we will turn answers to these questions into a framework. We'll work through how to address your stack layer by layer and build a prioritized view of where to start paying down the debt.

:::::::::::::::::::::::::::::::::::::::::::::::::::
:: Thank you to our sponsor ::
:: Maximor ::
:::::::::::::::::::::::::::::::::::::::::::::::::::

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.