A payout is a balance movement, not a day of sales

What it is

Three numbers describe the same week of selling and none of them agree: the revenue on your orders report, the total of the card charges Shopify Payments processed, and the amount that landed in the bank. Operators usually find the third number first, from the bank feed, and then spend an afternoon trying to tie it to the first. It does not tie, and it is not supposed to.

A payout is a transfer of whatever was available in your Shopify Payments balance at the moment the payout was created. Your balance is moved by charges, by the processing fee on each charge, by refunds, by chargebacks and their fees, by adjustments and by reserve movements, each on its own date. An order, by contrast, is a commercial document dated when the customer checked out, and it may have been paid with a method that never touched the Shopify Payments balance at all. Reconciling means rebuilding the balance, not comparing two totals.

Why the deposit is smaller, or missing

Pay period and business days. Payouts run on a daily, weekly or monthly schedule, counted in business days, and each one covers the transactions that became available before it was created. Weekends and holidays do not count, so a Friday sale is routinely in the following week's payout, and the last day of a month is almost always in next month's money. After the payout is marked deposited, the bank still needs one to three business days to post it, which moves the date you see in the bank feed again.

Payments that are not Shopify Payments. PayPal, Amazon Pay, a third-party gateway, cash on delivery and manual bank transfers settle in their own systems and never appear in a Shopify Payments payout, even though the orders sit in the same orders report. Gift cards are worse, because they are partial: redeeming a gift card reduces the amount charged to the card, so the order total is larger than the charge by the redemption, with no row anywhere to explain the difference. Sum only the orders whose gateway is Shopify Payments before you compare anything.

Fees. The processing fee is deducted from each charge as it settles, which is why the transaction list has separate amount, fee and net columns and why the payout equals the sum of the nets, not the sum of the amounts. Region-specific extras, such as tax charged on the fee itself, are deducted the same way.

Refunds. A refund reduces the balance on the day it is issued, not on the day of the original order, so it lands in a payout that contains none of the matching sales. In most regions the original processing fee is not returned with the refund, which means a refunded order costs you the fee twice over: once on the sale and once as the unreturned fee. Check your region's fee schedule rather than assuming either way.

Chargebacks and disputes. When a dispute opens, the disputed amount and the dispute fee are taken out of the balance immediately, weeks after the order was paid. If you win, the amount comes back later as its own credit, so the loss and the recovery sit in different payouts and neither is next to the order. An inquiry that has not become a chargeback yet takes nothing.

Reserves and negative balance. A reserve holds back a share of volume, or a fixed sum after a risk review, and releases it on its own schedule. If refunds and chargebacks exceed a period's charges the balance goes negative, and the shortfall is carried into the next payout or debited from the bank account, which makes the period after a heavy refund week look like missing money when it is arithmetic.

Currency. If you sell in a currency your payout account does not hold, the deposit is the converted amount at the rate applied on the payout date, less a conversion charge. Comparing charges in the sale currency with a deposit in the settlement currency cannot balance, and the residual you are left chasing is the spread.

Shopify's own bills. By default the subscription, shipping labels, app charges and domains are invoiced and charged to the payment method on your Shopify account, so they do not reduce a payout. A store that pays its bills from a Shopify Balance account is the exception, and there the deduction is a movement of that account rather than an order-level row. Confirm which setup yours uses before you look for label costs inside a payout.

Failed transfers. A payout that the bank rejects, usually after bank details changed or an account verification, shows as failed and is retried. The money is not lost, but the period looks empty and the retry lands with the next payout, doubling it.

Why it matters

Until the payout is rebuilt, you do not know whether cash is missing or merely late, and every downstream number inherits the doubt: cash forecasts, the deposit clearing account in the books, and any margin figure that uses net receipts instead of order revenue. Bookkeeping that posts the deposit as revenue also silently hides the fee, the refund and the chargeback, which are exactly the three lines worth watching.

Start from the identity for one payout: payout = sum(charges in the payout) − sum(fees on those charges) − sum(refunds assigned to the payout) − sum(chargebacks and dispute fees) ± adjustments ± reserve movement. For a period rather than a single payout, add the opening and closing balance: opening balance + charges − fees − refunds − chargebacks ± adjustments ± reserve movement − payouts = closing balance. The two balances absorb the timing difference that makes a calendar month never equal a set of payouts.

