# Ecommerce Reconciliation Across Platforms and Banks

- Author: PreciseBankFlow (https://www.precisebankflow.com)
- Published: 2026-08-10
- Updated: 2026-08-10
- Category: Payment and deposit reconciliations
- Canonical: https://www.precisebankflow.com/blog/ecommerce-reconciliation

> Ecommerce reconciliation across platforms: orders, payouts, fees, returns and taxes, a monthly routine and how to tie several channels to one bank.
Ecommerce reconciliation proves that every order a store took was either paid out to the bank, refunded, held back by the platform or still in transit, with fees and taxes accounted for along the way. It runs channel by channel, from order reports to payout reports to bank deposits, and ends with each platform's balance explained.

## Which records does an ecommerce reconciliation connect?

An ecommerce reconciliation connects four records: the orders the customer placed, the payout reports from each platform or payment processor, the ledger entries the bookkeeper posted, and the deposits on the bank statement. Each record is kept by a different system, and none of them, alone, shows whether the money arrived.

What each record holds:

- **Orders.** The storefront or marketplace order export: order number, date, item amounts, shipping charged, tax collected, discounts and the payment method.
- **Payouts.** The platform's settlement or payout report: which orders, refunds, fees and adjustments were combined into each transfer to the bank.
- **Ledger.** The entries recording sales, fees, refunds and taxes, usually posted from the payout reports or a summary of them.
- **Bank.** The deposit lines, which show only the net amount of each payout and the date it landed.

The reconciliation works in two directions. Forward from orders, it checks that every sale ended up somewhere. Backward from the bank, it checks that every deposit is explained by orders and their deductions. A store that only works backward will miss orders that were never paid out, and a store that only works forward will miss deposits it cannot explain.

## Orders, payouts and fees: three layers of ecommerce reconciliation

The three layers of ecommerce reconciliation are orders to payouts, payouts to ledger, and ledger to bank. Each layer answers one question. The first asks whether the platform paid for what it sold. The second asks whether the books recorded the payout correctly. The third asks whether the bank received it.

**Orders to payouts.** For each payout, list the orders it contains and add them up, then subtract the refunds, fees and adjustments the payout report shows. The result should equal the payout. Orders that appear in no payout are either still pending, held by the platform, or paid outside it.

**Payouts to ledger.** Record each payout at gross: sales and tax collected as credits, platform fees and refunds as debits, and the net amount to a clearing account for that platform. When the payout reaches the bank, move it from the clearing account to the bank. The clearing account's balance at month end should equal payouts that were issued but had not yet landed.

**Ledger to bank.** This is the ordinary bank reconciliation. Each deposit from a platform should match one payout in the clearing account. For the choice between matching line by line, by batch or by proof of cash, see [bank reconciliation methods](/blog/bank-reconciliation-methods).

Platform reports differ in their names and columns, but each one supports these three layers. [Reconciling Shopify payouts to orders](/blog/reconcile-shopify-payouts) and [Amazon settlement reconciliation](/blog/amazon-settlement-reconciliation) walk through two common platforms in detail.

## Returns, refunds and sales tax in ecommerce reconciliation

Returns, refunds and sales tax are the amounts in an ecommerce reconciliation that either leave the business again or never belonged to it. A refund reduces sales in the period it is issued. Sales tax collected is a liability to the taxing authority. Both pass through payouts, so both must be pulled out before payouts are compared to sales.

**Refunds.** A refund usually comes out of a later payout than the original sale, sometimes in a later month. Record it in the month it was issued and match it to the payout it reduced. Some platforms also return part or all of the original fee when a refund is issued, and that fee credit should reduce fee expense rather than increase sales.

**Returns without refunds.** A return that was received but not yet refunded is an obligation, not cash. Track it from the returns log until the refund appears in a payout.

**Sales tax.** Taxes collected through the platform need to be split by who remits them. Where a marketplace collects and remits the tax itself, the tax flows through the order report but may never reach the seller's payout. Where the seller remits, the tax arrives in the payout and must be set aside as a liability. Either way, sales tax should not appear in revenue.

**Shipping.** Shipping charged to customers is revenue, and shipping labels bought through the platform are an expense, often deducted from the payout. Keep them as separate lines, so the shipping margin is visible.

## How do you tie several ecommerce channels to one bank account?

Tie several ecommerce channels to one bank account by giving each channel its own clearing account in the ledger, recording every payout to its channel's clearing account, and matching each bank deposit to exactly one payout. The bank sees one stream of deposits; the clearing accounts keep the channels apart.

A month-end channel summary makes the tie visible. The example below is for an illustrative store selling through its own site, a marketplace and a social shop. All figures are invented.

| Channel (example) | Opening clearing balance | Payouts issued | Deposits received | Closing clearing balance | In transit at month end |
| --- | ---: | ---: | ---: | ---: | --- |
| Own site, card processor | 1,840.00 | 38,420.00 | 37,960.00 | 2,300.00 | One payout of 2,300.00, landed 1st |
| Marketplace | 4,215.50 | 21,380.25 | 22,110.75 | 3,485.00 | Settlement of 3,485.00, landed 3rd |
| Social shop | 0.00 | 2,960.40 | 2,960.40 | 0.00 | None |
| Total | 6,055.50 | 62,760.65 | 63,031.15 | 5,785.00 | |

The deposits column should agree with the total of platform deposits on the bank statement for the month, 63,031.15 in the example. Each closing balance should be explained by a named payout that landed after month end. A closing balance with no payout behind it means a deposit was posted to the wrong channel, or a payout was recorded twice.

Bank descriptions for platform payouts are often vague, especially when two platforms use the same payment network. Use the payout amount and date to choose the channel, and when two payouts of similar size land on the same day, check the payout IDs in each platform's report.

## A monthly ecommerce reconciliation routine, step by step

A monthly ecommerce reconciliation routine follows the same order every month: export, rebuild payouts, post, match the bank, then explain what is left. Keeping the order fixed makes it possible to hand the work to someone else and to compare months. The steps below fit a store with a few channels and one bank account.

1. **Export** the order report, the payout report and the fee report for each channel, for the calendar month. Add the first few days of the next month to the payout export.
2. **Rebuild each payout** from its orders, refunds, fees and adjustments, and confirm the total equals the payout amount the platform reports.
3. **Post** one summary entry per payout, or per channel per month, at gross: sales, shipping, tax collected, refunds, fees and the net to the channel's clearing account.
4. **Match the bank.** Tick each deposit against a payout in the clearing accounts. Note any deposit that matches nothing.
5. **Explain the clearing balances.** Each should equal payouts in transit. List them by payout ID.
6. **Reconcile tax collected** to the liability account, split by who remits.
7. **Check reserves and holds.** Compare the amount each platform reports as held with the asset you carry for it.
8. **Review orders never paid out.** Any order older than the platform's normal payout delay that appears in no payout needs an answer.
9. **Sign and file** the channel summary, the payout rebuilds and the bank reconciliation together.

Subscriptions sold through the store add a recurring layer: the same customer is charged each cycle, and failed charges retry. [Recurring billing reconciliation](/blog/recurring-billing-reconciliation) covers matching each billing cycle to its collections.

## Why won't ecommerce sales match the 1099-K or the bank?

Ecommerce sales will not match the 1099-K or the bank because each figure measures something different. Sales in the books are net of refunds and exclude tax collected. The 1099-K is a gross figure. The bank shows only net payouts, on payout dates rather than order dates. The differences are expected, as long as each one can be listed.

The IRS page on [what to do with Form 1099-K](https://www.irs.gov/businesses/what-to-do-with-form-1099-k) says the gross amount reported isn't adjusted for fees, credits, refunds, shipping, cash equivalents or discounts. A store's 1099-K total will therefore sit above its recorded sales by roughly those amounts. A short bridge from the form to the books, prepared each year, saves time later.

The usual reasons the three figures differ:

- **Timing.** Orders on the last days of a month are paid out the next month.
- **Fees.** Deducted from payouts, so the bank is lower than sales.
- **Refunds.** Deducted from later payouts, sometimes across months.
- **Tax collected.** Present in the order totals and payouts, absent from revenue.
- **Shipping and discounts.** Present in some reports and not others.
- **Payments outside the platform.** Orders paid by bank transfer, for example, never appear in a payout or on a 1099-K.
- **Reserves and holds.** Earned but not yet released.

If any difference is left after these items, it is an error to find, not a figure to plug.

## Ecommerce reconciliation edge cases: reserves, subscriptions and negative payouts

The edge cases that break an ecommerce reconciliation routine are reserves, negative payouts and charges taken directly from the bank. Each one moves money in a way the normal order-payout-bank chain does not expect. Spot them early in the month, because each needs an entry the standard payout posting does not make.

**Reserves.** Some processors hold back part of each payout, or a fixed sum, against future refunds and chargebacks. The held amount is still the store's money, so it belongs in an asset account, released as the processor pays it out. [Payment processor reserve accounting](/blog/payment-processor-reserve-accounting) covers the entries.

**Negative payouts.** When refunds and fees in a period exceed sales, the platform may show a negative balance. It may recover that amount from the next payout or debit it from the bank. A debit from a platform on the bank statement is not an expense. It is a reduction of the platform's clearing account.

**Subscription retries.** A failed subscription charge that succeeds on a retry appears in a later payout than the billing date. Match it to its billing cycle, not to the payout date.

**Currency conversions.** Sales in other currencies may be converted at payout, with a conversion charge deducted. Record the charge as an expense and the sale at the amount the platform reports in your currency.

PreciseBankFlow handles the bank layer: it reads each statement, confirms that it foots, and matches each deposit to the ledger, so a platform payout with no matching entry, or a duplicate, appears on the exception report. You can [request early access](/get-started) to try it on a client's statements.