Recording Payment Processing Fees: Why Your Deposit Is Smaller Than the Sale

The gap between the sale and the deposit

You charge a customer $1,000. A day or two later your bank shows a deposit of roughly $971. The missing slice is the payment processing fee your card processor or payment platform kept. It feels small per transaction, but it's one of the most consistently mis-recorded numbers in small-business books — and getting it wrong quietly distorts both your revenue and your costs. This guide explains why the deposit is smaller than the sale and the right way to record the difference. (General education, not tax or accounting advice.)

The trap: booking the net deposit as revenue

The tempting shortcut is to record what actually hit the bank: a $971 deposit, booked as $971 of revenue. It reconciles to the bank in one line, so it feels right. It isn't, and it causes two problems at once:

• Your revenue is understated. You earned $1,000 of revenue — that's the price the customer agreed to and the number your sales metrics, gross margin, and growth trends should be built on. Booking $971 hides a slice of real revenue.
• Your processing cost is invisible. That $29 is a genuine business expense — a cost of accepting card payments. Net-recording erases it. You can't manage, budget for, or even see a cost that never gets its own line, and across a year of transactions it adds up to real money you're blind to.

The principle behind doing it right is gross recording: record the full sale as revenue and the fee as its own expense, rather than silently netting them against each other. It's the same logic that keeps a chart of accounts honest — every distinct economic event gets recorded as what it actually is.

The right way: revenue gross, fee as an expense

For that single $1,000 sale paid by card, the bookkeeping records three things, not one:

• Revenue: $1,000 — the full amount the customer was charged.
• Processing fee expense: ~$29 — booked to a dedicated expense account, commonly Bank & merchant fees.
• Cash to bank: ~$971 — the net deposit that ties out to your bank statement.

Notice the deposit still reconciles perfectly — $1,000 of revenue minus the $29 fee equals the $971 that landed. You lose nothing in tie-out, and you gain a true revenue figure plus a visible, trackable cost.

Timing: per-transaction vs. monthly fees

Processors deduct fees in one of two patterns, and your bookkeeping should follow whichever yours uses:

• Netted per transaction. The fee is taken out of each payment before deposit (the $1,000 → $971 case). Here the fee and the sale are tied together, and software that connects to your processor can split each deposit into gross revenue and fee automatically.
• Billed as a monthly lump sum. Some processors deposit the gross amount and then charge total fees once a month as a separate debit. In that case each sale deposits at full value, and you book one Bank & merchant fees expense entry when the monthly charge hits.

Either way the destination is the same — full revenue recorded, fees in their own expense account. Only the timing of the fee entry differs.

Where the fee actually belongs: operating expense or COGS?

A fair question: is a processing fee an overhead cost or a cost of goods sold? It depends on how you want to read your margins:

• Many businesses treat merchant fees as a general operating expense — a cost of doing business overall, sitting below the gross-profit line.
• Others fold them into COGS as a direct, per-sale cost, because the fee only exists when a sale happens. This pulls the fee into your gross margin math, which is the more conservative, fully-loaded view of what each sale actually nets you.

There's no single right answer — pick one, apply it consistently, and make sure your expense categorization reflects the choice. Consistency matters more than the category, because period-to-period comparability depends on treating the fee the same way every time.

Don't forget refunds, chargebacks, and platform fees

Card revenue has a few cousins that follow the same gross-recording logic:

• Refunds reduce revenue (or hit a contra-revenue account) and are recorded as their own event — see credit memos, refunds, and overpayments. Note that processors often don't return the original fee on a refund, so a refunded sale can still leave a fee expense behind.
• Chargebacks can carry their own fee on top of the reversed sale; book the reversal and the fee separately.
• Platform or marketplace fees (commissions a sales platform takes) are the same idea at a larger scale: record gross revenue, then the platform's cut as an expense — never just the net payout.

Why this matters beyond tidiness

Recording fees correctly isn't bookkeeping pedantry — it changes numbers you make decisions on. True gross revenue keeps your growth and sales reporting honest. A visible fee line lets you see what card acceptance really costs and whether it's creeping up as you scale. And folding fees into a fully-loaded cost gives you an accurate read on per-sale profitability — the same discipline behind a trustworthy break-even analysis. Net-recording hides all three.

Record the sale at full price and the fee as its own expense, and the smaller deposit stops being a mystery — it's just revenue minus a cost you can finally see. Hosting Books splits connected card deposits into gross revenue and a merchant-fee expense automatically, so every sale records at full value, every fee lands in its own account, and the net deposit still reconciles to the bank.

This article is general educational information about accounting concepts and is not tax or accounting advice for your specific situation.