How to calculate true Amazon profit from settlement dataHow we calculate true profit

Your P&L won't equal your deposit - and it shouldn't

A settlement deposit includes money that isn't profit and excludes context that is. Deposits carry sales tax you're only holding, reserve movements that are timing rather than profit, and ad spend that we count from the Ads API instead (where it can be split by campaign type and attributed to products). So net profit and deposit amount are different numbers, by design and correctly - and we show you every reconciling line between them. That's a stronger claim than "matches your deposit," because it's the one that's true on every single account.

Where the numbers come from

Two sources, doing different jobs.

Settlements - the cash truth. Every line Amazon paid or charged, with its order ID, SKU, posted date, marketplace and currency. This is what reconciles. It arrives when Amazon closes a settlement period, roughly every two weeks.

Orders and live refund events - the current period. Settlement data for today doesn't exist yet. Until it lands, sales and units come from order data (which is actual, not estimated), refunds come from Amazon's Finances API within hours of processing, and fees are estimated from your own account's history: the same ASIN's recent settled effective rates - referral fee as a percentage of revenue, fulfillment fee as a per-unit amount. Not a generic fee schedule; your actual rates, from your actual settlements. As real settlements land, the estimated slice shrinks and trues up to exact - a fully settled period has no estimated component at all.

Every row is flagged with which regime it's in. A row either has settlement data behind it or it doesn't, and the platform says so rather than blending the two silently. A day only counts as fully settled when its settled revenue actually covers its ordered revenue - a stray fee landing on a recent date doesn't fool it.

The fee taxonomy - all thirteen buckets

Amazon does not post fees in a tidy list. A single account accumulates dozens of distinct transaction-type / amount-type / description combinations, and Amazon adds new ones without notice. Every combination is classified into one of thirteen buckets. Nine count toward your P&L; four are deliberately kept out.

Counted in your P&L (9)

Bucket	What it captures
Revenue	Principal, shipping, gift wrap - including liquidations and liquidation adjustments
Referral fee	Amazon's commission
FBA fulfillment fee	Per-unit fulfillment
Other item fees	Shipping chargebacks, gift-wrap chargebacks, liquidation brokerage
Refunds	Refunded principal, shipping, gift wrap, restocking fees, goodwill - and the fee credits that come back with them
Promotions	Principal and shipping promotions
Reimbursements	FBA inventory reimbursements by reason code, net of clawbacks
Other order-level	Deal participation and performance fees, coupon fees, AWD processing, inbound placement, disposal
Account-level fees	Storage, long-term storage, AWD storage, subscription, inbound transportation, fee adjustments

Two details worth calling out, because most tools miss both - and both mistakes are in the seller's disfavour:

• Refund fee credits. When a customer refunds, Amazon returns part of the referral fee. That credit is a separate settlement line from the refunded principal. Both are captured. A tool that only subtracts the refund overstates your loss.
• Reimbursement clawbacks. Amazon reverses reimbursements it later decides were unwarranted. Those post as negative lines and net against the credit. A tool that counts reimbursements as pure income overstates your recovery.

Deliberately excluded (4)

Tax - passthrough. Amazon collects sales tax and, under marketplace-facilitator rules, withholds and remits it. Both sides post to the settlement and net to approximately zero across an account. It was never your money, so it isn't revenue and isn't profit. (If you operate in a jurisdiction where you remit tax yourself, collected tax is still excluded from revenue - your remittance obligation lives outside the P&L, where it belongs.)

Advertising - counted once, from the Ads API. Ad spend appears in the settlement as a lump service fee. Counting it there and from the Ads API would double it. We count it from the Ads API instead, because that's the only source that splits Sponsored Products, Brands and Display and attributes spend to campaigns and products. The settlement figure is the reconciliation check, not the input.

MCF and non-Amazon orders. Multi-Channel Fulfillment ships your inventory for orders placed off Amazon. The fulfillment fee lands in your Amazon settlement, but the revenue never does. Including the cost without the revenue would understate your Amazon margin, so MCF is tracked separately - with its own view.

