Automatically reconcile payments when a transaction clears

Instead of manually comparing gateway transactions with invoices and bank deposits, configure payment gateway reconciliation automation to match cleared payment records, post approved accounting entries, and route exceptions to finance. Keep payment settlement and bank reconciliation separate: a successful charge does not prove the money reached your bank account.

Why this matters

A gateway payment, a settlement entry, and a bank deposit describe different accounting events. Treating them as interchangeable creates false matches, unexplained balances, and invoices marked paid against the wrong evidence.

Match the payment to the receivable; match the payout to the bank deposit. Use a clearing account to connect those stages without pretending they happen simultaneously.

For a 2026 implementation, define the accounting event before choosing the integration technology. A consultation with Hexagon IT Solutions can start with that workflow definition rather than a list of connectors.

This guide is a platform-neutral build specification. The field names below are proposed internal fields, not instructions for a particular vendor dashboard.

Before you start

• Access and permissions: Obtain gateway API or export access, settlement reports, accounting-system access, and bank-feed access. Use separate testing credentials and restrict production permissions to the actions the integration needs.
• Accounting materials: Gather invoice references, merchant-account identifiers, currency codes, fee mappings, clearing-account details, and finance-approved posting rules. Assign an owner for unmatched payments and adjustments.
• The gotcha: Confirm exactly what the gateway means by cleared, captured, settled, and paid out. Build against the documented event that supports your accounting policy; do not interpret a successful authorization as settled cash.

Before enabling production writes in 2026, have finance approve the rules for partial payments, overpayments, refunds, and foreign-currency transactions. If an event lacks the evidence required by those rules, the workflow should retain it without posting.

Transaction intake

The first configuration unit accepts payment evidence without immediately changing the ledger. Its job is reliable intake, not premature reconciliation.

Configure the event source

1. Identify the gateway event or settlement-report entry that represents your approved clearing milestone. Record the provider's documented meaning alongside the integration configuration.
2. Configure the event receiver or scheduled report import. For webhooks, validate authenticity using the provider's documented verification procedure before accepting the payload.
3. Store the original event and normalize the fields needed downstream: merchant_account_id, transaction_id, event_id, status, currency, gross_amount, and available invoice references.
4. Acknowledge receipt after durable storage, then process the record through a queue or equivalent recoverable mechanism. Keep intake separate from accounting writes so an accounting outage does not erase payment evidence.

Expected result: An accepted payment event exists in durable storage with its source, processing status, and original payload. No invoice has been closed merely because a message arrived.

Keep timestamps for the payment event, settlement entry, and ingestion separately. A delayed message should not silently become a payment dated on the day your integration received it.

For your 2026 configuration, document how the integration retrieves events missed during an outage. A webhook receiver without a recovery path leaves finance dependent on manual discovery.

Matching rules

Matching connects payment evidence to an existing receivable. It must establish identity before testing amounts.

Configure the match decision

1. Look up an existing payment using the merchant-account identifier and gateway transaction ID. If that payment already exists, continue its workflow rather than creating another payment.
2. Resolve the invoice using an explicit invoice reference or a stored relationship created when the payment was initiated. Do not use customer name or payment amount as the sole identifier.
3. Validate currency, invoice status, and the amount remaining. Apply only finance-approved allocation rules for partial payments or payments covering multiple invoices.
4. Assign the result to a controlled state: matched, unmatched, or review_required. Record the matching rule and evidence behind the decision.

Expected result: Each payment has either a defensible invoice allocation or a visible exception. An ambiguous payment cannot silently become a completed reconciliation.

Use exact identifiers for automatic matching; reserve fuzzy matching for suggested matches. Identical amounts are not proof that two records represent the same payment.

For example, two customers can pay invoices with the same balance. A shared amount establishes no relationship between either payment and either invoice; the invoice reference or stored payment relationship supplies that evidence.

Make exception reasons specific. Missing invoice reference, currency mismatch, and invoice already closed require different fixes, so they should not share a generic failed status.

Ledger and settlement records

A gateway clearing account keeps customer payment recognition separate from the later movement of money into the bank. Finance must approve the actual account mappings and journal treatment.

Configure the accounting action

1. Create or update the accounting payment using the accounting system's supported interface. Attach the gateway transaction ID and apply the approved invoice allocation.
2. Use a stable operation key for duplicate protection. Where the destination supports idempotency, send that key; otherwise maintain a processing record and check the destination before retrying an uncertain write.
3. Record gateway fees, refunds, reserves, and other settlement adjustments separately under approved account mappings. Do not reduce the customer's payment allocation simply because the gateway deducts a fee from the payout.
4. Group settlement entries by payout identifier. Compare the documented payout total with the corresponding bank entry, accounting for the adjustments included in that payout.

Expected result: The invoice allocation, gateway clearing balance, and bank deposit have traceable relationships. A payment can be recorded while its payout remains awaiting bank confirmation.

