This guide is for an AI invoice reconciliation result that already contains invoice and payment records. It does not ask the same AI to judge whether its answer is correct. Instead, it turns the matching policy into deterministic checks that can be rerun against the source data and the proposed reconciliation.
Preserve the original invoices, payments, and first reconciliation before fixing anything. A corrected table without the failed result cannot show which exceptions the AI silently removed or reclassified.
The five-check reconciliation checklist
| Check | Pass condition | Typical hidden failure |
|---|---|---|
| Record completeness | Every invoice and payment ID appears exactly once in the reconciliation trail | An inconvenient payment disappears from both the applied and unapplied lists |
| Exact matching | The invoice reference exists and the permitted amount rule passes | Vendor and amount similarity are treated as proof despite a blank reference |
| Partial balances | Short or partial payments leave the remaining invoice balance open | A one-cent short payment is silently rounded into a full settlement |
| Unmatched items | Missing and unknown references stay unapplied with an explicit reason | An unknown invoice ID is omitted instead of becoming an exception |
| Control totals | Outstanding invoices and unapplied payments equal their detailed rows | A polished summary reports totals that cannot be reproduced |
Before checking: separate source data from decisions
Keep three tables. The invoice source should contain an immutable invoice ID, counterparty, currency, original amount, and any already-approved adjustments. The payment source should contain an immutable payment ID, received amount, supplied invoice reference, and transaction date. The reconciliation table is a decision layer: it may link records and assign statuses, but it must not rewrite either source.
Normalize currency and decimal precision before matching. If the business permits tolerances, credits, fees, or foreign-exchange adjustments, store those as explicit rules with an owner and reason code. Never allow the AI to invent a rounding policy because two numbers look close.
1. Prove that every source record survived
Compare the set of source invoice IDs with the invoice IDs in the result. Then compare the set of payment IDs with the union of applied and unapplied payments. The reconciliation fails when an ID is missing, duplicated, or appears in both payment states.
source payment IDs = applied payment IDs ∪ unapplied payment IDs
applied payment IDs ∩ unapplied payment IDs = empty setCounts alone are insufficient: two duplicated IDs can conceal two missing IDs while the row count still matches. Compare unique identifiers and retain the source-to-result trail.
2. Require the reference and amount rule to pass
A safe automatic full match needs an invoice reference that resolves to exactly one source invoice and an amount that satisfies the declared policy. Vendor, date, memo text, and amount similarity can rank candidates for review, but they do not authorize an automatic match when the required reference is absent.
full match = reference resolves to one invoice
AND payment amount satisfies the approved amount ruleAlso fail closed when one reference resolves to multiple invoices or when a payment would be applied twice. Ambiguity belongs in an exception queue, not in a settled total.
3. Recalculate every remaining invoice balance
Calculate the remaining balance from the source invoice amount and only the payments that pass the matching rule. A lower payment is partial unless an explicit adjustment closes the balance. An overpayment should remain visible according to the organization's credit or unapplied-cash policy.
remaining balance = source invoice amount
− sum(valid payments applied to that invoice)In the saved fixture, a $599.99 payment against a $600.00 invoice must leave $0.01 open, and a $1,000.00 payment against a $1,200.00 invoice must leave $200.00 open. Calling either invoice settled hides a real exception.
4. Keep missing and unknown references unapplied
A blank reference and a reference that does not exist are different failures, but neither is a full match. Preserve the payment ID, amount, supplied reference, reason code, and review status. Candidate suggestions may be shown separately as long as they cannot change ledger status.
- Missing reference: hold for manual identification or remittance evidence.
- Unknown reference: verify data entry, timing, source-system sync, or counterparty details.
- Ambiguous reference: require a qualified owner to select the target record.
5. Rebuild both control totals from detail rows
Sum open invoice balances independently from the invoice table. Separately sum unapplied payment amounts from the exception table. These are different control totals: an unapplied payment does not reduce an invoice until the matching policy authorizes the link.
The corrected fixture contains $0.01, $980.00, and $200.00 of open invoice balances, for $1,180.01 outstanding. Its two unapplied payments are $980.00 and $320.00, for $1,300.00 unapplied. Both totals must be reproducible from the listed rows.
What the preserved failure exposed
Our first AI reconciliation retained all 13 source records and found three exact matches, but it silently cleared three exceptions: a one-cent short payment, a payment with no invoice reference, and a $200 partial balance. It scored 4/10. One correction limited to those detected failures reached 10/10 without changing the valid matches.
Read the complete invoice reconciliation test for the exact prompt, first result, correction, final tables, and scoring evidence.
Boundary: this checklist does not approve a close
These checks validate the bounded matching rules in the example. They do not cover duplicate bank entries, credit notes, taxes, fees, foreign exchange, split remittances, timing differences, fraud controls, accounting standards, or the organization's approval policy. The fixture is fictional, one AI run was tested, and no accounting platform or bank account was accessed.
A qualified reconciliation owner must define tolerances and exception policy, review material items, and approve the final close. Passing deterministic checks means only that the result satisfies the rules tested here; it is not accounting advice or authorization to post entries.