Treat AI document capture as a proposal, not a transaction

Faster capture moves the bottleneck to verification

On July 2, 2026, Xero introduced Smart Document Capture as a beta for selected Australian and New Zealand customers, describing invoice and receipt extraction and transaction matching in about 30 seconds. On August 19, it announced additional JAX capabilities around document requests, bank reconciliation, and exception handling. These releases are product signals, not permission to remove accounting controls.

The operational gain is real. An accounts team should not spend its best judgment typing a supplier name, date, invoice number, and total that software can read. Yet fast extraction changes the shape of the work: the team receives more proposed records, sooner, and must decide which can follow a standard route and which need investigation. If the verification design is vague, automation merely accelerates bad data toward reconciliation, payment, tax, and the ledger.

Xero's August update on Auto Bank Reconciliation illustrates a useful product boundary. It says the system only auto-reconciles high-confidence matches, exposes the matching method, permits edits, and does not handle every transaction. Those are sensible interface cues. They still do not establish that a document is authentic, complete, correctly classified, free of duplicates, or appropriate for a particular accounting period.

Current practitioner discussion supplies the caution. In an August r/Accounting thread, one commenter described spending an hour correcting figures exported to Excel by an AI file processor. A single anecdote cannot measure error rates, but it captures the failure pattern this guide addresses: a polished structured file can conceal a bad read, and downstream formatting can make the proposal look more authoritative than the source warrants.

Use six evidence states instead of one editable record

A common implementation mistake is to let the extracted record become the accounting record immediately. That destroys the distinction between what the document contained, what the system proposed, what a person corrected, and what was ultimately approved. A defensible design preserves six states.

1. Original evidence: the received PDF, image, email attachment, statement, contract, or receipt, with provenance and an immutable identifier.
2. Machine proposal: extracted fields, coordinates, confidence metadata, processing version, and suggested matches.
3. Verification record: field comparisons, recalculations, duplicate tests, match evidence, corrections, and reviewer identity.
4. Exception resolution: retained contradictory evidence, policy decision, owner, approval, and rationale.
5. Release candidate: a locked, versioned export with control totals and a digest.
6. Downstream result: imported record, approved bill, reconciliation, payment instruction, or journal, with system IDs and a tie-back to the approved candidate.

This separation matters when a PDF is converted, a tax field is corrected, or a user changes a supplier after review. PCAOB AS 1105, while written for audit evidence rather than as a management implementation manual, articulates relevant evidence principles: reliability depends on source and nature; converted or electronically processed information needs controls over accuracy and completeness; and recalculation and reperformance provide different forms of evidence. The practical translation is simple—retain originals and make transformation visible.

The IRS's Publication 583 similarly emphasizes retaining supporting documents and ensuring computerized records can be reconciled and can preserve enough detail to identify underlying source documents. Requirements vary by jurisdiction and organization, so teams should apply their own retention and privacy rules. The architectural principle is widely useful: the structured record should never sever the path back to evidence.

Start with a source register, not an inbox

A folder of PDFs is not a controlled population. Build a register from approved intake channels and reconcile it to an independent report: email gateway receipt log, expense-system submission list, supplier portal, scan batch, bank feed, or document-capture queue. Each source receives an ID before extraction. Record file hash, original filename, page count, received time, sender or uploader, conversion history, and proposed downstream record.

Image cleanup can improve extraction, but the cleaned image is a derivative. Keep both versions. Mixed PDFs deserve special handling: a single upload might contain three invoices, or one invoice may arrive across several files. The register records split and merge relationships without deleting the originals. That makes duplicate investigations and retention responses much less ambiguous.

Verify fields according to consequence, not visual prominence

The largest text on an invoice is not necessarily the riskiest field. A small currency code can change the payable; a single digit in a supplier bank account can redirect funds; an issue date can change the tax or reporting period; and a credit-note sign can reverse the intended effect. Define critical fields by document type and downstream consequence.

For each critical field, preserve the machine proposal and point the verifier to the exact page and region. Record the verified value separately. If the interface supports bounding boxes, use them as navigation aids, not as proof—the box can point to the wrong label or capture a subtotal rather than a total. When an authorized person corrects a value, retain who changed it, when, why, and what evidence supported the change.