The accounting sequence is payment intake, invoice allocation, ledger posting, and bank matching. Each stage needs its own evidence and processing status.

Do not calculate the expected bank deposit by summing customer payments alone. Use the gateway's settlement breakdown so fees and adjustments remain explainable.

A remaining clearing-account balance is a reason to investigate, not permission to force a balancing entry. Establish whether the difference represents an unsettled payment, an omitted adjustment, or a matching error.

Validation and release controls

A successful API response proves that a request completed, not that the accounting result is correct. Validate the records created and the balances affected.

Configure acceptance checks

1. Test 5 scenarios before release: a normal payment, a duplicate event, a partial payment, a refund, and a payout containing a fee. Inspect the resulting invoice allocation and accounting entries for each scenario.
2. Replay 1 identical event and confirm it creates no additional financial effect. Then simulate a timeout after the destination accepts a write; verify that retrying does not duplicate the payment.
3. Begin with 1 merchant account and 1 currency to limit the initial rule set. Expand only after finance confirms that payment, settlement, and bank records agree.
4. Enable alerts for rejected events, unresolved destination writes, and reconciliation exceptions. Give every alert an owner and a documented recovery action.

Expected result: Finance can trace a test payment from gateway evidence to invoice allocation and bank matching, including a safe retry path.

Treat these counts as a starting checklist, not proof of complete coverage. Add cases for every payment method, currency, adjustment type, and allocation rule included in your release.

Keep a dated 2026 acceptance record showing the rules approved, scenarios checked, and release owner. Avoid storing full card details in logs or test fixtures; retain only the payment references and evidence needed for reconciliation.

Reconcile whenever a settlement record is updated

A second workflow handles changes after the initial payment match. Use it when a gateway publishes later settlement details or an adjustment changes the accounting evidence.

Neither workflow replaces the other. The first answers which invoice a payment belongs to; the second answers how payment activity became a bank deposit.

For the settlement-update variant:

1. Receive the updated settlement record through a documented event or repeatable report import.
2. Retrieve the existing payout and its linked transactions using stable identifiers.
3. Compare the new source record with the previously processed version.
4. Apply only the new, approved adjustment and retain the prior record for audit history.
5. Re-evaluate the payout-to-bank match and reopen an exception when the evidence no longer agrees.

Expected result: Later changes update the reconciliation trail without reposting the original customer payment.

For 2026 reporting, preserve both the original payment date and the adjustment date. Finance should determine the accounting period for a correction rather than allowing an integration timestamp to choose it.

Troubleshooting

The same payment appears twice

Check whether duplicate protection uses only the delivery event ID. Different events can describe the same underlying transaction, so protect the accounting operation with the merchant account, transaction identity, and operation type as well.

If a write timed out, inspect the destination before repeating it. An unknown response is not proof that the write failed.

The bank deposit is smaller than customer payments

Inspect the settlement breakdown for fees, refunds, reserves, and other adjustments. Compare the bank deposit with the documented payout total, not an unadjusted sum of invoice payments.

Do not alter invoice allocations to hide the difference. Fix the settlement mapping or route the unexplained amount to finance.

A cleared payment has no invoice match

Check whether the invoice reference survived checkout, gateway processing, and event normalization. Also verify that the invoice exists in the correct company or accounting entity.

Send the payment to an unmatched-payment queue with its source evidence. Do not close a similar-looking invoice as a fallback.

Payment and settlement events arrive out of order

Retrieve the current source record and evaluate the permitted state transition. Retain event history, but do not let an older event overwrite a later confirmed state.

Keep refund and dispute activity separate from the original payment's delivery sequence. Later financial activity needs its own accounting decision.

Customize your workflow

Expand the scope after the core payment-to-bank trail works. Add another gateway, currency, or business entity as a distinct rule set rather than copying assumptions from the first connection.

Choose the implementation approach against concrete requirements: event recovery, stable identifiers, destination duplicate protection, settlement-detail access, and readable exception handling. The guide to API integration platforms for businesses provides a related starting point for evaluating the connection layer.

Track outcomes from your own records: unresolved exceptions, duplicate postings, manual interventions, and time between source availability and completed matching. Establish a baseline before claiming time savings or return on investment.

Review the workflow whenever a gateway changes its event schema or finance changes an account mapping. A 2026 configuration document should identify who approves those changes and how the integration is retested.

FAQ

One last thing

An unresolved exception is better than a confident false match. Give finance the transaction evidence, failed rule, and next action; do not reward the workflow for clearing records it cannot explain.

The release criterion is traceability, not an empty exception queue. A reviewer should be able to follow the customer payment through its invoice allocation, settlement adjustments, and bank deposit without reconstructing the story from disconnected logs.

Related guides

• Payment gateway platforms for businesses
• Business intelligence tools for enterprises
• NetSuite alternatives for growing businesses

Schedule a consultation with Hexagon IT Solutions to define your payment events, matching rules, and exception controls before connecting the workflow to your ledger.