Document intelligence,
when software reads the paperwork.

Document intelligence is software that reads documents and turns what they say into structured, usable meaning. Fed a supplier invoice, it produces the supplier, the line items, the amounts and the job codes, not a picture of them. Fed a drawing, it produces measurable geometry, the walls, areas and counts that takeoff is built from. Fed a contract, it produces obligations, allowances and dates. The document stays what it always was; the output is the facts inside it, in a form the rest of the business can work with.

Defined precisely, it sits between two things it is often confused with. Document management stores and organises files, so it knows where the PDF is. Optical character recognition (OCR) turns an image into text, so it knows what characters the page contains. Document intelligence knows what the document means for the job, and connects that meaning to the records it describes. It is one layer of the wider stack covered in the construction intelligence reference, the layer that turns paperwork into data the other layers can reason over.

Why it matters

A building business runs on documents. Nearly every fact a job depends on, what was quoted, what was ordered, what arrived, what is owed, what was promised, enters the business as a document, and in most businesses a person then re-types it. That transcription is hours of admin every week, it introduces its own errors, and whatever is not re-typed is effectively buried, correct and complete and unusable inside a PDF. The practical promise of document intelligence is blunt. The business already owns most of the information it needs; the category exists to stop that information being sealed inside its own paperwork.

Reading a bank statement is a solved problem, because bank statements are consistent. Construction is close to the opposite. Every supplier formats invoices differently, and the same supplier changes layout without notice. Quotes arrive as PDFs, email text and photographed spreadsheets. Dockets are carbon paper signed on a ute bonnet, then photographed at an angle. Drawings are superseded by revisions, so the current fact depends on knowing which sheet is current (see drawing revision control). And the language is trade shorthand, abbreviations, units and allowance terms that mean nothing to a generic reader and something exact to a builder.

The deeper difficulty is that the same fact is expressed differently across documents. One window exists in the floor plan, the elevations, the window schedule, the specification and the supplier's quote, described five different ways, and a useful system has to recognise them as one thing. The full document set a residential job produces, and what each document is actually for, is covered in construction documents. Reading any one of them is an extraction problem; reconciling them against each other, which is what disciplines like invoice matching do by hand, is where document intelligence starts paying for itself.

The useful question about document AI is not whether it is impressive but whether it is checkable. Every demonstration is impressive; the job is run on the boring Tuesday when the extraction is wrong. A builder does not need the software to be right every time. They need to see instantly when it is wrong, because a visible error costs thirty seconds and an invisible one costs money for months. Operators who have run these systems well describe trust as something the software earns one approved invoice at a time, and the earning mechanism is evidence, the system showing where each number came from, every time, until checking it becomes fast and boring.

That standard changes how experienced buyers evaluate. They trial on their own worst documents, not the vendor's samples. They watch what the system does when it is unsure, because a system that flags uncertainty is safer than one that guesses with confidence. And they time the verification, not the extraction, because the reviewer's minute per document is the real cost the category is supposed to remove.

What this looks like in a working system

Accounts payable is the workflow where most builders meet document intelligence first, because invoices are frequent, roughly consistent and expensive to key by hand. In VIABUILD, supplier invoices land in a dedicated accounts inbox, where Oryn™ reads the line items, recognises the supplier, matches the invoice to its purchase order and proposes the job and cost coding. The reviewer sees a queue with the match and the coding visible, lines that do not agree are flagged for a decision, and nothing posts on the system's say-so; a person approves every bill. The mechanics are on the accounts payable module page, and the wider payables process it sits inside is covered in the accounts payable guide.

These questions are vendor-neutral and apply to any product in the category, including VIABUILD. They fit inside the wider evaluation framework in choosing construction software, and a vendor comfortable answering all five plainly is telling you something as useful as the answers themselves.

