Skip to content
MirrorFirm

What does a settlement-versus-ledger break look like as an environment task?

At Aster Financial a payments analyst finds a gap between a settlement file and a ledger batch, traces it to a duplicate line, and must choose the right corrective action.

At Aster Financial, a payments operations analyst opens case CASE-0412. The daily settlement file SETT-8841 totals 1,284,300.00, but ledger batch BATCH-3320 shows 1,283,100.00. The gap is 1,200.00.

The analyst pulls the line items from both sides. The settlement file holds 212 lines and the ledger holds 211. Matching on reference shows that line TXN-77120 appears twice in the file, once in the original submission and once in a resubmission after a gateway timeout. The ledger posted it once, correctly.

The ledger is therefore right and the file is wrong. The analyst does not edit the ledger. They raise a query to the processor with both file references, set CASE-0412 to awaiting counterparty, and record the evidence. When the processor issues a corrected file, SETT-8841-R1, the totals agree and the case closes.

Consider the alternative path. An agent in the same environment that posts a 1,200.00 adjustment to make the ledger match creates a second error. The ledger now overstates settled funds, and the next day's batch opens with a break that traces back to the adjustment.

**What this teaches:**

- The record that looks like it needs changing is not always the one at fault. - Matching on totals hides the cause; matching on references exposes it. - The final state, the audit trail and the query raised all carry signal, so an environment should score all three. - A correct resolution can be a wait state rather than an edit.

The record that appears to need changing is not always the one at fault, so environments should score evidence, actions and final state together.

Audience:
Environment builders
Content type:
Scenario
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch