Article map
A bank reconciliation can balance while the treasury subledger is incomplete. A TMS-to-ledger reconciliation can balance while the bank contains an unauthorised or unmapped transaction. Pairwise controls each answer a narrow question, but they do not necessarily prove that the external cash event, treasury transaction and accounting entry represent the same economic activity.
Three-way reconciliation connects all three records using amount, account, date, currency, reference, transaction type and instrument identity. It distinguishes expected timing from missing data, incorrect mapping, duplicate posting and genuine accounting error.
This article explains how to design the control, automate matching sensibly and govern the exception lifecycle without masking differences through broad suspense accounts.
1. Define the populations and control assertions
The reconciliation should state which accounts, transaction types and periods are included and which assertions it proves: completeness, existence, accuracy, timing and classification.
The operating boundary should define:
- bank statement entries and opening-closing balance
- TMS payments, receipts, transfers, deals and fees
- general ledger postings and subledger references
- expected in-transit and clearing populations
- manual bank activity and transactions processed outside the TMS
The control should reconcile both record counts and values. A net zero difference can hide offsetting missing or duplicate items.
2. Create identifiers and matching hierarchies
Exact end-to-end identifiers provide the strongest match, but not every bank or ledger preserves them. The TMS should use a controlled hierarchy from deterministic reference matching to constrained composite and tolerance rules.
The governed data record should capture:
- end-to-end, bank, deal, journal and source references
- account, amount, currency and debit-credit direction
- value, posting and document dates
- transaction code, counterparty and business purpose
- tolerance, aggregation and one-to-many relationship rules
Every automatic rule should be explainable and tested against false matches. Broad amount-and-date matching can close the wrong items when transaction volume is high.
3. Separate timing, mapping and genuine breaks
An item may be valid but appear in different periods or systems. Classification determines whether it should reverse naturally, be remapped, posted, investigated or escalated.
The end-to-end workflow should make visible:
- bank booked but TMS status pending
- TMS transaction awaiting bank settlement
- bank fee or interest not initiated in the TMS
- TMS journal generated but not posted or rejected
- ledger entry with no supported bank or treasury event
Timing differences should have an expected clearing event and age threshold. A permanent “in transit” label is not resolution.
4. Control exception ownership and correction
Exceptions should route to the team able to resolve the cause: treasury operations, bank connectivity, accounting, master data, business or the bank. Correction should preserve the original record and approval.
The control architecture should address:
- exception type, value, materiality and owner
- source evidence and root-cause assessment
- corrective action, journal or mapping change
- maker-checker approval for financial correction
- closure evidence and recurrence indicator
The preparer of an unsupported manual journal should not be the only reviewer who closes the reconciliation difference it creates.
5. Use the TMS for continuous and period-end reconciliation
Daily or intraday matching can identify operational breaks early, while period-end control proves the signed financial position. Both should use consistent identifiers and rules.
The TMS configuration should support:
- automatic ingestion and completeness checks
- continuous matching and exception queue
- period-end freeze and balance certification
- rule version, override and manual-match history
- reconciliation report linked to journal and source evidence
Continuous matching does not remove the need for period-end sign-off. It reduces the backlog and improves the evidence available for it.
6. Measure automation quality and unresolved risk
An auto-match rate is useful only when the rules are accurate. Metrics should combine automation, ageing, value and false-match control.
Management reporting should measure:
- matched by deterministic, composite and manual method
- unmatched value and count by cause
- ageing and items past expected clearing date
- manual matches, overrides and reopened exceptions
- repeat breaks and post-close corrections
A rising auto-match rate achieved through looser tolerances may weaken control. Rule precision should be validated with sample review and exception outcomes.
7. Implement account and transaction-type waves
Start with material accounts whose data and references are reasonably mature. Establish balance proof and deterministic matching before adding complex aggregation and tolerance.
The implementation plan should sequence:
- reconcile population completeness for selected accounts
- map bank codes and TMS transaction types
- establish journal references and ledger extraction
- configure and validate matching hierarchy
- pilot continuous queue and period-end certification
Rules should be expanded only after the organisation understands the unmatched population. Automation built on unexplained data can hide rather than resolve problems.
Management questions before approval
Before management approves bank TMS ledger reconciliation, the discussion should test the boundary described by define the populations and control assertions, the reliability of end-to-end, bank, deal, journal and source references, and whether exception type, value, materiality and owner remains effective when an exception occurs. It should also ask how matched by deterministic, composite and manual method will reveal whether the decision delivered its intended treasury result.
- Are bank, TMS and ledger populations complete?
- Are both count and value reconciled?
- Is deterministic reference matching prioritised?
- Are composite rules constrained and tested?
- Do timing items have expected clearing dates?
- Are bank-only and ledger-only items visible?
The TMS record should connect those answers to separate timing, mapping and genuine breaks and to the action 'reconcile population completeness for selected accounts'. Where judgement changes the normal route for bank TMS ledger reconciliation, the evidence, approver, effective date and next review should remain visible beside automatic ingestion and completeness checks.
Evidence a controlled TMS should retain
The operating record for three-way treasury reconciliation should show how end-to-end, bank, deal, journal and source references became an approved action under control exception ownership and correction. It should retain source identity, calculation or transformation, workflow status, exception treatment and approval, together with the downstream result represented by automatic ingestion and completeness checks.
- exception type, value, materiality and owner
- source evidence and root-cause assessment
- corrective action, journal or mapping change
- automatic ingestion and completeness checks
- continuous matching and exception queue
- period-end freeze and balance certification
Version history for end-to-end, bank, deal, journal and source references should preserve the information used when the decision was taken, even if later correction changes the current view. Comparing that history with matched by deterministic, composite and manual method and the practical outcome in 'a balanced bank reconciliation with a missing TMS transaction' allows management to evaluate process discipline and decision quality without hindsight rewriting.
Operating decision record
The decision record for bank TMS ledger reconciliation should identify the event, the data cut supporting create identifiers and matching hierarchies, the assumptions applied and the policy or mandate that governed the choice. It should compare the selected action with a realistic alternative, identify the accountable owner and approver, and state when 'pilot continuous queue and period-end certification' or another change will require reassessment. A decision not to proceed with 'reconcile population completeness for selected accounts' should document the tolerance relied upon with the same discipline as an executed treasury action.
Continuity depends on linking that conclusion to reconciliation report linked to journal and source evidence and to later evidence of repeat breaks and post-close corrections. Reviewers can then distinguish whether the original decision was reasonable on the information available from whether the eventual outcome in 'a balanced bank reconciliation with a missing TMS transaction' happened to be favourable or adverse.
Review cadence and change triggers
Routine review of bank TMS ledger reconciliation should follow the cadence implied by bank booked but TMS status pending, while an immediate refresh should occur when tolerance, aggregation and one-to-many relationship rules, manual bank activity and transactions processed outside the TMS or a material system configuration changes. The reviewer should compare the current position with the last approved analysis and test whether closure evidence and recurrence indicator and related limits remain valid.
A trigger may confirm that the existing define the populations and control assertions design remains suitable; it does not always require a new transaction or configuration change. Continued reliance should nevertheless become a dated conclusion, supported by continuous matching and exception queue and reported through unmatched value and count by cause. Any bank TMS ledger reconciliation exception should carry an owner, interim treatment, escalation point and evidence of closure within the same TMS process.
Practical illustration: a balanced bank reconciliation with a missing TMS transaction
Finance reconciles a bank debit to a manual ledger journal and closes the account difference. The payment was released directly through a bank portal during a TMS outage and never entered the TMS, so treasury reporting and audit history omit the transaction even though the bank and ledger agree.
The three-way control identifies the bank-ledger pair without a TMS record. The exception requires a controlled TMS back-record linked to the continuity incident and original bank approval evidence. The journal and transaction then reconcile under one reference.
The control exposes an operating completeness gap that a traditional bank reconciliation considered resolved.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Are bank, TMS and ledger populations complete?
- Are both count and value reconciled?
- Is deterministic reference matching prioritised?
- Are composite rules constrained and tested?
- Do timing items have expected clearing dates?
- Are bank-only and ledger-only items visible?
- Does correction preserve original records?
- Are manual matches independently reviewed?
- Is continuous matching followed by period-end certification?
- Are rule precision and repeat breaks measured?
Common design failures
Three-way reconciliation weakens when organisations force every difference into a match or accept pairwise agreement as proof of end-to-end completeness.
- matching only net balances
- using broad amount-and-date rules without false-match testing
- leaving bank fees and portal payments outside the TMS population
- classifying aged items permanently as timing differences
- posting suspense journals without root-cause ownership
- reporting auto-match rate without disclosing manual override and reopen rates
The control should explain every external cash movement, every treasury record and every accounting posting as one connected chain or a visible exception.
Closing perspective
Three-way reconciliation proves more than balance agreement. It tests whether bank, treasury and accounting share the same complete population and economic meaning.
A TMS can provide the identifiers, matching hierarchy, exception workflow and evidence needed to make that proof continuous and auditable.
Frequently asked questions
What is three-way treasury reconciliation?
It is the reconciliation of bank statement entries, TMS transaction or subledger records and general ledger postings, including their relationships, timing and classification.
Why is a bank-to-ledger reconciliation not enough?
It can balance through a manual journal while omitting the treasury transaction, workflow, instrument or approval record needed for operational control and reporting.
Should all reconciliation differences be automatically matched?
No. Automation should be used where rules are precise. Ambiguous or unsupported differences should remain visible for investigation rather than be forced closed.