The most dangerous financial error AI can make isn't one that looks wrong. It's one that looks right.

Maximor was built with this in mind. It reverse-engineers your company-specific accounting knowledge, like those Excel workbooks with hidden judgment calls, into executable policy. That allows Maximor’s AI agents to run your accounting, close, and reporting. Day one: 90% automated. Month six: 99%. Your team reviews what gets flagged, with full context.

60-day guarantee, or $50,000. See what this looks like on your data →

Many years ago, I was hiring for a transformation lead in my divisional BU CFO role, following a major acquisition.

I knew the business we'd acquired had poor processes for capturing operational data. This was actually good news, as our own processes were pretty crap too. The deal had handed me the focus and budget I'd need to fix it.

But it was a complex job. A multi-step manufacturing process, messy legacy systems, and a shop floor that had no appetite to change. I'd been looking for someone who knew our industry. The candidates had all been a little... well, meh.

My recruiter put forward a wildcard. Michael. Less experienced than the others, and from a completely different industry… quarrying. A long way from what we did.

I didn't really get it. But my recruiter was adamant, so I saw him, mostly out of politeness.

I was glad I did.

He walked me through the data challenge in his world.

My layman's version of it (and I apologize to anyone who actually knows this industry) goes something like this: You start with rock in the ground. You blast it. What comes out is hauled to a primary crusher, which breaks it into smaller pieces. Those go to a secondary crusher. Smaller again. Then a third stage. Smaller still. Between each crush, the material gets screened, literally sifted, to separate it by size. What passes through gets stockpiled as product. What doesn't goes back for another pass.

By the end of the process, you have products at completely different scales. Large graded stone sold by the individual piece. Smaller aggregate sold by weight in bulk. And fine dust - ground almost to powder - sold in bags for agricultural or industrial use.

Every stage measures its yield. Every product has a grade. Every batch is traceable back to the point it entered the process.

He explained the challenge of ascribing unit costs and measuring product margins when your raw material isn't something you buy. It is not even manufactured. It's a small chunk of planet Earth that you've blown out of the ground. And because one blast produces a dozen different grades at yields you can't fully control, working out what any individual product actually costs you is genuinely hard.

But this business had got there through a deep partnership with operations and a top-to-bottom process redesign. Getting a sticky, archaic old business to operate differently and embrace source data capture.

And Michael had been the person who made that all actually work - I’d found my guy.

I figured if you can datarize that process, you can datarize anything…

In Week 1 we explored why the CFO tech stack has become such a mess.

Last week, we went deeper, tracing how multiple layers of flawed fundamentals have opened a gap between what your technology is theoretically capable of and what it actually delivers.

This week, we start closing that gap.

One thing before we go further. Everything that follows is written from the CFO lens, not the CIO lens. I have had large IT teams reporting to me in the past. I did an OK job, not a good one. So this is a non-technical guide for CFO’s to prioritize and address data issues.

Last week, we established that most tech problems aren’t really tech problems at all. They are data problems. Tech can be one way to unlock them, but not the only way, and often it’s not the tech that’s the constraint.

There are lots of so-called best practices out there for improving data quality: data stewardship programs, data dictionaries, data governance groups, etc.

And they aren’t wrong… all wonderful utopian ideas of a desired end state.

But when you can't even get Barry in supply chain to raise his purchase orders in the correct unit of measure, you're too far from that end state for any of it to be useful.

The big question isn't what the end state looks like. It's what the first step in the right direction looks like.

Data problems are complex and pervasive by nature - they touch everyone. "Who owns data?" never has a satisfying answer. It's like asking who owns culture, or engagement, or performance. Ultimately, it's everyone, from the CEO down. It touches too many places to just point at one person and say, "You're our data person now."

Here's a framework that will help you think about it more practically. 

The first question to ask yourself is how faithfully the financial reality of your business is captured at source. Last week's homework questions were designed to force some introspection on exactly this.

If something happens in the business that triggers an accounting event - a raw material is ordered, a new person is hired, a sale is made - to what extent is that instantaneously matched with the creation of data? How high fidelity is that data? Is it captured in a batch or at a unit level? And with what metadata attached?

Sector plays a huge role here. For a software business, this is mostly automatic. (Another reason software CFO roles are fundamentally simpler.)

