Use case
Reconciliation breaks stop ageing. Each one closed with evidence.
Mismatches between your ledger, the provider file, and the bank statement are cleared class by class: reproduced, corrected, re-run, and closed with evidence.
Last updated:
Send us an exception classAt 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.
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.

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