Home / Wiki / R / Reconciliation API

Reconciliation API

Financial InfrastructureUpdated 05 Nov 2026

A reconciliation API is a programming interface that supplies, or accepts, the data needed to reconcile payments: transaction records, fees, payout and settlement batches, bank statement lines and, in some products, the results of matching them. Merchants, marketplaces, fintechs and finance teams use reconciliation APIs to confirm automatically that every payment they expected arrived, in the right amount, and that the money in the bank agrees with their books.

The term is practitioner language with two common meanings. It can describe the reporting endpoints that a payment service provider (PSP), bank or card processor offers so that customers can download line-level detail behind each payout. It can also describe the interface of a dedicated reconciliation platform, through which a business loads data from several sources and retrieves matched items and exceptions. Either way, it automates the underlying discipline of reconciliation.

01

Reconciliation API in plain terms

At the end of each month, a small shop owner sits with a pile of receipts and a printed bank statement and ticks off each line that matches. Anything left unticked is a question: a missing payment, a fee nobody mentioned, a refund entered twice.

A reconciliation API lets computers do the ticking. Instead of printing a statement, the shop's accounting software asks the bank and the card company for their lists directly, lines them up against its own records and shows the owner only the handful of items that do not match.

02

What a reconciliation API exposes

  • Transaction records. Each sale, refund, chargeback and fee, with a stable identifier, amount, currency and timestamp.
  • Payout or settlement batches. The list of transactions included in each bank deposit, so that one lump sum can be broken back into its parts.
  • Fee breakdowns. For card payments, the split between interchange, scheme fees and the processor's own margin.
  • Bank statement data. Statement lines in a format such as ISO 20022 camt.053, often obtained through balance reporting.
  • Events. Webhooks announcing a new payout, a return or a dispute, so systems need not poll.
  • Match results. On reconciliation platforms, the status of each item (matched, partly matched, exception) and tools to resolve exceptions.
03

How automated matching uses the data

Matching rules compare references, amounts and dates. Some matches are one-to-one, such as a single invoice paid by a single transfer. Many are one-to-many: a card processor's daily payout settles hundreds of sales net of fees and refunds. The payout should equal:

Payout=∑Sales−∑Refunds−∑Fees−∑Chargebacks\text{Payout} = \sum \text{Sales} - \sum \text{Refunds} - \sum \text{Fees} - \sum \text{Chargebacks}

Each term is the total for the transactions included in that payout batch. Suppose a merchant's batch contains $10,000 of sales, $60 of refunds, $300 of fees and no chargebacks. The expected deposit is 10,000−60−300−0=9,64010{,}000 - 60 - 300 - 0 = 9{,}640, or $9,640. If the bank statement shows $9,640, the batch is reconciled; if it shows $9,540, the API's line-level data helps find the missing $100. This layered work, from transaction to payout to bank line, is described under payment reconciliation, settlement reconciliation and multi-step reconciliation, while item-by-item checks are covered by transaction reconciliation.

04

Design considerations

Good reconciliation APIs share a few properties. Identifiers stay stable across systems, so a sale can be traced from checkout to settlement to the bank. Records are immutable: corrections arrive as new adjusting entries, never as silent edits, which keeps an audit trail. Large result sets are paginated with cursors, and time windows are defined clearly, because a payment made just before midnight in one time zone can land in a different reporting day in another. Writes, such as marking an item as resolved, should be protected by idempotency keys, and access should follow role-based access control, since the data includes customer and bank details.

05

Place in the accounting process

Reconciled data flows onward into the company's books. Matched payouts become journal entries in a subledger or directly in the general ledger, usually inside an ERP system. Unresolved exceptions must be cleared before the financial close, and auditors often ask for evidence that reconciliations were performed and reviewed. Platforms holding customer money, such as wallets and marketplaces, also use the same data for bank reconciliation of safeguarding or for-benefit-of accounts, where a gap between the ledger and the bank is a regulatory as well as an accounting problem.

Last updated 05 Nov 2026