How Bank Reconciliation Actually Works

Reconciliation is the discipline that stops a bank from trusting its own database too much.

A ledger can be balanced internally and still be wrong against the outside world. A payment rail may say a settlement account moved by €2,480,000 while the bank's internal payment engine expects €2,479,940. A card processor may send a clearing file with a transaction reference that does not match the issuer's authorisation record. A correspondent bank may report a nostro debit that the internal treasury system has not booked yet. None of those problems are solved by saying "our ledger table is append-only" or "our debits equal credits".

Internal balance is necessary. External agreement is a different control.

Bank reconciliation is the set of systems and operating procedures that compare internal records with external records, explain the differences, and force unresolved items into controlled queues. It is not only an accounting chore after business has finished for the day. In high-volume banks it is a continuous production process that keeps payment operations, treasury, finance, customer support, and risk management aligned.

This article explains how reconciliation actually works inside banking systems. We will cover nostro and vostro accounts, internal sub-ledgers, external statements, matching engines, break categories, suspense accounts, retry queues, ageing, manual investigation, and why reconciliation quality often determines how quickly a bank can recover after an outage.

Reconciliation Asks Whether Two Versions of Reality Agree

The simplest reconciliation question is:

What did we book internally?
What did the external source say happened?
Do those views match well enough to close the item?

The internal source might be:

• a core banking sub-ledger
• a card authorisation platform
• a payment switch
• a treasury system
• a suspense account
• a general ledger feed

The external source might be:

• a central bank settlement statement
• a correspondent bank nostro statement
• a card scheme clearing file
• a SEPA or instant payment report
• an ATM journal
• an acquirer or processor settlement file

The word "external" does not always mean outside the legal entity. It means outside the system being reconciled. A bank may reconcile its card processor against its core ledger, its sub-ledger against its general ledger, and its internal treasury book against a correspondent statement. Each comparison has different references, tolerances, and consequences.

For example, a retail payment engine may believe it sent €49.80 from Sofia's account to a merchant in Milan. The customer account ledger may show the debit. The card settlement clearing account may show the expected credit. Later the scheme clearing file may show €49.80 with the same acquirer reference. The settlement report may then show the obligation included in a net settlement amount.

Only after those views align can the bank treat the item as clean.

Nostro and Vostro Accounts Are Reconciliation Anchors

Cross-bank accounting uses two useful terms: nostro and vostro.

A nostro account is "our account held with another bank". From the perspective of a bank in Athens, a euro account held at a correspondent in Frankfurt may be a nostro account. It is an asset because the correspondent holds money for the bank.

A vostro account is "their account held with us". From the correspondent's perspective, the same relationship may appear as a liability to the Athens bank.

This vocabulary matters because reconciliation often starts with statements for nostro accounts. The bank's internal treasury system maintains an expected position. The correspondent or central bank sends statements showing actual debits, credits, balances, references, and value dates.

If the internal expected closing balance is:

opening balance       €18,200,000
internal expected in  €4,850,000
internal expected out €6,120,000
expected close        €16,930,000

but the external statement closes at:

statement close       €16,929,875

the bank has a €125 difference to explain.

That difference may be harmless, such as a bank charge posted externally but not yet booked internally. It may be timing, such as a late statement line with tomorrow's value date. It may be a reference mismatch. It may be a missing internal posting. Reconciliation turns that difference from a vague concern into a set of classified items.

Sub-Ledgers Create Detail That the General Ledger Cannot Carry

Banks do not normally reconcile only at one level.

The customer account sub-ledger may have millions of detailed entries. The general ledger may only need summarised control postings by product, branch, legal entity, and chart-of-accounts node. Card systems, loan systems, treasury systems, and payment switches may each maintain operational records that later map into accounting.

A common chain looks like this:

payment event
  -> operational payment record
  -> customer sub-ledger posting
  -> settlement clearing account
  -> general ledger summary
  -> external settlement statement

Each arrow can break.

The payment event may be accepted but fail posting. The customer ledger may post correctly while the general ledger export fails. The settlement clearing account may contain an expected movement while the external statement has not arrived yet. The external statement may contain the movement but with a different reference than the internal record expected.

This is why reconciliation platforms often support several match types:

• sub-ledger to general ledger
• operational record to sub-ledger
• clearing account to external settlement file
• nostro book to statement
• internal suspense account to manual repair queue

The goal is not only to prove a total. The goal is to preserve an explainable path from original business event to final external cash or settlement evidence.

External Statements Are Not Always Perfect Mirrors

