Structured data out of documents
Somebody here retypes numbers out of PDFs all week.
Invoices, orders and forms become data your systems can use, measured on documents the system has never seen.
Design around the documents you actually receive.
Document formats vary by supplier, and fields may be incomplete or inconsistent. We test on the documents your team actually receives, agree field by field what a correct result is, and route exceptions to a named reviewer.
What we would ask you first
Could your team mark a sample that includes the documents they usually fix by hand?
Talk it throughWhat we usually hear first.
“Data is trapped in PDFs and being retyped.”
If the same fields are keyed from the same layout every week, that cost is measurable and fixable.
“We looked at OCR years ago and it was not good enough.”
Variable layouts are the key test. We would assess current extraction tools against a sample of your documents.
“The errors only show up much later, in the accounts.”
By then somebody has to trace each wrong figure back to the document it came from.
“Volumes went up and we added a person.”
The hours that person spends keying can be measured and set against a scoped extraction workflow.
Reliable extraction starts with real documents.
Built to be checked
Before we build, we agree with you what happens to a document the system is unsure of.
A real sample
The sample includes changing layouts, incomplete fields and the cases your team currently reviews by hand.
Agreeing what correct means
We agree the expected value for each field with your team, including checks they already apply during review.
Values you can check
Extracted values are checked against things that must be true, such as totals that add up.
A route for exceptions
Anything the system is unsure of goes to a person, with the document and the value side by side.
What this needs before it starts.
The sample, review criteria and destination for the data need to be agreed before work begins.
- A representative sample you can share, including variable layouts and cases currently reviewed by hand.
- A subject matter expert who can confirm the correct value for each field.
- A destination for the extracted data, such as a system, database or structured import.
If it is not there
If nobody can own the review, we agree who will before any build work starts.
What you have at the end.
- A working extraction pipeline
- Documents go in and structured data comes out, connected to the system that needed it.
- Accuracy, measured per field
- Each field is measured on documents the system has never seen, with the sample size and the date.
- The exception queue
- Documents it is unsure of wait in one place for a named person to check.
- A way to test it again
- The marked sample is kept, so the pipeline can be retested when a supplier changes a layout.
Where this page sits.
Our work sits in three layers, and each one depends on the one beneath it. The page you are reading is marked.
You are hereDocument Extraction
AI
- AI Adoption & Data Strategy
- AI Solution Packages
- You are here Document Extraction
- Document Analysis
- Proposal Workflows
If manual document entry is slowing the work, start here.
Share a representative sample, including variable layouts and fields your team checks by hand. We can assess whether extraction is a good fit.