AI Invoice and Payment Matching Agents: A Worked Example

Use a labeled set before evaluating an agent

This example extends the six invoices in the reconciliation guide to fifteen. The added cases introduce consolidated payments, ambiguous equal amounts, missing remittance and a currency mismatch. All names, references and amounts are synthetic. Expected allocations are supplied for teaching and repeatable evaluation; no agent has been measured against them here.

The first six invoices retain the same values as the category guide. They total $5,585, with $4,140 allocated and $1,445 open. The extended fifteen-invoice set totals $8,835, with $5,190 in expected confirmed allocations and $3,645 open. Do not compare the two totals without accounting for the added records.

The full worksheet shows each expected allocation. A blank match is not an invitation to guess. Some cases are deliberately unresolved because the available evidence does not identify a unique invoice. A correct agent response can explain why the money remains unapplied.

Match identity before relying on amount

Start with the receipt identity, customer evidence, invoice reference and currency. Amount is useful, but two invoices can have the same amount. In the dataset, Spruce and Fir each have a $400 invoice, and receipt B209 lacks enough identifying evidence to choose between them. The expected response is an ambiguous-match exception.

The agent should show both candidates and the missing evidence. It should not choose the older invoice, the first row or the company name that looks more familiar unless an authorized business rule and the available facts support that decision. A tie-breaking guess would turn an unresolved receipt into a potentially incorrect allocation.

Also preserve stable receipt references. B201 appears twice in the source feed but represents the same $1,200 receipt. Counting it twice would increase apparent received cash without any new money. The expected result excludes the repeated row from unique receipt totals while retaining evidence of the duplicate input.

A similar amount with a different receipt identifier deserves investigation rather than automatic deduplication. The test should distinguish repeated source identity from two real payments that happen to be equal. Require the agent to explain which identity evidence supports its treatment.

Keep partial payments and consolidated payments distinct

Northstar's INV102 is $875, and its $800 receipt leaves $75 open. The expected allocation records $800 against that invoice. It does not close the invoice or invent a fee for the difference. The receivables owner investigates any claimed deduction separately.

Oak's INV108 is $500 with a $200 receipt, leaving $300 open. This second partial-payment case checks that the agent applies the same reasoning with a different amount. If the expected behavior only works for the first example, the test has exposed a fragile rule rather than a reliable allocation process.

Receipt B208 is $550 with remittance identifying Maple's $200 INV109 and Pine's $350 INV110. The expected result has two allocation rows whose sum is $550. The agent should preserve the remittance reference connecting the receipt to both invoices, rather than selecting one and leaving an unexplained residual.

The allocation table is the financial output to inspect. An invoice may receive several allocations, and a receipt may cover several invoices. Confirm that each receipt's allocations do not exceed its value and that each invoice's allocations plus remaining balance reproduce the invoice amount.

Do not invent a fee or an exchange rate

Ash's INV113 is denominated in USD, while a candidate receipt is EUR 100. The equal number does not establish equal value or a valid allocation. The expected case remains unresolved until the team obtains the relevant currency and settlement evidence.

Do not add EUR 100 to the USD receipt total. The worksheet treats that receipt separately, and the USD balances remain internally consistent. If a real workflow converts currencies, it needs the applicable conversion evidence and the organization's accounting treatment. The model should not choose a convenient rate from memory.

A processor fee also needs evidence. A net settlement can differ from gross customer payments for a documented reason, but the agent should connect the fee record and settlement breakdown before proposing the adjustment. Without that evidence, a short payment remains a difference to investigate.

For Elm's INV114, a $250 receipt has no usable invoice remittance. The matching amount alone is insufficient in this exercise. The expected result leaves the receipt unapplied and the invoice open until the reviewer obtains supporting evidence. This deliberately tests whether the agent prioritizes explainability over apparent completion.

Make confidence useful without treating it as authority

An agent may supply a confidence label for a proposed match. The reviewer still needs to know what evidence supports the proposal. A numerical score without a calibration method cannot tell the finance team how many incorrect allocations to expect or whether a particular proposal is acceptable.

Set the review rule around the actual evidence and financial task. Exact supported references may permit a straightforward proposal. Missing remittance, competing candidates or currency differences can require human review regardless of the generated score. The policy belongs to the workflow owner, not to an improvised model threshold.

Beam and Sema4 describe matching-related workflows in their public product material. Those descriptions justify asking them to demonstrate relevant cases. They do not supply measured precision for this dataset, and this article does not adopt their advertised benefit percentages. [1] [2]

Ask a provider to show the same unresolved cases as well as the clean matches. A demonstration that excludes Spruce, Fir and the currency mismatch cannot establish how the product handles those exceptions. Keep the expected outcomes available during the review so success is judged consistently.

Export a result another person can check

The export should connect each proposed allocation to a receipt, invoice, amount, currency and evidence reference. Add the review status and reason for unresolved cases. These are conceptual fields; use the supported identifiers and schema of the selected system in an implementation.

For the extended set, expected unique USD receipts total $6,140. Expected confirmed allocations are $5,190, leaving $950 unapplied: the original $300 receipt, the ambiguous $400 receipt and the unsupported $250 receipt. The separate EUR 100 candidate is outside that USD total.

Check the invoice equation independently: $8,835 minus $5,190 equals $3,645 open. This includes the deliberately unresolved invoices as well as partial payments and invoices without receipts. The two equations describe different populations, so the open invoice balance does not need to equal unapplied cash.

Have a reviewer recompute these values from the exported rows. If the agent's summary differs from the rows, treat that as a failed result even when the narrative sounds plausible. Financial correctness includes consistent details and totals.

Repeat the test after changing the workflow

Run the set with expected outcomes fixed in advance. Record wrong proposals, missed exceptions, duplicate counting and missing evidence separately. Review all proposals in this small set rather than checking only the cases the agent marks uncertain. A confident wrong match is one of the failures the exercise is designed to expose.

Keep proposed and confirmed allocations separate. If a reviewer rejects a proposal, preserve that decision and the original evidence. Do not count a rejected proposal as a successful automatic match simply because the invoice eventually received the right allocation through human work.

Change one condition at a time when investigating a failure. Add a correct remittance to B209, for example, and verify that the case moves from ambiguous to supported without changing unrelated allocations. This demonstrates whether the agent uses the new evidence rather than merely repeating an earlier answer.

After adjusting prompts, mappings or integrations, repeat the affected cases and verify the aggregate balances. The output supports a decision about this configured workflow and dataset. It does not establish a general market ranking or a production accuracy promise. Use the reconciliation guide for balance reporting and the audit guide for preserving the review history.