Why a matching total does not prove the detail
A total is a sum, and a sum can hide two errors that cancel. When one line is counted twice and another line of the same amount is left out, the duplicate adds what the omission removes, so the total still agrees with the other record. A control that reads the total passes, and a control that reads the lines finds both. Reading at line level also places the fix, because a difference found on a line arrives with its reference, its date and its amount, while a difference found on a total arrives without a location.
How a line-level reconciliation runs
- Fix the two populations. Decide which two records enter the comparison and the period they cover, so both sides describe the same activity at the same cut-off.
- Prepare both sides. Normalize dates, formats and references, so a line on one side can be paired with a line on the other.
- Pair the lines. One line against one, one against several, or several against several. The pairing and its tolerances run on the rules the team configures.
- Route what does not pair. A line with no counterpart becomes an exception with a cause and an owner, and it stays visible until it is explained.
Example: the total agrees and the detail does not
The figures are illustrative and stated in US dollars. Calderway Trading closes March and reconciles its sales ledger against the settlement report for the same period. The report lists five movements, of 5,400, 3,800, 2,200, 1,200 and 1,200, so it totals USD 13,800.
The ledger also totals USD 13,800, and its detail is wrong. One of the two movements of 1,200 was posted twice, and the other was left out. On the total the two cancel: 1,200 – 1,200 = 0. The two sides therefore agree with each other: 13,800 – 13,800 = 0.
Correcting it does not move the total. Reverse the duplicate and post the missing movement, and the ledger reads 13,800 – 1,200 + 1,200 = 13,800, because what leaves as a duplicate returns as a real movement. The two records then agree line by line, and the control that matters verifies lines rather than totals: a total that agrees would have passed over both errors.
What gets compared, and with which documents
The object is two records that describe the same activity, and the pairing takes three shapes: one line against one, one line against several, and several against several. The document is not fixed by the name of the term. Employee expenses arrive with receipts, purchases with purchase orders, and bank movements with bank statements, and each case brings the records that support it.
When the comparison runs
The comparison can run daily, on a schedule, when new data arrives or at period close. Its cadence follows transaction volume, risk and data availability. A reporting cut-off still matters: both populations must cover comparable activity, and a line present on only one side needs an explanation, whether the control runs during the month or at its end.
The line that does not pair
An unmatched line is the finding, and its cause decides what follows. A timing difference is documented and carried forward with the date it is expected to clear. A real difference is investigated. The classification is a judgment the team makes and records.
From comparable records to an explained exception
Simetrik prepares source records, applies configured matching rules and keeps the comparison traceable to each transaction. The matching engine is deterministic: the same inputs and rules produce the same result. Its AI-native workflow adds assistance with preparation, configuration and analysis, while preserving the rules behind the match.
The payment reconciliation implementation guide shows how normalization, matching and exception review work together. In the Operation Center, teams can assign and track pending items, retain supporting evidence and record their resolution. The objective is to explain the unmatched line, including whether further data or an approved adjustment is needed.