One number, many deductions
Open a seller's bank account after a marketplace payout lands, and the statement shows exactly one thing: a deposit. Not the gross sales that generated it, not the commission the marketplace took, not the refunds processed against it, not the ad spend deducted before the money ever moved — just a single net figure that's already absorbed all of that.
Answering the question every seller eventually asks — did this payout actually reflect what we sold, at the fee rate we expected, minus only the deductions that were actually ours — means going back to the marketplace's own settlement report and matching its line items against that one deposit. The bank statement alone can't answer it.
Why a payout is harder to reconcile than it looks
The deposit is already net of everything
Commission, referral fees, fulfillment fees, ad spend, refunds and chargebacks are all deducted before the money ever reaches the bank — the deposit is the last step, not a starting point.
A payout period rarely matches a calendar period
A settlement covers whatever window the marketplace defines — every two weeks for Amazon, daily for some Shopify Payments accounts — which almost never lines up neatly with a sales report pulled for a calendar month.
Reserves get held back and released later
A marketplace can hold back part of a payout as a reserve against future refunds or disputes, releasing it weeks later as a separate, unrelated-looking deposit.
Multiple marketplaces means multiple formats
Amazon's settlement report, Etsy's Payment Account CSV and Shopify's payout report all structure the same underlying concepts — gross sales, fees, refunds — completely differently.
None of these four are a marketplace being unreasonable — they're the normal shape of how a payout gets assembled, and they're exactly why comparing a bank deposit against a gross sales report, by eye, rarely produces a confident answer.
What this doesn't do, stated up front
Doesn't calculate what fees should be
Fee schedules change and vary by category. This confirms the deductions the settlement report actually charged add up to the deposit that arrived — it doesn't audit whether the rate itself was correct.
Doesn't connect to Seller Central or any marketplace account
There's no API, no login, no integration. You download the settlement report yourself, the same way you already download a bank statement, and upload it.
Doesn't calculate VAT or sales tax owed
Tax calculation and remittance stay with your accounting system. This reads what the report shows was collected and deducted, not what you owe a tax authority.
Doesn't dispute a fee error with the marketplace
If a fee genuinely looks wrong, raising it with the marketplace is a step you take — this surfaces the discrepancy clearly enough to make that conversation possible.
What's left is narrow, and it's exactly the part that eats an evening every payout cycle: turning a settlement report and a bank deposit into a clear answer about what the payout actually represents.
What gets read
| Field | Source |
|---|---|
| Gross sales per order or period | Settlement report |
| Commission, referral and fulfillment fees | Settlement report |
| Refunds and chargebacks | Settlement report |
| Ad spend and promotional deductions | Settlement report |
| Deposit amount and date | Bank statement |
Five sources of truth, read as they actually exist — not summarized from memory, and not assumed to agree with each other until the matching step actually checks.
How a payout finds its sales
Matching runs on three signals together, not any single one alone, because any one signal in isolation is too weak to trust on its own.
| Signal | Why it isn't enough alone |
|---|---|
| Payout total | Two payouts from the same marketplace can land on similar amounts by coincidence |
| Deposit reference | Often just a marketplace's generic payment identifier, with no period or store name attached |
| Timing | Payout dates cluster around a marketplace's fixed schedule, so several can arrive in the same short window |
A deposit that lines up on all three — a total that matches the settlement report's net figure, a reference consistent with the marketplace's known pattern, arriving near the expected payout date — is a confident match. A deposit that lines up on only one is exactly the case flagged for a person to confirm rather than resolved silently.
A payout period, reconciled
A two-week Amazon settlement period covering 340 orders, one net payout deposited to the bank.
| Component | Amount |
|---|---|
| Gross sales, 340 orders | $28,410 |
| Referral and fulfillment fees | −$8,920 |
| Refunds and chargebacks | −$1,140 |
| Ad spend deducted at source | −$2,050 |
| Net payout deposited | $16,300 |
The $16,300 deposit on the bank statement, taken alone, tells the seller nothing about whether $28,410 of gross sales is a plausible figure for the period. Read alongside the settlement report, every deduction lands in its own category, and the deposit is confirmed to equal gross sales minus all four deduction types — a genuine reconciliation rather than an assumption that the number looked roughly right.
How it works
Upload the settlement report and bank statement
Whatever the marketplace exports, plus the statement covering the payout date.
Every line item is read
Gross sales, fees, refunds and ad spend, kept linked to the settlement report they came from.
Matched against the deposit
By total, reference and timing together, with a confidence level per match.
Export
Excel, CSV or JSON — matched, flagged and unmatched components kept as separate, clearly labeled groups.
Reserve holds and delayed releases
Many marketplaces hold back a portion of a payout as a reserve — a buffer against future refunds, chargebacks or account disputes — releasing it weeks or months later as a separate deposit that, on its own, looks like an unexplained payment with no obvious source.
A held reserve is read from the settlement report as its own line item and tracked as pending rather than treated as a missing or short deposit. When the release eventually appears on a later statement, it's matched back to the original reserve entry rather than showing up as an unexplained windfall.
When you sell on more than one marketplace
A seller running Amazon, Etsy and a Shopify store at once faces this problem multiplied — three different settlement report formats, three different payout schedules, and three sets of deposits landing in the same bank account without any label saying which marketplace produced which one.
Each marketplace's settlement report is read on its own terms, and the results roll up into one consolidated view — a total across every channel alongside the detail for any single marketplace, covered in more depth in multi-channel payout consolidation.
What happens to what doesn't match
A deposit that doesn't match any settlement report isn't discarded or hidden — it's kept as its own visible group, with the amount, date and whatever reference exists, so someone can look at it directly instead of it disappearing into a reconciled total that quietly absorbed a mistake.
In practice, unmatched deposits turn out to be one of a small number of things: a reserve release that hadn't yet been logged as pending, a payout from a marketplace or sales channel not yet included in the reconciliation, or occasionally a genuinely unrelated deposit. Each has a specific, quick fix once it's visible.
Cross-border sales and currency conversion
A seller shipping to more than one region often has sales denominated in more than one currency, converted to a home currency somewhere between the marketplace and the bank — sometimes by the marketplace itself, sometimes by a separate payment processor sitting in between.
That conversion step means the exact deposit amount rarely equals a clean sum of the settlement report's line items in the home currency — a small, expected variance from the conversion rate applied. The matching accounts for that variance rather than flagging every cross-border payout as a mismatch by default, while still flagging a variance large enough to suggest something beyond normal currency conversion.
Who this is for
Amazon, Etsy and eBay sellers
A payout confirmed against the settlement report instead of trusted on faith every two weeks.
Shopify and multi-channel store owners
One consistent reconciliation process across every sales channel, not a separate manual check per platform.
Bookkeepers serving ecommerce clients
The same matching method applied regardless of which marketplace's export format a client happens to use.
Finance teams scaling past founder-managed books
A clear, current answer to whether payouts are tracking gross sales, without reconstructing it by hand each cycle.
This isn't a Seller Central connection
Worth being precise about the boundary. This doesn't connect to Amazon Seller Central, Etsy's API, or any marketplace account — there's no login, no OAuth, no ongoing sync. You download the settlement report yourself, the same way you already download a bank statement, and upload it here.
For sellers who already convert marketplace-specific bank statements — the kind covered in bank statement conversion for Amazon FBA — this is the other half of that picture: the settlement report itself, read and matched against the deposit the bank-statement side already extracted.
Moving from a spreadsheet or a gut check
Most sellers who reach for this have been eyeballing payouts for a while — checking that the deposit amount is roughly in the range expected, without actually tracing it back to gross sales and each deduction. It works, in the sense that a wildly wrong payout usually stands out, but it catches nothing subtle: a fee category applied incorrectly, a reserve that was never released, a refund double-counted.
The transition doesn't require abandoning that instinct on day one. A reasonable first step is running the automatic matching alongside the gut check for one payout cycle, comparing the two, and building confidence in where they agree and where the automatic result catches something the eyeball check missed.
What tends to convince a skeptical seller isn't a claim about accuracy — it's seeing their own settlement report and bank deposit produce a reconciled figure that exposes a fee category they hadn't actually checked before, in a fraction of the time a manual trace would have taken.
How often to reconcile
Matching your reconciliation cadence to the marketplace's own payout schedule is the simplest rule that actually works — every two weeks for a marketplace on a biweekly cycle, daily or weekly for a payment processor that settles more frequently. Reconciling less often than payouts arrive means several settlement reports pile up before anyone looks at any of them.
For a seller running multiple marketplaces on different schedules, it's often simpler to batch the reconciliation on a fixed weekly or monthly rhythm instead of chasing each marketplace's individual calendar — slightly less immediate, but far easier to actually sustain as a habit.
Starting with one marketplace, not all of them
A seller running several channels at once can find the idea of reconciling every payout simultaneously daunting enough to never start. A more realistic path is beginning with the highest-volume marketplace — the one whose settlement report format is already well understood — and using that as a proof of concept before extending to the rest.
That first marketplace answers the practical questions that matter before scaling up: how cleanly does the settlement report actually match, how much manual correction do the flagged lines need, and how does the resulting reconciliation compare to whatever partial check existed before. Answers from one marketplace transfer reasonably well to the others, whereas trying to onboard every channel simultaneously multiplies every early surprise across the whole business.
A marketplace with straightforward, well-documented settlement reports is a natural first candidate, not because the messier ones don't matter, but because starting with the easy case builds a working process before it has to handle a channel with reserves, currency conversion or an unusual fee structure.
What accuracy actually looks like
A useful way to think about matching accuracy isn't a single percentage — it's the shape of the distribution across the three confidence levels. A seller with clean, consistent settlement reports sees most deductions land at high confidence, with only a small tail needing review. A seller with messier reports — several reserve holds, a fee structure that changed mid-year — sees a larger medium-confidence tail, which means more review time, not necessarily more errors.
That distinction matters because it's tempting to read a larger review queue as a sign the matching is working poorly, when it's often just an honest reflection of how ambiguous the underlying settlement report actually is. The alternative — a system that resolves every ambiguous case silently and reports everything matched — isn't more accurate, it's just hiding the uncertainty instead of surfacing it.
In practice, most sellers with a mix of ordinary orders and occasional reserves or refunds see somewhere between 85% and 95% of deductions land at high confidence on a given settlement report, with the rest split between a quick medium-confidence confirm and a small number of genuine discrepancies worth investigating individually.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Sales and marketplace data are never used to train AI models.
Full details are on the security page.