Document Pipelines Fail Before the Model

An accounts-payable queue receives a photograph of a crumpled invoice, a text PDF exported from a billing system, and a scan with a signature across the total. A single “extract the document” call treats those as the same job. They are not. One is an image. One already contains text. One contains marks a recognizer will try to read as words.

The failures that matter show up before anyone argues about which model is smarter. The pipeline posted a total that was a purchase-order number, or it posted nothing and nobody saw the page, or it posted the same file twice because the inbox worker retried. Fix the path from file to field. The model, if you use one, sits in the middle of that path as a drafter.

Three jobs that get collapsed into one call

• Capture: store the bytes, the page count, and a hash. You can do this without understanding the page.
• Transcription: recover text, and positions if a table matters. A scanned page needs recognition. A text PDF may already expose characters, in an order that follows how the file was drawn rather than how a clerk would read it.
• Business meaning: decide that a particular string is the amount due, that it is a decimal, and that it matches the sum of the lines you are willing to pay.

ISO 32000-2:2020 specifies PDF as a digital form for exchanging and viewing documents independent of the environment that created them. The standard states that it does not specify processes for converting paper or electronic documents into PDF, and it does not specify the operational details of rendering. “We have the PDF” is a statement about a file you can open. It is not a statement that a ledger field has been established. That interpretation is your pipeline’s job.

Confidence in a word is not confidence in a field

Open-source Tesseract can report a confidence for a recognized word through its result iterator, alongside the word and its box. That number is about the recognizer’s choice of characters. It is not a statement that those characters are the invoice total, that a handwritten signature was detected as a signature, or that two pages of a packet refer to the same supplier.

A large language model can propose a JSON object from the transcribed text. The proposal inherits every earlier mistake, and it can also fill a missing field with a plausible number. Treat the object as a draft. Code checks types, required keys, ranges, and relationships such as “amount due equals the sum of lines, within a tolerance you chose.” If a required key is absent, the draft goes to a person. The model does not complete the blank. How a system should behave when a check fails is the subject of AI Failure Contracts.

A path that can refuse a page

1. Hash the file. If that hash was already accepted or already queued for review, stop. A retry must not create a second bill.
2. Classify the input: image, text-bearing PDF, spreadsheet, or unknown. Unknown goes to a person with the original bytes attached.
3. Transcribe what you can. Keep the text and, when layout matters, the positions. Do not throw the page image away. The reviewer needs it.
4. Map the transcription to a schema you wrote, not a schema the model invented mid-request.
5. Run deterministic checks. Amounts parse. Dates parse. Required fields exist. Cross-field rules hold.
6. On success, post through the normal write path, with the file hash stored beside the record.
7. On failure, enqueue a review item that shows the page, the draft, and the check that failed. A reviewer accepts, edits, or rejects. Rejection is a terminal state for that hash until a new file arrives.

The same discipline shows up in Testing AI Workflows: the checks around the model can be asserted exactly, even though the model’s wording will not be identical every time.

Illustrative scenario: one inbox, three kinds of file

This scenario is illustrative. It is not a measured accuracy study.

A supplier sends a spreadsheet every month with stable columns. That file should be parsed as a table. A model is optional color, not the parser. A second supplier sends a text PDF whose labels move around. A model may draft the schema fields from the text. The amount still has to parse, and it still has to match the lines. A third supplier photographs a paper invoice. Recognition runs, the draft is often incomplete, and the page goes to review whenever a required field is missing. The reviewer posts from the queue. The inbox worker does not post from the photograph directly.

The product surface for that review is a structured confirmation, not a chat transcript. Put AI on the Decision, Not in a Chat Tab is the longer argument for that shape. The state of the item, pending review until a person accepts it, belongs in the same family as human-in-the-loop state machines.

Checklist before a document value hits a ledger

• The schema lists required fields. The model is not allowed to add required fields you did not name.
• Word-level or token-level confidence is logged if you have it, and it is not used as a substitute for the schema checks.
• Missing required fields route to review with the original file attached.
• Cross-field rules live in code, with tests that do not call the model.
• Intake is idempotent on the file hash.
• A rejected page stays rejected until a different file arrives.
• The posted record stores which file it came from, so a later dispute can find the page.

Questions that usually come next

Is a high recognition score enough to post an invoice?

It says the recognizer was comparatively sure about characters. It does not say those characters are the amount due, or that the amount matches the lines. Post after the schema checks pass, or send the page to review.

Should every file go through a large language model?

Use a model when the page does not match a stable layout and you need a structured draft. A spreadsheet or a text PDF with known columns can be parsed directly. In every case, validate the result in code before it posts.