Use case
Reconciliation exception management. Breaks stop ageing, each one closed with evidence.
Reconciliation exception management, step by step: every break typed, owned and evidenced, cleared class by class, and closed only when a person decides.
By Sanjay Singh, Founder · Last updated:
Send us an exception classOn this page 11 sections
At a glance
Use caseThis page describes how Flominzo handles this situation. It is not a report of a specific customer’s results.
- Typical team
- Finance, treasury, and payment operations
- Flominzo product
- Flominzo Recon
- Deadline set by
- Your month-end close
- Stays with you
- Accounting treatment, restatements, customer remediation
The situation
A mismatch between what your ledger says, what the provider’s file says, and what the bank statement says is usually a small logic gap: a mapping, a rounding rule, a timing window around a cutoff, or a duplicate event. Each one has to be reproduced from real settlement data before anyone can fix it, and that reproduction is the bottleneck.
While the queue waits, items age. Unreconciled positions become finance escalations, and in a regulated business they become control findings.
What good exception management looks like
Reconciliation exception management is the work of turning every break between your records, the provider’s and the bank’s into an item someone owns, can investigate from the evidence, and can close with a recorded reason. Each exception should carry:
- a type, so similar breaks are handled the same way;
- an owner, one named person or team, never “finance”;
- a due-by time, set by the type and the value at risk;
- the evidence: the original records that disagree, attached rather than described;
- a next action, and a history of every action taken;
- a resolution, recorded with the reason and the person or rule that made it.
- Break foundRecords disagree, or evidence is missing.
- Typed and ownedA type, an owner and a due-by time.
- InvestigatedEvidence gathered; an explanation drafted.
- DecidedA person or an approved rule resolves it.
- ClosedWith its reason; reopens if new evidence arrives.
Exception types, grouped by cause
Flominzo maps every break to one of thirteen types. Grouped by cause, they show where to look first:
| Cause | Exception types |
|---|---|
| The provider’s own records disagree | CLAIM_MISMATCH, API_CSV_DISAGREEMENT |
| Evidence that should have arrived didn’t | MISSING_CALLBACK, FILE_MISSING, STALE_STATUS, UNKNOWN_UNRESOLVED |
| Money doesn’t add up | SETTLEMENT_MISMATCH, FEE_FX_MISMATCH, POSITION_UNEXPLAINED |
| Records without a partner, or with two | ORPHAN, DUPLICATE |
| Something changed after the fact | REVERSAL_AFTER_SUCCESS, POST_CLOSURE_EVIDENCE |
The documentation describes each type. Typing matters because the fix is usually per type: a missing file is chased with the provider, a fee mismatch is checked against the contract, a duplicate is checked for money actually paid twice.
Why the queue ages
- Breaks arrive faster than a team can reproduce them.
- The same class of break keeps returning, because it was closed without anything proving it stays closed.
- Evidence lives in spreadsheets and email, so every investigation starts from scratch.
What you send us
- An exception class from your queue, with sample identifiers.
- The result you expect for those payments.
- Read access to redacted settlement data and statements for the affected days.
How the queue is drained
Every break in Flominzo Recon is an exception with a named type, an owner, a due-by time, and the evidence attached. That turns a queue into a worklist that can be cleared in order.

- Order: work exception classes by age and value, largest first.
- Reproduce: run the class against the redacted sample. If it cannot be reproduced, that is recorded, not skipped.
- Trace: find the cause: a mapping, a tolerance, a cutoff or time-zone rule, or a duplicate event.
- Correct: change the reconciliation rule or Rail Profile as a new, owned version. Rules are versioned configuration, so the previous version stays on record.
- Re-run: apply the new rule version to the same evidence. Reconciliation is deterministic, so the result is repeatable, and the sample is kept to check future rule versions.
- Decide: a person with the right permission records the resolution. Agents can investigate and draft, but never close an exception.
What finance receives
A position finance can defend at month end, not a ticket that says done.
- For each class: the cause, the rule version that corrected it, and the re-run result.
- The evidence behind every closed item, kept with the payment rather than in a spreadsheet.
- Classes that could not be reproduced, listed as open rather than quietly closed.

Ageing, ownership and escalation
An exception queue stays healthy when age is visible and ownership is clear. Set a due-by time per type and value band, so a large settlement mismatch is due today and a small rounding difference by month end. When an item passes its due-by time, it escalates to a named person, not to a shared inbox.
Watch these numbers every week: open exceptions by age band and by value; exceptions per type, to find the classes worth fixing at the rule; items reopened after closure; and the time to close each business day. A queue that shrinks while reopenings rise is being closed, not resolved.
Decisions that stay with finance
- How a correction is booked.
- Whether a period is restated.
- What a customer is told, and any remediation.
Where this lives in Flominzo
Let’s make it specific to you.
Bring your systems, payment flows, and questions. We’ll help define the next step.
Talk to the team