A payment event and a bank settlement are different moments.
An authorization, capture, refund, fee and settlement can arrive at different times and from different sources. If the integration treats them as interchangeable, the business may see a paid order while finance still has an unexplained balance.
We follow that lifecycle with finance and the provider. An illustrative reconciliation might explain a settlement as gross captures less fees and refunds, with timing differences held separately. The design needs the identifiers and dates that support that explanation, alongside the approved accounting treatment.
Payment and settlement are different moments
A conceptual relationship. Timing, fees, refunds and currency affect how the records are reconciled.
Preserve the detail that makes reconciliation possible.
Stable references
Carry appropriate transaction, invoice, payment and settlement identifiers across systems. These references help distinguish a missing event from one that has been recorded under a different relationship.
Fees, refunds and adjustments
Model the ordinary differences between a gross transaction and the amount settled. Include partial refunds, reversals and adjustments in the design rather than treating them as rare exceptions.
Timing and currency
Agree dates, periods, currencies and the treatment of timing differences. Define who investigates an unmatched item and which information they need to resolve it.
Design the connection with finance at the table.
- 01
Map the financial events
Trace the journey from the originating transaction to settlement and reconciliation. Separate operational status from the accounting entries required by your policy.
- 02
Confirm provider and account constraints
Review available interfaces, supported records, permissions and relevant licenses. Establish the boundaries of responsibility between the payment provider, bank, finance team and implementation team.
- 03
Validate representative cases
Test successful transactions, failures, partial payments, refunds, fees and repeated notifications. Reconcile the resulting records and amounts with the source evidence.
- 04
Prepare controlled recovery
Document how to investigate and correct an exception. Define safe reprocessing so a repeated event does not create a second payment or accounting effect.
Limit sensitive payment data by design.
The integration should use provider-supported references and appropriate data-handling methods. Avoid moving full payment credentials or unnecessary personal information into working files, logs or support requests. Security and compliance requirements must be assessed for the actual payment architecture and providers involved.
A dependable process also needs operational controls. Decide who can change mappings, initiate corrections and approve financial adjustments. Keep those authorities visible, particularly where automation prepares records for a later review or posting step.
The limit of automatic matching
- Can reconciliation be fully automated?
Some matching can be rule-based, but the appropriate level depends on data quality, references and the range of exceptions. Define confidence, tolerances and review responsibilities with finance. Preserve a clear route for items that do not meet the agreed rules.