How Ledger and Reconciliation Work Together

A ledger and a reconciliation system answer different questions.

The ledger answers:

What does the financial institution believe its financial position to be?

Reconciliation answers:

Does that internal position agree with the records produced by banks, payment providers, card processors and other external parties?

A ledger without reconciliation can remain internally balanced while disagreeing with the outside world. Reconciliation without a controlled ledger can identify differences but cannot establish a reliable internal financial position.

A production financial platform needs both.

Three records usually exist for one transaction

A payment commonly produces at least three related records:

1. An operational payment record
2. One or more ledger transactions
3. An external provider record

The operational record describes the payment lifecycle: who created it, who approved it, whether compliance checks were completed, when it was submitted and what status the provider returned.

The ledger records the financial effect.

The provider record shows what the external bank or payment system processed.

All three should be linked by durable identifiers, but they should not be collapsed into one database record.

The ledger is an accounting system

A double-entry ledger records every financial movement through balanced debit and credit entries.

For example, consider an illustrative outgoing payment of USD 100 with a USD 2 customer fee.

When the payment becomes financially effective, the accounting could include:

When the external provider settles the payment:

The precise chart of accounts and timing depend on the institution's accounting policy and settlement model. The important principles are that entries remain balanced and that the customer movement, fee and external settlement can be traced separately.

A balanced ledger does not, by itself, prove that the provider sent the payment correctly. It proves that the internal accounting entries balance.

Operational state is not accounting state

A payment may pass through several operational states:

Created → Approved → Submitted → Accepted → Completed → Reconciled

Not every transition requires a final ledger posting.

A card authorisation, for example, may create a reservation that reduces the customer's available balance without immediately becoming a settled accounting movement. The final transaction may arrive later for a different amount because of tips, offline adjustments, partial completion or foreign-exchange conversion.

This is why a banking platform may need to distinguish:

• Ledger balance
• Available balance
• Reserved amount
• Pending incoming amount
• Pending outgoing amount
• Settled balance

Displaying only a single number called “balance” can conceal important differences.

Immutability does not mean mistakes cannot be corrected

An immutable ledger does not prevent corrections. It prevents historical entries from being silently rewritten.

If a financial posting is incorrect, the platform should normally create a reversal or compensating transaction and then, if necessary, post the correct transaction.

This provides an evidence chain:

1. Original transaction
2. Identified error
3. Reversal or correction
4. Replacement transaction
5. User and reason for the intervention

Changing the original amount directly in the database may make the present balance appear correct, but it destroys the ability to reconstruct what happened.

Reconciliation compares independent records

The CPMI defines reconciliation as a procedure for verifying that two sets of records produced by different entities match.

In a banking or payment platform, reconciliation may occur at several levels.

Transaction-level reconciliation

Each internal payment is matched to an external provider transaction.

Matching fields may include:

• Internal transaction ID
• Provider transaction ID
• End-to-end payment reference
• Account or virtual account
• Currency
• Amount
• Value date
• Counterparty
• Direction
• Status

The strongest match uses a unique reference shared by both systems. When such a reference is unavailable, the reconciliation engine may need a controlled combination of amount, currency, date and counterparty information.

Balance reconciliation

The platform compares aggregate internal positions with external balances.

Examples include:

• Internal settlement account versus bank statement
• Card settlement receivable versus processor report
• Customer-funds liability versus safeguarded-funds position
• Provider wallet balance versus internal provider account
• Internal cash account versus correspondent-bank balance

A transaction-level match can still coexist with a balance-level difference, for example because of an opening-balance problem, an unrecorded fee or a timing difference.

Both forms of reconciliation are therefore necessary.

Settlement reconciliation

Authorisation and payment acceptance do not always equal settlement.

A provider may:

• Accept an instruction immediately
• Process it in a later batch
• Deduct fees separately
• Apply an FX conversion
• Return the payment
• Reverse a transaction
• Settle a net amount covering many transactions

Settlement reconciliation links these external movements back to the relevant internal transactions and ledger accounts.

Why one-to-one matching is not always possible

Some transactions match cleanly: one internal payment corresponds to one provider transaction for the same amount and currency.

Other situations are more complex:

• One settlement covers hundreds of card transactions
• One payment produces separate principal and fee movements
• Multiple internal transfers are netted externally
• The provider reports a converted amount in another currency
• A transaction settles over several days
• A payment is partially returned
• A provider deducts fees from a batch
• A statement contains movements not previously received through an API

The reconciliation model must therefore support:

• One-to-one matching
• One-to-many matching
• Many-to-one matching
• Partial matching
• Tolerance rules
• Timing differences
• Manual resolution with an audit trail

Automatic matching should accelerate work without concealing uncertainty.

Idempotency protects both ledger and reconciliation

Duplicate messages are normal in distributed systems.

A provider may send the same callback several times. A client may repeat a payment request after a timeout. A statement may overlap with the previous reporting period.

The system should recognise that a message has already been processed before creating another financial effect.

Useful identifiers include:

• Client idempotency key
• Internal transaction ID
• Provider transaction ID
• Provider event ID
• Statement line identifier
• Card network reference
• End-to-end payment reference

Deduplication should be enforced as close as possible to the financial posting operation. Logging a duplicate after it has already created a second ledger entry is too late.

Reconciliation exceptions are operational work

A reconciliation system should not merely produce a large spreadsheet of unmatched records. It should create controlled exception workflows.

An exception record should explain:

• What failed to match
• Which matching rules were attempted
• The internal and external amounts
• Relevant dates and references
• The financial exposure
• The responsible operations queue
• Actions already taken
• Whether a ledger correction is required
• Who resolved the exception
• The resolution reason

Exceptions can then be prioritised by value, age, provider, currency and risk.

Typical categories include:

• Internal record missing externally
• External record missing internally
• Amount mismatch
• Currency mismatch
• Duplicate transaction
• Status mismatch
• Unrecorded fee
• Unexpected reversal
• Settlement delay
• Unexplained balance difference

Reconciliation frequency should follow risk

Not every process needs the same schedule.

Some payment and card flows benefit from near-real-time reconciliation as provider events arrive. Formal balance and safeguarding controls may also require daily processes using complete bank statements or settlement reports.

A practical operating model may combine:

• Event-level checks when provider callbacks arrive
• Intraday transaction reconciliation
• End-of-day statement reconciliation
• Daily balance certification
• Monthly accounting close
• Periodic review of aged exceptions

The institution should define when a transaction is considered operationally complete and when it is considered financially reconciled.

Metrics that reveal control quality

Useful reconciliation metrics include:

• Percentage automatically matched
• Unmatched transaction count
• Unmatched financial value
• Oldest unresolved exception
• Average exception resolution time
• Duplicate-event count
• Balance differences by provider and currency
• Manual adjustments
• Reversals and returns
• Failed statement imports
• Transactions awaiting final settlement

A high automatic-match rate is helpful, but it should not be achieved by overly broad matching tolerances. The objective is accurate control, not an attractive dashboard.

The final question is explainability

At the end of each day, a financial institution should be able to explain:

• The amount owed to customers
• The funds held with each external institution
• Payments that have been submitted but not settled
• Reservations that affect available balances
• Fees earned or payable
• Returns and reversals
• Unmatched external movements
• Every manual financial correction

The ledger provides the internal financial structure. Reconciliation tests that structure against independent external evidence.

Together, they make balances explainable.

References

• CPMI-IOSCO: Principles for Financial Market Infrastructures
• EBA Guidelines on the Authorisation of Payment Institutions
• Basel Committee: Principles for Effective Risk Data Aggregation and Risk Reporting