Reconcile the Payout Before the Bank Deposit Becomes Revenue

The Signal

Open the bank feed and pick one deposit from a payment processor. Can you name the orders, refunds, disputes, fees, reserves, and adjustments inside it without starting a search across three systems?

If the answer is no, the deposit is not a revenue receipt. It is a payout total waiting to be reconciled. The processor may have combined several days of charges, removed fees, netted refunds, held part of the balance, and released an earlier reserve. The bank only shows the amount that arrived. It does not show how that amount was built.

Stripe describes its payout reconciliation report as a way to reconcile each payout with the batch of transactions it settles. That is the operating object a founder needs: one payout tied to the transaction rows that explain it.

Why this matters now

A business can collect through a storefront, invoices, subscriptions, payment links, marketplaces, and point-of-sale terminals while receiving one net deposit. Sales may be recorded when an order is placed, when a service is delivered, or when a charge succeeds. The payout arrives on a different schedule.

Those clocks create legitimate differences. A Friday sale may settle on Tuesday. A refund may reduce this week's payout even though the original sale happened last month. A dispute can remove cash before the team has classified the case. Processing fees reduce the deposit but should not quietly reduce reported gross sales.

When nobody keeps the bridge, the founder sees a healthy sales report and a smaller bank balance, then asks finance to find the missing money. Finance starts with the deposit instead of a complete transaction list. The result is a recurring investigation that should have been a routine close step.

The mistake to avoid

Do not post the full deposit to revenue just because the cash reached the bank. A net payout is a mixture of sales, refunds, fees, disputes, reserves, and timing. Treating that mixture as one revenue number hides both the economics and the exceptions.

Do not force the bank deposit to equal one day's sales either. Settlement windows, weekends, currencies, and processor timing can make that comparison fail even when every dollar is accounted for. The useful comparison is payout ID to the exact batch of transactions it settles.

The other bad fix is changing the processor, accounting platform, or payout schedule before the current gap is understood. A new system will not repair missing transaction ownership. It will give the same unclear handoff a new interface.

Build the payout bridge

Start with the processor's payout ID. Put the payout date, currency, destination account, and net amount on one row. Under it, group the settled balance activity into gross charges, refunds, disputes, processing fees, reserve movements, and other adjustments. The categories should add back to the net payout.

Then connect the charge rows to the business record that explains them: order ID, invoice, subscription, customer account, or point-of-sale receipt. Keep the processor transaction ID too. The business record explains what was sold. The processor record explains how cash moved. The bank deposit proves where the net cash landed. These are three layers, not one interchangeable number.

Create an exception only when the bridge does not close or the transaction lacks a business record. Give that exception a reason, owner, next action, and due date. “Timing” is acceptable only when the expected settlement date is recorded. “Unknown” means someone still owns the investigation.

What stays protected

Keep the existing processor, bank account, payout schedule, refund authority, dispute process, and accounting rules unchanged while you build the baseline. This review does not authorize moving money, reissuing refunds, changing reserve settings, or rewriting closed books.

Protect customer and payment data too. The bridge needs transaction IDs, order or invoice references, dates, categories, and amounts. It does not need full card details or an exported customer profile. Work from approved processor and accounting reports, and keep access with the people already authorized to see them.

The bridge also does not replace accounting judgment. It provides the transaction evidence. The existing finance owner still decides the correct period and account classification.

The first move

Pull the last ten payouts and their matching bank deposits. For each payout, total gross charges, refunds, disputes, fees, reserves, and adjustments. Confirm the categories equal the net deposit, then trace five charges back to their order or invoice records.

Mark the first missing object for every failure: payout report, processor transaction, business record, bank match, or classification owner. Do not call the whole issue a reconciliation problem when one handoff is repeatedly breaking.

The move this week

Create a payout-close checklist with eight fields: payout ID, settlement date, bank deposit, gross charges, refunds and disputes, fees, reserve or adjustment activity, and unresolved difference. Add the evidence link and owner for every exception.

Run it on each payout for one week. Review the exceptions by cause, not just amount. If the same channel keeps losing order IDs, fix that mapping. If refunds lack an approver, repair that workflow. If timing explains the gap, record the expected settlement date and close it when the cash arrives.

The objective is not another finance report. It is a deposit the business can explain from sale to settlement without guessing where the difference went.