A statement line from another institution looks authoritative, but it may not contain the same fields, timing, or granularity as the internal event.

An internal record may store:

payment_id: PAY-20260424-000184
debtor_account: GR1601101250000000012300695
creditor_iban: DE75512108001245126199
amount: €740.00
rail_reference: SCTINST-8B4C21
posting_time: 2026-04-24T09:17:42+03:00
value_date: 2026-04-24

The external statement may show:

24/04/2026 DEBIT 740.00 EUR SCT INST REF 8B4C21 FRANKFURT

Those two records are semantically the same, but they are not byte-for-byte equal. A matching engine has to normalise references, dates, signs, amounts, and sometimes text descriptions.

That normalisation creates engineering work:

• strip prefixes and suffixes from references
• map debit and credit signs according to account perspective
• convert local timestamps to banking dates
• handle decimal precision and currency codes
• tolerate known reference truncation
• split or aggregate records when one side reports a batch

Poor normalisation creates false breaks. Overly loose normalisation creates false matches. Both are dangerous.

Matching Starts With Deterministic Rules

The safest reconciliation rule is exact deterministic matching.

For example:

internal.rail_reference == statement.reference
internal.amount == statement.amount
internal.currency == statement.currency
internal.value_date == statement.value_date

If all fields align and neither side is already matched, the system can close the item automatically.

Most banks build a hierarchy of rules:

1. exact reference, amount, currency, value date
2. exact reference, amount, currency, small date tolerance
3. composite key using counterparty, amount, and date
4. aggregate match for batch totals
5. fuzzy candidate for manual review

The system should record which rule matched the item. A match closed by an exact rail reference is stronger evidence than a match closed by amount and date alone.

This audit trail matters during later disputes. If an operator asks why a €12,400 nostro debit was cleared, the answer cannot be "the system thought it looked close". It needs to show the rule, source records, timestamps, and any operator action.

Many Breaks Are Timing Differences

Not every unmatched item means something is wrong.

Timing differences are common because systems receive evidence at different times. A bank may post an outgoing transfer internally at 16:59 in Athens. The external settlement statement may arrive at 17:05. The item is unmatched for six minutes, then matches cleanly.

Typical timing breaks include:

• internal posting before external confirmation
• external statement line before internal ingestion completes
• rail report delayed by maintenance
• general ledger feed arriving after sub-ledger close
• value-date difference caused by cut-off handling

Reconciliation systems therefore need ageing rules. A fresh unmatched item may be normal. The same item still unmatched after three business days may require escalation.

A simplified ageing policy might be:

Ageing turns reconciliation from a static report into a workflow. The question is not only "is it unmatched?" It is "is it still unmatched beyond the tolerance for this break type?"

Amount Breaks Need Careful Classification

An amount mismatch is more serious than a pure timing break, but it still has several explanations.

Suppose the internal record says:

internal: outgoing transfer €1,250.00
statement: nostro debit €1,247.50
difference: €2.50

Possible explanations include:

• correspondent fee deducted externally
• foreign exchange conversion difference
• partial settlement
• wrong internal fee treatment
• duplicate internal posting on one side
• statement parsing error

Each explanation leads to different repair.

If the €2.50 is a known correspondent fee, the bank may book:

Debit:  Bank charges expense        €2.50
Credit: Nostro account              €2.50

If the difference is a duplicate internal posting, the correct action is a reversal of the duplicate. If it is a parsing error, the repair belongs in ingestion, not accounting.

This is why serious reconciliation systems separate break classification from posting repair. The classification says what kind of disagreement exists. The repair workflow decides which accounting or operational action is allowed.

Reference Breaks Are Often More Annoying Than Amount Breaks

Reference mismatches can be operationally painful because the money may be correct while the evidence is weak.

For example:

internal reference: SCTINST-20260424-001948-A
statement reference: 001948A
amount: €93.25
value date: 2026-04-24

If this pattern is known, a normalisation rule can solve it. If it appears unexpectedly, operations may need to inspect the source messages.

Reference breaks happen because:

• external systems truncate fields
• different systems use different identifiers
• batch files carry one settlement reference for many transactions
• manual payments include free-text references
• migration or vendor changes alter reference formatting

The danger is false confidence. If the amount and date are common, a fuzzy match may pair the wrong internal and external records. A €20 payment on a busy settlement account is not unique enough by itself.

Good reconciliation design uses match confidence. A low-confidence candidate may help an operator investigate, but it should not automatically close a material break.

Suspense Accounts Keep Unresolved Money Controlled

When a bank knows value exists but does not know the final classification, it often uses suspense.