• Can I see where this number came from? Ask to be shown the source document, page and line behind an extracted fact, live, on a document of yours.
• What happens when it is wrong? Watch an error being found and corrected. If wrong answers are hard to locate or awkward to fix, that is the product you are buying.
• Does a correction teach the system? Fix the same miscoding twice in a trial. If the second fix was needed, corrections are labour, not learning.
• Does my data train someone else's model? Where documents are stored, what trains shared models and what you can export on exit are contract terms, not marketing answers.
• What does it refuse to guess at? A system that lowers its confidence and hands a document to a person is safer than one that has never met a document it could not read.

Honest limits

Some limits belong to the whole category, and a vendor who denies them is describing a demo. Handwriting and degraded scans read unevenly, and the failure mode to look for is confident guessing rather than a flag. Ambiguous scope descriptions, the one-line quote that says supply and install to plans, cannot be made precise by extraction, because the precision was never in the document. And judgement calls are not extraction problems at all. Whether a variation is justified, whether a claimed quantity is plausible, whether an allowance is realistic, these are decisions the paperwork informs and a person makes. Document intelligence done well shrinks the transcription; it does not, and should not, shrink the judgement.

Document intelligence itself is not regulated as a category, but the documents it reads are, and Australian conditions shape what a system has to handle. The points below are labelled by evidence class; requirements change and differ by jurisdiction, so confirm the current source before relying on any of them.

• Government guidance. The ATO defines what a document must contain to be a valid tax invoice for GST purposes, which makes supplier invoices one of the more predictable document classes in the business. That predictability is a large part of why invoices are usually where document intelligence is adopted first. Confirm the current requirements at ato.gov.au.
• Legislation. Each state and territory's domestic building contract legislation prescribes content for residential building contracts, and the prescribed forms and disclosure rules differ by jurisdiction. A system reading contract obligations and allowances is reading against your state's form, and its output still needs checking against the current legislation, not treated as a legal reading.
• Common practice. The Australian residential document set is a mix of formats by nature. Architect PDFs, engineering drawings, supplier price files, photographed dockets and email quotes all describe the same job. Any evaluation should therefore run on your real document set, because performance on clean documents predicts very little about performance on yours.
• Professional recommendation. Construction documents carry personal and commercially sensitive information, and Australian privacy obligations can apply to personal information they contain. Where documents are stored, who can access them and what trains shared models belong in the vendor contract review before anything is uploaded; confirm current obligations with OAIC guidance or your adviser.

Illustrative only, not a benchmark. A frame-stage timber invoice arrives by email, 22 lines, $18,400 plus GST. A system built on the principles above recognises the supplier, reads the lines, and matches 20 of them to the purchase order. Two lines are flagged, a delivery fee that was not on the order and a rate above the PO rate on LVL beams. The reviewer opens the first flag and sees the invoice line beside the order line, decides the delivery fee is legitimate and codes it to cartage, then disputes the beam rate with the source evidence already in hand. Total review time is a couple of minutes, spent entirely on the two lines that deserved a human.

The same invoice keyed by hand is ten minutes of typing at night, no flag on the beam rate because nobody compared it to the order, and a price rise absorbed without a decision. The difference is not that the software was clever; both flagged lines still needed a person. The difference is where the person's minutes went, verification and judgement instead of transcription, and that the delivery fee correction is remembered so next month's invoice from the same supplier arrives already coded.

Document intelligence (software that reads documents into structured meaning), OCR (turning an image of a page into characters), extraction (pulling specific facts from a document), classification (deciding what kind of document something is), deterministic method (a rule that gives the same answer every time), probabilistic model (a system that interprets and can be wrong), confidence (the system's own estimate of how sure it is), traceability (a fact pointing back to its source in the document), human-in-the-loop (a person approving before anything becomes a record), correction loop (fixes teaching the system). The wider vocabulary lives in the construction glossary. From here, the natural next article is construction knowledge, which asks what happens to everything the documents and the corrections teach, and how a business keeps what it learns.

• Australian Taxation Office , the current content requirements for tax invoices, the document class most document intelligence adoption starts with.
• Office of the Australian Information Commissioner , current guidance on privacy obligations that can apply to personal information in business documents.
• Your state or territory's domestic building contract legislation and regulator, for the prescribed contract content any contract-reading output must be checked against.