If a new customer signs up or cloud usage increases, a new unit of high-fidelity data is created at source. It might not be in the right place, or you might not be using it in the right way, but it exists.

At the other end of the spectrum, imagine you are a hotdog vendor, buying your supplies for cash and making cash only sales. There is zero data capture native in the business model. Except for how much cash and inventory you had at the start and end of the day.

That's not to say good data provenance is only possible if you are buying and selling through a platform. Just that, without one, it requires deliberate effort to create the connective tissue between the real world atoms and the digital bits.

And how much of that work has already been done determines the quality of your data provenance.

The second question is to understand how well your business is able to move that data to the right place in the business. How fluid is your data?

An example of good data fluidity would look like this: a modern SaaS or fintech business. Stripe captures the transaction, it hits the data warehouse automatically, and finance sees it in the reporting layer in near-real time. All without human intervention. The data doesn't just exist; it flows to exactly where it needs to be, clean and structured, without anyone carrying it there.

At the other end, imagine a mid-market manufacturer with a decent ERP. The hard work has been done to get operations recording and digitizing data; work orders, bill of materials completions, and yield reports. But it lives in the operations module that nobody in finance has access to or knows how to query. FP&A wants to understand margin by product line. The answer requires a data extract from IT, a web of complex spreadsheets, and three days of someone's time. The data isn't missing. It's stranded. So often, there is wonderful sales data stranded in a CRM system that would be useful for finance. Contract, rebate structures, discounts, payment terms.

So if we now plot data provenance and data fluidity against each other, we can start to diagnose your precise issue more deeply and find an approach:

If you have good data provenance and high data fluidity, you're living your best life. Whether you got there because your industry and business model gave you a giant inherent head start, or because you did the hard work of aligning business processes and systems, nailing master data, and building intelligent reporting, it doesn't matter. You definitely don’t need my help… this post isn't for you. 

If you have good data provenance but poor data fluidity, you have a technology problem. The data exists, and it's traceable; you just can't get to it. Either you have the wrong systems, or the right systems implemented badly.

So many businesses live here. They’ve invested the time in capturing data at source, but haven’t figured out how to structure it and move it in a way that it can be used. It was the vision of the ‘data warehouse.’

The good news if you live here … help is coming (more on what in a moment).

If you have good data fluency but poor source data capture, you have great technology and a process problem. Many manufacturing businesses live here. You may have spent heavily in the past to fix a data problem with tech - a wall to wall ERP - and never actually solved the problem. Because the gap between your business processes and your systems was always too wide to bridge with software alone.

Some of that is the system demanding more than your operation can realistically deliver. Some of it is that nobody ever tried hard enough to close the gap.

I have an old college friend called Tom. Whenever he got a new hobby - cycling, golf, whatever was the flavor of the week - he'd rush out and spend thousands on the best equipment before he even knew if he enjoyed it. We called it having ‘all the gear but no idea.’

Assuming technology will fix what is fundamentally a process problem is the corporate version of that. The fix is buried in your business processes. There is no shortcut.

Sidenote: as I've gotten older, I've come to realize ‘all the gear, but no idea’ is a middle-aged male phenomenon - myself included. Tom just got there ahead of schedule.

Dark Ages

If you have poor data provenance and low data fluency, you are in the dark ages. And have a world of pain ahead. Your biggest challenge is knowing where to start. Hold that thought, I'll come back to it in a moment.

In reality, your business won't sit cleanly in one quadrant. Even within the finance stack, you'll have corners of the plumbing that work much better than others.

Inventory is a classic laggard. Your order to cash cycle might be clean, procure to pay working well, but stock (and therefore COGS and margin) position is still reliant on an end of month count nobody fully trusts.

Or it might be a consistency problem rather than a capability one. Same systems, same processes on paper, but one business unit books everything at source while another catches up at month end with a spreadsheet. That's actually the easier fix, because the right practice already exists inside the business.

So a good start is to figure out the different kinds of data problems in the different parts of your business. That turns one giant unmanageable issue into something more snackable.

That could mean mapping by

Then you can understand precisely how many different flavors of data issue you have, and where they hurt the most.

And, of course, some of these problems are much easier to fix than others.

There are two key things that will determine the complexity multiplier of any work to upgrade data quality, whatever the issue:

You can start to see why this challenge is so much harder for more mature businesses. They carry several disadvantages at once: 