Example: an incoming transfer reaches the bank's settlement account, but the beneficiary reference is malformed.

The bank should not ignore the incoming statement line. It should not guess the customer. It can book the value into unapplied suspense:

Debit:  Nostro or settlement asset          €500
Credit: Unapplied incoming suspense         €500

Later, when operations identifies the correct customer:

Debit:  Unapplied incoming suspense         €500
Credit: Customer deposit liability          €500

Suspense is not a place to hide problems. It is a controlled location for unresolved value. A mature bank monitors suspense ageing aggressively:

• total balance
• count of items
• oldest item
• items by break type
• items by responsible team
• items requiring finance approval

Old suspense is a warning sign. It means the bank has value sitting in an unresolved classification for too long.

Retry Queues Are Part of Reconciliation, Not Only Messaging

Many reconciliation breaks are caused by temporary processing failure, not business disagreement.

Examples:

• statement file arrived before the internal payment event was indexed
• general ledger feed timed out
• enrichment service could not map a counterparty reference
• downstream posting API returned a transient error
• duplicate detector was temporarily unavailable

For these cases, retry queues are safer than immediate manual repair.

A reconciliation retry worker might do:

for break in retry_queue:
    refresh_internal_candidates(break)
    refresh_external_candidates(break)
    run_match_rules(break)
    if matched:
        close_break(rule_id)
    elif retry_count_exceeded:
        route_to_operations(break)

The retry policy needs to be idempotent. A retry must not book the same repair twice or close two items against one statement line. Reconciliation systems therefore maintain strict match locks and item states:

unmatched -> candidate_found -> matched -> closed
unmatched -> retrying -> operations_review
operations_review -> repaired -> closed

The state machine is as important as the match algorithm. Without it, retries can create duplicate repairs.

Break Management Is Workflow Engineering

Once an item cannot be closed automatically, it becomes workflow.

An operations user needs to see:

• internal record details
• external statement details
• candidate matches
• previous retry attempts
• age
• materiality
• related customer or account
• proposed repair actions
• approval requirements

The system also needs routing rules:

• card breaks to card operations
• nostro breaks to treasury operations
• sub-ledger to general-ledger breaks to finance control
• suspected fraud or sanctions issues to risk teams
• high-value items to senior approval

This is not glamorous software, but it is critical. A weak break-management tool produces spreadsheet archaeology. Operators export files, colour rows, email screenshots, and manually track who did what. That behaviour is risky because it moves control outside the system.

A good reconciliation platform keeps the investigation trail inside the workflow:

• who changed the status
• what evidence they attached
• which repair posting was created
• who approved it
• when it closed

That trail often matters months later during audit or customer disputes.

Reconciliation Is Different From Settlement

Settlement is the movement or finalisation of obligations. Reconciliation is the proof that records agree about that movement.

A bank can settle and still fail reconciliation. For example, a central bank account may actually move by the correct net amount, but the internal system may allocate that movement to the wrong product clearing account. Cash moved. Records disagree.

A bank can also reconcile an expected item before final settlement in some workflows, depending on the evidence being compared. For example, a payment rail acknowledgement may match the outgoing payment instruction, while later treasury settlement still needs a separate nostro reconciliation.

Conflating these concepts creates bad designs. A payment status of "settled" should not automatically mean every finance, sub-ledger, and nostro reconciliation is closed. It means the rail or settlement layer reached a defined final state. The accounting proof still needs its own controls.

Card Reconciliation Has Several Layers

Card payments show why reconciliation becomes multi-stage.

An issuer may need to compare:

• authorisations approved by issuer processor
• clearing records presented by the card scheme
• holds and posted transactions in core banking
• settlement totals from the scheme
• chargeback and reversal records
• fees and interchange entries

Common breaks include:

• authorised but never cleared
• clearing without matching authorisation
• clearing amount differs from hold amount
• reversal received after posting
• duplicate clearing record
• settlement total differs from clearing detail

Some breaks are normal for a period. A hotel authorisation may not clear for days. A fuel pre-authorisation may clear for a lower amount. A clearing without online authorisation may be allowed under specific offline or stand-in scenarios. The reconciliation engine needs product and scheme knowledge, not only generic matching.

The repair action differs by state. Releasing a stale hold is not the same as reversing a posted debit. Booking a scheme fee is not the same as fixing a duplicate customer transaction.

Instant Payment Reconciliation Is Fast but Not Simple

Real-time payment rails compress the time window, but they do not remove reconciliation.

An instant payment may involve:

• customer instruction
• fraud and sanction decision
• debit posting or reservation
• rail message
• rail acknowledgement
• liquidity or prefunding movement
• beneficiary bank response
• final confirmation or rejection

If all goes well, the records line up within seconds. If a timeout occurs, the sender bank may be uncertain:

customer debited locally
rail acknowledgement missing
beneficiary status unknown
liquidity position changed or unclear

That uncertain state becomes a reconciliation problem. The bank must determine whether the payment reached finality, whether to restore funds, and whether a later rail report will contradict the local state.

Instant rails make aged breaks less tolerable. A card clearing mismatch may sit in operations for a while. An instant transfer timeout affects customer trust immediately. The reconciliation loop therefore needs tighter monitoring, faster retries, and clearer customer-status translation.

Sub-Ledger to General Ledger Reconciliation Catches Mapping Errors

Some reconciliation is not about external cash. It is about internal accounting consistency.

The customer sub-ledger may say that today's retail deposit liability changed by €14,800,000. The general ledger feed should reflect the same economic movement in the correct control accounts.

If the feed says €14,790,000, the €10,000 difference might be:

• missing journal export
• duplicate reversal
• wrong chart-of-accounts mapping
• branch or legal entity mapping error
• rejected GL batch

This matters because finance reports from the general ledger, while customers are serviced from sub-ledgers. If they drift, the bank cannot explain itself cleanly.

A typical control might be:

sum(customer_deposit_subledger_entries)
  == general_ledger.customer_deposit_control_movement

If the equality fails, reconciliation should identify the population that explains the variance, not only show a failed total.

Tolerances Are Useful and Dangerous

Reconciliation systems often use tolerances.

Examples:

• allow €0.01 rounding difference for FX conversion
• allow one business day date difference for certain correspondent statements
• allow known fee deduction if the fee code is present
• auto-write-off small differences under strict policy

Tolerances make operations manageable. Without them, teams drown in low-value breaks. But tolerances can hide real problems if they are too broad.

An acceptable tolerance should be:

• specific to product and account
• materiality-aware
• approved by finance or risk control
• logged as part of the match or write-off
• monitored for aggregate drift

Writing off one €0.01 rounding difference is harmless. Writing off millions of tiny differences without aggregate monitoring is not harmless. A tolerance is a control, not a shortcut.

Reconciliation Data Models Need Immutability and State

A reconciliation platform usually stores source items separately from match decisions.

A simplified model:

recon_item(
  item_id,
  source_system,
  source_reference,
  account,
  amount,
  currency,
  value_date,
  direction,
  raw_payload_hash,
  status
)
 
recon_match(
  match_id,
  left_item_id,
  right_item_id,
  rule_id,
  confidence,
  matched_at,
  matched_by
)
 
recon_break(
  break_id,
  item_id,
  break_type,
  age_bucket,
  owner_team,
  status,
  resolution_reference
)

The raw source record should be immutable or at least hash-protected. Normalised fields can be corrected through controlled reprocessing, but the platform should preserve what was originally received.

This matters when statement parsing rules change. The bank may need to re-run matching against historical items while proving it did not invent new source evidence.

Idempotency Prevents Repair From Becoming a New Incident

Repair postings must be idempotent.

Suppose operations resolves a €500 unapplied incoming payment by crediting the correct customer. If the browser times out and the operator clicks again, the customer must not receive two credits.

Repair actions should therefore carry unique resolution references:

repair_reference = RECON-BREAK-20260424-00931

The posting engine can then enforce:

if repair_reference already posted:
    return existing result
else:
    create repair posting

The same rule applies to automated retry workers. A retry that closes a break or posts a correcting journal must be safe to repeat after a crash.

Reconciliation systems are often built around failure recovery, so they cannot rely on perfect one-shot execution.

A Worked Example: Matching a Nostro Statement

Assume a bank starts the day with an internal expected nostro opening balance of €8,000,000.

During the day internal systems record:

The external statement arrives:

The matching engine closes OUT-1001 and IN-1002.

It leaves:

• internal expected OUT-1003 with no statement line yet
• external BANKFEE-77 with no internal booking

The first may be a timing break. The second may be a fee that needs a bank-charge posting. After repair:

Debit:  Bank charges expense        €25
Credit: Nostro account              €25

The remaining OUT-1003 ages until the statement line appears or operations investigates why the expected outgoing movement did not settle.

This example is small, but it captures the real pattern: match clean items automatically, classify differences, repair only with controlled accounting.

A Worked Example: Clearing Without Authorisation

Now consider a card clearing file with this item:

PAN/token reference: TKN-7781
merchant: Lisbon Electronics
amount: €219.00
clearing reference: CLR-66001
authorisation reference: AUTH-44019

The issuer searches for AUTH-44019 and finds nothing.

Possible explanations:

• the original authorisation was approved by stand-in processing
• the authorisation record was lost or not ingested
• the clearing item is invalid or duplicated
• the reference was transformed by a processor
• the transaction was offline-approved under card rules

The reconciliation system should not blindly reject or post. It should create a break:

break_type: clearing_without_authorisation
materiality: customer affecting
owner: card operations
candidate actions: post under scheme rule, reject if allowed, request evidence, map alternate reference

The decision depends on card scheme rules and evidence. If the transaction is valid, the bank may still need to post it to the customer. If it is invalid, the bank may contest it. The reconciliation system provides the queue and evidence, not the whole business judgement.

Why Reconciliation Matters During Outages

During a banking outage, customer-facing errors are visible first. Reconciliation damage appears later.

Suppose a payment switch slows down for twenty minutes. Channels retry. Some messages time out. Some rails accept payments after the channel has already shown failure. Some internal postings complete while acknowledgements are delayed.

After the incident, the bank needs to answer:

• which customer requests succeeded?
• which rail messages reached finality?
• which customer debits need reversal?
• which duplicate retries were suppressed?
• which nostro or settlement movements actually occurred?
• which items remain uncertain?

This is a reconciliation problem as much as an incident problem. Logs show attempts. Ledgers show postings. Rail reports show external state. Reconciliation connects them.

Banks with strong reconciliation can recover by classifying and repairing a finite population of breaks. Banks with weak reconciliation often discover the incident is not over when the service is back online.

Operational Metrics Reveal Reconciliation Health

Useful reconciliation metrics include:

• auto-match rate
• unmatched item count
• total unmatched value
• ageing by break type
• retry success rate
• manual touch rate
• suspense balance by age
• breaks reopened after closure
• repair postings by reason code

Auto-match rate alone is not enough. A high auto-match rate can hide dangerous low-volume high-value breaks. A low unmatched count can hide large aggregate tolerance write-offs.

Good dashboards combine count, value, age, materiality, and ownership.

For example:

nostro breaks over 3 days: 12 items, €1,840,000 total
card clearing breaks over 1 day: 4,821 items, €97,200 total
unapplied incoming suspense over 5 days: 38 items, €42,600 total

Those populations require different responses. The first may be treasury-critical. The second may be operationally high-volume but individually small. The third may affect customers waiting for credits.

Machine Learning Is Rarely the First Answer

It is tempting to use machine learning for fuzzy matching. Some banks and vendors do use statistical candidate ranking, especially for messy remittance text or correspondent statements. But the core of reconciliation should remain deterministic where possible.

The reason is accountability.

If a system closes a high-value break, finance and audit need to understand why. A deterministic rule such as "same rail reference, same amount, same currency, value date within one day" is explainable. A model score of 0.93 may be useful for ranking candidates, but it should not replace controls for material items without human review and strong governance.

A practical pattern is:

• deterministic rules auto-close high-confidence matches
• fuzzy logic suggests candidates
• operators approve low-confidence or high-materiality cases
• feedback improves candidate ranking

The point is to reduce manual search, not to make unexplained accounting decisions.

Cut-Offs and Banking Calendars Create Predictable Breaks

Reconciliation is full of calendar logic.

A payment may be initiated on Friday evening in Athens, posted internally on the same calendar day, value-dated on Monday, and appear on an external statement using the correspondent's local banking calendar. If the bank reconciles by raw timestamp only, it will create false breaks.

Systems therefore need explicit treatment for:

• local calendar date
• banking date
• value date
• statement date
• scheme cycle
• legal entity time zone
• public holidays

Consider a payment submitted from Lisbon after the sending bank's internal cut-off but before the instant rail's technical day boundary. The customer sees it as a Friday payment. The ledger may post it on Friday. Finance may classify the value date as Monday for a non-instant fallback route. The external statement may group the movement under a Saturday technical statement.

None of those views is automatically wrong. They answer different operational questions.

A reconciliation rule that tolerates one business day on a specific rail may be correct. A rule that tolerates any one-day difference on every account may be reckless. Calendar tolerance needs product knowledge.

This is why reconciliation engines often have calendar tables and rule configuration per account, rail, branch, and legal entity. The matching engine is not only comparing strings and amounts. It is interpreting dates according to banking rules.

Materiality Changes the Workflow

Not every break receives the same treatment.

