AI document processing

Every supplier, customer and form looks a little different, so accuracy claims from a vendor's demo tell you little about your documents. We start with a sample of your real documents, typically a few dozen per type, and write down the correct value for each field with someone who knows them.

That sample becomes the test. Each week you see how many fields were read correctly, which ones fail and why, and the model cost per document. Fields that are read reliably go straight through; fields that are not are routed to review until they are. You decide where that line sits before anything goes live.

When a model or prompt changes later, it runs against the same sample first, so a change that makes results worse never reaches your books.

A language model reads a document well, but it can still misread a digit or pick the wrong date. The checks after extraction are plain code, not another model call, so they behave the same way every time:

• Line items add up to the subtotal, and the subtotal plus tax equals the total
• The purchase order exists and the amounts match it within the tolerance you set
• The supplier and its tax or VAT number are already in your records
• The same invoice number from the same supplier has not been entered before
• The amount is in line with earlier invoices from that supplier

Our AI document checks product follows this design. Documents are classified and their fields extracted with Claude, values the model was unsure about are shown as such, and the checks are deterministic code. Classifications, extractions, corrections and check runs are append-only, so history is never overwritten. You can try the same flow in the document checks demo with a sample invoice.

At handover you get the code, the prompts under version control, the test sample with its results and the script that runs it. Model usage is billed to your own API key, and the runbook covers how to review flagged documents and add a new document type.