Most document projects fail on the number of layouts you hold, not on how well a model reads one of them.
We turn documents into records your systems can act on. The work starts with a count of the shapes yours actually arrive in, and a decision about which of them are worth automating.
The date the document was issued
- Current
- Older
- Partner
- Scanned
- Photo
The dashed box is where a tool tuned on one layout looks. Every page here is legible. Layouts are illustrative of a real corpus, not a client record.
Four ways this goes wrong, and only one is about the model.
Reading quality is the thing buyers ask about and the easiest of the four to fix. The other three are all consequences of how many kinds of document a business is holding without having counted them.
Nobody counted the corpus
The build is scoped against the layouts somebody could find in an afternoon. The rest arrive one at a time over the following year, and each is a small piece of work that was never in the estimate.
The document was read against the wrong schema
Deciding what a document is happens before anything reads it for values, and getting it wrong does not fail loudly. Every field comes back populated, and against the wrong document type they are populated with the wrong things. No field-level accuracy number will show it either, because the fields you meant to read were never attempted.
The threshold was set without asking who sits in the queue
Where the system stops and asks a person is a staffing decision wearing a technical name. Set it high and the queue is longer than the team. Set it low and the mistakes leave the building unseen.
A sender changed their template and told nobody
Nothing announces it. Extraction carries on returning values, and the values now come from the wrong part of the page, which is harder to notice than an outright failure.
Six pieces of work, and extraction is one of them.
A working extractor is the middle of this rather than the whole of it. What decides whether the output is usable is what happens before it and what happens to the field it was not sure about.
Classification, before anything reads for values
Deciding what a document is, and saying so when it does not recognise one. An unknown document that stops and asks is cheap. An unknown document confidently read as something else is the expensive kind of wrong.
Extraction built against your own corpus
Field extraction developed and measured on documents you actually hold, including the shapes your team least likes receiving. A model tuned on a clean sample tells you nothing about the rest of the pile.
A confidence threshold somebody owns
Every field carries how certain the system is, which is what makes selective review possible at all. Where the line sits is a risk decision, so we build the dial and hand it to the person who should be holding it.
The review queue as a designed screen
The document, the values read from it, the field in question and the reason it stopped, on one screen. A queue that makes the reviewer reconstruct the case from three systems gets approved unread, which is worse than no review at all. The harder half is that making a check easier is not the same as making it safer, because confirming a value already on the screen catches less than reading it off the document yourself.
The record, and the route into the system that runs the business
Extraction is not the deliverable. A record in your system is. Where a system has no route in we say so at design stage rather than discovering it at the end.
An evaluation set you keep
A held set of documents with agreed correct values. It is what turns a later change from an argument into a measurement, and it is yours rather than ours.
We do not take on bulk backfile scanning and we do not sell an accuracy figure. If the expensive part is matching documents against an order, that is a different problem.
See finance and document workflowsOne document type, and the shapes it actually arrives in.
This is the exercise that decides whether the work is worth doing, and it takes a week. Sort one month of one document type into the shapes it really arrives in, then draw the line.
The current template, exported from the app
Typed throughout, fields in fixed places, and most of the pile. This is the one a demo runs on.
612Build for it.
The previous template, still in circulation
The same fields in different places, and no version marker anywhere on the page to tell the two apart.
148Build for it, once the version can be detected.
Three subcontractors' own templates
Different words for the same field. A defect here is an observation there, and neither side thinks the difference matters.
96Build for them, one at a time, after the vocabulary is agreed.
The line is the design decision.
Above it, a shape is common enough that building for it repays the build and the maintenance behind it. Below it, a shape is rare enough that a person reading it is the cheaper arrangement and always will be. We bring the counts. Where the line sits is yours, because you carry the cost of the queue underneath it.
Paper sheets completed on site and scanned
Handwriting, ticks that overrun their boxes, and a signature block that is not text in any useful sense.
14A person reads these. Three or four a week is an hour.
A photograph taken in the van
Angle, glare off the sheet, and the top of the page outside the frame. Legible to a human, unreliable to anything else.
7A person reads these, and the crew is asked to photograph the whole page.
Reports whose defect list runs onto a second page
The continuation rows carry no header, so reading them correctly means knowing the table did not end.
5Fix it upstream. The export can be asked to repeat the header.
Shapes and counts illustrative of a real corpus, not a client record.
Below the line is 26 documents a month out of nearly nine hundred, and it is where most of the build time would go. A project that promises to read everything is quoting for the tail.
Six steps, and the first one can end the conversation.
The order matters more than usual here. Three of the six happen before anything is built, because each of them can change what gets built or whether it should be.
Count the shapes
Take one document type and sort a real month of it, unsorted, into the shapes it actually arrives in. Almost nobody knows this number before they look, and it is the number everything after this is scoped against.
Agree what the right answer is
A set of documents with the values a person says are correct. Without it there is nothing to measure against, and no way to tell an improvement from a change.
Draw the line
Which shapes are worth building for and which stay with a person. We bring the counts to that meeting. The decision belongs to whoever carries the cost of the queue.
Settle what the system may keep
Which fields are extracted, how long the original and the derived record are each kept, and where the processing happens. Where the documents carry personal data this is a legal question rather than a preference, and at any real volume it is an impact assessment rather than a paragraph.
Classification first, then extraction
In that order. A document read badly fails visibly and gets caught. A document sent to the wrong schema fails silently and does not.
Design the queue with the people who will sit in it
Then set the threshold against what that queue can absorb in a working day, and put something in place that notices when a sender changes their template.
Step one ending the conversation is a good outcome, not a failed sale. If the count comes back as one shape that never changes, a template and a rule will read it and we will say so.
Where the answer is smaller work, or none yet.
We would rather say one of these in the first conversation than in the third month. Most documents are pages printed from a database, and asking for the data is the shorter job.
Some piles are an afternoon. Automating an afternoon is a standing commitment.
One shape, and it never changes
If everything arrives from one sender in one layout, a template and a rule will read it. A model is a more expensive way to get the same answer and a standing commitment on top.
The document should not be a document
If the sender could send the data instead, ask them. A feed, a form or an export beats reading a page that was generated from a database in the first place, and it is usually a shorter conversation than a build.
Nobody can say what the right answer is
Without a set of documents with agreed correct values there is nothing to measure and nothing to improve. Building that set is the first piece of work, and some quarters it is the only piece worth doing.
Low volume, hard documents
A hundred handwritten sheets a month is closer to an afternoon than to a project. Replacing that afternoon means a build, a review queue and somebody maintaining both, which is not obviously the cheaper arrangement.
No published engagement of ours is a document AI project.
So none is offered as one. What the three below share is narrower: each is a production system where a record had to be right, and correctness was measured rather than assumed.
Fitelo, AI running in production
An AI product running in production with evaluation and cost controls in place, rather than shipped and watched.
Cited as production context, not as a document engagement. An evaluation set that is rerun rather than referred to is the same discipline this page asks for in step two.
Vizitor, records that have to stand up later
A workplace platform in daily use across 500+ workplaces in 15+ countries, with a fully digital audit trail.
Cited as records context, not as a document engagement. What a record said and who changed it is the question an audit asks, and it is the reason the original is kept beside every extracted value here.
Conscious Chemist, answers from a named source
A documented 38% faster product-question response.
Cited as product context, not as a document engagement. Answering from an identified source rather than from a plausible one is the same boundary a confidence threshold draws.
We build that document set with you, and we quote against it rather than ahead of it.
Deliberately absent
The figures a page in this category normally opens with. None of them appears here, and the reason is the same in every case: a number without the document set it was measured on is not information.
- An extraction accuracy percentage
- A straight-through processing rate
- A cost per processed document
- A review-queue throughput figure
- A time to first value, in weeks
- A headcount saved figure
What this costs to own once it works.
Documents change because the people sending them change, and none of that is visible from inside your systems. These four are the running cost, not risks to avoid.
- Any week
A sender changes their template
Extraction keeps returning values from the wrong part of the page and nothing raises its hand. The build should watch the shape of what it reads, so a change surfaces as an alert rather than as a quiet run of odd records.
- Every few months
A shape you have never seen arrives
It lands in the queue as an unknown and the queue absorbs it until somebody decides whether it is worth building for. That decision needs the count from step one kept current, not remembered.
- Within the year
The review team turns over
The person who knew which exceptions were normal has gone and corrections start to drift. Recording why a value was changed, not only that it was, is what survives the handover.
- Without notice
The model or the provider is updated
Output shifts in either direction with no change on your side. The evaluation set from step two is rerun, so the shift is measured rather than argued about in a meeting.
A document system is a standing commitment rather than a delivery. The first year of one is mostly the second and third of these.
What is yours at the end of it.
Six things, and the reason each one matters to somebody who was not in the room when it was decided.
The shape count, and how it was arrived at
Sorted from a real month of your own documents, with the counts and the method. It is what you will use to decide where the line goes next time.
The evaluation set
Documents with agreed correct values, held by you. Every later change is measured against it rather than asserted over it.
The review screen, and why the threshold is where it is
Including the reasoning, because the person who inherits the queue was not in the meeting where the number was chosen.
The original, linked to every record
Retained beside the values read from it, because the question that comes up later is always what the document itself actually said.
The corrections, with their reasons
What a person changed and why. The reasons are the part worth having and the part usually not captured anywhere.
The retention and residency decisions, in writing
How long the source document is kept, how long the derived record is kept, and where each is processed. Three separate decisions, each written down rather than inherited from a default.
Choose the right path
Several services in this set sit next to each other in search. This is the one that starts at the documents themselves and asks how many kinds of them you are holding.
- Our documents are invoices or statements, and the painful part is matching them to an orderFinance and document workflowsReading the invoice is the cheap failure there. That page is about the match and the approval chase, which this one does not cover.
- We hold documents of several kinds and need them to become recordsDocument AI · you are hereThe question here is how many shapes you hold and which of them are worth building for.
- The reading works and the output still ends in a copied messageAI Integration ServicesThe seam between a capability that works and the system that actually runs the business.
- The data behind the documents is the part nobody trustsData Engineering ServicesReading documents faster into a source people already disagree about makes the disagreement faster too.
- The trigger, the decision and the next action are all already definedAI Workflow AutomationRules are cheaper and more reliable than a model when nothing about the work requires judgement.
- We would rather the documents stopped arriving as documentsA conversation about the source, not a serviceUsually the cheapest fix in this whole category and rarely a product. Bring it to the assessment or to a first call.
Send us a month of one document type, unsorted.
Not the clean sample: the real month, including the one your team quietly does by hand. We will tell you which shapes are worth building for and which should stay with a person.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.