Resources · automationecommercefinance
Ecommerce SKU profitability reporting - see profit after fees and returns
Ecommerce SKU profitability reporting should show a margin card for each product with sales, refund rate, fees, fulfilment, available ad spend input, and confidence in the cost data. Revenue alone can make a product look healthy while fees, returns, and fulfilment make it a poor choice.
Do not promise a true margin when key costs are absent. The card should show what it knows and what it does not.
What should a SKU margin card show?#
| Field | Why it belongs on the card |
|---|---|
| SKU and period | Makes the comparison specific and dated |
| Units and gross sales | Shows the revenue base |
| Refunds and return rate | Shows money and demand that did not hold |
| Platform and payment fees | Includes costs withheld before payout |
| Fulfilment and product costs | Makes the delivery cost visible |
| Ad spend input, where available | Separates sales from acquisition cost |
| Data confidence | States missing, estimated, or verified inputs |
A card with a confidence field is more honest than a precise-looking margin based on partial data. Reconciled fees and refunds should come from the reconciliation ledger, not a guessed percentage.
Which SKU should trigger a review?#
Review a high-revenue SKU with rising refunds, a product whose fee or fulfilment costs changed, or an item whose cost data is missing. The point is not to rank every product automatically. It is to stop an operator increasing spend or reordering based only on sales.
Inventory numbers matter too. A product can look profitable while an inaccurate count creates stockouts, backorders, or rushed fulfilment. Keep the daily stock check in inventory discrepancy detection separate from the margin calculation.
How does the SKU-profit build actually go?#
We first agree the store's definition of a usable SKU margin and the period it will use. We list the sources for sales, refunds, fees, fulfilment, and cost data. The client keeps the card, source list, and the note that explains every missing input.
The build joins the agreed source files into a draft card and flags a product when a written rule calls for review. It can state the data confidence. It does not set a price, pause an ad, or place a purchase order. An operator sees the evidence and decides the next commercial action.
We shadow-run the cards against a past period that the finance owner understands. The team checks whether fees and refunds tied to the source records and whether the cost fields mean what the card says they mean. Where the data is incomplete, the correct output is a visible gap, not a made-up margin.
Amazon operators can use the same discipline for settlement and listing signals in Amazon seller back office. The system should find the product worth reviewing, not tell a human what to buy.
What should you build before a profitability dashboard?#
Choose one SKU you are tempted to promote. Put sales, refunds, fees, fulfilment, and the confidence of each cost on a card. If a number is missing, label it. That is more useful than a dashboard with a margin nobody can defend.
Where does this fit with the rest of the operation?#
The evidence-first design follows automation that finds problems: a system should show why a product needs attention. If a file arrives in a messy shape, the judgment boundary in AI agent vs Zapier helps decide what should remain a review.