Supplier identity needs two distinct checks. First, does the visible document identify the supplier and customer entity? Second, does that identity correspond to the controlled supplier master? A matching logo is weak evidence. Bank-detail changes should follow an established out-of-band verification process, not be approved because the model found the new details on the invoice.

Confidence scores can reduce work only inside a tested routing policy. They are often system-specific and may not be calibrated across document layouts or field types. A 98 percent-looking score does not mean a one-in-fifty error probability unless the vendor has defined, tested, and monitored it that way for the relevant population. Use confidence alongside document quality, field consequence, supplier risk, amount, novelty, and observed performance.

Reperform what software can prove deterministically

Models are useful for locating and organizing values; arithmetic and structural tests should be reproducible. Recalculate line extensions, discounts, subtotal, tax by rate, withholding, freight, credits, and total in a controlled spreadsheet, accounting module, or script. Make tolerances explicit and distinguish an approved rounding difference from a failed tie-out.

expected_total = subtotal + tax + freight - discounts - credits
difference = extracted_total - expected_total
result = "PASS" if abs(difference) <= approved_rounding_tolerance else "HOLD"

duplicate_key = normalize(supplier_id, document_number, currency, gross_amount)
release_allowed = source_complete and critical_fields_verified 
                  and arithmetic_passed and duplicate_status == "CLEAR"
                  and match_status in approved_match_states
                  and blocking_exceptions == 0

Duplicate detection needs more than an exact invoice number. Suppliers vary punctuation, leading zeros, spacing, and prefixes. Search normalized identifiers together with supplier, amount, currency, and date; also compare file hashes, perceptual image similarity when approved, purchase-order consumption, and prior credits. False positives should remain linked candidates until a reviewer resolves them. The AI must not delete or merge records to make the queue disappear.

Matching is also evidence-specific. A three-way match compares purchase order, receipt or service acceptance, and invoice across supplier, entity, item, quantity, price, currency, tax, and tolerance. A bank match compares amount, direction, counterparty, reference, currency, and timing. “Suggested match” describes a system action; “exact,” “within approved tolerance,” “partial,” “multiple candidates,” and “contradictory” describe the evidence.

Worked example: a clean-looking invoice with three holds

Assume an AI capture service reads a two-page software invoice as supplier Northlake Cloud Ltd., invoice NL-10482, dated August 28, currency USD, subtotal 24,000, tax 2,400, and total 26,400. It proposes a match to purchase order PO-7719 and a recurring software expense code. All fields have high displayed confidence.

The source register shows that only one page arrived through the portal, while the image itself says “Page 1 of 2.” That is the first hold: the population may contain an omitted terms or detail page. Visual verification then finds that the currency mark is “AUD,” not USD. That is the second hold because currency affects the liability and payment. Finally, PO-7719 has only 18,000 of unconsumed authorized value and no approved change order. That is the third hold even though the arithmetic on the invoice is correct.

The important lesson is that “five fields extracted correctly” and “record ready to release” are different propositions. Arithmetic can pass while document completeness, currency, purchase authorization, or accounting period fails. The review packet should preserve each result rather than collapse everything into one confidence score.

Make the exception queue a controlled work product

An exception queue is not a miscellaneous inbox. Each item needs a source ID, failed control, proposed and verified values, amount at risk, downstream consequence, evidence required, named owner, deadline, and route. The route might be supplier master, purchasing, receiving, tax, accounting policy, fraud or security, payment operations, or the document submitter.

Separate local exceptions from population-wide failures. One illegible low-value receipt may be excluded under policy while the remaining batch proceeds. A missing intake report means completeness is unknown and can block the whole batch. A suspected supplier-bank change should not sit in the same normal correction queue as a mistyped postal code.

Preserve contradictory evidence. If the invoice says one bank account and the master says another, do not rewrite the extraction to match the master and mark it “fixed.” Record both, freeze the transaction, and use the approved verification channel. If a purchase-order number matches but the supplier and currency do not, keep the contradiction visible instead of selecting the closest candidate.

Earn sampling with measured field performance

Teams often want to move immediately from full review to sampling. Begin with 100 percent review for a bounded pilot so you can measure performance by supplier, layout, document type, capture channel, field, currency, and exception class. Report false acceptance, not only extraction accuracy: the harmful event is a bad record passing the release gate.

