Getting clean data out of invoices, contracts and forms

What this actually solves

Somewhere in the business there is a person, often two, retyping. Invoices arrive as PDFs and email attachments and photographs, and someone reads each one and puts the supplier, the date, the line items and the total into another system by hand. It is dull, it is slow, and being dull is exactly what makes it error-prone — the mistakes cluster in the last hour of the day and they are not the ones anybody checks for.

The costs stack up in ways that do not appear on a single line anywhere. There is the wage bill for the typing itself. There is the delay, because nothing enters your reporting until someone has got to it, so the numbers you make decisions on are a few days stale by construction. There is the rework when a transposed figure surfaces at month end. And there is the ceiling it puts on growth, since taking on twice the volume means hiring, not scaling.

The thing that makes this service work commercially is a shift in what is being sold. Clients think they are buying accuracy. What actually saves them time is trustworthiness — a system that separates the documents it handled confidently from the ones it is unsure about, so a person spends twenty seconds on a short queue instead of checking everything just in case. Get that separation right and even an imperfect extractor removes most of the work. Get it wrong and a very accurate extractor removes none of it.

How the work runs

1. Collect and study a real sample. Fifty to a hundred genuine documents covering every type and every awkward supplier, deliberately including the messy ones rather than the tidy ones that were easy to find. This sample decides what gets built. Two to four days.
2. Write the field schema. Every field, its type, whether it is required, and the rule that if a value is not present in the document the answer is null rather than a plausible guess. Instructing the model to leave a gap where there is no evidence is the single most important line in the extraction prompt. Three to five days.
3. Build the extraction path. Digital PDFs read directly with pypdf; scans and photographs routed through a multimodal model. The extraction prompt is written against the schema and validated structurally with Pydantic or Zod so malformed output is caught at the boundary rather than downstream. About a week.
4. Write the validation rules and the confidence score. This is the heart of the project. Line items must sum to the subtotal. Grand total must equal subtotal plus freight plus tax. Dates must fall in a plausible range. Supplier names must resolve against your known-supplier list. Tax registration numbers and commodity codes must match their expected shape. Each failing rule contributes to a confidence score, and a threshold you set decides which documents a human sees. One to two weeks.
5. Build the review screen. Document on one side, extracted fields on the other, uncertain fields highlighted, corrections saved in a couple of keystrokes. The target is a document reviewed in seconds rather than minutes, because that ratio is what determines whether the system is adopted or quietly abandoned. One to two weeks.
6. Integrate and test on held-out documents. Push into the destination system, then measure field-by-field accuracy on real documents the build never saw, and report it as a breakdown rather than an average. Four days to two weeks, depending on the integration.

What moves the price

The range is $1,500–$15,000 over 3–10 weeks, and it is set mostly by three things.

How many distinct layouts. Five document formats and forty are different projects wearing the same description. Every additional supplier format brings its own quirks — a total in an unexpected place, a table that wraps, a column header nobody else uses — and each one has to be found, tested and covered.

Capture quality and languages. Clean digital PDFs sit at the bottom of the range. Skewed scans, photographs taken on a phone in a warehouse, faxed copies and mixed-language documents all add extraction difficulty and, more importantly, add validation work to catch what the extraction gets wrong.

Where the data has to land. A destination with a well-documented API is straightforward. A system that only accepts CSV imports on a schedule, or one with an undocumented interface, turns the final phase into an integration project. The review screen is also a small product in its own right — if you want a polished one with role-based access and an audit trail, it is priced as such.

What usually goes wrong

A perfect result on twenty tidy documents becomes a promise. The prototype is tested on whatever was easiest to obtain, everything comes back correct, and someone says the process will be fully automatic. Then production arrives with two invoices scanned onto one page, a supplier who redesigned their template last month, and a credit note formatted as a negative invoice. The right conversation on day one is about the split — most documents handled automatically, the rest identified and sent to a person — with the target agreed and measured rather than assumed.

Extraction gets built and validation gets skipped. The extractor works, the output looks right, and it goes live with no arithmetic checks and no confidence scoring. It is then silently wrong on a small fraction of documents with nothing to indicate which ones, which means every document still gets checked and none of the promised time is saved. Validation is not the finishing touch on this build, it is the reason it is worth buying.

Nobody asks what happens at the far end until late. The extraction is finished and then the accounting system turns out to have no API, or an import format with strict field requirements nobody mentioned, or a validation step of its own that rejects half the batch. That question belongs in the first meeting, because the answer reshapes the last third of the work and the estimate that goes with it.