Payment processor statements show what the bank statement hides: the gross sales, refunds, disputes and fees that add up to each payout. Use them to break every processor deposit into its parts, book sales at their gross amount and fees as an expense, and match each payout's net total to the deposit line on the client's bank statement.
What do payment processor statements show that the bank does not?
A processor statement or report lists the individual charges, refunds, disputes and fees behind each payout. The bank statement shows only the payout, as one net deposit. Booking from the bank alone records sales minus fees as a single number, which understates both revenue and expenses and leaves the client unable to see what card processing costs them.
Consider a client who takes card payments through a processor. Customers pay by card. The processor keeps its fee, holds the rest for a few days, then sends one transfer covering many sales to the client's bank. On the bank statement that transfer is a line such as "PROCESSOR PAYOUT 4,817.32." Nothing on it says how many sales it contains, how much was refunded, or what the fees were.
The processor's own records fill that gap. Most processors offer a dashboard with downloadable reports listing each transaction and each payout. Stripe, for example, describes its payout reconciliation report as a way to match the payouts you receive in your bank account with the batches of payments and other transactions they relate to. Its itemized download lists every payment, refund, dispute, fee and other balance transaction in each payout.
What a bookkeeper needs from the processor
For each month, ask the client for access to, or an export of:
- The list of payouts in the month, with dates and net amounts.
- The itemized detail for each payout: gross charges, refunds, disputes, fees.
- Any month-end balance still held by the processor and not yet paid out.
Read-only access to the processor dashboard is better than a monthly export, because you can pull the report yourself without waiting for the client.
Booking gross sales, fees and refunds from a processor payout
A processor payout is recorded as one entry with several lines: gross sales as income, refunds as a reduction of income, fees as an expense, and the net amount as the deposit to the bank. The lines must add to the payout total. Booked this way, the profit and loss shows true sales and true processing cost.
A worked example
The figures below are an example for one payout, not data from any real account.
| Line in the processor's payout detail | Amount |
|---|---|
| Charges, 52 payments | 5,140.00 |
| Refunds, 2 payments | -180.00 |
| Processing fees | -142.68 |
| Net payout sent to bank | 4,817.32 |
The entry that records it:
| Account | Debit | Credit |
|---|---|---|
| Checking | 4,817.32 | |
| Merchant processing fees | 142.68 | |
| Sales refunds and returns | 180.00 | |
| Sales | 5,140.00 |
Debits total 5,140.00 and credits total 5,140.00, so the entry balances. The checking line equals the deposit on the bank statement to the cent, which is what lets the bank side reconcile.
Where the sales figure comes from
If the client also uses invoicing or a point-of-sale system, sales may already be recorded there, one by one. In that case the payout entry should not record sales a second time. Instead, the processor acts like a holding account: invoice payments flow into it, and the payout moves the net amount to checking, with the fee booked as an expense. Decide which system is the record of sales for each client, and write that decision down.
Matching each processor payout to a bank deposit
Every payout in the processor's report should have exactly one deposit on the bank statement with the same net amount, usually within a business day or two of the payout date. Match them one to one. A payout with no deposit, or a deposit with no payout, is the first thing to chase each month.
A two-column list works well. Put the processor's payouts on the left and the bank's processor deposits on the right, both sorted by date. Tick off each pair. What remains unmatched is the work. In practice, most unmatched items fall into a few groups:
- Timing. The processor shows a payout on the 30th, and the bank credits it on the 2nd of the next month.
- A failed payout. The bank returned a transfer, and the processor retried later with a different amount.
- A wrong account. The payout went to another of the client's accounts, such as a savings account.
Stripe notes that its payout reconciliation report groups a payout by its estimated arrival date, not the date the bank posts the deposit. That difference is why a one-day gap between the two columns is normal and not an error.
Clients often ask why their bank deposits do not match their sales. The answer is in this match, and it is worth keeping as a standing document in the client file. The guide to bookkeeping workpapers covers how to keep a reconciliation like this one with each month's close.
Which processor report should the books use?
For matching bank deposits, use a report organised by payout, because each payout corresponds to one bank line. For a month-level check of total activity, use a balance or activity report covering the whole month. A monthly summary that only lists gross volume is useful for sales totals but cannot tie to the bank on its own.
Processors name these reports differently, but the same three shapes appear:
| Report shape | Organised by | Good for | Weak at |
|---|---|---|---|
| Payout report | Each transfer to the bank | Matching bank deposits and splitting fees | Showing activity not yet paid out |
| Balance or activity report | Every transaction in a date range | Month-end totals and money still held | Tying to individual bank lines |
| Monthly statement or summary | Calendar month | Gross volume and total fees | Matching individual payouts |
Stripe's documentation reflects this split. Its payout reconciliation report is meant for reconciling each payout as a settlement batch, and it points users who prefer to track the processor balance like a bank account to its balance report instead.
At year end, processors that handle card payments may also send the client a Form 1099-K. The IRS describes Form 1099-K as a report of payments received for goods or services during the year, filed by payment card companies, payment apps and online marketplaces. Keep the processor's year totals in the file so the preparer can compare them with the books.
Processor refunds and disputes larger than a day's sales
When refunds and disputes exceed new sales, the processor balance can go negative, and the processor may pull money from the client's bank instead of paying out. On the bank statement this appears as a withdrawal from the processor, not a deposit. It is still a processor payout in reverse, and it is booked from the same itemized detail.
Stripe's payouts documentation gives exactly this case. If you receive 100 USD in payments but refund 200 USD of earlier payments, the balance is -100 USD, and without further payments Stripe creates a payout that debits the bank account.
The entry mirrors the normal one. Refunds and dispute amounts reduce income, any dispute fees are an expense, and checking is credited for the amount pulled. Disputes deserve a note in the file, because a dispute the client later wins comes back as a credit in a future payout, and the bookkeeper should recognise it when it arrives.
Processor payouts that cross a month end
A sale made on the 30th is revenue for that month even if its payout lands on the 3rd of the next month. At month end, the sales the processor is still holding are an asset of the client: money owed to them by the processor. Record that balance so the month's sales are complete.
Many bookkeepers keep a clearing account for each processor. Sales and fees go in as they happen, payouts come out as they land in the bank, and the month-end balance of the clearing account should equal the processor's own figure for funds not yet paid out. A clearing account that grows month after month is a sign that payouts are being booked as sales somewhere else.
The same timing question appears whenever any statement period does not line up with the books. Statement periods that do not follow the calendar month covers cutoffs for bank and card statements in more detail.
Recording net processor deposits as sales
The most common processor mistake is to code each payout deposit straight to sales. Revenue is understated by the fees and refunds, fees disappear from the expense report, and the year's sales will not agree with the processor's year totals. It is quick to do and slow to undo, because the correction needs every payout's detail.
The pattern usually starts innocently. A categorization rule says that deposits from the processor are sales, which is true in spirit, and it runs every month. If the rule sits in a client's books for a year, fixing it means pulling every payout report for that year and reposting each one. Bank feeds, statement conversion and receipt capture all hand you the net deposit; data entry automation methods for accounting compares what each of them actually captures.
A safer rule sends processor deposits to the processor clearing account instead of sales. The deposit then waits there until the payout detail is posted, and an unmatched balance makes the missing work visible. When a client's statements are converted with AutoBankConvert, the client's rules assign each deposit to an account, so pointing the processor's deposits at a clearing account is a rule written once.
Clients who sell online or take cards in person have this problem in every month of the year, and many have never had it handled properly. Being able to explain it clearly is useful when you talk to prospects; how to get bookkeeping clients covers where to find businesses that need exactly that.