What is left after every term is filled in with real rows is the only figure worth investigating: residual = deposit − sum(net of the rows assigned to that payout). If it is zero, the gap was timing and you are done. If it is not, the usual causes are a second gateway you did not exclude, a payout to a bank account nobody reconciles, a refund issued outside Shopify, or an export window cut through the middle of a payout. Treat the residual as potential exposure, never as a loss, until the balance activity report confirms it: reserves and in-transit payouts reverse themselves, and a loss that repays itself next week costs you the credibility of every other number you report.

How to reconcile one payout

1. Work payout by payout, never month by month. In the Shopify admin open Finance, Payouts (older stores: Settings, Payments, View payouts), pick one payout, open its transactions and export them. The export has one row per balance movement with transaction date, type, order, card brand and source, payout status, payout date, available on, amount, fee and net. The available on date, not the transaction date, is what decides which payout a row belongs to.

2. Sum the net column for that payout. It must equal the deposit on the bank statement to the cent. If it does not, you exported by transaction date instead of by payout, and the window cut a payout in half; re-export from the payout itself.

3. Pivot the same rows by type. You now have charges, refunds, chargebacks, adjustments and transfers as separate totals for that payout, which is the left side of the identity above. Transactions still marked pending belong to no payout yet and must stay out of the total; they are next week's deposit.

4. Reconcile the charge rows to orders. Join on the order column and compare each charge amount with the order total. Expect three kinds of difference: gift card or store credit on the order, a partial capture, and an order edited after payment. Charges with no order at all are the ones to escalate.

5. Account for every non-charge row against a document. Each refund row should have a refund in the orders report, each chargeback row a dispute in the disputes list, each adjustment a description naming its reason. Adjustments are where chargeback fees, seller protection credits and tax corrections hide, and they are the term operators most often leave out.

6. Cross the period boundary deliberately. Keep a running list of transactions available in this period but paid out in the next one, and of the previous period's tail that arrived in this one. That list, not a formula, is what makes the month tie, and it is the same list your accountant wants for the deposits-in-transit balance.

7. Then check the sales that are not in any payout: orders paid by another gateway, gift card redemptions, and orders still unpaid. Reconcile each gateway against its own payouts, and use the Shopify Payments balance activity report from Finance, Documents when you need the whole balance for a date range rather than one payout.

What AXIOTRA checks here, and what it does not

There is no payout comparison for Shopify Payments in this build, and the copy will say so until there is. The importer accepts seven files — orders, payments, refunds, shipments, inventory, costs and fees — and none of them is a payout file. Payout rows enter the ledger only through a Stripe connection whose restricted key can also read payouts. The payout detector then filters both sides to the source stripe, so a workspace whose captures came from the Shopify Payments transactions export never triggers it: it computes zero captures against zero payouts and stays silent. The reconciliation above stays spreadsheet work for now.

Do not relabel Shopify Payments charges as stripe to force the detector. Captures are summed only for rows whose status is captured or succeeded, while fees are summed on every stripe row, and payouts you do not have count as zero; the finding you would get is a gap equal to the amount you expect to be paid, or to the fees alone, and it is meaningless. Keep source as shopify and the ledger stays honest.

What the export does feed is the payment-to-order comparison, which is the part of step 4 above that AXIOTRA can do for you. Import the rows whose type is charge as the payments file with source shopify, mapping the transaction id to payment_id, the order column to order_id, amount to amount, fee to fee and the transaction date to captured_at. The order_payment_mismatch detector then raises an order with no captured payment at all (exposure = the order total, confidence high), and, for each payment whose amount differs from its order total, a finding whose exposure is the unsigned difference — which is how a gift card redemption, a partial capture and an edited order each surface, with the order status on the evidence to tell them apart.

Two limits of that comparison are worth knowing before you read the list. A charge whose order column is empty is raised as a payment with no commerce order, but a charge that names an order which is not in the ledger — an order outside the date range you exported — produces nothing at all, so export orders and charges over the same window. And several mismatching payments on one order share a single finding id, so the stored list read by the API keeps one of them while the board shows both. Refund rows from the same export belong in the refunds file, where they arrive with return_received and restocked false because the payout export knows nothing about parcels.