How do you build an AI workflow for document processing you can check quickly?

You build a document processing workflow in two halves. The first half names the fields you need and asks for each one exactly as printed, with the place in the document it came from. The second half is the check: a way to confirm those values against the source in less time than retyping them would have taken. Most document workflows fail on the second half, because a wrong extracted field doesn't look wrong. It looks like a fact.

That one difference should change how you design the whole job.

TL;DR

• A document has its own truth and you didn't write it, so the failure mode inverts. A draft built from your own notes reads wrong when it's wrong. An extracted field reads right when it's wrong, because it's the right shape sitting in the right box.
• Design the check before the prompt. If confirming the output costs about what the manual work cost, you've moved the work rather than removed it.
• Only process documents that hand you something to check against: an arithmetic relation inside the document, or a second source such as a purchase order, a price list or your supplier record. Documents with neither, contract clauses being the obvious case, need a person reading the source, and should be scoped that way from the beginning rather than discovered later.
• Ask for values as printed, plus a location for each one, and make missing fields visible instead of filled. A flagged blank costs a minute. An invented value costs whatever it flows into.
• Never let the assistant calculate a field you asked it to extract. On an Australian tax invoice the GST amount can legitimately be a statement rather than a number, and one eleventh of the total is simply wrong once the invoice carries GST-free lines. 1
• File the source document, not just the extracted row. Most business records have to be kept for five years, stored so the information can't be changed, and indexed well enough that you can produce them on request. 2
• The tool sits downstream of all of that, and it will be renamed or replaced before your field list changes.

What makes document processing different from your other AI workflows?

The document holds facts you don't already know, which is the entire reason you're reading it.

Most of the workflows we build in a session run on source material the business already owns. In my own business, Searchmaxxed, the proposal workflow runs on facts we wrote and approved ourselves, so when a draft says something wrong, someone in the room recognises it immediately. The same is true of a customer reply or a weekly report. You are the authority on the input, so you are automatically the detector for the output.

Document processing removes that safety net. You don't know the invoice number. You don't know which of the three dates on the page is the invoice date. An extractor that returns a plausible reference of the right length, a date in the right format and a total that looks like a total has produced something that survives every glance a busy person gives it. Then it flows into the accounting system, the payment run and eventually the BAS, quietly, as a number nobody questioned.

AWS puts the commercial case for automating this work plainly: processing documents manually is expensive and time consuming. 3 I agree with that, and it's also why the checking step gets skipped. The saving people imagine is the typing. The saving they actually get is the typing minus the checking, and if you design the check last you find out which one is bigger after the workflow is already in use.

So the interesting design question isn't how to extract. Current models extract well. The question is how a person confirms twenty fields in a minute instead of five, and that answer has to be built into the instructions, not bolted on afterwards. Our general guidance on how to check AI output before anyone uses it applies here too, with one addition: with documents, you're not checking whether the writing is good, you're checking whether a value was copied or invented.

Which documents are worth processing, and which ones aren't?

Process the ones that come with their own answer key.

That's the test almost nobody applies. The standard advice is to start with invoices, and the advice is right, but the reason given is usually volume. Volume isn't what makes invoices the easy case. Invoices are the easy case because they arrive with arithmetic inside them and a second copy of the truth outside them. The line items add up to a subtotal. The purchase order already says what you agreed to pay. Your supplier record already holds the ABN and the bank details. Three independent ways to catch a wrong value before a human reads a single page.

Run a document type through five gates before you build anything:

Insurance sits in the harder half of that table. AWS describes extraction in insurance as particularly challenging because quotes, forms, claims and receipts arrive in varying layouts and formats. 3 Lending has the same problem for a different reason, with incomplete loan packages, tax forms and payslips creating more work when data turns up missing during underwriting. 3 Both still pass the answer-key gate, because the numbers reconcile against something.

Contracts are the honest failure. AWS notes that contractual documents often arrive in non-standardised formats, and that reviewing legal filings means loading, reading and extracting the case number, parties and legal entities by hand. 3 Pull the notice period out of a services agreement and there is no purchase order to compare it against, no sum that has to balance, and no second copy anywhere in your business. The only check is a person reading clause 14. That doesn't make the workflow pointless. It makes it a different workflow, one where the output is a reviewer's shortlist with a page reference rather than a field ready to use, which is roughly how we'd scope it for an AI workshop with a law firm.

