Profit per order and profit per unit differ because an order can contain more than one sellable unit. When both calculations use exactly the same profit total and reporting scope, profit per order equals profit per unit multiplied by units per order. Multipacks, mixed-product orders and refunds add complications because they can change what you mean by a unit, which orders belong in the calculation, or which costs the profit total includes.
Before treating the difference as a reporting error, write down three definitions: the profit numerator, the order population and the sellable-unit count. Then check whether the two metrics describe the same activity. A higher profit per order can simply mean larger baskets, while profit per unit stays unchanged or falls.
What must match before the two figures are comparable?
Start with the same date range, marketplace, currency and product selection. Use one profit total, after the same costs, for both calculations. Dividing historical net profit by orders and comparing it with an estimated profit on the next unit is a different comparison altogether.
For your own analysis, define order count as the number of distinct qualifying orders, rather than the number of rows in a file. Define units as the quantity of sellable units included in those orders. One order containing three units contributes one order and three units. An order split across several product lines still contributes only one order to the whole-catalog calculation.
These choices give a useful arithmetic check:
Profit per order = total profit ÷ distinct orders.
Profit per sellable unit = total profit ÷ sellable units.
Therefore, profit per order = profit per sellable unit × sellable units per order.
The identity depends on matching populations. It does not prove that the underlying profit is complete, that costs are correct or that the next order will earn the average. It proves that two averages built from the same totals fit together.
How do multi-unit orders change the result?
Consider a hypothetical month for one SKU. The figures below are illustrative arithmetic, not a seller result or an Amazon fee estimate. Assume the stated profit already includes the costs chosen for this analysis.
| Measure | Calculation | Result |
|---|---|---|
| Distinct orders | Count of qualifying order IDs | 100 |
| Sellable units | Sum of quantity on those orders | 150 |
| Total profit | Same numerator for both averages | $600 |
| Units per order | 150 ÷ 100 | 1.50 |
| Profit per order | $600 ÷ 100 | $6.00 |
| Profit per unit | $600 ÷ 150 | $4.00 |
Both profit averages are correct. The $2 difference is not a missing fee. It follows from selling 1.5 units per order.
Now imagine the following month produces $660 profit from 100 orders and 180 units. Profit per order rises to $6.60, but profit per unit falls to approximately $3.67. Larger orders generated more total profit while earning less per unit.
That observation creates a specific next question: what changed in the economics of the additional units? A quantity discount, different shipping cost or product combination might explain it. The denominator check gets you to that question without incorrectly concluding that the two reports disagree.
Compare total profit alongside both averages. A falling per-unit average can coexist with a useful increase in total profit. It can also conceal rising handling demands or inventory consumption. The averages describe what happened; the operational decision requires the costs and constraints behind them.
Does a three-pack count as one unit or three?
For analysis, distinguish the sellable pack from the physical pieces inside it. If the order record shows quantity one for a three-pack SKU, that row represents one sellable pack in the calculation. You can separately convert it into three component pieces for manufacturing or purchasing analysis.
Suppose a hypothetical three-pack produces $9 profit per pack. One pack per order gives $9 profit per order and $9 profit per sellable unit. Dividing by the three pieces inside produces $3 profit per component. All three figures can be useful, but the last one is a new metric with a different denominator.
The same distinction applies to costs. A pack containing three components with a $2 component cost consumes $6 of components before any pack-specific costs. Entering a $2 component cost against a sellable three-pack would understate that portion of cost by $4 per pack. This is a unit-definition problem before it is a margin problem.
Maintain a small mapping that records SKU, sellable-unit description and components per sellable unit. Review it when pack size changes. Do not silently overwrite an old pack definition and then apply the new quantity to historical orders.
Avoid combining singles and packs into a single physical-unit average unless the comparison genuinely needs that view. A catalog containing bottles, replacement caps and gift boxes does not have a naturally meaningful total component count. Profit per sellable unit remains reproducible, but its interpretation depends on the product mix.
What happens when one order contains several SKUs?
At product level, an order count usually answers a narrower analytical question: how many distinct orders contained this product? Those counts cannot automatically be added to recover total catalog orders.
Imagine 70 orders containing SKU A and 50 containing SKU B. If 20 orders contain both, there are 100 distinct orders overall, not 120. Adding the two product-level order counts double-counts the shared baskets.
This matters when assembling a report from product tabs. Sum additive measures such as the relevant units and profit amounts after checking that the rows are mutually exclusive. Recalculate the distinct order count across the combined population. Do not add product-level order counts or average their profit-per-order figures without the appropriate weighting and deduplication.
A related mistake is dividing a SKU’s profit by every order in the account. That can be a deliberate portfolio measure, but it is not average profit per order containing that SKU. Give it an explicit label if you need it, and do not compare it with the narrower measure as though both describe the same denominator.
Should a partial refund remove an order from the denominator?
A refund changes the economic result, but it does not automatically mean that the original order disappears from an analytical population. Decide what question the metric answers before changing either denominator.
Return to the 100-order, 150-unit example. Suppose the profit total falls from $600 to $570 after a partial refund and the associated cost effects included in this hypothetical analysis. If the aim is profit generated by those original orders, the denominators remain 100 orders and 150 originally sold units. The averages become $5.70 per original order and $3.80 per originally sold unit.
Removing one whole order because it received a partial refund would change the question. Subtracting one unit would also need evidence about the unit event, rather than an inference from the refund amount. A monetary adjustment does not specify how many physical units were returned or retained.
You may also want a separate metric based on retained units or completed, non-refunded orders. Label it clearly and define the exclusions. Do not quietly substitute that denominator into a metric previously based on all original orders. Otherwise the average can improve simply because loss-making activity was removed from the population.
For calendar-period reporting, check timing too. Profit recorded during a month can include adjustments connected with earlier orders. Dividing that total by this month’s orders describes a period average; it does not necessarily describe the final lifetime profitability of this month’s order cohort. Keep that caveat beside the result rather than inventing a universal waiting period.
How can you investigate the difference in sellerboard?
Start with the Profit Dashboard for the historical period you want to understand. sellerboard supports product and marketplace filters, so align the selection before comparing figures. Record the active filters and the profit amount you are using. The Profit Dashboard help describes these controls.
Next, establish whether the value you compared was historical or estimated. The Profit per unit column on sellerboard’s Products page is a quick estimate, with its own cost breakdown. It is not interchangeable with a period’s realized profit divided by units. The Products help makes this distinction explicit.
A practical investigation has two parts. Use sellerboard to understand the profit numerator and review the relevant cost inputs. Then, in your working analysis, independently count distinct order IDs and quantities from suitable order-level records. Inspect a few multi-unit and mixed-SKU orders before scaling the calculation to the whole period. This is a recommended reconciliation method, not a claim that sellerboard automatically provides every custom denominator described here.
For a pack SKU, compare the cost input with the cost of the sellable pack. For a multi-unit order, check whether each cost you modeled is genuinely per order or per unit. For a historical comparison, retain the original cost evidence and note corrections rather than assuming a current estimate explains the past.
Keep a short calculation sheet beside the dashboard review: profit source, date range, filters, distinct orders, sellable units and the resulting averages. If someone else cannot reproduce the numbers from that sheet, resolve the missing definition before using the comparison. The arithmetic does not require a new reporting feature; it requires consistent inputs.
Which mistakes most often create a false discrepancy?
Counting rows as orders is the first. Check whether repeated IDs are different products, quantities or events before deciding how to aggregate them.
Mixing sellable packs with their components is the second. Put the unit definition in the column heading, especially when a supplier invoice and an order report use different units.
Averaging averages is the third. For a catalog’s profit per unit, divide total profit by total units. A simple average of SKU averages gives a low-volume SKU the same weight as a high-volume one.
Changing the numerator while blaming the denominator is another. An estimated unit profit, a product contribution figure and account-level net profit may include different costs. Match those costs first.
Finally, avoid treating a better average as proof of a better business result. Review total profit, quantity and operational demands together before changing prices or encouraging larger baskets.
FAQ
When are profit per order and profit per unit equal?
When the calculation uses the same profit total and there is exactly one sellable unit per qualifying order on average.
Can profit per order rise while profit per unit falls?
Yes. Larger baskets can increase profit per order while earning less on each unit. Compare both with total profit.
Should I count the pieces inside a multipack as units?
Use the sellable-unit definition for order analysis. A per-component calculation is separate and needs a documented conversion.
Does a partial refund reduce order count?
Not automatically. Keep the original population for profit per original order, and label any alternative exclusion-based measure.
The useful result is a reproducible comparison: one profit total, a defined order population and a clear unit count. Once those align, the difference between the averages becomes information about basket size rather than an unexplained reporting problem.
