Turning 1,000-Page Carrier Contracts into Pricing Records the System Can Trust
Carrier rate contracts that analysts transcribed by hand into 378-column import files, one row per rate, now pass through an AI pipeline built so that code reads the file, AI reads the sentences, a person decides, and the client's own file is the judge. 53,543 rows from a single contract, zero silent errors. The same pattern fits any document-heavy process where a person turns long, inconsistent documents into a strict system record.
The Challenge
A North American logistics software provider runs a pricing system on rate data from ocean carrier contracts. Every carrier sends its own contract in its own format, an amendment arrives every few weeks, and none of it can reach the pricing system until an analyst has turned it into a spreadsheet the system will import without interpretation. The customers who price shipments on that data expect it to be current and exactly right. The question was not whether AI could read the contracts. It was whether AI could be trusted to feed a pricing system, and what had to sit around it to make that true.
Contracts arrive as whatever the carrier produces: a 1,057-page PDF, a Word file with tables, an Excel workbook, sometimes legacy .doc
One contract produces an import file of 53,543 rows and 378 columns, about 20 million cells, every one of them keyed by hand
A rate row on the page fills about 8 of those 378 columns; the other 370 come from notes printed pages away and from conventions that live in the analyst's own working spreadsheet
Context travels: an origin set on page 3 governs rows on page 43, a note printed after a block of rows changes the rows above it, and commodity numbering restarts for every trade lane
The dangerous error is not the obvious one. It is the plausible wrong value nobody notices, and at 20 million cells there is no way to check by eye
A first automation attempt reached an accuracy nobody could verify. It read the characters correctly and still got the context and the conventions wrong
Approach
Started from one design rule: code reads the file, AI reads the sentences, a person decides, and the client's own file is the judge. Every choice below follows from it
Benchmarked four ways of reading the same 60 contract pages before designing anything: a native code parser, Azure Content Understanding, Azure Document Intelligence and a model asked to produce the table itself, all scored the same way. The result settled where AI belongs in the pipeline and where it does not
Built a stateful parser that walks the document in reading order, carries the governing origin, commodity, validity and notes across pages, lets notes reach backwards, and flags any row whose context is unknown rather than guessing
Read the exact 378-column schema from the client's own import file, headers byte-exact, and compiled the analyst's formula workbook into per-carrier rule sheets, so the client's own transformation runs as code instead of being re-derived
Put four deterministic gates on every row, including a verbatim check that re-reads the cited page to confirm the value is literally printed there, and a ledger that must balance: every source line is emitted, withheld or ignored with a reason, or the run fails
Put the AI model at four fixed points, each with a small output a gate can check: classifying documents and sections, reading prose notes into fields with a verbatim quote for each, auditing context independently, and proposing fixes. It never reads the rate table and never approves a row
Built an agent factory in which an engineer agent drafts a mapping or rule in a sandbox, an adversarial reviewer agent attacks it with its own channel to the page text, the client's file grades it, and a person promotes it. Agents cannot write the schema, the rules, the scorer or the answer keys
What Was Delivered
53,543 rows delivered from a single 1,057-page contract with zero silent errors, scored against the client's own import file
Roughly 99.99% cell accuracy on the columns completed so far for that contract; every cell of a second carrier's file matched
0 review items from the native parser on 60 digital pages, against 58 from Azure Content Understanding, 268 from Azure Document Intelligence, and 2,892 from a model asked to produce the table itself
16 seconds to read the full contract natively, at no model cost; the model-only route extrapolated to 6.7 hours and roughly $51 in tokens with nothing verifiable to check against
6 silent defects found during the build, none visible by eye, each caught by counting rows against the page or re-reading the cited value, and each now a regression test
Import registries built for all 9 carriers and formula workbooks compiled into rule sheets for all 9
3 files per run: the import workbook containing only rows that passed every gate, a review workbook listing every withheld row with its reason and source line, and a run report whose arithmetic must close
A new carrier profile drafted by the agent factory in minutes for about a dollar and a half of model time
Business Impact
The accuracy claim became an operational guarantee. The client does not get "99.9% accurate." It gets every row either in the import file with a quoted source or in a queue with a reason, and the two add up to the rows in the contract.
The reading problem was settled in a day. On digital contracts, code reading the file's own coordinates beat every AI service on review load, so the weeks went where the difficulty actually was: context, rules and verification.
Most firms spend the budget on a better model. This pipeline puts verification in cheap deterministic checks that do not depend on the model at all. A confidence score never caught one of the six silent defects. Counting did.
The client already owned the specification. Its import file is the schema, its formula workbook is the transformation, and its past output is the answer key. Compiling those removed most of the questions that would have gone back to the client and the hand-written rules that would have drifted from theirs.
Onboarding a carrier is now configuration, not code. A new contract type is a profile, a set of rules compiled from the analyst's own formulas, and a scored run against a file the client already has.
Take away the freight vocabulary and what remains is a general method for any document-heavy process: read losslessly, treat context as a state machine, compile the rules from the file the analyst already works in, score against their past output, fail closed, and bound the AI to sentences and proposals. Roughly two thirds of what was built carries to the next client unchanged; the document profiles, code maps and vocabularies are rebuilt per client. Lease abstraction, healthcare fee-schedule loading, insurance schedules, supplier price lists into ERP pricing, covenant schedules from credit agreements and telecom rate decks all have the same shape.
This engagement built and verified the pipeline against the client's own files. The outcomes here are demonstrated on two of nine carriers and are not yet full-production figures. Upload to the pricing system is manual today, and the remaining carriers are being run through the same loop. Effort and cycle-time savings will be measured once the pipeline runs against live contract volume.
Azure - Python - Azure Document Intelligence - Azure Content Understanding - Frontier Model - Excel formula compiler
Frequently asked questions
- Why do AI document projects reach an accuracy nobody can verify?
- Because the effort goes into reading the page and the errors live somewhere else. In a long contract, the values that govern a row are often printed pages away from it, and the output has to follow conventions that were never written into the document. A pipeline can read every character correctly and still produce a confidently wrong record. The fix is a parser that carries context across the whole document, rules taken from the client's own working file, and a check that compares every cell with what the client's analyst actually produced.
- Is a better model the answer to extraction accuracy?
- Usually not. Where the answer is already in the file, code reading the file's own coordinates is exact by construction and costs nothing. A model asked to produce a table is being asked to retype it, which is slow, expensive and unverifiable. A model asked "which origin governs this row?" answers in two seconds. Bounding the model to short jobs that a deterministic gate can check is what makes AI safe to use on documents that feed a billing or pricing system.
- Does this approach work outside freight, for other document-heavy processes?
- Yes, wherever a person turns a family of long, inconsistent documents into a strict system record and has been doing it long enough that input and output pairs exist. The five-question fit test: a strict target schema already exists, past human output exists to compile and score against, inputs are mostly born-digital, meaning depends on context printed elsewhere in the document, and the volume justifies a setup of hours to days per document family. Commercial lease abstraction, healthcare fee-schedule loading, insurance bordereaux and supplier price lists all pass that test. The single most useful question to ask is "show me the file your analyst actually works in." If it exists, the pattern fits. If the output is free text, the documents are one-offs, or most inputs are poor scans, a general-purpose model with a person reading the result is cheaper and no less safe.
- What does "zero silent errors" mean, and how is it guaranteed?
- It means no row is quietly dropped, truncated or shifted. It is guaranteed by arithmetic, not confidence scores. Every rate row on a page prints one currency token, so 46 on the page and 45 extracted means something is missing and the run fails. Every value cites the page it came from and is re-read there before it is accepted. Every source line in the document is accounted for as emitted, withheld or ignored, and if the ledger does not close, nothing ships.
Related industry
AI for Logistics and Supply Chain