AI Agents on ERP Data: Why “Nothing Found” Is the Most Dangerous Answer
The most dangerous answer an AI agent gives on ERP data is not a wrong number. It is “nothing found”. An empty result looks exactly the same whether the data is not there or the agent looked in the wrong place, and the agent reports both with the same confidence. So the rule is simple: every negative and every total an agent reads gets checked by a second route, every query is bounded by date, and the agent shows its evidence, not just its conclusion.
We learned this on our own system. We run an AI agent on our own Business Central for internal checks such as time sheets, and it has given us confident empty answers that were wrong. The two failures are told in our article on AI agents inside Business Central. Here is the method we built around them.
Why is “nothing found” more dangerous than a wrong number?
Because a wrong number invites a question, and an empty answer closes one. When an agent reports a total that looks off, someone checks it. When it reports “no absence recorded” or “no open item for that month”, nobody looks further. There is nothing to look at.
An agent that filters the wrong field and an agent that reads a truly empty table return the same answer, in the same tone. The model does not know the difference, because from its side there is none: it asked a question, the system answered with zero rows, and it reported zero rows.
This is also why the usual worry about AI, that it invents things, is the wrong worry for ERP data. On our tenant, the agent never made up a time entry. It read real data, from the wrong place, and drew a clean conclusion from it.
How does an AI agent misread ERP data without inventing anything?
Four patterns, all seen on our own data.
- The same fact stored two ways. Our absences are recorded differently for employees and for contractors. An agent that searches one way finds half of them and reports that the other half do not exist. In a group, this pattern multiplies: two entities that record the same thing differently are the normal case, not the exception.
- A truncated window. Some fields cannot be filtered on some API endpoints. If the agent fetches the first batch of rows and filters afterwards, it reads a window that may stop months before the period you asked about.
- A vocabulary mismatch. On our tenant, the value an import page expects for a field is not the value the read page returns for the same field. A filter written with the import value returns zero rows on the read page. No error, no warning, just an empty list.
- A fact the ERP only knows when someone declares it. We once tried to detect public holidays from the lines people had entered. It cannot work: a person who works on a public holiday enters a normal day, so by construction there is no holiday line to find. The check was blind exactly where it mattered.
None of these is a model problem. Each one is a gap between how the data is recorded and how the question was asked, and a stronger model asks the question the same way.
What is a second route, in practice?
A second route is a different way of reaching the same fact, one that does not share the first route’s blind spot. When the two agree, you can act. When they disagree, you have found the problem before it reached a decision.
On our own checks, second routes look like this:
- Two tests, joined. To find absences, we test two different fields and take the union. Testing either field alone misses one population.
- An independent document. A monthly total read from the ERP is compared with a document produced another way. Once, a total for a month was wrong, plausible, with no zero and no error anywhere. Only the comparison with an independent document caught it.
- An outside source for outside facts. Public holidays come from the official public calendar, not from what people entered. The ERP tells you what was declared. It cannot tell you what should have been.
A negative answer is accepted only when two independent routes agree on it. That rule costs one extra query. Skipping it once made the agent ask our founder a question his own data had already answered.
Why bound every query by date first?
Because the date is the one axis you can always check afterwards. If the agent fetches a capped number of rows and filters them later, the result depends on which rows happened to come first, and that has nothing to do with your question.
So we bound the query on the period first, then group and filter. And we ask the agent to report the earliest and latest dates it actually read. If you asked for a month and the latest date read is weeks before that month starts, the window was truncated, and the zero it reports means nothing. The date range of what was read is a better witness than the answer itself.
What should a finance team ask an agent to show?
Evidence, not confidence. Before anyone acts on an agent’s answer, it should show four things:
- The filter it used, written out.
- The number of rows it read.
- The date range those rows cover.
- The fields it tested, and the ones it could not filter on.
A “no” without the query behind it is not an answer, it is a guess with a straight face. This is the same discipline we apply to permissions: we do not trust a read-only setting because a box is ticked, we prove it by searching for write actions and getting none back.
It also changes what you ask for. “Are there any unapproved lines?” invites a yes or a no. “List the unapproved lines between the 1st and the 31st, with the filter you used and the row count” invites an answer you can check.
Where does a person still have to decide?
Wherever the fix would require guessing. Our rule: the agent flags, it does not repair to make a check pass.
An example from our own data. Some lines carry a project but no task. Fixing them is never automatic: the line does not say what was meant, and when the ticket reference is missing too, only the author knows. An agent that fills the gap with the most likely value turns a visible problem into an invisible one.
The same goes for differences between entities. When two subsidiaries record the same thing two ways, the agent can find every case. It cannot decide which way is right for the group. That is a governance decision, and root cause work is how it gets made before any tool is trusted on the data.
The Asio Services way
We put agents on ERP data to read, cross-check and prepare, and we treat every answer as a claim to verify, not a fact to file. Second route for every negative, date bounds on every query, evidence before trust, and a person deciding wherever a guess would be needed. That is the core of how we approach AI for multi-entity groups: the hard part is the data underneath, not the model on top.
If you are testing an agent on your own ERP data and want to know which of its answers you can trust, start with a clarity session.
FAQ
Do AI agents make up numbers on ERP data?
Rarely, in our experience. The common failure is a misread: the agent queries the wrong field, or a truncated set of rows, and reports a clean result. That is harder to catch than an invented number, because it looks like a real answer.
How can I tell if an agent’s “nothing found” is real?
Ask for the filter, the row count and the date range it read, then confirm the answer by a second, independent route. If the date range does not cover the period you asked about, the empty result tells you nothing.
Does a better AI model fix these errors?
No. These errors come from how the data is recorded and how the question is asked. A stronger model asks the same question the same way and gets the same empty answer. The fix is on the data and verification side.
Should an AI agent correct the errors it finds?
Not when the correction requires a guess. The agent should flag the line and say what is missing. A person who knows the context decides, otherwise a visible problem becomes a hidden one.