Card program reconciliation is the process of proving that authorizations, clearing records, settlement movements and cardholder ledger entries agree. These records arrive at different times and can change through reversals, adjustments and disputes. A daily control needs stable identifiers, clear cut-off times and an owner for every exception.

A successful authorization is only the beginning.

Follow the transaction through separate stages

A card transaction commonly produces several records:

  1. Authorization: the merchant asks whether the transaction can proceed.
  2. Authorization response: the issuer side approves or declines and can place a hold.
  3. Reversal or expiry: an unused or changed authorization can release all or part of the hold.
  4. Clearing: the merchant side submits the financial record, which may differ from the authorization.
  5. Settlement: network positions and funding move between the participating institutions.
  6. Cardholder posting: the program turns cleared activity, fees and adjustments into ledger entries.
  7. Dispute or adjustment: a later event can change the financial result.

These stages should not be flattened into one “completed” status. A team needs to know which record exists and which one is still expected.

Use identifiers that survive the whole flow

The reconciliation model should retain the identifiers supplied by the processor and network, plus the program’s own transaction and ledger IDs. Merchant name and amount are not unique enough.

At minimum, record:

  • program and account ID;
  • card token or safe internal card reference;
  • authorization ID;
  • network and processor references;
  • merchant and acquirer data;
  • authorization amount and currency;
  • cleared amount and currency;
  • settlement amount and currency;
  • timestamps and cut-off date;
  • reversal and adjustment links;
  • ledger entry IDs;
  • exception status and owner.

Keep raw source records immutable. Corrections should create linked entries rather than erase the evidence used in the earlier reconciliation.

Match authorization to clearing without demanding equality

An authorization and its clearing record do not always have the same amount. Hotels, car rentals, restaurants and other merchants can complete for a changed amount. Partial reversals and incremental authorizations also affect the final result.

A matching engine should use identifiers and permitted tolerances, not amount alone. It should distinguish:

  • one authorization to one clearing record;
  • several authorizations to one clearing record;
  • one authorization to several presentments;
  • clearing without a matching authorization;
  • authorization with no clearing after the expiry window;
  • duplicate clearing;
  • late presentment;
  • partial and full reversal.

A difference can be valid. It still needs a reason code.

Reconcile three balances, not one

A card program usually needs at least three related reconciliations.

Network or processor reconciliation checks authorization, clearing and adjustment files.

Settlement reconciliation checks calculated obligations against actual funding movements and statements.

Cardholder-ledger reconciliation checks holds, posted transactions, fees, refunds and adjustments against the account balance.

A fourth control often links the program ledger to the sponsor bank’s account or general ledger. The exact architecture depends on who operates each ledger, but no balance should be assumed correct simply because the user interface displays it.

For the broader distinction between records, see account reconciliation: ledger vs bank balance.

Define the cut-off before measuring breaks

Records can arrive after midnight, in another timezone or after a network cut-off. A report that mixes event time, file date and settlement date will produce false breaks.

Document:

  • the business timezone;
  • daily cut-off;
  • expected file-delivery window;
  • settlement calendar;
  • weekend and holiday handling;
  • maximum expected clearing delay;
  • when an open item becomes an exception.

Keep the original timestamps. The reporting date is a derived field, not a replacement.

Reversals need their own control

An authorization reversal can release a hold, but it does not always prove that no clearing record will arrive. A clearing adjustment can occur after settlement. A dispute can create a new financial entry weeks later.

Link each reversal to the original event and test:

  • whether the hold changed;
  • whether a clearing record later arrived;
  • whether the cardholder ledger posted both events correctly;
  • whether settlement reflected the final position;
  • whether any fee was reversed.

Do not “net away” the trail before the exception is explained.

Reconcile fees explicitly

Network, processor, sponsor and foreign-exchange fees may appear in different files or invoices. Store them as named components rather than one unexplained difference.

For each fee, identify:

  • source record;
  • calculation basis;
  • currency;
  • party charged;
  • ledger account;
  • settlement or invoice date;
  • contractual schedule used.

This matters when a program changes processors or pricing schedules. A historical calculation must use the terms that applied on the transaction date.

Give every exception an owner and clock

A useful exception queue contains the amount at risk, age, reason, source records and next action. Typical buckets include:

  • missing clearing;
  • missing authorization;
  • duplicate record;
  • unmatched settlement movement;
  • ledger posting failure;
  • unexpected fee;
  • currency or rate difference;
  • late file;
  • reversal mismatch.

Assign ownership across processor operations, program finance, sponsor bank, fraud operations and customer support. The program should know who can close an exception and what evidence is required.

Controls for a sponsor-bank review

Visa’s VisaNet Connect issuing documentation calls for daily review of exception and settlement reconciliation reports for directly connected participants. A sponsored fintech can have a different technical setup, yet a sponsor still needs credible evidence that reconciliation is complete and exceptions are managed.

Prepare:

  • file inventory and delivery monitoring;
  • end-to-end transaction map;
  • daily control totals;
  • exception ageing;
  • settlement funding evidence;
  • access and change logs;
  • month-end sign-off;
  • escalation thresholds;
  • business-continuity steps for a missing file.

The BIN sponsorship guide explains the sponsor relationship. The instant card issuance guide covers the customer-facing creation flow.