- Two reports say different things about the same month, and nobody made a mistake. Each one is counting something slightly different, and neither of them says so.
- Sorting that out takes two people's worth of knowledge. Someone who knows what the number is supposed to mean, and someone who knows how the report was built. A small team usually has one person who is both.
- Nobody planned it this way. The reporting ended up with whoever was able to do it, which isn't the same as whoever should own it.
- Building a warehouse doesn't necessarily change that. Everything still goes through the same person, and the better their reports get, the more people ask for.
- The fix is a model that keeps up with the ERP on its own. Without that, every change means somebody going to find the reports it broke.
A chairman asks for a board pack. He reads it, then sets it next to the financials, and the two don’t agree. Not by a rounding difference. By enough that he asks about it.
Nobody made a mistake. The sales figure on the board pack comes from a reporting warehouse built on order lines. Some of the discounts in that business are applied to the whole order rather than to each line, so they sit on the order header. The lines never see them. The warehouse reads the lines, adds them up, and returns a number that’s higher than the one in the ledger.
Each calculation is internally correct. They are measuring different things, and neither report says so. That version is a familiar one in ERP reporting, and the general version is broader: two figures built from different levels of the same data, both right, with nothing on the page to say why they differ.
The interesting part isn’t that the reports disagree. It’s what has to happen next. Somebody has to work out what the number is supposed to mean, and work out how the data produced it. In a small team, that’s usually the same person.
Why one person ends up in the middle
Reliable reporting takes two kinds of knowledge, and they don’t naturally sit together.
The first is knowing what a number is supposed to mean. Which date counts as the sale, whether intercompany is in or out, which discounts belong in the figure. Those are finance questions, and they get settled by agreement rather than by looking them up.
The second is knowing how the data produces that number. Which tables it came from, how they join, what the load does, where a change would have to be made. Those are technical questions, and the answers live in the model rather than in the business.
A large company keeps the two apart and pays for the gap between them. The IT team waits on the finance team at the end of every month to find out what a particular field actually means, and the finance team waits on IT to change it.
A business of a few hundred people doesn’t have that option. What it has is one or two people who between them cover most of both, and usually one person who covers enough of each to finish the job alone. That person is good at it. That’s the reason it landed with them.
Which is worth saying plainly, because it usually gets treated as somebody’s failure to plan. Reporting on ERP data sits in a narrow gap between two skills, and a business of this size rarely gets to hire for it. What it gets is somebody who can already do enough of both, so that person picks it up. The reporting ends up owned by whoever was able to build it, rather than by whoever should own it. As our CEO puts it, the warehouse is a requirement of the finance team that ends up belonging to the data team, and nobody really wanted that.
It works. It works right up until that person is on leave, or busy, or gone. At one of our customers, the person in the middle had their leave cancelled twice, because the business couldn’t manage without them.
Does building a warehouse fix it?
The obvious answer is to build the thing properly. It helps, and on its own it doesn’t remove the dependency. Two businesses show why.
One of them has. A dimensional data warehouse loading from several ERP databases across the group, Power BI over the top, years of history in it. It works. Maintaining it means that any change he makes he has to repeat once per database. Working out where a particular field lived, and which parts of the load he had to touch, cost him a week, because the model has several levels and the answer was in all of them. That isn’t a skill problem. He knows exactly what he’s doing. The work just doesn’t get smaller.
Another has no warehouse at all. Reporting is SQL queries run against the ERP and pasted into Excel, and recently some of those became Excel files that refresh on their own, which was an improvement. She isn’t a data engineer and says so. She came in from the implementation side and is one of two people covering IT. She has a handful of reports out in the business.
They’re working. That’s her problem.
Adoption is starting, and she can already see what it turns into: queries running whenever users decide to refresh them, a dozen or more people on a single workbook, and a new request each time somebody wants a number that isn’t on an existing report. Each request comes to her, because writing the query means knowing which tables hold what, and she’s the only one who does.
The better her reports get, the more requests they generate, and the workload grows with adoption rather than leveling off.
One of them has a warehouse and one doesn’t. Technically they are a long way apart. In practice the same person is still the only route from a question to a number. Building the warehouse fixed where the data lives and how it’s structured. It didn’t fix who has to change the model when the source changes, and that’s the work that never finishes.
What actually changes it?
So the question isn’t whether to build a warehouse. It’s what has to be true of it before the person in the middle can step out. Three things.
The first is that the definitions have to be written down somewhere the software reads, rather than held in one person’s memory and re-applied by hand each time. If the answer to which date counts, or which discounts belong in the sales figure, lives with a person, then that person is in the loop on every question that touches it.
The second is what happens when the ERP changes. A field moves, a module gets switched on, a company is added. Either the model picks that up on its own, or somebody has to go and find every report that used it. That difference is what turns finding one field into a week.
The third is that the same model has to serve every tool. If Power BI, Excel and anyone asking a question in plain language each read from the same definitions, a new request doesn’t automatically become a new build.
None of this removes the need for someone who understands the business. It removes the need for that person to be present for every question.
Three questions will tell you where you stand, and none of them needs a project. If your reporting owner were unavailable for a month, what would stop? How long does it take to add one new field to an existing report, from asking to seeing the number? And when a field changes in the ERP, who can tell you which reports it affects? If reporting stops when one person is away, if a new field takes days, or if nobody can answer the third question, the dependency is still sitting with the person.
Where Zap fits
This is the problem Zap has spent more than fifteen years on, and specifically the ERP side of it.
The model for your ERP is pre-built rather than assembled per customer. The standard part of an ERP, which tables carry the transactions, how the ledgers relate, where the header sits against the line, is the same at every business on that system and version, so it ships already modeled. Your own configuration, custom fields and extensions sit on top of that rather than inside it, and they are read from your system rather than assumed. Those models are versioned and re-released, so a correction made for one ERP reaches everyone on it rather than being rediscovered site by site. Multiple companies or databases are one model rather than the same change repeated for each of them.
Over that sits a governed semantic layer, where the definitions your business has agreed are recorded once and inherited by Power BI and Excel today, and by an AI assistant reading the same model as that capability arrives. Dimensional security travels with the definitions, so the same restriction applies whether somebody opens a dashboard or refreshes a pivot table.
What that changes for the person currently holding all of this is narrow and worth being precise about. They still decide what the business measures. They stop being the only route to a number.
If the two reports disagreeing is the part you recognize, why ERP data breaks the textbook semantic layer goes further into it. If it’s what happens when AI starts reading the same data, making your ERP data ready for AI covers that.