How to make your ERP data ready for AI

Start with a question somebody in your business asks most weeks. What is our stock actually worth right now?

It sounds like a single number. In practice the answer depends on whether consignment stock counts, whether goods in transit are included, what the business treats as obsolete, and whether the write-down finance booked last month has made it back into the operational system yet. Ask an assistant that question over a spreadsheet export and you will get a number. What you will not get is a note explaining which of those four decisions it quietly made on your behalf.

For most businesses that horse has bolted, and the interesting question is no longer whether people should be using AI with financial and operational data. It is what happens when they do, and more specifically, what the assistant is being asked to work from.

Give one a spreadsheet exported from your ERP and it will do what these models do remarkably well. It will find patterns, interpret the information in front of it, and produce an answer that reads as coherent and considered. The difficulty is that the spreadsheet contains the numbers without necessarily containing the things that give those numbers meaning. It may say nothing about how your fiscal calendar works, which transactions are eliminated on consolidation, what your organization actually counts as revenue, how entities relate to one another, or who is supposed to see what.

The model has to work with what it has. Where that context is missing, it will generally infer it.

This is where a lot of the conversation about AI accuracy starts in the wrong place. We tend to ask whether the model is capable enough, whether the prompt was good enough, or whether the next release will fix whatever went wrong last time. If the ambiguity was already sitting in the data before anyone asked a question, a better model does not remove it.

The errors don't look like AI errors

Picture asking an assistant to work through your general ledger and explain why margin fell last quarter.

The ledger may record debits and credits using conventions that the ERP understands perfectly well but that are not apparent from a row of exported values. Your financial year might start in July while the model reasonably assumes that last quarter means a calendar quarter. An export spanning several entities may still contain the intercompany transactions that need to be eliminated before anyone calculates group revenue.

None of that is exotic. Those are ordinary features of financial data, and every finance team knows about them. The problem is that the answer does not announce that any of it happened.

It is a recognizable pattern. A monthly reporting template built on top of an assistant, working from a fairly complicated spreadsheet source, produces something that looks right most of the time. What it does not do is produce something reliably right. Run the same template again a month later and something comes back wrong or quietly missing. Sometimes it is a comparison against prior period figures held in a separate file. Sometimes it is simpler than that: a number misread, or one that should have been updated and was not.

The obvious response is to structure the inputs better, and it genuinely works. Give the assistant a cleaner, more consistent source and the error rate falls. But look at what that actually is. You are building and maintaining a structured, well-defined layer between the operational system and the question, so that the answers coming back can be relied on. That is the same job a governed model does, done by hand, by a person, every month. The work does not disappear. It moves into template maintenance that never ends, which is the work the assistant was supposed to save you.

An assistant can calculate confidently from an incomplete export without knowing the extract hit a row limit. It can include a salary field because somebody selected more columns than they meant to. It can hand you one entirely plausible definition of sales when the ERP, the CRM and the cash receipts each hold a different number that could reasonably carry that name.

The same thing happens as soon as the question leaves finance, and it gets harder. Ask what your stock is worth and the answer depends on whether consignment inventory counts, whether goods in transit are included, and what the business treats as obsolete. Ask what a job cost to make and it depends on which overheads are absorbed and whether work in progress at period end is captured at all. Ask about working capital and you are asking for payables, receivables and inventory ageing to be read side by side, which usually means three systems that have never fully agreed on what a customer record is.

In each case the model is working faithfully with the information it was given. The ambiguity existed before AI entered the picture, which is worth dwelling on, because it tells you what better data architecture can and cannot fix. A governed foundation does not make a model infallible. It can still reason badly, build the wrong query, or state something with total confidence that turns out to be wrong.

What governance does is reduce the ambiguity sitting underneath the model, and remove some sources of it entirely. Definitions get settled before the question is asked. Fiscal periods become explicit. Relationships between entities are modeled rather than guessed. Access rules are enforced. And when a number looks wrong, there is somewhere to go and find out why.

It is not a guarantee, and it would be dishonest to present it as one. A semantic layer can hold a definition somebody got wrong. A warehouse can be stale. Permissions can be misconfigured. What changes is that each of those is findable and fixable in one place, rather than being reinvented, differently, in every extract.

For a finance leader that is the difference between getting an answer and being able to stand behind one.

You can test this without taking our word for it

There is a simple experiment worth running with whichever assistant your organization already uses. Tell it that every month you export general ledger and sales data from your ERP into a spreadsheet, paste that into the assistant, and use what comes back to help prepare a board pack. Then ask it what could make its answers unreliable, and what it would need in order to make them consistent, traceable and defensible.

The exact response will vary by model, but the themes it raises tend to be familiar. How fresh is this export? What does each field mean? Are the relationships between these tables clear? How are accounting periods defined? Is anything missing? Which business rules should be applied before the numbers are used? Does this file contain information the person asking should not be able to see?

Those are not really AI questions. They are data questions, and AI has simply made them much harder to ignore.

What needs to sit underneath

