Payment reconciliation for ecommerce: why don’t payouts match orders?

Why don’t payment processor payouts match your orders?

Payment reconciliation means proving that the money a business expected to receive is the money that arrived, and explaining every difference. For an online store the hard part sits between the order and the bank. A card or wallet payment is captured by a payment processor, held in a balance with that processor, and later paid to the bank in a batch. Each batch, usually called a payout or settlement, is a net amount for many transactions, and it is built on the processor’s calendar rather than the store’s. This is narrower than bank reconciliation, which compares the bank statement with the ledger balance. Payment reconciliation goes underneath each deposit to the payments, fees, refunds and disputes inside it.

An AI-initiated purchase adds another evidence chain before the payment: who delegated it, the approved offer and the merchant’s acceptance. The agentic order acceptance and authority guide shows how to keep those records linked without mistaking payment permission for a completed order.

Processors run two separate clocks. Settlement timing decides when a captured payment becomes available in the processor balance, often a few business days later. The payout schedule decides when available funds are sent to the bank: daily, weekly, monthly or on request. Each payout is simply the available balance at the moment it was created, net of everything deducted since the last one. An order total and a bank deposit therefore almost never agree on their own.

What does one ecommerce payout look like line by line?

Take an illustrative homewares store. On Monday 14 September it takes five web orders worth $600 in total, including tax and shipping. Four were paid by card through its main processor and one through a separate wallet provider. On Wednesday a deposit of $311.19 arrives in the bank with the processor’s payout reference in the description. The fee rate and dispute fee below are invented. The refund line returns no fee because many processors keep the original processing fee when a payment is refunded. Check your own agreement, because fees and refund terms differ by provider and contract.

The payout contains three of Monday’s orders, plus a refund and a chargeback that belong to earlier orders. It does not contain order 1044, captured after the processor’s cut-off, or order 1045, which was paid through the wallet provider. A bridge from the order report to the deposit makes the gap explainable:

Booking $311.19 as sales would understate revenue by $133.81, hide $28.81 of fees, lose the link between the refund and order 1027, and leave order 1044 unexplained until the next deposit. Each item in the bridge needs a separate entry, an owner and an ID that leads back to an order.

How do you reconcile a payout step by step?

The worked example follows the same six steps for every payout. Work payout by payout rather than day by day: the payout is the unit the processor and the bank agree on, and it stops a batch that crosses a weekend or month-end from being counted twice.

Which IDs connect an order to a bank deposit?

Reconciliation becomes a lookup instead of an investigation when four links are reliable: order to payment, payment to balance transaction, balance transaction to payout, and payout to bank line. The most important decision is made at checkout. The commerce system should send its own order ID to the processor as a reference or metadata field, so the order ID comes back on every charge, refund and dispute in the settlement report.

Processors expose these links under different names. The table shows three documented examples, checked on 3 October 2026, so the pattern is concrete. Use it to find the equivalent fields in your own provider’s reports. It is not a ranking of providers.

Two limits matter for automation. Where a processor offers instant payouts, the merchant chooses their timing and amount, so the processor may not be able to say which transactions an instant payout contains; those have to be reconciled against the transaction history instead. Some reports also group payouts by expected arrival date rather than the date the bank posts the deposit, and the itemised data can be ready after the money arrives. Build a matching window of a few business days rather than expecting the same date on both sides.

What changes when payment is captured at dispatch?

Many stores that ship physical goods authorise the card at checkout and capture the money only when the order ships, so a customer is not charged for items that cannot be sent. Reconciliation then has to follow shipments as well as orders. Three constraints shape the design. An online card authorisation typically lasts about seven days, depending on the card network and processor. Capturing less than the authorised amount usually releases the remainder. And many processors allow only one capture per authorisation, unless they support multiple captures for eligible card payments.

The matching rule changes from “one order, one charge” to “captures less refunds equal the amount invoiced for what shipped”. That only works if the fulfilment system sends shipment and capture IDs back to the order, which is a design decision covered in the ecommerce fulfilment workflow guide. Authorisations close to expiry belong on the daily exception list, because a missed capture means goods shipped without payment.

How should the payout be recorded in the accounts?

