Invoice extraction has a property almost no other extraction task has: the document contains a checksum of itself. Line items sum to a subtotal, tax is a stated percentage of a stated base, and the total is their sum. If the extracted numbers do not reconcile, something is wrong — and you know it before a human ever looks, without a confidence score and without a labelled test set.
Why invoices are the good case
Most structured extraction fails silently: a model reads a contract, returns a plausible date, and nothing in the world objects. Invoices object. That makes them the right first project for anyone building extraction, and it makes the validator — not the prompt — the interesting part of the build.
The pipeline: get text or an image in front of a model, extract to a strict schema, validate arithmetically and against your own records, and route the failures. Only the middle step involves a model, and it is the step you will spend the least time on.
One decision comes before all of it: text or image. If the PDF has a real text layer, extracting the text and sending that is cheaper, more faithful for long strings like account numbers, and reproducible. Sending the rendered page to a vision model instead preserves layout — which is what tells you that a number in the bottom right is the total — and handles scans, but costs image tokens and reads long digit strings less reliably. The pragmatic answer is text first, image on validation failure, which is the repair path below and which means the expensive route is used on the small fraction that needs it.