A €0.01 rounding item on a high-volume FX account is not operationally equivalent to a €1,200,000 missing nostro debit. A €15 card clearing mismatch affecting one customer is not the same as a €15 variance in an internal fee summary with no customer impact.

Materiality usually combines:

• monetary value
• customer impact
• regulatory impact
• account sensitivity
• age
• break type
• repeat pattern

Example routing:

The repeated parser variance is important. A single €20 break may not be material. A thousand similar breaks may indicate a systemic mapping error. Reconciliation monitoring must therefore look at individual breaks and patterns.

This is also why banks separate operational materiality from accounting materiality. A small amount can still be customer-critical if it blocks a salary credit. A large amount can be low-risk if it is a known settlement timing difference that always clears in the next statement cycle. The workflow should reflect both dimensions.

Ownership Must Be Clear Before the Break Happens

Reconciliation breaks become expensive when nobody owns them.

An unmatched item can sit between teams:

• payments says the ledger posted correctly
• treasury says the nostro statement is external evidence
• finance says the GL feed is wrong
• technology says the parser behaved as configured
• operations says no one gave them repair authority

Good reconciliation design avoids this by assigning ownership through rules.

Ownership may depend on:

• source account
• break type
• product
• rail
• age
• value
• customer impact
• legal entity

For example:

if source_account = instant_payment_settlement
and break_type = no_final_rail_status
and age > 15 minutes:
    owner = payment_operations

if source_account = correspondent_nostro
and amount > €100,000
and break_type = statement_without_internal_booking:
    owner = treasury_control

The ownership rule is part of the control environment. It prevents breaks from turning into shared ambiguity. The system should also record reassignment, because reassignment can reveal poor classification or missing process design.

Reconciliation Needs Segregation of Duties

Repairing breaks can move money or change accounting classifications. That means reconciliation tools need permission controls.

A user who investigates a break should not always be able to approve their own high-value repair. A technology support user may be able to re-run parsing but not post an accounting adjustment. A payments operator may be able to release a stale hold but not write off a nostro variance.

Typical controls include:

• maker-checker approval for material repairs
• role-based repair action lists
• separate permissions for match override and accounting posting
• mandatory reason codes
• attachment requirements for manual closure
• audit logs for every state change

This is not bureaucracy for its own sake. A reconciliation platform is close to money movement. If one user can create a break, match it manually, post a repair, and close it without review, the control is weak.

A healthy design makes the easy path safe:

operator proposes repair
system validates allowed action
approver reviews source evidence
posting engine enforces idempotency and accounting rules
break closes with repair reference

The workflow should be fast for low-risk items and strict for high-risk ones.

Manual Matching Should Be Constrained

Manual matching is necessary, but unconstrained manual matching is dangerous.

An operator may see two items:

internal: €10,000 outgoing, ref missing, value date 2026-04-24
external: €10,000 debit, vague text, value date 2026-04-24

Those could be the same item. They could also be two different payments with the same amount. A busy nostro account may contain many repeated amounts.

Manual matching should therefore require evidence:

• reference similarity
• counterparty agreement
• amount and currency match
• plausible value date
• no better candidate
• operator note for weak evidence
• approval for material amounts

Some systems compute a candidate score but still require the user to select a reason:

manual_match_reason:
  reference_truncated_by_correspondent
  batch_total_matches_detail
  external_fee_deducted
  rail_reference_missing_but_message_trace_attached

The reason code becomes useful later. If many manual matches use "reference truncated by correspondent", the bank may improve normalisation. If many use "message trace attached", the external statement format may be inadequate.

Manual work should feed process improvement rather than remain invisible labour.

Break Reopening Is a Sign of Weak Closure

A closed break is not always truly solved.

Breaks may reopen because:

• a later statement line contradicts the match
• the repair posting failed downstream
• an operator matched the wrong candidate
• a duplicate external file arrived
• the general ledger rejected the repair journal
• a customer dispute surfaced new evidence

Reconciliation systems should support reopening with a new audit trail. They should also measure reopened breaks.

A high reopen rate often means:

• match rules are too loose
• manual closure standards are weak
• source data arrives out of order
• downstream posting confirmation is not checked
• tolerance policies are hiding unstable items

Closure should mean the item is resolved according to evidence and control rules, not merely removed from a queue.

For accounting repairs, closure should often wait until the repair posting has a confirmed posting group id. For external investigation, closure may require attached correspondence or rail status evidence. For write-offs, closure may require approval metadata.

File Ingestion Quality Shapes Everything Downstream

Many reconciliation problems begin before matching. They begin in file ingestion.

External sources may arrive as:

• ISO 20022 XML
• MT940 or CAMT bank statements
• CSV settlement files
• fixed-width processor files
• API responses
• compressed archives over SFTP

The ingestion layer must handle:

• file completeness
• duplicate files
• sequence numbers
• encoding
• decimal separators
• debit and credit signs
• account identifiers
• cut-off and statement ranges
• late corrections

If ingestion treats a duplicate file as new evidence, the reconciliation platform may create duplicate statement lines. If it drops a correction file, an already closed match may become wrong. If it parses debit signs from the statement perspective incorrectly, every movement is reversed.

This is why ingestion usually stores both raw files and parsed items. A raw file hash helps detect duplicates. A file sequence number helps detect missing statements. A parser version helps explain why historical items changed after reprocessing.

Example controls:

reject file if sequence number already processed
raise alert if expected sequence number is missing
store raw payload hash before parsing
version parser output by rule set
never overwrite a closed source item without reprocessing audit

Reconciliation quality depends heavily on these boring details.

Reconciliation and Customer Support Are Connected

Customers rarely ask for "reconciliation". They ask:

• why did my transfer not arrive?
• why is my card payment still pending?
• why did my refund disappear?
• why did you debit me twice?
• why does the recipient say they never received it?

Support tooling needs reconciliation visibility. A support agent does not need a full accounting workstation, but they need enough state to avoid guessing.

For a payment, support may need to see:

• internal posting state
• rail status
• external confirmation reference
• reversal or return state
• reconciliation break if one exists
• operations owner
• customer-safe explanation

If support only sees "processing", they cannot help. If they see raw internal jargon, they may mislead the customer. The reconciliation system should expose controlled summaries:

Payment sent to receiving bank. Final rail confirmation missing.
Operations status investigation opened at 09:42.
Customer should not retry until final status is confirmed.

That kind of translation reduces duplicate submissions and support escalation.

Reconciliation After Migration Is Especially Sensitive

Core banking migrations, processor changes, and ledger replacements create reconciliation risk.

During migration, the bank may move:

• open customer balances
• historical postings
• active holds
• unresolved suspense
• open reconciliation breaks
• settlement accounts
• mapping rules
• reference crosswalks

If open breaks are not migrated correctly, the new system starts with unexplained differences. If reference crosswalks are incomplete, old external statements cannot match new internal records. If suspense balances migrate only as totals, operations loses the item-level evidence needed for repair.

A strong migration plan includes parallel reconciliation:

old system expected balances
new system migrated balances
external statement evidence
open break inventory
control-account totals

The goal is not only to prove that balances migrated. It is to prove that unresolved items remain explainable after the cutover.

Many migration incidents are not caused by the main account balance. They are caused by old pending items, stale suspense, fee accruals, or clearing accounts that did not map cleanly.

A Reconciliation Engine Should Be Re-runnable

Source data changes. Rules improve. Files arrive late. Parsers get fixed. A reconciliation platform should support controlled reprocessing.

Re-running does not mean deleting history and starting again. It means:

• preserve raw source evidence
• version normalisation rules
• re-evaluate unmatched items safely
• avoid disturbing closed high-confidence matches unless policy allows
• record when a match changed because of reprocessing

For example, suppose a correspondent changes statement references from:

SCTINST/REF/883144

to:

REF883144

The bank adds a normalisation rule. Historical unmatched items may now match. Reprocessing should close those items with the new rule id while preserving the fact that they were previously unmatched.

This is another reason source immutability matters. If the original raw statement line is gone, the bank cannot prove why the new rule is valid.

Control Totals Catch Problems Before Item Matching Does

Item-level matching is powerful, but banks also rely on control totals.

A control total compares aggregate amounts before or alongside detailed matching. For example:

statement file total debits:          €18,420,500
parsed statement debit total:         €18,420,500
internal expected debit total:        €18,420,475
variance before item matching:        €25

This tells the bank several things quickly.

If the statement file total and parsed total differ, the problem is probably ingestion. If parsed total and internal expected total differ, the problem is likely missing booking, fee treatment, timing, or unmatched item population. If the item-level engine claims every item matched while the control total still differs, the match logic is suspect.

Control totals exist at several levels:

• file-level totals
• account-level totals
• currency totals
• debit and credit totals separately
• scheme cycle totals
• batch totals
• general ledger control totals

They are especially useful when files contain thousands or millions of records. The bank can know within seconds whether the file is broadly consistent before every individual item has finished matching.

Control totals also help detect silent data loss. If a parser drops one record because of an unexpected character, item matching may simply never see it. A file-level total mismatch exposes the omission.