The common pattern is a clearing account for each processor and currency, sometimes called a processor receivable or undeposited funds account. Sales are recorded at their gross value when the order is invoiced or paid. The payout report then moves fees, refunds and chargebacks out of the clearing account to the right accounts, and the bank deposit clears the remainder. If everything is posted correctly, the clearing account returns to zero for that payout. Processor fees can include sales tax, VAT or GST. Some itemised reports show that tax in its own column while also including it in the fee, which matters where the tax can be reclaimed. The exact accounts, timing and tax treatment are decisions for your accountant; the postings below show the mechanism for the illustrative payout.

Order 1044’s $60 sits in the clearing account until payout PO-0917 arrives. That is correct, not an error. At month-end, the clearing balance should equal the processor’s unsettled balance: captured or adjusted transactions not yet paid out. Most processors report an ending or unsettled balance that can be used for that check. Shopify notes that its Payments activity report is not a statement of revenue, which is a useful reminder: the payout report proves cash and deductions, while the commerce and accounting records prove revenue.

How does a chargeback move through the accounts?

A chargeback is not settled when the money leaves. When a card dispute opens, the processor typically withdraws the disputed amount and a dispute fee straight away. The business usually has one to three weeks to respond, depending on the card network, and the whole process can take two to three months. If the business wins, the disputed amount comes back, but the fee for receiving the dispute is often kept. The disputed amount can also differ from the original charge, for example after currency conversion or when only part of an order is disputed. Treat the withdrawn amount as a receivable until the outcome is known:

Decide early whether postings are summarised or itemised. Posting each order separately gives full traceability but floods a small accounting system with entries. A daily or per-payout summary entry with the itemised report attached keeps the ledger readable, provided that every amount in the summary can still be traced to an order ID.

What matching rules should a reconciliation process follow?

Whether a person or a program does the work, write the rules down. Each rule needs a match key, an allowed tolerance and an owner for the exceptions it produces. Matching by amount alone is the most common shortcut and the most common source of wrong matches, because many orders share the same total.

Exceptions should sit in a list with the order ID, amount, reason and owner, not in a reviewer’s memory. A charge with no order is especially important. It can be a manual payment taken over the phone, a test made in production or a checkout fault that took money without creating an order. Each needs a different fix, and only the last one is urgent for customers.

Four set-up mistakes cause most of the rework these rules then have to catch:

• Booking the deposit as revenue. Fees never appear as an expense and revenue is understated. Post sales gross through the clearing account and post only the deposit against it.
• Posting refunds twice. Once from the commerce refund and again from the payout report. Let one system own each posting; the other only matches.
• Reconciling by bank date. A payout that spans month-end leaves sales in one month and cash in the next. Work by payout ID and check the clearing balance against the unsettled balance.
• Ignoring a second processor. Wallet or buy-now-pay-later orders look unpaid. Give each processor and currency its own clearing account and payout import.

Should you reconcile payouts in a spreadsheet, an app or a custom integration?

Volume alone does not decide the method. The number of processors, currencies and sales channels matters more, along with whether refunds and disputes are frequent and whether the accounting system can import itemised data. All four approaches below need the same ID chain and rules. Automation applies the rules faster; it does not supply them.

A practical route for many stores is to start with exported reports and a written bridge for each payout, then automate the parts that repeat. The first parts to automate are usually importing the itemised report and posting fees, refunds and disputes. Matching the payout to the bank line can follow. Keep a person reviewing the exception list in every option.

How do you test a payment reconciliation process before relying on it?

Run these cases in the processor’s test mode where it offers one, then confirm them against one real month of payouts before switching off the old process. Each case has a single pass condition that finance can check without reading code.

Where should a store start?

Pick last month’s three largest payouts. For each, download the itemised payout report and build the bridge from the order report to the bank deposit, as in the worked example. If every line can be traced by ID, the work left is posting discipline and perhaps automation. If charges can only be matched by amount, fix the checkout first so the order ID reaches the processor. If orders and invoices disagree between the store and the ERP, the ecommerce ERP integration guide covers that upstream problem. Reconciliation cannot be more reliable than the order record it starts from.

Harmatiq’s accounting and reporting work covers this route: passing order IDs through checkout, importing payout reports, posting fees, refunds and disputes through clearing accounts with your accountant’s rules, and setting up the exception list your finance team will keep running.