Three things have to be in place underneath, and none of them is especially futuristic. They are requirements rather than stages, which matters most for the last one, because security treated as a final step is how access control ends up bolted on.

The first is a current, governed source of operational data. Rather than analysis depending on whichever spreadsheet somebody exported on Tuesday morning, ERP data is brought into a warehouse automatically and kept current. Finance stops having to work out which extract an answer came from, and analytical work stops going back to the operational system every time someone wants to explore something.

The second is meaning, and this is the part that gets underestimated, because businesses have historically stored a great deal of it in people’s heads. An experienced analyst knows what revenue means in that organization. They know which entities roll into which group, which dates matter, how customers relate to orders, and which calculations were agreed with the CFO three years ago and never written down.

An assistant arrives with none of that institutional knowledge. So the meaning has to live in the data model itself: the relationships, calculations, hierarchies, definitions and business rules, applied consistently whether the person consuming them is in finance, looking at Power BI, working in Excel, or asking an assistant a question in plain language.

The third is permission. Giving people an easier way to ask questions of business data should not quietly give them an easier way around the controls that already exist. What you want is for an assistant to inherit the same governed access rules as the reporting layer rather than becoming a separate path around it. That does not happen automatically because a warehouse is involved. Identity and authorization have to be carried through the architecture deliberately. Once they are, AI becomes another governed consumer of operational data rather than another uncontrolled copy of it.

Those three requirements are really the same question asked by different people. The CFO wants to know whether it is the right number and whether they can stand behind it in a board meeting. The CIO wants to know whether access is secure and auditable. The data team wants definitions that do not have to be rebuilt for every new use case. The assistant has the simplest version of all: what does this data actually mean?

What the assistant can do once that is underneath

Most of this argument has been about what goes wrong. The more useful question runs the other way: what can you ask with both that you cannot ask with either on its own?

An assistant working from an export can read what is in the file. An assistant working from a governed model can ask what is happening in the business. Margin by product this quarter against the same quarter last year, across three entities, with intercompany already eliminated. Which customers have gone quiet, measured against how they used to buy. What working capital looks like when payables, receivables and inventory ageing are read side by side rather than assembled by hand first. And when somebody challenges the number, a path back toward the transactions underneath it.

Ask the same question again next month and you get the same answer, because the definitions did not move in between. That sounds like a small thing. It is most of what makes a number usable by somebody who did not produce it.

None of that depends on which assistant your team has settled on. Copilot, ChatGPT, Claude and whatever follows them all start from the same place: what they were handed. Hand them a governed model instead of a spreadsheet and the range of questions they can be trusted with changes, without anybody waiting for the next release.

The assistant should not see what the person can't

This one deserves saying plainly, because it is the point most often skipped and the one with the sharpest consequences.

When an assistant answers through a governed layer, it can answer within the permissions of the person asking. Somebody who cannot open payroll today does not get a payroll answer by asking a chatbot instead. That is not automatic, and it is worth being precise about why: it holds when identity and authorization are carried through the architecture deliberately, which is a design decision rather than something a warehouse gives you for free.

A pasted export does the opposite. Once the file exists it has left your controls, and from that point access is decided by whoever it gets forwarded to.

What changes with a governed model

An ad hoc export is a snapshot. It reflects what one person chose to extract at one moment, with whatever filters and columns happened to be selected, and once the file leaves the ERP its access is determined largely by where people forward it.

A governed model starts from a different premise. The data is refreshed systematically. Definitions and relationships are already established. The same business logic can be consumed by different tools. Access controls can be carried through. And when somebody challenges a number, there is a path back toward the underlying source.

None of that is an argument against exports as such. An export can be scheduled, access-controlled, version-controlled and documented, and plenty are. The point is that by the time you have done all of that, you have started building the governed layer yourself. The question stops being whether you need one and becomes who maintains it.

There are operational differences as well. Repeatedly extracting and moving raw operational data creates work somewhere, whether that shows up as API usage, compute, manual preparation or load on the source system. A governed model does not make that work vanish, but it does mean much of the ingestion, modeling and definition can be done once and then reused across reporting, analytics and AI. That distinction gets more valuable as the number of consumers grows.

Six questions to ask about your own data

If you want a quick read on where you actually stand, these are the things worth checking. None of them requires a project to answer, and the ones you cannot answer cleanly tend to be the ones that matter.

Every one of those you cannot answer cleanly is a place where an assistant would have to infer something. Inference is not the problem in itself. Inference that never announces itself is.

Where an export is enough, and where it stops

There is a version of this argument that turns every ad hoc question into an architecture project, and that is not the argument. Sometimes an export really is enough. It is worth being precise about when, because the honest answer tells you something useful about your own situation.

It holds up when the person preparing the number is also the person reviewing it. Somebody with the full business context notices the odd misinterpretation, knows a figure looks wrong before anyone else sees it, and corrects it on the way through. With one or two people in finance, working only with financial data, an export and an assistant may genuinely be all you need.

