Reconcile a merchant payout without mistaking it for sales

The deposit in a merchant's bank account is usually not the day's sales total. A processor can batch transactions on a different clock, subtract fees, refunds, disputes, or other adjustments, and leave recent activity pending. Reconciliation means proving how the processor's activity became the bank deposit, then proving what remains in the processor balance.

Provider screens and field names differ. The method below is general bookkeeping logic; the cited report mechanics are provider-specific examples, not promises about every processor.

Use a clearing account

Record customer payments at gross value, not at the net deposit. Route the payment activity through a “processor clearing” account. Record processing fees to an expense account, refunds against the appropriate sales or returns account, and disputes or adjustments according to the business's accounting policy. Record the payout as a transfer from clearing to the bank.

This prevents a $970 bank deposit from being mislabeled as $970 of revenue when the underlying activity might be $1,000 of sales less $30 of fees. Ask the bookkeeper or accountant how taxes, tips, shipping, foreign exchange, and disputed amounts should be classified; reconciliation proves movement, not the correct tax treatment.

Tie one payout before automating

Start with the processor's payout ID and the matching bank deposit. Then obtain the processor's payout-level detail or balance activity. In Stripe's provider-specific documentation, the Payout reconciliation report groups transactions included in an automatic payout, while the Balance report records activity over a date range and treats payouts as transfers to the bank. Stripe also says instant payouts require the user to reconcile against transaction history because Stripe cannot identify a transaction batch for a user-chosen amount.

Square's provider-specific Payouts API overview describes a Payout as the transfer summary and PayoutEntry records as the included transactions. It also warns that its cutoff can create a difference between orders processed on a business day and the funds reaching the bank. Those concepts are useful, but Square's times and fields should not be assumed for another provider.

A hypothetical tie-out

Suppose payout PO-1042 deposits $1,147.20:

• captured customer payments: $1,250.00
• customer refund: minus $40.00
• processing fees: minus $37.80
• dispute adjustment: minus $25.00
• net payout: $1,147.20

The four activity lines add to the bank deposit. That proves the batch, but not the ending clearing balance. If another $300 of captured payments is still pending, the clearing account should not be zero. Reconcile the opening processor balance, plus activity, minus payouts, to the closing processor balance.

Investigate differences in a fixed order

First compare payout ID, currency, amount, and bank date. Next align time zone and report date basis: transaction date, balance-availability date, and payout date are not interchangeable. Then look for refunds, disputes, reserves, failed payouts, instant-payout fees, currency conversion, and manual adjustments. Finally, check whether one bank deposit combines activity from multiple locations or merchant accounts.

Keep the downloaded report, bank-statement reference, payout ID, and explanation for each manual adjustment. Do not force a difference into “fees” merely to make the month close. An unexplained plug hides the exact information reconciliation is meant to preserve.

Month-end checklist

• Every bank deposit has a processor payout ID.
• Every payout is posted as a transfer, not revenue.
• Gross payments, refunds, fees, and disputes have separate totals.
• Pending and reserved funds explain the closing processor balance.
• Currency and time-zone settings are recorded.
• Old unmatched items have an owner and follow-up date.

Sources

• Stripe, How to select a report — provider-specific
• Square Developer, Payouts API overview — provider-specific