Intelligent Document Processing

"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.