Templates and Semantic Extraction

There are two ways to get structured data out of a vendor’s invoice, and the difference determines how much work the system costs you in its second year.

Reading by position

The older approach: record where the information sits on a particular vendor’s invoice. The invoice number lives in this rectangle, the total in that one, the line table starts below this heading and has columns at these offsets.

Once configured, it is fast, cheap and completely deterministic. The same document produces the same answer every time.

The cost is that the configuration is per vendor, and it has to exist before the first invoice can be processed. That produces a characteristic shape of work:

• Each new vendor needs a setup step before their first invoice can be handled.
• Until then, their invoices go to a person.
• Vendors with occasional invoices may never be worth configuring, so a long tail stays manual forever.

And the configuration is brittle in a specific way. It does not fail when the document is unreadable. It fails when the document is perfectly readable but the layout moved.

A vendor changes accounting software. Adds a logo. Moves the tax summary from the right column to underneath the table. Everything a human reads identically now sits in different rectangles. The system either extracts nothing, or — worse — extracts the wrong field, confidently, because something else is now in the rectangle where the total used to be.

That second failure mode is the dangerous one, because it does not look like a failure.

Reading by meaning

The newer approach: read the document the way a person does. Find the thing that is the invoice number, wherever it happens to be, because it is labelled as one, positioned like one, formatted like one, and located near the other header fields.

This requires no per-vendor configuration, which changes the operational shape entirely:

• A vendor’s first invoice is handled as well as their hundredth.
• A layout change does not require anything.
• The long tail of occasional vendors is covered on the same footing as the top twenty.

The trade-off is honest and worth stating: it is not deterministic in the same way. The same document is not guaranteed to produce a byte-identical reading forever. It costs more per document than reading a rectangle. And it can be wrong in ways that are harder to predict than “the rectangle moved”.

The trade-off is only survivable under one condition

Non-determinism in the reader is acceptable if, and only if, the reading is not what gets posted.

This is the part that matters, and it is why the two design choices — how you read the document, and where the posted figure comes from — cannot be evaluated separately.

If the extracted invoice is transcribed into a purchase invoice and posted, then a misreading is a wrong payment, and the non-determinism is a genuine risk that has to be managed with thresholds and review queues.

If the extracted invoice is used only as a claim to be checked — compared against your purchase order and posted receipt, with the actual document built from those records — then a misreading produces an exception. The system says the claim disagrees with your records, which is exactly what you want it to say about a document it has read wrong.

Under that architecture, extraction errors and vendor overcharges surface through the same mechanism, and both get a person’s attention. The reading being occasionally wrong stops being a safety question and becomes a queue-volume question.

What each approach costs over time

Positional: front-loaded cost per vendor, ongoing maintenance whenever a layout changes, a permanent manual tail for low-volume vendors, and a silent failure mode when a moved field lands in the wrong rectangle.

Semantic: no per-vendor cost, no layout maintenance, a per-document processing cost, and errors that surface as exceptions rather than as silently wrong fields — provided the architecture puts something between the reading and the ledger.

Neither is free. But the costs land in very different places, and only one of them scales with how many vendors you have.

Questions worth asking

If you are evaluating anything that reads invoices:

• What happens with a brand-new vendor’s very first invoice? If the answer involves a setup step, you are looking at a positional approach, and you should ask how many vendors you have.
• What happens when a vendor changes their layout? Ask specifically whether it fails visibly or extracts the wrong field.
• Where does the number that gets posted come from? If it comes from the reading, the reading’s accuracy is your risk. If it comes from your own receipt and order, it is not.
• Is there a per-vendor hint or override, and is it required or optional? Optional is fine and often useful. Required is a template by another name.

A note on this product

DocumentQ reads semantically. There are no templates, no coordinate zones and no training phase — and there is an optional short per-vendor hint that nothing requires you to use.

More to the point, on a PO-backed invoice the extracted claim never becomes the posted figure. The purchase invoice is built by Business Central from your posted receipt and your purchase order. That is what makes the semantic trade-off worth taking: the thing that can be wrong is not the thing that reaches your ledger.