Truncation is the quiet bug in ERP AI

An assistant reads a table. The table holds 3,901 matching rows. The read stops at 500. The assistant writes a total.

The total is arithmetic over a sample. It is wrong, and nothing on the screen says so. This is the quiet bug in AI over an ERP system, and it gets worse as your data grows, because it only appears on the tables that matter most.

What is a truncated read?

A truncated read is a query that stops before it returns all matching rows.

Every data connection has a limit. An API page has a page size. A read tool has a record ceiling. A response has a maximum size. These limits are correct. A system with no limit fails differently and worse.

The fault is not the limit. The fault is a result that does not say it was cut.

Why is truncation harder to catch than a wrong number?

Because the answer looks right in every way that a person checks.

A wrong customer name is visible. A wrong date is visible. A total over 500 of 3,901 rows is a plausible number with correct formatting, in a sentence with correct grammar, about a question you asked. It fails only against the real total, which is the thing you did not have.

The tables where this happens are ledger entries, value entries and posted document lines. Those are the tables that carry your money.

How do I test an assistant for truncation?

Use this test on any assistant, including ours. It takes five minutes.

1. Choose a table with more rows than one page of results. Customer ledger entries over a long period works in most companies.
2. Ask a question that requires every row: a total, an average or a count.
3. Ask a second question: how many records did that query return?
4. Ask a third question: were there more rows that you did not read?

A correct system answers question 3 with a number and question 4 with a plain yes or no. A system that cannot answer question 3 cannot have answered question 2 correctly, except by luck.

Then repeat the first question with a filter that makes the result small. If the two totals disagree in a way that the filter does not explain, you have found the bug.

What should a correct system do?

Four things, in order.

Page until the data is finished, up to a stated ceiling. A single page is never enough. Automatic paging to a documented limit, for example 2,000 records, handles most real questions.

Carry the truncation state in the result. The result must say how many records came back and whether rows remain. This must be part of the data, not part of the prose.

Refuse to aggregate a truncated read. This is the part most systems skip. If the fetch reached its ceiling, a total or an average over it is not a total or an average. A report must say that the read was incomplete instead of drawing a number.

Say it in the answer. The reader, not only the log, has to learn that the read stopped.

A report is where this becomes expensive

A conversation is read once. A report is opened every month by people who did not ask the original question.

If a report is a saved picture of a number, the truncation is frozen into it, and the number stays wrong for as long as the report exists. If a report is a set of queries that refetch, then each opening is a new read, and the truncation state can be checked again each time.

This is the practical argument for reports that re-read rather than reports that store. It is not about freshness alone. It is about a limit that can be re-evaluated instead of a limit that was recorded once and forgotten.

A related trap: the right rows, the wrong field

Truncation has a cousin. Business Central's aged accounts receivable reporting can age by different date fields, and Microsoft documents the choice. Aging by posting date, document date or due date gives three different correct answers.

An assistant that picks one without telling you has not truncated anything. It has answered a question you did not ask. The control is the same: the answer must state what it filtered and how, so a reader can see the choice that was made.

The short version

Ask any assistant how many rows it read. If it cannot tell you, it cannot tell you the total either.