The mismatch that breaks a lot of books
You send an invoice for $500. The customer pays by card through Stripe, PayPal, Square, or a similar processor. A day or two later, money hits your bank — but it is not $500. It is $485.50, and worse, it is lumped together with three other customers' payments into a single deposit for $1,912.30 that matches none of your invoices. If you simply mark the $500 invoice "paid" and then also record the bank deposit, your books will be wrong in two directions at once: your sales will be understated by the fees, and your income will be double-counted or fail to reconcile. This is one of the most common ways small-business books drift, and it comes entirely from misunderstanding what a processor deposit actually is. (General education, not accounting advice.)
The core fact to hold onto: the processor collects the full amount from your customer, keeps its fee, and deposits the rest. Your customer paid $500. That full $500 is your revenue. The roughly $14.50 the processor kept is a business expense — a payment processing fee — not a discount and not a reduction of the sale. Record it any other way and the numbers stop telling the truth.
Gross, fee, net: the three numbers in every transaction
Every card payment has three numbers, and good bookkeeping keeps all three visible instead of collapsing them into one:
- Gross — what the customer paid. This is your sale. It is what the invoice was for, and it is the amount that belongs in revenue.
- Fee — what the processor kept. This is an expense, recorded on its own so you can see what card acceptance actually costs you over a year (often a bigger number than owners expect).
- Net — what landed in your bank. Gross minus fee. This is the only one of the three your bank statement ever shows, which is exactly why reconciling from the bank alone goes wrong.
The mistake is recording only the net and calling it the sale. Do that and your revenue is permanently understated by every fee you ever paid, your profit and loss statement hides a real and growing cost, and your invoices never quite tie out to your deposits.
Recording it so everything ties out
The clean approach records the sale at gross and the fee separately, so the net is what remains to be deposited. Walking one $500 card sale through:
- Record the sale at the full $500. The customer's invoice is marked paid in full for $500. Revenue is $500, not $485.50.
- Record the fee as an expense. The roughly $14.50 processor fee posts to a "merchant fees" or "payment processing" expense account. Now your books know what accepting that card cost.
- The $485.50 net is what the processor owes you until it deposits. Many businesses run these through a clearing account — a holding account that the processor's balance sits in between the sale and the payout, the same idea as undeposited funds. The sale increases the clearing account by the net; the payout moves it to the bank.
When the batch deposit of $1,912.30 finally lands, it clears out the individual net amounts sitting in that holding account. Because you recorded each sale's gross and fee separately, the batch reconciles to the sum of the nets — and your bank reconciliation ties out cleanly. Bank reconciliation for small business covers that final matching step.
Batch deposits and the timing gap
Two practical wrinkles trip people up even once they understand gross-vs-net. First, processors pay in batches, not per sale. A single deposit represents many transactions, sometimes across more than one day. You reconcile it against the processor's payout report, which lists the transactions in the batch and the fees — not against any one invoice. Second, there is a timing gap. A sale made today may not be deposited until two days later, which at month-end means real money is sitting "in transit" at the processor. That in-transit balance is genuinely yours; leaving it invisible understates your assets. It is the same category of timing issue as deposits in transit and outstanding checks, just on the receiving side.
Let the rules do the repetitive part
Once you understand the shape of the transaction, you should not be hand-entering every fee. The fees are predictable and land in your bank feed as part of the payout, so a bank feed rule can categorize the processor's payouts and split out fees consistently, and reconciling against the processor's own settlement report keeps the batch honest. The goal is a system where a card sale automatically books gross revenue, records the fee as the expense it is, and lands the net in the bank — so that at year-end your revenue reflects what customers actually paid you, your fee expense is fully visible, and every deposit reconciles. Get this one pattern right and a whole category of "my books never match my bank" problems simply disappears.