Two more categories fail the gates outright. One-off documents never earn their setup, no matter how painful the one-off felt. And a surprising amount of what people call document work isn't extraction at all. It's an email with something attached, where the job is the reply and the attachment is context. That belongs in an AI workflow for handling business enquiries instead, because the output is a message to a person, not a row in a system.

What fields should you ask for, and how should you name them?

Name the fields a decision needs, using the labels the document actually prints, and stop there.

The principle comes from a different part of my work. What made the managed search loop we built at Searchmaxxed work wasn't collecting more data about a site's search presence. It was connecting that data into one process that could make a recommendation about what to do next. Information that couldn't change the next action didn't need to be in the loop. Document extraction rewards the same discipline. Every field you add is a field someone has to check, forever, so a field that changes nothing is a permanent tax with no return.

For an Australian supplier invoice, the decision is whether to approve it for payment and how to code it, and the field list mostly writes itself from the law. A tax invoice for a taxable sale under $1,000 has to carry enough information to determine seven things: that the document is intended to be a tax invoice, the seller's identity, the seller's ABN, the date it was issued, a brief description of the items including quantity and price where applicable, the GST amount payable if any, and the extent to which each sale on the invoice is taxable. 1 At $1,000 or more it also has to show the buyer's identity or ABN. 1 That's not a suggested field list from a vendor blog. It's the set of things that has to be on the page, which means it's the set you can reasonably expect an extractor to find.

Then name each field the way the document names it. If the page says "Invoice No.", don't ask for reference_number and hope. Ambiguous field names are where the right answer to the wrong question comes from, and Snowflake's own guide flags the same risk from the other direction, noting that for some extraction questions multiple answers might be correct. 4

Three rules do most of the work in this half of the job:

• As printed, not as interpreted. Ask for the characters on the page. Date formatting, currency symbols and abbreviations get normalised later by something deterministic, not by a model making a judgement you can't see.
• Missing stays missing. Any field the assistant can't locate comes back explicitly empty with a note, never filled from context. This is the single highest-value instruction in a document workflow, because it converts an expensive silent error into a cheap visible one.
• Location with every value. Page number and the printed label it sat next to. This is what turns checking from reading into looking.

How do you check extracted values against the source without re-reading the document?

You stack four checks in order of cost, and only the last one involves reading.

Check one is free, and it runs on the extracted values alone. Line items sum to the subtotal. Subtotal excluding GST equals the total. The invoice date isn't after today. The PO number matches the format your POs use. None of this needs the document or a person, and it catches the ordinary transcription failures, a digit read wrong or a line missed, before anyone opens the file.

One warning on the arithmetic, because it decides whether people trust your flags. GST rounding has more than one legal answer. Where a tax invoice has multiple taxable sales, the ATO describes two approaches, the total invoice rule and the taxable supply rule, and you and your customer don't have to use the same one. 1 So a recomputed total can differ from the printed total by a cent without anything being wrong. Build a tolerance of a cent or two into the check. A flag that cries wolf twice a week is a flag your team learns to click past, and then you have a check on paper and no check in practice.

Check two is cheap, and it runs against what you already hold. Supplier name and ABN against your supplier list. PO number against the open PO. Unit price against the agreed price. Quantity against the delivery docket. One operational rule belongs here permanently: bank details get compared against the account you already hold for that supplier, never accepted from the document, because an invoice that arrives with new payment details is precisely the document you don't want a fast automated workflow to process obediently.

Check three is a lookup rather than a read, which is the whole point of asking for locations. With a page number and the printed label attached to each value, confirming a field means opening one page and glancing at one line. Snowflake's document guide does this in product form twice over: a Locate Answer control that shows where in the document the model found its answer, and a review screen that puts the extracted values beside the rendered PDF page so a person can approve or clear each one. 4 You don't need their platform to copy the idea. You need the location in the output.

Check four is expensive and sometimes unavoidable. A person reads the document. Reserve it for two things: the handful of fields where a wrong value can't be recovered, and a small permanent sample of everything else.

That sample is the part people drop first and shouldn't. Confidence scores are tempting as a substitute. Snowflake's example verification app only surfaces fields that are missing or that score below a threshold, with 0.5 used in their walkthrough. 4 Triaging that way is sensible and it will save you real time. It also can't find your systematic errors, because a confidence score is the model's confidence in its own answer, not a measurement of whether the answer is right. A field that is confidently and consistently wrong scores well every time. Ten documents a month read properly, chosen at random, is what finds that. Keep doing it after the workflow feels reliable, which is exactly when it stops being watched.

