Skip to main content
Every settlement day, two independent records of the same card activity reach Lead: the network’s settlement report (the aggregate money truth — what the network cleared and drew down) and the transactions you report in your daily Transactions file (the customer-level truth — which cardholder spent what). Network settlement reconciliation is Lead matching the two, so that the funds Lead moved to the networks (Funding Obligations) are fully explained by customer activity you’ve attributed.

​
What Gets Matched

  • The key is the settlement date, card network, and BIN. You report each posted card transaction with its network settlement date — the date the network cleared it, which is the date whose report it must tie to. The card network and BIN ensure it identifies the correct report if there are multiple involved.
  • The check is aggregate. The sum of your reported card transactions for a settlement date (gross spend, gross refunds) is compared against the transaction and refund amounts in that date’s network report. Interchange, disputes, and network fees are network-level components that Lead books from the report itself — your transaction reporting covers the spend and refund legs.

​
What You Must Report for a Day to Tie Out

  • Every posted transaction, with its settlement date — reported through the daily Transactions file no later than 6:00 a.m. CT on T+1.
  • Both legs of same-day exceptions. If a transaction clears on settlement date T and is reversed the same day, the network report includes the spend in the transaction amount and the reversal in the refund amount — so both transactions must be reported to Lead for the day to pass reconciliation.
  • The settlement report itself, on time and in a supported format — reconciliation can’t run against a missing report (formats).
Network timing nuances. Some networks’ report dates and funds-movement dates differ — for example, Pulse’s PRC643 aligns to settlement date T while funds move T+1 or T+2 depending on purpose. Lead manages this behind the scenes; from your side, nothing changes — you report each transaction’s settlement date as the date the network cleared it. Per-network specifics: Network Settlement Reports.

​
When a Day Doesn’t Tie Out

Reconciliation breaks surface through your program’s Slack alert channel as validation alerts on the file cycle, and do not block file processing. The usual causes, in order of frequency:
  1. Missing transactions — activity the network settled that you haven’t reported yet (often the reversal leg of a same-day exception). Fix: report the missing transactions in a future file version.
  2. Wrong settlement date — transactions reported against the posting date or authorization date instead of the network settlement date, so they tie to the wrong day’s report. Fix: correct the date and submit in a future file; the recovery loop is the standard one.
  3. A late or malformed settlement report — the network file for the day hasn’t arrived or wasn’t parseable. Funding proceeds independently, but reconciliation waits; coordinate with your issuer processor on delivery.
For credit programs, an unreconciled day also matters downstream: network settlement is what originates the day’s receivables, so recon breaks and daily sale discrepancies usually share a root cause — fix the transaction reporting and both resolve. Still stuck? Escalate in your Slack channel with the settlement date, the network, and the delta the alert reported.