An AI reconciliation tool can report 987 matched transactions without showing which 987 pairs produced that number. The total looks useful. It is not enough to close the month, correct the ledger, or explain the result to a client.
If you need to know how to check what an AI reconciliation tool matched, start with the row-level output. Every source row must appear somewhere. Every matched row must point to one specific counterpart. Every match must show the field or combination of fields used to make the decision.
Without that evidence, you are checking a summary rather than checking the reconciliation.
Start with the evidence the tool gives you
Open the exported result before reviewing any dashboard percentage. You need to establish whether the tool produced a reconciliation record or only a reconciliation claim.
| Output element | What verifiable output contains | What an opaque result contains |
|---|---|---|
| Matched transactions | The row from File A beside the exact row from File B | A total such as “987 matched” |
| Match basis | The reference, amount, date, or field combination used for that pair | “AI match” or an unexplained confidence score |
| Unmatched rows | Every remaining row from both files, identified by source | One unmatched count or percentage |
| Exceptions | The affected rows and the specific difference | A general warning that exceptions exist |
| Source coverage | Proof that every input row was classified once | No way to trace the result back to both files |
| Exportable record | A row-level report another person can review | A dashboard summary or generated narrative |
A confidence score does not replace this evidence. A tool can be 96% “confident” about a pair without telling you whether it matched on invoice number, amount, date proximity, customer name, or a combination of weak similarities.
The real question is not whether the tool sounds certain. It is whether you can reproduce the match from the two source rows.
Run a six-step check against the source files
Do this before editing either file. Preserve the original exports, the tool output, and the settings used for the run. Changing a date, deleting a duplicate, or normalizing a reference before verification destroys the baseline you need to test.
1. Count the result rows
Record the row count of File A, File B, and the reconciliation output. Exclude headers, subtotal lines, and blank rows consistently.
Suppose the files contain:
| File | Transaction rows |
|---|---|
| Sales ledger | 1,040 |
| Bank export | 1,012 |
| Tool output marked “matched” | 987 |
The 987 matched rows do not explain the other 53 ledger rows or 25 bank rows. The tool must also provide unmatched or flagged output that accounts for them.
Do not expect the two source counts to equal each other. One bank deposit may represent several invoices, and one refund may relate to an earlier period. The test is whether every source row has a visible status, not whether both files started with the same number of rows.
2. Confirm every File A row appears once
Add a stable source-row identifier if the file does not already have one. A-0001, A-0002, and so on is enough for verification. Then check the result for every identifier.
Each File A row should appear as one of:
- Matched to a specific File B row
- Unmatched
- Flagged for review
- Included in a clearly disclosed one-to-many or many-to-one group
A missing source ID means the row was dropped. A repeated source ID may mean the same transaction was used in more than one match.
3. Confirm every File B row appears once
Repeat the same test from the other direction. This catches a common failure that a one-sided check misses: two ledger transactions matched to the same bank row.
If the tool permits grouped matching, repeated use can be valid. The output must identify the group and show that the grouped amounts reconcile. If it presents both pairs as independent one-to-one matches, the result is a false positive.
Coverage in both directions is essential. A reconciliation is incomplete when File A is fully represented but File B still contains invisible rows.
4. Identify the basis for each match
Look for the fields the tool actually used, not the fields you expected it to use.
| Match basis | What to verify |
|---|---|
| Exact reference | Both source values are identical after disclosed normalization |
| Amount and date | The amount agrees and the date falls within the stated tolerance |
| Invoice or order ID | The identifier is unique in both source files |
| Composite key | Every component of the key agrees |
| Grouped amount | The listed component rows add to the paired total |
| Fuzzy text | The similarity did not override a conflicting reference or amount |
If the basis is unavailable, you cannot verify the pair systematically. You can only inspect it and guess why the tool selected it. That is the same audit-trail problem described in AI matching without a row-level record.
5. Test a deliberate sample of matched pairs
Do not sample only the first 20 rows. Early rows often contain the cleanest data, especially when files are sorted by date or reference.
Choose pairs from several risk groups:
- Exact-reference matches
- Date-tolerance matches
- Repeated amounts
- Round-number payments
- Transactions near the period boundary
- References with prefixes, spaces, or truncated characters
- One-to-many and many-to-one groups
- High-value transactions
For each pair, compare the source reference, amount, date, currency, account, and customer or supplier. A match is correct only when the fields support the same underlying transaction.
If several sampled pairs are wrong for the same reason, stop sampling and test the full affected group. Three false matches among date-tolerance pairs indicate a rule problem, not three isolated mistakes.
6. Look for reused rows and duplicate amounts
Sort the matched output by the File A source ID, then by the File B source ID. Any duplicate identifier needs an explanation.
Next, sort by amount. Repeated values are where weak matching logic becomes visible. Fixed retainers, subscriptions, payroll payments, and standard supplier invoices regularly create identical amounts.
For a fuller breakdown of this failure pattern, see why AI reconciliation tools match the wrong transactions.
Work through a duplicate-amount example
Assume the ledger contains this invoice:
| File A row | Date | Invoice | Customer | Amount |
|---|---|---|---|---|
| A-184 | June 3 | INV-8041 | North Street Ltd | $250.00 |
The bank file contains two receipts:
| File B row | Date | Reference | Payer | Amount |
|---|---|---|---|---|
| B-390 | June 4 | INV-8041 | North Street Ltd | $250.00 |
| B-391 | June 4 | INV-7792 | Mason Retail | $250.00 |
The correct pair is A-184 to B-390. Amount and date alone cannot prove that. Both bank rows satisfy those conditions. The invoice reference and payer identify the correct transaction.
An opaque output might show:
| Ledger row | Bank row | Status | Confidence |
|---|---|---|---|
| A-184 | B-391 | Matched | 94% |
The percentage does not repair the match. The source fields contradict it.
A verifiable output should show:
| Ledger row | Bank row | Status | Match basis |
|---|---|---|---|
| A-184 | B-390 | Matched | Exact invoice reference, amount, and payer |
| — | B-391 | Unmatched | No ledger row with reference INV-7792 |
This is why manual spot-checking must include duplicate values. A total can still reconcile when two equal amounts are swapped, while the transaction-level result remains wrong.
Treat unexplained confidence as a review flag
Confidence scores can help prioritize review. They cannot establish correctness on their own.
Ask four questions about any score:
- Which fields increased the confidence?
- Which conflicting fields reduced it?
- What threshold changed the result from unmatched to matched?
- Can the same score be reproduced from the same inputs?
If none of those answers are available, treat the score as interface information rather than audit evidence.
The same rule applies to labels such as “suggested,” “likely,” or “intelligent match.” They describe the tool's assessment. They do not show the underlying comparison.
Separate wrong matches from unresolved exceptions
A conservative tool may leave an ambiguous pair unmatched. That creates review work, but it preserves the uncertainty.
A false positive is more dangerous. It removes the transaction from the exception list and makes the reconciliation appear cleaner than it is.
Classify the reviewed output into:
| Review result | Meaning | Action |
|---|---|---|
| Confirmed match | The source fields identify the same transaction | Keep the pair |
| False positive | The tool paired different transactions | Break the match and return both rows for review |
| Ambiguous | More than one counterpart satisfies the rule | Require another field or supporting record |
| Missing source row | An input row does not appear in the result | Rerun or reject the output |
| Reused source row | One row appears in multiple independent matches | Check grouping logic and duplicate use |
| Valid grouped match | The listed rows form one traceable settlement or batch | Keep the group with its components |
This classification turns a vague concern about AI matching accuracy into a controlled review. It also gives you a record of what changed after the automated run.
Decide whether the output is safe to rely on
The result is ready for a client report or month-end close only when all of these statements are true:
- Every row from both source files appears in the output
- No row is used twice unless it belongs to a disclosed group
- Every matched pair identifies both source rows
- The match basis is visible and reproducible
- Unmatched rows remain visible
- Exceptions explain the affected rows and required action
- Duplicate amounts have been tested separately
- Material and high-risk matches have been reviewed
- The final matched, unmatched, and flagged counts reconcile to the source counts
If the tool cannot export the row pairs, request the underlying match data. If it cannot provide that data, do not convert the dashboard result into an audit-ready report. Preserve the source files and complete the comparison in a system that exposes the actual matches.