Reconciliation Rules Need Test Data Like Any Other Code

Matching rules are business logic. They deserve tests.

A new rule such as "strip prefix SCT/ from external reference before matching" may seem safe. It can still create false matches if the stripped reference becomes too short or common.

Useful tests include:

• exact-match happy paths
• known correspondent reference transformations
• duplicate candidate cases
• same amount and same date but different counterparties
• date tolerance edge cases around holidays
• currency mismatch cases
• already matched item protection
• reprocessing historical unmatched items

A test case might look like:

given:
  internal ref = SCT/883144
  external ref = 883144
  amount = €4,200
  currency = EUR
  value date = 2026-04-24
expect:
  match by rule reference_strip_sct_prefix

Another test should reject:

given:
  internal items = two payments of €4,200 on same value date
  external ref = 883144 with no unique internal reference
expect:
  no auto-match, route candidate to manual review

Without negative tests, reconciliation rules drift toward convenience. They close queues faster while quietly increasing false-match risk.

Reconciliation Has to Handle Corrections From External Sources

External sources can correct themselves.

A correspondent may send a statement line today and a reversal tomorrow. A card scheme may send a late adjustment. A payment rail may issue a correction report. An acquirer may resend a file with corrected settlement references.

The reconciliation system needs to model external corrections explicitly. It should not simply overwrite yesterday's source item.

A correction flow may be:

original statement item loaded
item matched and closed
external correction arrives
new correction item links to original
closed match is reviewed or reopened
repair posting created if needed

The difficult case is a correction against an item that already drove accounting repair. Suppose a bank booked a €25 fee expense because the statement showed a bank charge. The correspondent later reverses that charge. The bank now needs a second explicit accounting event, not deletion of the first repair.

This is the same discipline used in ledgers: preserve history, add corrective events, and keep references linked.

Currency Conversion Adds More Than Rounding

Multi-currency reconciliation is harder than adding a currency column.

An internal system may record a customer transaction in euros, while the external statement shows a movement in Swiss francs. The bank may need to reconcile:

• original payment currency
• settlement currency
• account currency
• exchange rate source
• spread or fee
• revaluation entry
• value date

Example:

customer debit:            €1,020.00
nostro statement debit:    CHF 980.00
internal FX rate:          1 EUR = 0.9608 CHF
scheme or correspondent:   separate fee CHF 1.20

There may be no single "same amount" comparison. The reconciliation rule must know whether the euro entry maps to the franc statement through a specific FX deal, scheme conversion, or treasury rate.

Breaks can arise from:

• rate mismatch
• fee separated externally but bundled internally
• wrong value date rate
• rounding policy difference
• missing FX income leg

For this reason, multi-currency reconciliation often links payment records to FX contracts or rate snapshots. Without that linkage, operations has to reverse-engineer conversion logic from amounts, which is slow and error-prone.

Reconciliation Is a Feedback Loop Into Product Design

Recurring breaks are product signals.

If many card transactions break because a merchant category allows amount uplift, the hold-matching logic may need improvement. If instant payment timeouts generate many uncertain states for one destination bank, routing and monitoring may need attention. If manual matches cluster around one correspondent reference format, normalisation should be updated. If suspense grows for one incoming payment type, the customer reference capture flow may be weak.

Reconciliation data can therefore feed:

• product rules
• fraud monitoring
• payment routing
• customer form validation
• parser improvements
• settlement account design
• support scripts

This is one reason reconciliation should not be treated as back-office cleanup detached from engineering. It is one of the best sources of evidence about where the payment system's abstractions fail against reality.

Engineers should review break populations after major launches. A new payment feature that looks successful by API metrics may still create avoidable reconciliation work. If that work grows linearly with volume, the feature has an operational scalability problem even if latency and uptime look fine.

The Smallest Useful Mental Model

Reconciliation is how a bank proves that internal records, external evidence, and accounting consequences agree.

The key ideas are:

1. a balanced ledger can still disagree with external reality
2. nostro statements, scheme files, rail reports, and sub-ledger feeds provide separate views of the same economic events
3. deterministic matching closes clean items quickly
4. breaks need classification, ageing, ownership, and controlled repair
5. suspense accounts hold unresolved value without pretending it is solved
6. retry queues handle temporary uncertainty, but repair actions must be idempotent
7. old breaks are operational risk, not harmless paperwork

The customer sees a payment, a refund, or a transfer. The bank sees a set of records that must agree across systems and institutions. Reconciliation is the machinery that finds the places where they do not agree yet.

That is how bank reconciliation actually works.