From Inbox PDF to Validated Record, Without the Rekeying

It depends on your documents: their quality, layout variety, handwriting, and how many fields you need. Anyone quoting a single accuracy figure before seeing your files is guessing. We measure field level accuracy on a labelled sample of your own documents during the build, show you where errors happen, and set review thresholds with you so that uncertain fields are checked by a person. Validation rules then catch many of the errors that remain.

Typical examples are supplier invoices, receipts, remittances, claim forms, medical certificates, contracts, leases, delivery dockets, bills of lading, bank statements, identity documents, applications and correspondence. Printed, scanned, photographed and handwritten content can all be handled, with handwriting and poor scans generally needing more human review.

A RAG knowledge base answers questions by retrieving passages from a collection of documents. Document processing turns each incoming document into structured, validated data that another system can use, such as an invoice posted to your accounts payable ledger. Some organisations need both, for example contract extraction to populate a register and a knowledge base for questions about contract terms.

If the built in feature handles your documents accurately enough, use it: it is cheaper and already integrated. A custom pipeline is worth it when you have document types the product does not support, need validation against several systems, want control over where documents are processed, or need extraction feeding more than one platform.

In your own cloud account. We can host your data in Australian cloud regions. If your data must stay in Australia, tell us before you sign and we write it into your Schedule of Work. At the time of writing (September 2026), document services such as Amazon Textract have an endpoint in the AWS Sydney region, and extraction with language models can use in region endpoints or a privately deployed model. We document the full data flow, apply retention rules you set and restrict who can view original documents.

Because extraction is based on understanding the content rather than fixed template positions, a new layout usually works without changes. If accuracy drops for a particular source, reviewer corrections and monitoring show it quickly, and we add examples to the evaluation set and adjust.

It can. From 10 December 2026, APP entities must describe in their privacy policies certain decisions made, or substantially assisted, by computer programs using personal information where the decision could significantly affect an individual's rights or interests. Extracting claim data is not itself a decision, but auto approving or declining a claim may be. We map where decisions occur so your privacy team and lawyer can assess disclosure, and keep humans in the loop where you decide it is needed.

Every build is priced on its own scope. It starts with a Discovery Audit (a fixed fee, credited in full against the build). After the audit you get a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete. The option you choose is paid in three stages against work you have accepted. We never publish day rates. Per page processing and model usage are running costs on top, which we estimate from your monthly volumes.

Documents arrive from an inbox, upload or scanner and are converted to text with OCR and layout analysis. Each one is classified by type, the specified fields are extracted by a language model or extraction service, and those fields are validated against business rules and your own records. Anything uncertain or failing a rule goes to a person for review before the data is posted downstream, and reviewer corrections feed back into evaluation.

Yes, invoice data extraction is one of the most common starting points. Header fields, line items, GST and ABN are extracted and checked, matched to purchase orders where you use them, and posted through your accounting system's or ERP's API, with exceptions held for review. Cloud accounting platforms such as Xero and MYOB provide APIs for this; which fields and matching rules apply is agreed in the Discovery Audit.

No. OCR turns an image of text into characters, but it does not know which number is the invoice total or whether it is right. Intelligent document processing uses OCR as its first step, then adds classification, extraction based on what each field means, validation against rules and systems, and human review of uncertain results. That is what lets it cope with many layouts instead of one fixed template.

About 10 weeks for a typical first document type, from inventory and sample labelling to a parallel run and go live. Labelling, schema and rules take the first three weeks, the extraction pipeline, review screen and integration are built through week 8, and accuracy thresholds are set in weeks 7 to 9. A second document type on the same pipeline is usually quicker, because classification, review and integration already exist.

Yes, but only for the fields the system is unsure about. Every field carries a confidence score, and anything below the threshold you set, or failing a business rule, goes to a review screen that shows the value beside the highlighted source. Clean documents pass straight through. You set the thresholds with us from measured accuracy on your own files, and reviewer corrections feed the evaluation set, so thresholds can be revisited as evidence builds.

Yes. Validation rules check that line items sum to the total, that GST is consistent with the amounts and that the ABN passes the ATO's check digit algorithm, and they can confirm a purchase order number exists in your ERP. An invoice that fails any rule is held for review instead of being posted to your ledger. Rules are agreed per document type, so credit notes and statements follow their own path.