I'd also treat any claim that a model removes the review step as marketing rather than engineering. AWS writes that generative AI can identify and secure sensitive data at scale and "guarantees adherence to evolving industry regulations - without needing manual reviews". 3 Read that as a description of ambition. Nothing in the technology transfers the obligation to have the records right, and the obligation is where your exposure sits.

The errors that survive all four checks

Four of them, and knowing their shapes is most of the skill.

The right answer to the wrong question. Snowflake's guide walks its reader through this exact moment: while reviewing a training document, the extracted payment terms are wrong "since it is a schedule, so it should be cleared". 4 Real text, from the correct document, confidently returned, sitting in the wrong field. Arithmetic won't catch it. A second source won't catch it. It only surfaces when somebody reads the page, which is the argument for the sample.

The calculated value wearing an extracted value's clothes. Ask for "GST amount" and most assistants will give you a number every time. But the ATO allows the GST to be shown either separately or, where it's exactly one eleventh of the total price, as a statement reading "Total price includes GST". 1 So on a compliant invoice with no GST figure printed anywhere, the model divides by eleven and hands you a number that is usually correct. It's wrong the moment a line on that invoice is GST-free, and a tax invoice covering taxable and non-taxable items has to show which items are taxable. 1 Two fields fix this: what was printed, and whether it was printed at all.

The document that was really two documents. Google's Document AI includes a splitter for composite files, and the example they give is a mortgage package containing an application, income verification and a photo ID. 5 If your workflow assumes one document per file, page four silently becomes part of page three's answer and every field after the join is drawn from the wrong paperwork. Check the page count against what you expected. It's a one-line check and it catches a whole category.

The classifier keyed to a signal that isn't reliable. Sorting invoices by looking for the words "tax invoice" seems safe until eInvoicing arrives. The ATO notes that some eInvoices may not include words such as "Tax Invoice", and still satisfy the requirement when issued under the Peppol specification with all the mandatory data. 1 A workflow built on the heading misfiles those, and misfiled documents are worse than failed ones because nothing alerts you.

There's a fifth thing to be sceptical about, which isn't an error in your workflow but in your evidence. Vendor write-ups on this subject are full of numbers with nothing attached to them. One states that a global technology company automated invoice processing and achieved a 50% reduction in processing time with a significant decrease in errors. 6 No company, no baseline, no method, no way to tell whether the comparison included the checking time.

I'd hold my own experience to the same standard. I previously worked at Radiant Roof Repairs, where we helped automate internal processes with AI, and that work doesn't give me a saving to quote at you for invoices or claims. Measure your own before and after on your own documents, with the checking time included. It's the only figure that will still stand up when someone asks you where it came from.

What does the whole workflow look like written down?

Five inputs, and the rules section carries most of the weight.

We teach a workflow as the five inputs of Context, Task, Source, Rules and Output, and the reason it works for documents is that it forces the check into the instructions rather than leaving it in someone's head. Written out for supplier invoices, it reads roughly like this.

Context. We're a Sunshine Coast service business checking supplier invoices before payment. Purchases are raised against a purchase order and coded to a job.

Task. Read the attached invoice and return the fields we approve against, with a location for each value.

Source. The attached invoice, the matching purchase order, and our supplier list. Nothing else.

Rules. Copy every value exactly as printed. If a value isn't on the page, return it empty with a short note saying what you looked for. Don't calculate any field, including GST: if the invoice states that the total includes GST without printing an amount, record that statement as the value. Give the page number and the printed label beside every value. Flag any line that isn't clearly taxable. Don't read payment details.

Output. A table of the named fields with value, page and printed label, then a list of blanks and flags for me to resolve.

Read those rules again. Every one of them is about control rather than capability: copy instead of interpret, show the gaps, keep values checkable, and stay away from the one field you never want an automated workflow touching. Not one of them tries to get more out of the document. That ratio is what a document workflow looks like when it's designed properly, and it's the part that transfers to claim forms, statements, delivery dockets and remittance advices without being rewritten.

The gaps the workflow flags need somewhere to go, too. Incomplete paperwork is usually a client or supplier problem rather than a model problem, which is why chasing it deserves its own process, the same way an accounting firm's document request workflow handles the documents that never arrived in the first place.