No wonder SAP R/3 has been so sticky…

If you read the definition of the ‘Dark Ages’ of data, and immediately reach for this button:

I want to say “I hear you” … I’ve been there. Many CFOs have. The whole ‘digital transformation’ movement that (in turn) fired up billions of unwanted unbound LinkedIn DMs was a well meaning solution to this problem.

And for some, Digital Transformation worked… I got most of the way there.

The real challenge is, where the hell do you start? Tech, data, process? How do you build a business case? Is your culture strong enough?

And it’s a very difficult question to answer. You need to get to work on improving data capture, but then you need somewhere to put it… a data warehouse? But… data warehouses need structured data. BUT… it’s hard to build a taxonomy for that structure until you understand the data. It’s a vicious cycle and easy to spin yourself in circles and do nothing.

So the answer is to start somewhere. And I think AI is making a big difference to where you should start …

Data lakes aren't a new idea. IT teams have been talking about them for a minute; the data warehouse's messier, less organized sibling. A warehouse stores clean, structured, labelled data. A lake stores everything else: raw, unstructured, and largely ignored by anyone outside of IT.

The reason finance never got excited about them (or more likely never heard of them) is simple. They were abstract, invisible, and required an enormous amount of structuring work before anything useful came out the other side. One more technical layer between the business and an answer.

AI changes that. AI is genuinely sensational at bringing order to messy, unstructured data. You can try this yourself…. Throw an ugly ass CSV into Claude or ChatGPT with a half decent prompt, and it will give you something good back.

For the longest time, data had to earn its way into a data warehouse, and until it had done that, it didn’t get invited to the party.

That super valuable factory yield data is off limits for the shiny new BI tool, because the data it just too messy for it. So your team end up contorting it in excel for ever more.

Clean structured data has been the entry ticket to the tech stack for the longest time.

But I think AI is flipping that, and we are moving into an era where a single exhaustive dump of data - however messy - will trump a smaller set of perfect clean data. It’s a great big dirty data party and everyone’s invited.

That will be transformational for finance tech debt. AI on top of a data lake is an exciting idea… it can help you structure, query, and organize it without the full weight of a human data engineering project first.

AI’s potential effectively collapses data warehouse and the intelligence layer into something real non-technical people can actually use, even if the data is messy.

Databricks is an example of this in practice, but that's an engineering-grade tool, built for data teams, not finance teams. But the potential to do something more user-friendly directly for finance teams is huge. And this isn’t hypothetical, I saw something firsthand just last week that does exactly that.

In fact, I think it’s so exciting, and so important, I’m going to share it in a dedicated piece next week.

So… AI can do a lot with messy data, but it can’t work with no data. If your data provenance is broken - if the gap between what happens in your business and what gets recorded is wide - no amount of AI closes that gap. The lake needs water…

Which is why fixing data provenance, if it's an issue for you, is a no-regrets move. And should be your priority.

Any business can be thought of in three cycles:

Most businesses have the sales cycle reasonably well digitized - you couldn't raise accurate invoices if you didn't. And often at least some of the buy side is covered too. A clean PO process goes a long way… and that might be hard work to implement, but it’s well trodden ground.

The make cycle is where it gets harder. That means capturing the relationship between what you buy and what you sell. The costs, conversions, and operational steps in between. It's unique to every business. But this is also where your downstream insight and value lives.

The clearest example is gross margin. Whatever level you can trace your cost through your make cycle will determine the level at which your margin insight lives. You can start with wide intervals, maybe that's at a total operating location, moving down to shift, then batch, then product, maybe even eventually unit …

I’m using manufacturing as an example - because it’s most tangible an easiest to visualize - but the principle works for any business. The more you can attribute your engineering team to individual business activities, products, project, categories, the better your downstream reporting and insight.

You are probably capturing a lot of this data already… but it’s messy. And as I said earlier, maybe that isn’t the problem it used to be.

Most finance functions are carrying data problems they've learned to live with. But the calculus is changing. AI can take messy, unstructured data and help make sense of it, work that previously required a full human engineering effort. That makes focusing on data capture a no-regrets move. Even if what you're capturing is ugly for now.

Next week, we return to the design of the finance tech stack. What it looks like today, how AI is changing it. And most importantly, where to look first when paying down your tech 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.