Why Shopify payouts do not match the bank

The short answer is that a Shopify payout is not a sale. It is a net settlement of many sales, minus fees, minus refunds, sometimes minus a dispute, landing on a date that has nothing to do with when the orders were placed.

Reconciling order totals to bank deposits directly will therefore never tie out, and no amount of care in the ledger fixes that, because the two numbers are not measuring the same thing.

The structural mismatch

• Hundreds of orders settle as a single deposit with no line-level reference on the bank side.
• Processing fees are netted before the deposit arrives rather than billed separately.
• Refunds reduce the payout they are deducted from, not the payout containing the original sale.
• Payout timing follows the settlement schedule, so month-end orders routinely settle in the following period.
• A single payout can be split across more than one bank credit.

Where it gets harder than the standard case

For a single-channel store on Shopify Payments alone, a well-configured connector usually handles this cleanly, and that is the right tool. The difficulty appears when Shopify is not the only source.

A brand running Shopify Payments alongside PayPal, or selling wholesale on terms, or operating in two currencies, now has several settlement streams landing in overlapping accounts. Each stream reconciles on its own logic, and the clearing balance becomes the sum of several unfinished reconciliations rather than one.

How the matching actually works

Rather than matching a deposit against orders, the deposit is reconstructed: orders in the payout window, less fees, less refunds deducted from that payout, less any dispute activity. The reconstructed figure is then matched against the bank line, and any residual outside tolerance becomes a reason-coded exception.

You can watch that run on synthetic data in the reference build, including the bundled-payout rollup and the split-deposit case.

When standard software is enough

Standard connectors are often the right solution for standard workflows. If the connector posts activity correctly and the clearing account returns to zero without investigation, there is nothing here worth building. Keep the software you have.

When custom automation may be justified

The case for a custom reconciliation layer depends on recurrence, not on frustration. It is worth looking at when the same exception patterns return every close, several sources have to agree before the balance resolves, and meaningful staff time goes into work that follows repeatable rules.

If you want a structured answer rather than an opinion, the Fit Score scores one workflow against recurrence, effort, source complexity, rule repeatability and portfolio reuse. It runs in your browser and takes a couple of minutes.