A settlement report is a wall of deductions
Open a marketplace settlement report and the hard part isn't reading it — every line is labeled clearly enough. The hard part is confirming that all those individually labeled lines actually add up to the one net figure that landed in the bank, and that nothing was double-counted, mislabeled, or quietly missing.
This page describes exactly that mechanic — the logic that sits underneath marketplace payout reconciliation, spelled out on its own because it's the part worth understanding in detail before trusting it with real settlement data.
Why fee categories alone aren't enough
In the simplest case, a settlement report lists every fee under a clearly named category, every refund tied to a specific order, and the whole thing sums cleanly to the deposit. That case needs no cleverness at all. What makes matching genuinely hard is everything short of that ideal.
A fee might be labeled generically enough that it's unclear which order it belongs to. A refund might be processed in a different settlement period than the original sale, appearing to belong nowhere in the current report. Two orders might carry near-identical amounts, where a single misattributed line changes which order a real deduction lands against. None of these are exotic edge cases — they're what a settlement report built for a marketplace's own internal accounting, not for a seller's reconciliation, produces routinely.
What gets read
| Field | Where it's checked |
|---|---|
| Order or transaction ID | Read exactly as printed on the settlement line |
| Fee or deduction category | Compared against the marketplace's own category structure |
| Amount | Summed per category and checked against the report's own subtotals |
| Settlement period and date | Compared against the payout's expected date range |
The matching hierarchy
Rather than trying every possible category at once and picking whichever seems most likely, matching checks a fixed hierarchy in order — the same sequence, applied the same way, every time.
Order or transaction ID matches exactly
The strongest signal available. Matched with high confidence when the category and amount also fit.
Category and amount match, order ID is ambiguous
Matched with a flag for a quick human confirm rather than accepted outright.
Only the amount and settlement period point to one plausible line
Matched with medium confidence, based on the strength of the remaining signals alone.
None of the signals resolve to a single line
Left unmatched, visible as its own group, never guessed from whichever category is currently short.
A line never skips to a weaker signal just because a stronger one wasn't found — each combination is evaluated on its own merits, not as a fallback chain.
Reading a settlement report's fee categories
Every marketplace structures its fee categories differently. Amazon splits fees into referral fees, FBA fulfillment fees and storage fees, each with its own line. Etsy separates listing fees, transaction fees and payment processing fees. Shopify Payments bundles processing fees per transaction with a separate payout-level summary.
Rather than forcing every marketplace's categories into one fixed template, matching reads whatever category structure the actual settlement report uses and groups deductions accordingly — a referral fee stays a referral fee, a transaction fee stays a transaction fee, and the totals are checked category by category against what the report itself claims.
Three confidence levels
Not every match is equally certain, and treating them all the same — either all trusted or all reviewed — wastes effort in one direction or risks silent errors in the other. Three levels keep that distinction visible.
| Level | When |
|---|---|
| High | An exact order ID match with a category and amount that fit the report's own subtotal |
| Medium | A category and amount match with an ambiguous order reference, or a period-only match against a unique line |
| Low / unmatched | No combination of signals resolves to a single settlement line |
For a settlement report with hundreds of lines, that distinction is what turns a full manual review into a review of the handful that actually need one — most of a payout period's deductions typically land at high confidence and need no attention at all.
When a line item genuinely doesn't match anything
Some deductions were never going to match a clean category — a one-off adjustment, a promotional credit applied outside the normal fee structure, or a correction from an earlier settlement period folded into the current one. Forcing a match onto those lines would be worse than leaving them unmatched, because it would misrepresent an unusual deduction as a routine fee.
Those lines are kept in their own visible group rather than being pushed into whichever category happens to look short at the time. What happens to them next — investigated, reclassified, or simply logged — is a decision made by a person, not by the matching logic.
Why consistent SKUs and order IDs help
A seller whose product listings use consistent, stable SKUs across marketplaces is, without realizing it, doing a large part of the matching work in advance. Order IDs are assigned by the marketplace and can't be changed, but keeping SKU naming consistent across a catalog makes it far easier to spot when a deduction pattern shifts unexpectedly for a specific product line.
For a seller whose settlement lines consistently land at medium confidence or worse, checking whether SKUs are being renamed or reused across different products is often the fastest fix — the cleanest correction to a matching problem is frequently upstream, in the catalog itself, not downstream in how the report gets read.
How it works
Upload the settlement report
Whatever the marketplace exports, in whatever category structure it uses.
Each line is read
Order ID, category, amount and period, for every deduction found.
The hierarchy check runs
Order ID, category, amount and timing evaluated together, in a fixed order.
Export
Excel, CSV or JSON, with confidence levels and source documents kept per line.
When a marketplace changes its fee structure
Marketplaces periodically restructure their fee categories — a new category introduced, an old one split into two, a rate change applied mid-quarter. A settlement report from before the change and one from after can look meaningfully different even though the seller's actual selling activity didn't change at all.
Because matching reads whatever category structure the current report actually uses, rather than expecting a fixed template, a fee-structure change doesn't break the matching — it just means the categories in the output shift to reflect the new structure, which is itself useful information when comparing periods before and after a change.
A settlement report, matched
An Etsy settlement report covering 210 orders over two weeks, run through the matching hierarchy.
| Result | Lines |
|---|---|
| Matched with high confidence | 196 |
| Matched, flagged for a quick confirm | 9 |
| Unmatched — investigated separately | 5 |
The five unmatched lines turned out to be a mix of promotional credits applied from an earlier marketing campaign and one refund processed against an order from the prior settlement period — both legitimate, neither obvious without the flag pointing directly at them.
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 settlement report with clean, consistent order IDs and a stable category structure sees most lines land at high confidence, with only a small tail needing review. A report with messier data — categories that shift between periods, orders spanning a multi-item bundle — 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 line 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 promotional or reserve activity see somewhere between 90% and 97% of settlement lines land at high confidence on a given report, with the rest split between a quick medium-confidence confirm and a small number of genuine discrepancies worth investigating individually.
Improving match rates over time
The match rate on a seller's first settlement report is rarely its best one. Two things tend to improve it steadily after that: a catalog with progressively more consistent SKU naming, and familiarity with a specific marketplace's recurring quirks — the effect described above in the section on consistent SKUs and order IDs.
A third factor is specific to sellers running multiple marketplaces: once each channel's settlement format is understood and confirmed to parse cleanly, that channel's deductions tend to match at consistently high confidence every subsequent period, since the underlying report structure rarely changes once established.
None of these improvements require a change to the matching logic itself — they're improvements to the underlying data the matching runs against, which is usually the more effective place to invest effort when a match rate feels lower than expected.
How reserves interact with matching
A reserve line on a settlement report doesn't behave like an ordinary fee or refund — it doesn't correspond to a specific order, and it isn't meant to be matched against gross sales the same way a commission or fulfillment fee is. Treated as an ordinary deduction, a reserve line produces a confusing mismatch that has nothing to do with a real error.
Matching handles a reserve line as its own category, tracked separately from order-level deductions, and checked only against its own later release rather than against gross sales for the current period. That keeps the reserve from distorting the confidence scoring applied to every other, genuinely order-level line on the same report.
The practical result is that a settlement report with a large reserve hold doesn't automatically produce a wave of low-confidence matches across unrelated lines — the reserve is isolated to its own line, and the rest of the report matches exactly as cleanly as it would without the reserve present at all.
What you get back
One row per line item
Category, order reference, amount and confidence level, each in its own column.
Unmatched lines kept separate
Visible as their own group, not folded into whichever category was short.
Traceable to source
Every row linked back to the settlement report it came from.
Who this is for
Mostly useful for anyone processing more than a handful of orders per settlement period, where checking individual fee lines by hand has stopped being a quick task: Amazon, Etsy and eBay sellers, Shopify store owners with high order volume, and bookkeepers matching fees across multiple sellers each with their own marketplace mix.
Matching across several settlement reports at once
A seller catching up on a backlog of unreconciled payouts often has several settlement reports to process together rather than one at a time. Matching each report individually and combining the results afterward works, but it means any order that spans two reports — a sale in one period, a refund processed in the next — has to be tracked across the boundary manually.
Reading multiple settlement reports together lets matching resolve those cross-period cases automatically, connecting a refund to its original sale even when the two fall in different reports, rather than leaving both halves flagged as individually unexplained.
Where this stops
Fee and payout matching confirms that a settlement report's own numbers are internally consistent — it doesn't decide whether a fee rate was correct, dispute a charge with the marketplace, or replace the accounting system you already use for inventory and bookkeeping. Those decisions, and the full picture of how matched line items become a reconciled payout, are covered in marketplace payout reconciliation.
That boundary is worth restating plainly, because it's easy to conflate “the numbers are internally consistent” with “the numbers are correct.” A settlement report can be perfectly self-consistent and still reflect a fee rate a seller never actually agreed to — matching surfaces that possibility clearly, but confirming or resolving it is a separate step outside what this feature does.
Keeping that distinction visible, rather than blurring it, is what lets a seller trust the matched output for what it actually is: a reliable map of where every deduction landed, ready for a human decision about whether any of it is worth questioning further.