How we compute an Amazon channel’s contribution from its own payment reports

What we built

Many margin models get Amazon’s referral fee wrong on the German marketplace. They apply the rate to net revenue. Amazon’s fee page applies it to the total price, including any shipping charged. On the German marketplace that price includes VAT. An ad break-even built that way starts from a fee that is too low. One built on the full amount withheld errs the other way, since part of it comes back with the VAT return.

The fee was one of several operating numbers we recomputed from the business’s own documents. A growing channel decides every week where ad budget goes, which route ships, what gets reordered and what gets dropped. Each of those decisions needs a contribution figure, and a rate card or a rebuilt spreadsheet is a weak base for it.

For a distributor’s Amazon channel we built a model that computes contribution per order and per route from payment reports, invoices and ERP records. Every figure traces back to a source line, and every margin shows how much of the data it covers. We estimate a manual cycle of the same analysis at 54 to 68 hours. The finished model rebuilds in about 15 seconds. Contribution per product follows once every purchase price is joined.

The commercial question

As the channel grew, the business needed to know which part of the growth made money. That decides which products get more stock and ad budget, which fulfillment route pays for which product, and which items should be fixed or dropped.

Every one of those decisions depends on contribution per product. If that number is wrong, budget and stock go in the wrong direction, and the error grows with the channel.

Why we started from documents

On the German marketplace a rate card applied to net revenue understates the fee, since Amazon charges it on the buyer’s total price. An analytics tool would read the same incomplete inputs and rarely show what it does not know. Primary documents are slower to start from, yet they are traceable, reusable and honest about coverage.

So we began with the few numbers that drive live decisions and recomputed them from the documents. A tool can sit on top later, once it has the same corrected inputs.

How we worked

We worked from the client’s own records. Our tool retrieves the seller account’s reports through the Amazon API and writes nothing back. We read the ERP without writing to it either. Supplier and carrier invoices arrived as PDFs and scans, which we first extracted into structured data.

The only buyer details in the transaction reports are order city, region and postcode. The parcel match uses just the postcode and the date.

Every model is built from formulas that point back to raw rows, and the team can trace a margin figure back to the transactions behind it. Each report states its coverage, and assumptions are labelled as assumptions.

The model is built for decisions on ads, fulfillment routes and reorders. The client decides, and we prepare the evidence and implement what is agreed.

The baseline

We started by listing the numbers the channel’s decisions relied on, then asked where each one came from.

• The referral fee usually comes from the rate card.
• Product cost is often missing from order data, so early models use a placeholder ratio.
• In-house shipping under the company’s own carrier contract does not appear in Amazon’s payment data.
• Monthly revenue often comes from a sales tool that counts by order date, while payments settle later.
• Ad break-even is often a rule of thumb, not a calculation.

A number is a hypothesis until a document confirms it

The figure a business runs on is often an assumption that was never checked against its own records, and usually the corrected figure is already on file.

The referral fee is a good example. The rate card states a percentage, and Amazon’s fee page says it applies to the total the buyer pays. The payment reports show what was actually withheld, order by order. A model that applies the rate to net revenue carries a fee that is too low, and every break-even built on it inherits that gap.

The economics

Contribution per unit is net revenue minus fee, fulfillment, advertising, returns and product cost. Each of those lines can be taken from a rate card or from a document, and the difference compounds.

In the example sale below, the rate-card view keeps 15 euros per 100 of net revenue and the document view keeps about 10. Only 1.90 euros of that gap comes from the fee basis. The rest comes from a shipping service that costs more than assumed and slightly higher returns, both set by the example. Small differences in several lines add up, and the fee is only one of them.

That gap changes decisions. A product that looked worth growing may belong in the fix column. One that looked like a loss may be worth keeping, because it carries orders that support the account. Advertising works the same way. A campaign breaks even when its return on ad spend equals the net price divided by contribution per unit before advertising. If the ad report counts sales including VAT, use the gross price.

One example

In-house shipping cost shows the method from end to end.

The problem. Contribution per product could not be compared across fulfillment routes. FBA orders carry Amazon’s fulfillment fee in the payment data, and so do labels bought through Amazon’s shipping service. Parcels shipped under the company’s own carrier contract do not. That cost sits in carrier invoices, outside Amazon’s reports.

