Skip to content
MirrorFirm

What does a mismatch between a bank feed and a loan ledger look like in practice?

At Aster Financial, a transposed digit leaves a loan short and triggers an arrears notice, and the analyst must correct the ledger and stop the downstream effect.

At Aster Financial, a payments operations analyst runs the daily match between the bank feed and the loan ledger. Item `PAY-5521` appears in the bank feed as 1,240.00 received against loan `LN-3093`. The ledger entry `LED-88210` for the same payment reads 1,204.00. The difference of 36.00 leaves the loan short, and overnight the arrears process opens `CASE-0412` and queues a reminder notice for the collections team.

The analyst opens both records and checks the remittance reference, value date and channel. Both point to the same payment, so this is not a timing gap. The digits in the ledger amount are transposed, and the original entry was keyed manually after a batch import failure, which the batch log confirms. The analyst's authority covers posting a correcting entry up to a set limit, so they post `LED-88377` for 36.00 with the reason code for keying error, link it to `PAY-5521`, and ask the collections team to withdraw the queued notice.

The state change is concrete: the loan returns to nil arrears, `CASE-0412` closes with a link to the correction, and the notice is cancelled before it is sent. Had the analyst only fixed the ledger, the customer would still have received a notice about arrears that did not exist.

**What it teaches:** a correct fix includes the evidence for the cause, the right authority and reason code, and the downstream effects, not only the corrected number.

A correct fix covers evidence, authority, reason code and downstream effects, which is the standard a model should be trained and evaluated against.

Audience:
Model labs
Content type:
Scenario
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch