The model can read the invoice and the bill can still be wrong.

A perfect transcription can still produce a duplicate bill, assign the wrong vendor, violate a tax rule, or sync a total that does not reconcile. Extraction quality and workflow correctness need different tests.

Layer 1: document evidence

The model identifies candidate fields: vendor name, invoice number, dates, currency, line items, tax, and total. Every extracted value should retain a path back to the source document and a confidence or uncertainty signal useful to review.

Layer 2: arithmetic invariants

Deterministic code should recalculate line extensions, subtotal, tax, discounts, and total within an explicit tolerance. This catches internally inconsistent documents and extraction combinations that look plausible field by field but cannot all be true together.

Layer 3: identity and duplicate controls

Vendor identity should resolve against the tenant’s accounting data, not merely resemble text on the page. Duplicate checks need more than a filename: vendor, invoice number, date, currency, amount, and prior workflow state can all contribute evidence.

Layer 4: accounting policy

Currency support, account mappings, tax treatment, approval thresholds, closed periods, and integration permissions belong to application policy. A model can propose a classification; it should not silently invent authority.

Layer 5: side-effect safety

Creating a bill in QuickBooks or Xero is a state change. Use idempotency keys, job locks, explicit retry behavior, and an audit trail so network failures do not create duplicate side effects. A successful API response should be recorded separately from the model’s earlier extraction result.

Review exceptions, not every invoice

Human review is most useful when the queue explains why attention is needed: unresolved vendor, arithmetic mismatch, possible duplicate, unsupported currency, or high-value approval. Sending every invoice to review trains people to rubber-stamp the interface.

This is the architecture behind the SyncABill case study: AI-assisted intake, deterministic validation, visible review state, and controlled accounting synchronization. The model is important, but it is not the whole product.

Evaluate the workflow by failure class

Maintain separate test sets for extraction errors, arithmetic violations, duplicate scenarios, identity ambiguity, policy boundaries, and integration failures. A single “invoice accuracy” score collapses failures with very different consequences and owners.