The new measurement. We extracted the carrier’s invoices parcel by parcel. The carrier data and the orders share no common key, so we matched parcels to orders by postcode and date, within a window of a few days. Machine checks confirm that no parcel is counted twice and no order carries two shipping sources.

Those checks prevent double counting, but they cannot prove that every match found the right order. Two orders to the same postcode within the window can swap their parcels. That only moves single label amounts between orders. Our model reads shipping cost per product and route, where such swaps largely even out.

We then compared margins like for like, with only orders that carry a visible shipping cost in the comparison and the coverage share shown next to every margin.

What it changes. With the match in place, routes become comparable per unit, and that can show whether a service level was chosen by default or by need. Switching needs a check against the delivery promise first. An export with parcel numbers and order references would replace the postcode match with an exact key.

The whole calculation rests on one data model. Payment lines hang off orders, and fees and refunds hang off payment lines. Carrier parcels and purchase prices join from outside the marketplace.

The fee has two VAT effects

Nothing here is hidden. Amazon publishes the rule, yet the fee line is easy to misread when a margin model starts from net revenue.

On the German marketplace the referral fee is charged on the buyer’s total price, including VAT and any shipping charged. The business earns only the net price. Measured against net revenue, the fee for standard-rate goods is 19 percent higher than the rate, so 10 percent becomes 11.9 percent. That part is a true cost, and reduced-rate goods show a smaller gap.

Some categories use tiered rates, and most have a minimum fee of €0.30 per item. On a refund Amazon keeps an administration fee, the lesser of €5 or 20 percent of the referral fee. The payment lines already reflect all of this, which is one more reason to start from them.

The second effect is different. Since August 2024, per the platform’s notice, Amazon has invoiced its fees to German sellers with German VAT added. That VAT is withheld from the payout too. A seller entitled to deduct input VAT recovers it through the next VAT return. It costs cash for a few weeks, not margin.

The payout data shows both effects together. The profit and loss should show only the first. Our model separates them. The contribution view uses the fee after the VAT recovery, and the cash view uses the full deduction.

Reconciled is not complete

Agreement between two systems says nothing about what both are missing.

Two systems can agree to the cent while the field a margin needs is almost empty. Purchase prices often exist in supplier price lists but are never joined to the articles in the ERP, because names differ between the lists and the ERP. The result is a margin view that is precise and verified, but not yet trustworthy.

Nothing is broken in that case. Every component does what it was built to do, and the limit has moved from engineering to data supply. A system that goes live without a plan for its inputs reports accurate figures about incomplete data. People then experience that as the system being wrong.

We show coverage first: a margin figure always comes with the share of orders it covers. A placeholder stays labelled as a placeholder until real purchase prices replace it.

Guardrails

• Source lines, not summaries. Every figure is a formula over raw transaction rows, and manual inputs such as purchase prices sit in marked cells.
• Coverage beside every result. Missing costs are shown as missing, not as zero.
• Payment date and order date kept apart. Month-end orders land in different months in the two views. Each chart says which one it uses.
• Consistency checks on every build. Automated checks confirm that totals agree and nothing is counted twice. They catch errors in the build and do not replace a review of the inputs.
• Estimates stay labelled. When a transaction report omits fees on some units, we estimate those conservatively and mark them for a check.

In 2026 Amazon added lines above the header of its transaction report. A parser that skips a fixed number of lines would have taken the wrong row as the header. Ours now finds the header row itself.

What it makes possible

A traceable contribution figure can feed several decisions at once. Ads can get a break-even per campaign, and stock can go to the fulfillment route that earns more per unit. As purchase prices are joined, the range can be sorted into grow, fix and stop, each time from a view that rebuilds in seconds.

The same model can also serve cash planning, as it already records what each order pays out and when. That payout timing is what a business needs to buy stock closer to demand and move budget to products that pay back faster. The next measurement is contribution per product, once every purchase price is joined.

Principles for your business

1. Treat every operating number as a hypothesis. Start with the few that drive live decisions.
2. Recompute from your own documents. Payment reports, invoices and the ERP usually hold the answer already.
3. Show coverage beside every margin. A precise figure on thin data is worse than an honest range.
4. Separate cost from cash. Some deductions come back. Plan them as cash, not margin.
5. Fix inputs before dashboards. A tool on top of wrong inputs only makes the wrong number faster.

If your ad break-even still rests on the rate card, your own payment reports are the first document we would open with you.

Credits

Built by Capcelerate with the client’s management and operations team.