Invoice coding that sends unsupported fields to review

Structured e-invoicing gave invoices machine-readable data, but the process around a cost invoice stayed manual: reading, matching against the order and delivery, choosing the account and cost center, deciding readiness for posting. Automating it has one trap that gets discussed too rarely.

A model asked for a coding entry will usually propose one. The account may exist in the chart, the cost center may be real, and the amounts may add up even when the proposal has no basis. Such a plausible result can pass a rushed review and surface later during payment.

An empty value as a safety mechanism

In the payables desk we built, the model answers only inside a closed, validated schema: document fields, the three-way match result, the proposed entry, and the readiness decision. The schema's key rule: a value unconfirmed by the document, the order, the delivery, or the supplier's precedent stays empty.

An empty field is a deliberate result that means the basis is missing. An invoice with an empty account, an empty cost center, or no precedent automatically goes to human review and cannot be marked ready. The result format has no field for a merely probable value.

A precedent you can see and click

The second design decision concerns trust. Beneath the proposed entry stands a cited precedent: an earlier invoice from the same supplier, posted to the same accounts, clickable through to the source document. The accountant can inspect that document instead of relying on the model's assertion.

The system also performs a deterministic three-way match. It compares the tax ID, quantities, unit prices, and currency with the order and delivery confirmation, field by field, and records an explicit agreement status. Code computes that status.

A simple architecture without an agent framework

The whole system uses one model call per invoice, a validated response format, and three containers. It needs no agent framework because there is no repeated tool use or multi-step decision process.

Matching the architecture to the process keeps the system smaller. Fewer moving parts also mean less audit surface in a process that touches money.

Is the process ready for automation?

The strongest starting scope is recurring suppliers with a stable chart of accounts, clear cost-center rules, and a history of entries that accountants consider correct. A high share of these invoices gives the system useful precedents and lets the AP team focus on exceptions instead of reconstructing supplier history every time.

Before a pilot, establish five baselines: monthly volume, the share of recurring suppliers, the share of invoices linked to purchase orders, the number of corrections after coding, and elapsed time from receipt to readiness. Volume alone is a weak qualification signal when every invoice concerns a different expense or the coding rules change frequently.

The process needs preparation when accountants use different accounts for equivalent expenses, allocate cost centers from unwritten knowledge, or retain bad precedents in supplier history. Automation will reproduce that inconsistency quickly. Agree the policy and identify which historical documents are fit to support a proposal before connecting a model.

A practical pilot sequence

Start with a representative batch in shadow mode. The system proposes an entry while the team continues its normal coding. Compare three outcomes separately: accepted without change, corrected by the accountant, and correctly held because the evidence was incomplete.

Next, add the three-way match. The accounting and procurement owners need to define tolerances for quantity, unit price, value, and currency, including which discrepancies block readiness. A rule that stops every difference can fill the queue with harmless exceptions; loose thresholds can clear documents that need investigation.

Connect the workflow to the ERP, e-invoicing system, or general ledger only after those rules and responsibilities are stable. Integration moves a result faster but does not make the proposal more accurate.

How to interpret evidence and cost

Field completion is not the leading quality measure. A system that always supplies an account can look complete while producing unsafe suggestions. Measure proposal accuracy, correctly held invoices, falsely ready invoices, and the accountant's review time as separate outcomes.

The recorded model cost is USD 0.004514 per invoice on the prepared run. It excludes integration, infrastructure, maintenance, and human review. The commercial calculation should compare the full handling cost and correction rate before and after the pilot. In most AP teams, minutes of skilled accounting time matter more than fractions of a cent in model usage.

Buyer checklist

1. Do the highest-volume suppliers have approved, accessible precedents?
2. Who owns the chart of accounts, cost-center policy, and match tolerances?
3. Which missing fields or discrepancies must block readiness?
4. Can an accountant open the basis for every proposal in one action?
5. Will the pilot measure corrections, correct holds, false readiness, and review time?
6. Which actions stay outside the system: posting, changing an order, and approving payment?
7. How is an invalid precedent withdrawn so it cannot affect later invoices?

The measurement

The test covered 12 generated invoices and 72 expected fields. Every field and every readiness decision matched the expected result, including four fields that had to remain empty. None of the eight blocked invoices received a ready status. The 95th-percentile response time was 8.14 seconds, and recorded model cost was USD 0.004514 per invoice. Client documents need their own evaluation before these figures can guide an operating target.

The system also produced zero cases in which a plausible proposal concealed a missing basis.

Full measurements and screens are on the case page. If coding eats your accounting team's hours, a free process scan will show whether this pattern fits your volume.