Why your payout total will not match your sales total

You made five sales yesterday. Your storefront shows £250 in sales, but the amount reaching your bank account is smaller — and it may arrive on a different day. That difference is not automatically an error. A sales total and a payout total answer different questions: one records what customers paid, while the other records what is ready to be transferred after adjustments.

Start with the two totals

Begin by writing down exactly what each figure includes. Your sales total is generally the total charged to customers before deductions. It may include the product price, delivery of a digital item, and any tax collected at checkout. Your payout is the amount sent or scheduled to be sent to your connected payment account after the payment provider applies its adjustments.

The basic reconciliation is therefore: gross sales − processing fees − refunds − disputes − reserves or holds − other adjustments = amount available for payout. Timing then determines whether that amount has already arrived in your bank account. If you sell through store.fan, money goes straight to your own Stripe account, while Stripe’s own processing fee still applies. You can review the payment setup and the path money takes on the store.fan payments page.

Fees reduce the amount, not the sale

A customer can be charged £50 while less than £50 becomes available for payout because payment processing has a cost. The sale remains a £50 sale in your order records; the fee is a separate deduction. Do not change the product’s sale price in your accounts just because the payout is lower.

This distinction matters when you check margins. If you sell a £50 product and the customer pays £50, your revenue record and your cash record are not identical. Record the gross sale, then record the processing fee as a cost. The exact fee depends on the payment provider, payment method and transaction circumstances, so use the fee shown in your Stripe transaction rather than applying a guessed percentage.

Refunds and disputes move the total backwards

A refund reduces the money you keep from a sale. If you refunded one of yesterday’s five £50 orders, your gross sales report may still show the original order and a separate refund entry, while your available balance reflects the deduction. A partial refund creates the same pattern at a smaller amount.

A dispute is different from a normal refund. The customer, card issuer or bank has challenged the payment, so the amount may be removed while the dispute is reviewed. A dispute can therefore create a sudden gap between the sales list and the balance available for payout. Keep the order, customer communication and fulfilment evidence together so you can understand the adjustment and respond when required.

Taxes may be in the charge but not in your income

Suppose a customer pays £60: £50 for your digital product and £10 shown as tax. Your sales screen may show the customer’s full charge, but the £10 may be an amount you need to set aside or pass on rather than money available for your business. The correct treatment depends on where you and the customer are based, what you sell, your registration status and the rules that apply.

This is why a lower payout is not always explained by a fee or refund. Separate the product price, tax amount and payment adjustment in your records. Do not label every pound that entered checkout as revenue you can spend. For a practical record of what to retain for each transaction, see the tax records your storefront should keep for every digital sale.

Timing creates gaps that disappear later

The simplest timing problem is a date boundary. A sale made late on Monday may appear in Monday’s sales total, while its funds become available in a later balance or payout. A refund made today may relate to a sale from last week. Comparing one calendar day of sales with one calendar day of payouts mixes different groups of transactions.

Use a consistent period and compare like with like: order date against order-level adjustments, then balance availability against payout date. Also check whether a payment is pending, whether a payout has been scheduled, and whether a temporary reserve or hold is affecting the available balance. For a first payout, the delay can feel especially confusing because the first sale and first transfer are separate events.

If you want a quick operational check, the store.fan iOS app can send instant sale alerts. Those alerts help you notice orders as they happen, but they are not a substitute for the Stripe balance and payout records. Use the alerts for awareness and the transaction records for reconciliation; the store.fan iOS app details explain the alert feature.

A simple reconciliation routine

1. 1Choose a period, such as a calendar month, and export or list every order in that period.
2. 2Add the gross order values and keep refunds as separate negative entries rather than deleting the original sale.
3. 3Match each payment to its processing fee, then identify disputes, reserves, holds and any other balance adjustments.
4. 4Separate tax collected from the amount that belongs to your business, using the records and rules that apply to you.
5. 5Compare the resulting available amount with the payout record, allowing for payments that are pending or scheduled for a later date.
6. 6Investigate only the unmatched items. An order reference, adjustment date and payout reference will usually narrow the search faster than comparing two large totals.

Keep this routine boring. A spreadsheet with columns for order date, order reference, gross charge, tax, fee, refund, dispute, reserve, payout date and notes is enough to expose most gaps. If you use store.fan for digital downloads, courses or memberships, the same principle applies: reconcile each transaction before relying on the headline total in your storefront.