A supplier's invoice arrives by email. A tool reads it and produces a tidy list: supplier, number, date, total, due. It looks like the job is done.
It is not. Those fields are what the document says. Whether they are true, and what should be done about them, is a different question, and it is the one that costs businesses money.
What a document cannot tell you
Whether this invoice has already been paid. Whether the forty units it bills were the forty that were delivered, or thirty-two. Whether the supplier is one the business actually uses. Whether the total is over the amount one person is allowed to approve.
None of that is on the page. It is in the order, the delivery note, the supplier list and the approval rule. An intake system that does not look there is a typist, and a typist with no memory.
What a real intake does
It reads the document, and then it checks it. The invoice number against past bills. The quantities against the order and the delivery. The supplier against the list. The arithmetic against itself, because totals that do not add up are more common than people expect.
Then it decides, according to the page the owner approved. A clean invoice under the limit is posted, scheduled and filed without anyone touching it. A duplicate is stopped and the supplier is written to. A short delivery is held, with the working shown, and a person decides. A big one waits for an approval.
Every one of those is a different outcome from the same kind of document, and the difference is never visible on the document itself.
The honest result for a stranger
Drop in a document from a supplier the system has never seen and the right answer is not a guess. It is "no order found, supplier not on the list, held for a person". A system that refuses to invent a match is doing its job.
That is the standard we hold a document system to: not how well it reads, but how well it knows what it does not know.