AI Document Processing That Never Leaves Australia

Native digital PDFs, Word documents, Excel workbooks, emails with attachments, and images including JPEG, PNG, TIFF and HEIC photographs taken on a phone. Native PDFs are the easiest case because a text layer already exists. Scanned and photographed documents go through an OCR stage first, typically a local OCR engine so the image never leaves your environment, and the model then works on the recognised text plus the page layout. Quality genuinely matters: a clean 300 DPI scan behaves very differently from a photograph taken at an angle in poor light. For low-quality sources we set stricter confidence thresholds and route more documents to human review rather than pretending the extraction is reliable. Handwriting is supported for short fields such as dates, signatures and dockets, but it is far less reliable than print and we treat it as review-required by default.

Accuracy is measured per field rather than per document, because a document is rarely all-right or all-wrong. Before go-live we build a labelled test set from your own documents, typically 200 to 500 samples covering every layout and edge case you can find, and score the pipeline on field-level precision and recall against it. That produces a real number per field: the ABN might sit at 99 percent while a hand-annotated purchase order reference sits at 82 percent. Those numbers set the thresholds. Fields above the threshold post straight through; anything below is queued to a review screen showing the extracted value beside the highlighted region of the source page, so the reviewer verifies rather than re-keys. Corrections are logged and re-scored, which tells you whether accuracy is holding as your document mix changes.

The whole pipeline, covering OCR, embedding, extraction and storage, runs either in an Australian cloud region you control or on your own hardware. No document, page image or extracted field is sent to an overseas AI provider, because the model runs inside your boundary rather than behind someone else's API. That matters for two Australian Privacy Principles in particular. APP 8 holds you accountable for personal information disclosed to an overseas recipient, and sending a document containing personal information to an offshore AI API is a disclosure you need to be able to justify; keeping processing onshore removes the question rather than answering it. APP 11 requires reasonable security steps, which is considerably easier to evidence when you can point to where the data physically sits. It also narrows the assessment you owe the OAIC under the Notifiable Data Breaches scheme if something does go wrong.

Yes. Extraction that stops at a spreadsheet has only moved the re-keying, not removed it. For accounts payable we post to Xero or MYOB through their APIs, creating the bill with the supplier matched, GL codes applied, GST treatment set and the source PDF attached to the transaction so the audit trail stays intact. Purchase-order matching happens before posting, so a mismatch becomes an exception rather than an incorrectly approved bill. For larger environments we integrate with ERPs including NetSuite, TechnologyOne, Pronto and SAP, generally through their APIs or an integration layer you already run. Where you receive Peppol e-invoices through the framework the ATO administers, those already arrive structured and bypass extraction entirely, so this pipeline is for the long tail of PDF and emailed invoices that Peppol has not replaced.

This is where template-based tools break, and it is worth being precise about how an LLM pipeline behaves differently. A template tool matches a layout and returns nothing, or worse plausible garbage, when that layout changes. A language model reads for meaning, so a new supplier's invoice layout is usually handled with no configuration at all, because it is still recognisably an invoice. A genuinely new document class is a different matter: the classifier flags it as unknown rather than forcing it into the nearest schema, and routes it to a review queue instead of posting it. You then decide whether it is a one-off worth handling manually or a class worth defining a schema for, which is configuration rather than redevelopment. Silent coercion of an unknown document into a familiar schema is the failure mode we design against, because it is the one nobody notices.

There are two components and they scale differently. Implementation is a one-time cost driven by the number of document classes and integrations rather than by volume: a single workflow such as accounts payable with one integration typically runs $25,000 to $60,000, while a multi-workflow deployment spanning contracts, invoices and claims with several integrations sits in the $60,000 to $120,000 range. Running cost is where volume shows up, and it is mostly compute rather than per-page licensing: a sovereign cloud-hosted pipeline at moderate daily volume generally runs $800 to $3,000 per month, and processing ten times the documents does not multiply that tenfold, because infrastructure is sized for peak throughput rather than metered per page. That is the structural difference from per-page SaaS pricing, where the bill grows in lockstep with your volume indefinitely.