E-commerce Bookkeeping: Matching Stripe, PayPal, and Amazon Payouts to Your Bank

The payout-vs-gross-sales problem

A customer buys a $100 product. Your books, if you're recording sales at all, might show $100 of revenue. But the deposit that lands in your bank account is $97.10, or $94, or some other number that doesn't match anything in your sales report. Multiply that by hundreds of transactions across Stripe, PayPal, and Amazon, and you get a bank statement full of round-looking deposits that don't tie to a single invoice.

This is the defining reconciliation problem in e-commerce bookkeeping. The processor isn't depositing your sales — it's depositing a net figure after fees, refunds, chargebacks, and sometimes a reserve holdback, batched over a payout period that rarely lines up with your accounting period.

What gets netted into a single deposit

Before you can reconcile anything, you need to know what's actually inside that one bank line. Depending on the processor, a single payout can bundle:

• Gross sales for the payout period
• Processing fees, typically a percentage plus a per-transaction charge
• Refunds issued during the period, which reduce the deposit rather than showing as a separate outflow
• Chargebacks and disputes, often with a separate fee on top of the reversed sale
• Reserves — a percentage the processor holds back, common for new accounts or high-risk categories, released later on its own schedule
• Adjustments from prior periods, like a late-arriving dispute resolution

Amazon adds its own layer: FBA fees, storage fees, advertising spend, and returns all net against sales inside the same settlement, on a cycle that almost never matches a calendar month.

Reconciling Stripe payouts to the bank

Stripe's payout report is the source of truth here, not the bank line. Pull the payout reconciliation report for the period covering each deposit. It breaks gross charges, fees, refunds, and disputes into separate lines that sum to the exact deposit amount hitting your bank.

Match each Stripe payout to its corresponding bank deposit by date and amount — they should be one-to-one if the account is on Stripe's standard payout schedule. Book gross sales as revenue, fees as an expense, and refunds against the original revenue account, rather than net-booking the deposit as a single revenue line. Net-booking is the shortcut that makes a P&L technically balance but hides the real fee load and refund rate from the owner.

Reconciling PayPal and Amazon payouts

PayPal works similarly to Stripe but with more manual timing quirks — instant transfers, held funds for newer sellers, and currency conversion fees on international sales. Pull the PayPal activity report for the payout window and reconcile the same way: gross, fees, refunds, net.

Amazon is the heaviest lift. The Date Range Report or Settlement Report inside Seller Central shows every fee category netted into the deposit — referral fees, FBA fulfillment, storage, advertising, and any reserve movement. Because the settlement period doesn't align with the calendar month, a deposit will often span two accounting periods. Book it in the period the settlement actually closes, and use an accrual adjustment if a large settlement lands right on a month-end boundary and would otherwise distort one month's numbers.

Building a repeatable matching workflow

Once a client has more than one processor, doing this from memory stops working. A workflow that holds up:

• Pull the bank statement for the period — converting it to CSV makes it filterable so you can isolate exactly which deposits came from which processor by amount and date pattern.
• Pull the matching payout report from each processor for the same window.
• Match deposit to payout report one-to-one. Flag anything without a matching bank line — that's usually a reserve still being held or a payout still in transit.
• Book gross, fees, and refunds as separate lines, never a single net figure.
• Track any reserve balance separately so it doesn't quietly disappear from the books until it's released.

The processor side of this only gets you halfway — you still have to prove every payout actually landed in the bank for the amount the report says it should. That's the step people skip, and it's the one that catches a missing payout or a processor error before the client does. When a client hands over PDF statements instead of a live feed, converting them to a spreadsheet first turns dozens of scattered deposits into rows you can sort by amount and match against payout reports in one pass.