Intelligent Document Processing

Intelligent document processing reads invoices, dockets, forms and PDFs and turns them into data, without a person typing them in. CodeFish builds it for Australian operators whose suppliers send the same information in fifty different layouts.

What is intelligent document processing?

Intelligent document processing (IDP) is software that reads a document, works out what kind of document it is, pulls out the fields that matter, checks them against your records, and writes them into your systems — without a person retyping anything.

We build document processing for Australian mid-market operators, most often in logistics, manufacturing, food and construction, where a supplier network sends the same information in fifty different layouts. The job it replaces is always the same: somebody with a PDF open on one screen and a data-entry form on the other.

The part that matters commercially is not the reading. It is what happens when the document is wrong, unreadable, or does not match the order — because that is where the money actually leaks.

The four documents worth automating first

These four carry the most manual handling in an Australian operations business, and each has a measurable error cost when it is done by hand.

Supplier invoices

Read the header and the line items, match them to the purchase order and the receipt, flag the ones that do not agree. This is the highest-volume document in most businesses and the one where overpayment is invisible until someone checks.

Delivery dockets and proof of delivery

Signed, photographed, sometimes handwritten, often the only evidence a delivery happened. Automated capture matches the docket to the job and the invoice, which is what stops a credit note six weeks later.

Compliance and certification documents

Inductions, insurances, licences, test certificates, safety data sheets. The value is not the data entry — it is knowing before someone starts work that a document is missing or expired.

Forms filled in by hand

Field reports, inspections, timesheets, applications. Anything captured on paper because the job happens away from a desk, then typed up by someone at one.

How is this different from OCR?

OCR converts an image into text; intelligent document processing understands what the text means. Traditional OCR and template-based capture depend on the value sitting in the same place every time, so a new supplier layout — or a scan two degrees crooked — breaks the extraction and someone fixes it by hand.

Model-based processing reads the document the way a person does: it finds the invoice total because it understands what a total is, not because it was told the total lives at those coordinates. That is why it holds up across hundreds of supplier formats without a template for each one.

The honest limit: no system reads every document correctly. A build that does not route low-confidence documents to a person for a two-second check is a build that will quietly put wrong numbers into your ledger.

Nobody should still be typing numbers off a PDF into your system.

What document data extraction actually involves

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.

Is document processing worth doing for your documents?

Volume decides it: at a handful of invoices a week a person is cheaper; at hundreds the case makes itself. Consistency decides the rest, since a few known layouts are simple and handwritten dockets are slower. Where a wrong value flows into your accounts unchecked, validation matters more than extraction.

Check the cheaper answer first: a supplier who sends a structured file, or a portal where data is entered directly, removes the problem. We will say so when that path is open.

What does intelligent document processing cost, and how is it justified?

Document processing is one of the easier investments to justify, because both sides of the sum are already measurable: minutes per document times volume, plus the error cost you can see in credit notes, duplicate payments and rework. A Rapid Insight Workshop at a fixed $9,000 + GST looks at a real sample of your documents — not a clean one — puts numbers against both, and says whether the build clears the bar.

The build cost is driven by variety, not volume. One document type in three layouts is a short project. Fifteen types from two hundred suppliers is a programme, and it is worth doing the highest-volume two or three first and measuring before committing to the rest. A defined build is quoted fixed-price as an Amplify project; where document volumes and formats keep shifting, it runs inside an Apex partnership.

Running costs are per document and small. The ongoing cost that matters is the exception queue: the person-time spent checking what the system was unsure about. If that is not falling over the first few months, the thresholds or the capture need work. You own the code, the extracted data, and the IP.

How a document processing project runs

Sample the real documents (1 week)

We take a few hundred of your actual documents — the messy ones included — and measure what proportion can be read reliably. That sample sets the accuracy expectation before anyone commits to a build.

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

Build extraction plus the exception path (4–8 weeks)

Extraction, validation against your own records, write-back into your systems, and a review queue for anything below the confidence threshold. The review queue is built first, not last.

CodeFish Studio team members in a workshop

Run both, then switch

The automation runs alongside the manual process until the numbers agree, then the manual process stops. We measure minutes per document and the error rate before and after.

A hand on a laptop showing a colour-coded project Gantt schedule, with the same view on a wall screen

Document processing questions we get asked

"99% accurate" means nothing on its own — accuracy on which field, on which documents, and what happens to the other 1%? A useful system reports its own confidence per field, auto-processes what clears the threshold, and sends the rest to a person. The number to negotiate is the share of documents that need human review, not a headline accuracy figure.

When a document does not match the order, or a field cannot be read, something has to happen. If that path is not designed, the exceptions pile up in a folder and the manual process continues alongside the automation — with the automation now adding work rather than removing it.

Pulling data out of a PDF is half the job. If the numbers are not written into the finance or operations system, matched against the order, and reconciled, a person is still doing the part that takes the time. The value is in the write-back, not the read.

Low-volume document handling is often cheaper to leave with a person and a good template, however annoying it is. The case turns on two numbers: how many documents a month, and what an error costs when it happens. Both get measured in the workshop before a build is quoted, because a document automation that saves a few minutes a week will never pay for itself.

On clean digital invoices, field-level extraction is typically in the high nineties; on photographed or handwritten documents it is materially lower. The right way to buy it is not on a headline accuracy number but on the share of documents that clear a confidence threshold and process without a person — measured on your own documents during scoping, not on a vendor's demo set.

Usually nothing breaks, because the system reads the fields by meaning rather than by position on the page. A supplier who moves the total, adds a logo or switches accounting packages still sends an invoice with a total, an ABN and line items, and the model finds them. What can drop is confidence: the first few invoices in a new layout may score lower and go to the review queue for a quick check. If one supplier keeps landing there, we look at why and adjust the rules for that supplier, rather than building a new template from scratch.

Whoever keys the documents by hand today, usually someone in accounts payable or the operations admin team. They already know what a correct invoice or docket looks like, so they are the right person to confirm what the system was unsure about. Each item shows the document beside the extracted values, so most checks take seconds, not minutes. In the first weeks the queue is larger while thresholds are tuned on your real documents. The goal is that it shrinks month by month, and we track its size and the time spent on it as part of the before-and-after numbers.

Sometimes, and never as reliably as print. Handwritten numbers on a field form can usually be read well enough to be checked by a person in seconds rather than typed from scratch. If handwriting is the bulk of your volume, the better project is often moving the capture to a phone form at the source, and we will say so.

That is a design decision made up front. Processing can run in an Australian region, in an environment you control, with a contractual guarantee that your documents are not used to train anyone else's model. For businesses with privacy, ISO or customer contractual obligations, this gets decided before the architecture, not after.

Four to eight weeks for the first document type once we have a real sample and access to the target system. Additional document types after that are faster, because the validation and write-back plumbing already exists.

Ask them to run your worst documents, not their sample set. Ask what proportion needed human review and where those documents went. Ask whether the data gets written back into your systems or just extracted. And check that you own the extracted data and the code — some platforms keep your document history inside their product.

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.

If you process one standard document type — invoices into a mainstream accounting package — buy the product; that market is mature and cheap. Build when the document mix is unusual, when the validation depends on your own operational rules, or when the write-back target is a system no product supports. We will point you at the product where a product fits.