How document data extraction works

Invoices, delivery dockets, purchase orders, certificates — most businesses still move information off paper and PDFs by hand. This is the guide to reading documents automatically, and to what it takes to trust the result.

The document is not the problem. The retyping is.

What is document data extraction?

A designer reviewing a website layout in Figma on a large monitor

Read each document once, by software, and check it.

Intelligent document processing reads invoices, delivery dockets, purchase orders and certificates, pulls out the fields that matter and puts them into your ERP or accounting system. Today someone reads each one and retypes it, which is slow, expensive and where the errors start. Reading the page is mostly solved; the real work is the checks that catch a wrong value before it reaches your accounts. You get the hours back and stop paying wrong amounts.

Is document processing worth it for you?

Volume, variety and the cost of a wrong value decide it.

Worth it: hundreds a week

The same document types arrive in the hundreds each week. At that volume the retyping is a real cost, and removing it pays back.

Worth it: a few layouts

Documents come in a handful of recognisable formats, so extraction gets reliable quickly and the project stays short.

Not yet: a handful a week

A person rekeying a few documents is cheaper than the setup, and the setup cost will not come back.

Not yet: suppliers could send data

If suppliers can send e-invoices over the Peppol network, which the ATO administers, the data arrives structured. Turn that on first and there is nothing left to read.

What does document processing actually involve?

Reading the page is one step of six. The rest is what makes the result trustworthy.

Getting the document in

Email inboxes, scanners, supplier portals, photos from a phone. Capture is unglamorous and it decides your input quality — a straight scan and a creased photo are not the same problem.

Reading the page

Turning the image into characters. On clean, consistent documents this is close to solved; on handwriting and crumpled dockets it is not, and no vendor demo uses those.

Understanding the fields

Which number is the total, which date is the delivery date, which lines belong to which order. This is the part that separates document processing from plain scanning.

Checking against what you know

An invoice matched to the purchase order and the receipt. Validation against your own data catches more errors than any accuracy score, because it tests the meaning rather than the reading.

A queue for the unsure

Low-confidence extractions routed to a person with the document and the values side by side. Fast to check, and over time it tells you exactly where the process needs work.

The honest constraint

Accurate enough to be useful is not accurate enough to be unsupervised. The design question is never whether it will be wrong, it is what happens when it is.

How long does a document processing project take?

Take a real sample (1–2 weeks)

Several hundred documents as they actually arrive, including the bad scans and the one supplier who sends photographs. A sample of clean examples produces a number that will not survive production.

A CodeFish developer reviewing a project's commit history on screen

Extract, then validate (4–6 weeks)

Fields pulled and checked against your own records — invoice to purchase order, docket to delivery. The validation catches what a confidence score cannot, because it tests the meaning.

A CodeFish developer working across three monitors, reviewing code and version history

Set the threshold, work the queue

Confidence tuned so the right proportion goes to a person, and the queue reviewed as the measure of health. The exceptions show you which suppliers or layouts to fix next.

Two CodeFish team members in discussion across a meeting room table, one taking notes

What does document processing cost?

It starts with a Rapid Insight Workshop at a fixed $9,000 + GST. We take a real sample of your documents, including the bad scans, count the volume and the handling time, and say which document types are worth automating. Variety moves the price, not volume: one document type in three layouts is a short project, while fifteen types from two hundred suppliers is a programme that starts with the top two or three. You know what the first document type costs, and what it saves, before any build starts.

Document processing questions we get asked

Accurate enough to be useful is not the same as accurate enough to be unsupervised. On clean, consistent documents the extraction is very good; on photographs of creased dockets it is not. The design question is what happens to the ones it is unsure about — the answer should always be a person, not a guess.

OCR turns an image into characters. That is the easy half. The work is understanding what those characters mean — which number is the total, which date is the delivery date, which line items belong to which order — and reconciling that against what your systems already know.

They go to a person, which is the point. A well-built process routes the uncertain cases to a queue with the document and the extracted values side by side, so checking is quick. Over time that queue tells you exactly where the process needs work.

Through the same integration work any other system needs — the extracted values land as a draft transaction for approval, matched against the purchase order where there is one. The extraction is only half the saving; the other half is not rekeying the result into the system that needed it.

Per document, and the amount is small. The cost that decides whether the project pays off is the exception queue — the person-time spent checking what the system was unsure about. If that time is not falling over the first few months, the thresholds or the document capture need work.

Ready to build something great?

Local partners, global standards – full service design and development.