Reserve movements. Amazon holds and releases reserve balances between settlement periods. The lines are equal and opposite, they move your deposit, and they have nothing to do with whether you made money.

Refunds arrive twice, and we use the fast one

A refund shows up in Amazon's Finances API within hours of processing, with exact per-SKU amounts. The same money shows up in the settlement weeks later. Waiting for the settlement means your P&L looks better than reality for two weeks - right when you'd be making bidding decisions on it.

We take the refund event immediately. When the settlement lands, the settlement line wins per order and SKU and the early event steps aside - the same refund is never counted twice, and the early number is replaced by the reconciled one rather than layered on top of it.

COGS

Your landed cost per SKU and marketplace - the unit cost plus optional freight, duty, and packaging components - versioned by effective date. A cost change applies from the day it took effect, not retroactively across your history: a container of goods at one price in March and another in August produces the right margin in both months.

Coverage is measured and shown, not assumed. Every P&L row carries how many of its units had a known cost and what percentage that covers. A product with no COGS entered doesn't get a quietly wrong margin - it gets a visibly incomplete one.

The waterfall

Revenue → refunds → COGS → gross profit → Amazon fees → contribution margin before ads → advertising → contribution margin → operating expenses → true profit

Three margin lines, because they answer different questions: is the product itself economic, is it economic the way you're currently advertising it, and what's actually left after your own operating costs.

Breakeven ACoS falls out of the margin before ads. It's not a category benchmark or a rule of thumb; it's the point where an additional advertised sale stops adding money, computed nightly from your own trailing costs and fees. That number is what the automation thresholds and the AI's recommendations key off.

Currency and marketplaces

Every figure carries its currency, and currencies are never blended. No conversion at an invented FX rate, no "total revenue" that silently mixes USD, CAD and EUR at yesterday's spot. You look at one currency at a time, because that's the only version that's true. Days are bucketed by each marketplace's local date - the same way Seller Central buckets them - not by UTC.

The honesty layer

Every P&L row is flagged for what's behind it: whether settlement data has landed, whether ad cost is present and by ad type, whether COGS exists and for what share of units, and whether a row is ad-spend-only with no matching sales.

We would rather show you an incomplete number labelled incomplete than a complete-looking number that's wrong. That's the design principle the whole warehouse is built on, and it's why the flags exist at row level instead of as a footnote.

Check our work

Two things you can do that most tools don't offer:

• Audit the classification. The settlement audit shows every distinct fee combination Amazon has ever charged your account, with the bucket it landed in and whether it counted. If something looks miscategorised, you'll see it - and so will we, because it's the same view we use.
• Trace any number to its transaction. Drill from a P&L figure to the settlement lines underneath it: order ID, SKU, posted date, amount, settlement ID. Nothing is a black box.

Known limits

A methodology page that claims perfection isn't a methodology page. Honestly:

• First sync. Your most recent weeks land within hours of connecting; order history backfills to roughly 90 days automatically, and settlement history reaches as far back as Amazon still serves settlement reports at connect time. History accumulates forward from there.
• The current period is partly estimated. Until settlement lands, fees on unsettled sales are estimated from your own settled rates (above). Sales, units, and refunds are actual.
• Account-level fees post at settlement. Storage, AWD, and deal fees have no reliable pre-settlement source, so the current period carries a visible caveat for that unsettled tail instead of an invented estimate - the same behaviour you see in Seller Central.
• A fee type we've never seen still counts. An unrecognised combination lands conservatively as an order-level or account-level cost, and it appears in the audit as its own line - it is never silently dropped. If Amazon invents a fee tomorrow, you'd see it in the audit the day it first posts.
• Some auxiliary datasets roll out by marketplace. Sessions and traffic sync per storefront and backfill marketplace by marketplace, so newly added storefronts may still be filling in. Brand Analytics datasets require Brand Registry.