A risk-based policy may later allow straight-through handling for a tested, stable, low-risk population while retaining full review for new suppliers, new layouts, material amounts, credits, foreign currency, tax-sensitive documents, bank changes, poor images, conflicting matches, and closed-period activity. Random samples test baseline drift; targeted samples test known risks. Both need escalation rules when error rates exceed thresholds.

NIST's AI Risk Management Framework resources recommend defined roles, testing, evaluation, verification and validation, and documented oversight. The framework does not prescribe this accounting workflow, but its governance pattern fits: specify who owns the system, the data, the test, the exception, and the decision; monitor performance in context; and change the control when the model, layout, integration, or risk changes.

Approve one exact artifact, then reconcile the result

Approval should bind to a specific release candidate—not to “the documents in the folder” or a chat response. Record a version, digest, record count, control totals, exclusions, schema, creator, and timestamp. The approver selects a clear outcome: approve for controlled import, approve with documented exclusions, rework, hold, or reject.

Any change to a critical field, source linkage, match, accounting code, tax field, exception, count, or amount creates a new candidate. This prevents the classic gap where a reviewer approves one spreadsheet and an operator uploads a later edited version. Segregate preparation, independent verification, master-data change, approval, payment, and posting according to the organization's policy and system capabilities.

After downstream processing, reconcile. The imported record count and totals should agree to the approved candidate; rejected rows and manual edits need disposition; accounting-system IDs should link back to source IDs; and the resulting reconciliation, payable, expense, tax record, or journal should be compared with the authorized artifact. The process is not complete at export.

Failure modes that a good demo can hide

Another subtle failure is reviewer automation bias. A clean interface, a fast result, and a high confidence label encourage confirmation rather than inspection. Design the review screen to expose evidence and contradictions first. Randomly insert known test cases during validation, rotate reviewers, and measure both missed errors and unnecessary holds.

A practical 30-day controlled pilot

1. Days 1-5—scope and baseline: choose one document type, entity, approved intake channel, and downstream process. Define critical fields, tolerances, duplicate rules, match states, roles, exclusions, and a manually verified baseline set.
2. Days 6-12—parallel run: process documents without changing the existing release path. Compare proposals with originals and established results. Classify errors by field, layout, supplier, amount, and consequence.
3. Days 13-18—exception design: test missing pages, low-quality scans, credits, foreign currency, altered invoice numbers, duplicate uploads, recent bank changes, PO overruns, and conflicting matches. Confirm the system fails closed.
4. Days 19-24—controlled release: allow approved candidates into a non-payment or test environment first. Verify version locking, system validation, rejected rows, access, segregation, and reconciliation receipts.
5. Days 25-30—decision: review false acceptance, false holds, correction time, exception aging, reviewer agreement, downstream differences, privacy, and observed control failures. Expand only the populations whose evidence supports it.

Useful metrics include source-population completeness, field-level precision for critical fields, arithmetic pass rate, duplicate resolution quality, exception rate by cause, reviewer time, false acceptance, late downstream edits, rejected imports, and percentage of released records traceable to originals. “Documents processed” is throughput, not control quality.

Frequently asked questions

Can AI-extracted invoice data be posted without human review?

Not under this workflow. Extraction stays a proposal until an authorized reviewer verifies the source, critical fields, calculations, duplicates, match evidence, accounting context, exceptions, and exact release version. A mature policy may later automate narrowly tested low-risk populations, but that decision requires evidence, controls, monitoring, and accountable owners.

Which fields require visual verification?

At minimum, verify supplier identity, document number and type, dates, currency, subtotal, tax, total, payment details, entity, purchase-order reference, and any field that drives accounting, payment, tax, approval, or period. The exact list should be risk-based and document-specific.

Is a high confidence score enough to accept a document?

No. Confidence is a routing signal, not evidence of correctness. Calibration may vary by system, field, and population. Pair it with direct source verification, arithmetic, duplicate tests, matching, risk indicators, and monitored performance.

Should teams keep the original after converting a PDF to structured data?

Yes, subject to applicable retention and privacy rules. Preserve the original and record the conversion as a derivative. The structured data needs a durable link back to the source, plus correction and approval history.

Does the workflow decide accounting or tax treatment?

No. It organizes evidence and routes questions. Qualified people must apply the relevant framework, policy, facts, materiality, tax, legal, audit, and regulatory requirements.

Continue building the control chain