The most useful rule of thumb is what happens when the person who prepares the number is no longer the person who has to answer for it.

That moment arrives sooner than most teams expect. It arrives when a second person has to review or sign the number. When an auditor or a lender asks how it was derived. When several entities have to be consolidated. When the data stops being purely financial and starts involving stock, work in progress or anything coming out of an operational system, at which point nobody holds the whole picture in their head any more. And it arrives abruptly when the person who did hold it moves on.

None of those are about company size, and none of them are about AI. Each one is a point where somebody other than the author has to trust the number, and where the working has to be available rather than remembered.

It is a rule of thumb rather than a rule. What actually decides it is some combination of how material the number is, how often it has to be reproduced, how many systems it crosses, how sensitive the underlying data is, and whether anyone will ever have to audit it. One person can genuinely need governance. A larger team can run a controlled, well-documented export perfectly safely.

Below that line, an export and an assistant are a perfectly reasonable answer. Above it, what the business is asking for is not really an answer any more. It is an answer with an audit trail, and that is a different piece of engineering. You still want the assistant above the line. What changes is what you point it at.

This investment doesn't depend on AI

Plenty of finance teams are still experimenting with AI rather than running it in workflows that matter, and that gets presented as a reason to wait before investing in the data underneath. I would argue the opposite, because everything that makes operational data safer and more useful for AI also improves the work those teams are already doing.

A warehouse that refreshes on its own reduces the dependence on manually assembled workbooks and on the person who maintains them. Shared definitions end the recurring meeting where finance and operations arrive with different versions of the same measure. Reading payables, receivables and inventory ageing beside each other stops being a monthly assembly job. Margin by product, plant or job becomes something you can look at rather than something you commission. And when a number is challenged, there is somewhere to go and find out why.

It is worth being straight about the comparison, too. Building your own reporting layer is not free, it is costed differently. The licence is visible. The person maintaining the structure, the reconciliation every month, and the risk carried by whoever signs the number are not. If one capable person holds all of it and nobody else has to answer for the output, building your own can genuinely be the cheaper answer, and we would rather say so than pretend otherwise. What changes the arithmetic is a second reviewer, an audit, a lender, another system that has to be brought in, or that person moving on. A reporting layer that lives in one person’s head is a reporting layer with a single point of failure.

If you already run a proper data platform, with a warehouse, transformation tooling, source control, testing and people who know how to use them, then most of the above is not your problem and this argument is not aimed at you. The cost that remains is narrower and more specific: interpreting the ERP itself. Its schemas and conventions, what differs between versions and editions, what changes at upgrade, and which of the thousands of tables actually carry the concepts the business talks about. That work does not finish, because the ERP keeps moving, and almost none of it gets easier because your data platform is good.

So this is not really an investment in AI infrastructure. It is an investment in a trusted operational data foundation, and AI is simply another consumer of it. An increasingly important one, but not the reason to build it.

Where Zap fits

This is the problem Zap has spent more than fifteen years working on.

ERP data is genuinely difficult to model well, because understanding the source system is most of the work. Tables have to be interpreted, relationships established, business concepts modeled, and differences between products and versions accounted for, all before the data becomes useful outside the ERP itself.

Zap has encoded a lot of that knowledge into pre-built models for systems including Sage, SAP Business One, Syspro and Microsoft Dynamics 365, and maintains them as those systems change. Rather than starting with raw tables and a blank data model, a project starts with an existing understanding of how that operational data fits together. From there Zap builds and maintains the governed foundation that sits between the ERP and the tools people actually want to use.

The ERP is rarely the whole picture, though. Most questions worth asking cross into the CRM, the payroll system, the warehouse or whatever else the business runs on, and joining those sources is where the manual reconciliation actually lives. The same governed model is where that joining happens once, rather than in a workbook every month. If you run three or more systems that have to agree with each other before anyone can answer a question, that joining is the work.

That is the part that is genuinely expensive to build yourself, and the part that has to be maintained indefinitely, because ERPs change. Building reports is not the hard bit. Knowing what the tables mean, and keeping that knowledge current across versions and upgrades while the business carries on, is the hard bit.

There is a direction of travel worth naming here, and worth being straight about. Zap’s roadmap includes exposing that governed model to external assistants directly, through an MCP endpoint carrying the same permissions as the reporting layer, so that a tool like Claude, ChatGPT or Copilot reads through the access rules that already apply rather than around them. That is roadmap rather than something in your hands today. The reason it matters now is that it only works if the governed model exists underneath it, which is an argument for building the foundation before the interface arrives, not after.

That might be Power BI. It might be Excel. It might be an AI assistant. Increasingly it will be all three, and the useful part is that they do not each have to invent their own version of the truth.

Which is worth holding onto as the tools keep changing, because they will. The assistant your finance team prefers in two years may not be the one it prefers today. The models will improve, the interfaces will change, and new ways of querying business information will keep arriving. Your definition of revenue, your fiscal calendar, your entity structure and your governance obligations will still be yours. That is the part worth owning.