Summarise the article with your AI
Here you can read:
Effective reconciliation exception management determines whether a financial close takes a few days or half of the month, and this gap is largely explained by upstream exception handling. Finance teams that master exception management through clear ownership, ageing rules, and documented workflows close faster, reduce risk, and free capacity for strategic work. At period end, unresolved exceptions can delay the entire financial close and require significant manual intervention. When a stack of unmatched transactions sits in the reconciliation queue, finance professionals are forced to spend hours chasing breaks, emailing counterparties, and manually correcting general ledger entries that should have posted days prior.
What a reconciliation exception is, and why the leftover is the real work
Every reconciliation produces two outcomes: items that matched automatically and items that did not.
A reconciliation break occurs when two records that should align fail to do so on one or more key fields: amount, date, currency, reference or transaction identifier. In bank reconciliation, that might be a payment appearing in the ledger but not on the bank statement. In payments, it could be a settlement entry that doesn't tie to the internal transaction record.
Managing these exceptions rigorously through structured reconciliation exception management is a regulatory requirement for regulated firms and for general corporates it is a business requirement:
The Basel Committee on Banking Supervision places reconciliation of accounts explicitly within its framework for internal controls. In the UK, FCA CASS rules require regulated firms to perform internal client money reconciliations every business day and to resolve any discrepancy promptly.
Where there is doubt, the firm must assume the higher figure is correct and make up any shortfall until the matter is finally resolved. An unresolved exception is not a housekeeping oversight; it is a potential breach of regulatory obligation.
For corporate finance teams outside regulated environments, the stakes are just as high. According to a 2025 Broadridge global study of over 270 asset servicing leaders, up to 67% of asset servicing are attributed directly to data quality issues, rather than matching logic failures. Unresolved exceptions distort general ledger balances, corrupt cash flow reporting, and in the worst cases, produce incorrect partner settlements.
The exception taxonomy that separates cause from symptom
Not all exceptions are the same. Before attempting to resolve a break, the finance team must classify it, because the resolution path and the correct general ledger entry depend entirely on the root cause. Here's how to distinguish between timing issues and genuine errors:
| Exception type | Side (books or bank) | Required action |
|---|---|---|
| Timing difference | Either side: transaction recorded in different periods | Park in short-hold suspense; confirm it clears next cycle; no adjusting entry unless it ages |
| Missing transaction on books | Books: in GL but not in bank record | Investigate; raise query to counterparty or post reversing entry. |
| Missing transaction at bank | Counterparty: in bank but not in GL | Post the required GL entry with narrative and supporting documentation. |
| Amount mismatch | Either: reference matches but values differ | Identify discrepancy source (FX rate, fee, rounding); post difference to clearing account |
| Duplicate entry | Books—same transaction posted twice | Reverse duplicate posting; document correction in audit trail |
| Data/format mismatch | Either—same transaction coded differently | Correct reference data; escalate to data governance if systemic |
| Counterparty error | Counterparty—bank or third party posted incorrectly | Raise formal query; hold in suspense; do not adjust internal books until confirmed |
| Intercompany mismatch | Books—two group entities record differently | Initiate intercompany reconciliation query; one entity posts adjustment |
Treating a timing difference the same way as a missing transaction wastes analyst time and creates spurious general ledger entries. For example, supervisors under COSO's monitoring framework expect organisations to distinguish between exceptions indicating a control weakness and those arising from normal operational timing.
One queue, one owner: how an exception gets assigned
The most dangerous state for a reconciliation exception is being open and unowned. An exception that sits at the boundary between treasury, accounts payable and bank reconciliation will fall between all three teams if assignment rules aren't explicit.
Every exception must be assigned to one named owner within a defined period of detection. The workflow typically has four stages.
1. Detection and creation
The reconciliation engine identifies a break and creates an exception record capturing: exception type, sources compared, discrepancy amount, affected account or entity, transaction date and exception raised date.
2. Triage and categorisation
Automated rules classify the exception by type and materiality band. Items below a de minimis threshold may be auto-cleared or batch-grouped. Items above the threshold route for human review.
3. Assignment
The exception is routed to the team or individual responsible for that account, entity or transaction type. Routing logic should be based on account ownership tables, not ad hoc judgement. In well-designed systems, the exception lands in the named owner's queue within minutes of detection.
4. Acknowledgement
The assigned owner must acknowledge the exception and begin investigation within the SLA window. Unacknowledged exceptions trigger escalation to the line manager.
Segregation of duties applies throughout: The person who posts a general ledger entry should not be the same person who signs off the reconciliation that validates it. This independent check for example, is a primary control requirement under Basel guidance and a core element of internal audit testing.
Ageing and materiality: which exceptions get escalated, and when
Once an exception has been assigned, the clock starts. Ageing rules determine when an unresolved exception must be reviewed by more senior oversight. Materiality rules determine which exceptions demand urgent treatment regardless of age.
Here's a typical corporate finance ageing framework:
0–2 business days: Analyst-level review, expected to self-clear or have resolution plan agreed.
3–5 business days: Flagged to team lead or controller if unresolved, investigation note required.
6–10 business days: Escalation to Finance Director or Head of Treasury, written narrative explaining status.
10+ business days: Escalation to CFO or Head of Control, reviewed in weekly exception meeting, material items may require GL provision.
Materiality rules work alongside ageing: An exception large relative to account balance or revenue threshold warrants immediate escalation regardless of how long it's been open.
Long-ageing exceptions are diagnostic: Backlogs of aged items usually point to data quality issues, unclear ownership or operational inefficiencies that need upstream correction.
Setting reconciliation SLAs that survive a real close
A service level agreement defines expected timelines, responsibilities and quality standards within which reconciliation must operate. SLAs that look sensible on a project plan but collapse under pressure of a real month-end close are one of the most common failure points in finance control design.
What must a reconciliation SLA specify?
Some typical SLA elements include:
- Frequency: How often reconciliation runs.
- Detection-to-assignment time: Maximum elapsed time between exception identified and owner assigned.
- Investigation window: Time within which the owner must open and categorise the exception.
- Resolution deadline: When the exception must be cleared or escalated with an investigation note.
- Minimum match rate: Percentage of items cleared automatically.
- Reporting cadence: How often exception counts and ageing profiles reach management.
Where SLAs fail in practice is at the boundary between teams?
PwC's analysis of intercompany reconciliation identifies lack of control arising from decentralised data sources, multiple accounts and contributors whose responsibilities aren't embedded as the primary risk. Clear process monitoring supported by modern workflow functionality—not a longer SLA document—is what fixes this.
From resolved exception to posted journal entry
Resolution of an exception isn't complete until underlying accounting records are correct. For most exceptions, resolution requires a GL entry that follows the organisation's journal posting policy as rigorously as any other accounting entry.
Timing differences that self-clear in the next cycle don't require a GL entry but do require a documented note confirming the item is monitored and expected to clear.
Missing transactions require posting to the appropriate account with clear narrative referencing the original transaction, supporting documentation and the preparer's identity. Independent review, the four-eyes check, should be evidenced in the workflow record.
Suspense accounts deserve specific attention: ACCA guidance explains that suspense accounts are temporary holding accounts for bookkeeping entries that will end up somewhere else once the final correct account is determined. They're the natural home for exceptions genuinely unresolved at balance sheet date—but they must be monitored with the same ageing discipline as the exception queue itself.
What to measure, and what the numbers actually tell you
The metrics that matter in reconciliation exception management are not the ones that look best in management reports. They are the ones that most honestly reflect the health of the upstream data and process environment.
Primary Metrics for Exception Management
| Metric | Description |
|---|---|
| Exception volume | Absolute number of open exceptions, segmented by account and type. |
| Exception rate | Exceptions as a percentage of total transactions, normalised for volume growth. |
| Aged exception count | Number passing each SLA threshold, such as Day 2, Day 5, or Day 10+. |
| Average days to resolve | Mean business days between creation and clearance, tracked separately by exception type. |
| SLA compliance rate | Percentage resolved within the agreed window. |
| Match rate | Proportion cleared by automated rules versus requiring human review. |
| Exception backlog trend | Week-on-week or month-on-month change in total open exceptions. |
Diagnostic Indicators and Actions
| Scenario | Diagnostic Meaning | Recommended Action |
|---|---|---|
| High exception rate + short average days to resolve | Typically indicates a data quality problem where numerous breaks clear quickly upon review. | Address upstream issues through data governance and format standardisation. |
| Low exception rate + long average days to resolve | Indicates an ownership issue where few exceptions occur, but they remain ignored until the close forces a resolution. | Enforce stricter SLA monitoring and clear assignment protocols. |
Transaction volumes are growing at more than 25% year-on-year, settlement timelines are shrinking and regulatory expectations are intensifying. The same metrics applied to larger data sets will increasingly surface breaks previously buried in the noise.
Fewer exceptions, and a faster route through the ones that are left
The endgame for reconciliation exception management isn't zero exceptions—it's a control environment where exceptions are structurally fewer, better categorised when they arise, owned from the moment they appear and cleared on a timeline that doesn't determine the close.
Modern account reconciliation software platforms increasingly support these workflows natively, handling straightforward matching automatically while directing human expertise to breaks that actually require it. When combined with PSP reconciliation capabilities for payment gateway settlement matching, finance teams gain end-to-end visibility from transaction to GL posting.