The tool choice matters later than the field list

It starts to matter when volume changes the arithmetic, and not much before that.

I'm not going to hand you a ranked list of extraction products, and it isn't modesty. Look at what happened to the most detailed walkthrough I read while researching this. Snowflake's document processing guide now opens with a notice that the feature it teaches has been deprecated in favour of a successor called AI_EXTRACT, and closes by saying the content is provided as is, is not maintained on an ongoing basis, and may be out of date. 4 That page was updated in March 2026. Any article that ranked tools for you would have aged the same way, while the field list, the rules and the four checks above would still be sitting on your screen unchanged.

What does change the decision is the arithmetic of scale. Google lists Document AI pricing by the page: $1.50 per 1,000 pages for its OCR processor and $30 per 1,000 pages for its custom extractor. 5 Check the current figure for your own region and currency before you plan around it, but the shape of the number is the point. Machine extraction costs cents per document. Your cost is the review queue and the connection into your systems. You are not buying extraction. You're buying somewhere for a person to confirm things quickly, which is why the check is the product and the model is a component.

Two signals tell you when to graduate from a general assistant plus a written workflow to a dedicated pipeline. The first is that you have enough examples to train on: Google says you can improve accuracy by providing as few as 10 documents to fine-tune, while Snowflake's guide recommends at least 20 for a build and uses 5 only to keep the walkthrough short. 5 4 If you can't assemble twenty representative documents of one type, you don't have a volume problem yet. The second is that the same document type keeps beating a carefully written workflow after you've fixed the field names and the rules. That's a real signal. The version where the instructions were vague and everyone blamed the model is not.

How do you hand it to a team and keep it honest?

Give the workflow an owner, a filing rule and a sample, and treat the source document as the record.

The filing rule is the part most homemade workflows get wrong, and it isn't a preference. Australian businesses are legally required to keep records of transactions relating to their tax, super and registration affairs, and the ATO's rules are specific: the relevant information in your records must not be changed and must be stored so it can't be altered or damaged, you need to keep most records for five years, you need to be able to show them on request, and stored data has to be identifiable, labelled or indexed. 2 An extracted row in a spreadsheet satisfies none of that on its own. So the workflow has to file the original document and make the extracted row point back at it. Get that right and the check stays possible in two years, when someone asks why a number is what it is.

Then three habits, none of which take long:

• One named reviewer per document type. Not the team. A person, who approves before the data is used, and whose approval is recorded with a date. Snowflake's verification example stores exactly that, a file name and a verification timestamp, which is a reasonable model to copy in whatever system you already use. 4
• An error log with two columns. What was wrong, and which rule would have caught it. Most entries turn into one added sentence in the Rules section. A log without the second column becomes a list of complaints.
• The monthly sample, permanently. Ten documents read properly against their extracted values. This is also how you find out that a supplier changed their invoice template three weeks ago.

Bring people into that habit early, because the workflow that survives is the one the team helped write and knows how to break. That's the same reason we run training on your own documents with a safe example rather than a demo file, and why it helps to think about which of your documents are safe to use as training material before the session. The rest of the discipline is ordinary maintenance, and the general version of it is in our guide to testing and maintaining an AI workflow.

Where can you get help building your document workflow?

Two ways, depending on whether you want your team to own the build or you want it built for you.

The public Sunshine Coast workshop runs for a full day, in person, at A$495 excluding GST per person, with a maximum of 15 paid attendees. The venue is confirmed as the Avani Mooloolaba Beach Hotel, The Cove room, in Mooloolaba, and the next date is Wednesday 7 October 2026, so the registration is the way in for now. Bring a laptop, a charger and one safe example of the document task you want to fix. You leave with the written workflow you built and tested, not notes to write up later.

For a team, we bring private onsite AI training to your workplace. It's scoped in a conversation about your team's tasks, locations and experience first, then quoted as a fixed price, and it's usually sized for roughly 4 to 20 people with larger teams split across sessions.

Some businesses don't want to build it at all, and that's a fair answer for a document workflow that has to connect into an accounting or job management system. We also do implementation, where the workflow gets built and connected for you. It's a separate engagement from training, with its own scope and price, so the starting point is the same enquiry and a conversation about which of the two you actually want.

Frequently asked questions