Shopify's profit reports subtract the cost recorded with each sale from net sales, and stop there. Sales made without a recorded cost are left out, the cost has no dated history you can read or correct, and shipping, payment fees, ad spend and overhead never reach the report. Its gross profit is a CM1 at best.
Shopify's profit reports answer one question: net sales minus the product cost it had on file, which it calls gross profit. Behind them sits one field with no dates attached, which decides what that cost was. Three mechanics decide whether even that number is right. The cost per item field holds a single static value captured at the moment of the sale, sales made before a cost was entered are left out of the report rather than counted, and nothing below gross profit exists in the report at all. In one example store, the costs sitting below gross profit came to €5.152.163,10 over fourteen months, which is 41,55% of net revenue.
None of that is a flaw. Shopify records what customers paid with real precision: orders, discounts, taxes and returns, to the cent, on the right day, and its help pages are candid about what the cost field can and cannot do. The argument is about scope, not competence. What follows is the mechanical version, behaviour by behaviour, and what each one does to the number you read.
Shopify's cost field has no history
Every variant has one Cost per item field. It holds one number, it carries no dates, and entering it is optional. The help page for profit reports states the consequence plainly.
The Cost per item field contains static data, which means that the data in your profit reports is only relevant to a specific point in time. Shopify Help Center, Profit reports, checked 1 Oct 2026
In practice the cost is captured when the sale happens. Change the field today and yesterday's report does not move, which is better behaviour than the spreadsheet everyone starts with, where editing one cell silently reprices three years of orders. The same design has two costs of its own. You cannot correct a past order, because there is no way to put a cost back into a sale that did not carry one. And you cannot hold two facts at once: what a unit cost you in March and what it costs you now. The field only knows now.
The fix is effective dating. A cost rule carries the day it takes effect, so saving a new value closes the previous one the day before and opens a new one, and every order stays priced by the rule that was true when it was placed. Backdating is still possible, but it becomes a deliberate act that reprices the days from that date forward and nothing earlier.
An example store shows what that buys you, on a cost that is not even a product cost. Its return handling charge was €1,25 per returned shipment until 1 Apr 2026 and €1,50 from that day on. A return processed on 20 Mar 2026 is still priced at €1,25 today and always will be; one processed on 20 Apr 2026 is priced at €1,50. Neither figure moves when the next price change is entered. Every cost in nouz behaves that way: product costs, the shipping rate card, pick and pack, packaging, payment fee rules and fixed costs.
Missing costs are not treated as zero, they are dropped
A variant with no cost does not report a 100% margin in Shopify's profit reports. It is left out of them. The help page for those reports says which sales are counted.
The report only takes into consideration the variants that have product cost information at the time of sale. Shopify Help Center, Profit reports, checked 1 Oct 2026
The finance reports go further and name the gap: net sales are split into the part where a cost was recorded at the time of the sale and the part where it was not, and only the first counts towards gross profit. That is an honest design and a better one than the alternative, because a blank treated as €0,00 turns your worst documented product into your most profitable one.
The catch is what it does to a percentage. If two thirds of your catalogue carries a cost, your gross margin is a true statement about two thirds of your sales, sitting next to a revenue chart that covers all of them. Neither number is wrong and the comparison between them is meaningless. The gap is only visible if you go looking for it, and blanks do become zeros the moment the data leaves Shopify for a spreadsheet or a tool that multiplies whatever it finds in the field.
nouz takes the third option. The sale still counts, the missing cost is reported as a data health warning on the Products page with the variants named, and an unset cost is never quietly treated as €0,00. A gap you can see is a task. A gap you cannot see is a wrong number.
Refunded units and which day they land on
Shopify dates the revenue side of a refund the same way nouz does, and that is worth saying on a page like this one. From the sales reports documentation:
Returns display as a negative number on the date the return was processed. Shopify Help Center, Sales reports, checked 1 Oct 2026
The cost side is the harder half, and two questions decide it: which day the credit for the returned unit lands on, and at what cost that credit is valued. Any report that nets refunded units against sold units inside whichever date range you picked answers both questions with the range. Ask it about June and you see a sale with no credit. Ask it about August and you may see a credit with no sale. Neither view is wrong so much as partial, and a margin percentage read off either one is doing arithmetic across two different populations.
nouz answers both questions explicitly. The credit lands on the refund date, beside the refunded amount, the refunded tax and the cost of processing the return. It is valued at the cost rule effective on the original order date, so the credit matches the original debit to the cent, and a supplier price change between the sale and the return can never manufacture a gain or a loss that nobody made. That rule is subtle enough to deserve its own post.
Nothing below gross profit exists
The profit reports are gross profit by product, gross profit by product variant, gross profit by POS location, average profit margin by market, and profit margin by order. Every one of them is net sales minus the recorded product cost. There is no line below that and nowhere to put one. The revenue half of this argument is made in what Shopify Analytics does not tell you; this is the cost half.
So none of the following reaches the report: your shipping rate card by zone and by weight or parcel size, pick and pack, packaging, packaging EPR fees, the cost of processing a return, the payment provider's percentage and fixed fee, what you spent on Meta, Google and TikTok yesterday, and rent, salaries, software and agency retainers. Some of that data does exist inside Shopify. If you use Shopify Payments, the fees are in your payouts and in the payments activity report, in a different place and in different units, and they never touch gross profit. A PayPal or Klarna fee is not in Shopify at all.
| Cost group | Over the window | Share of net revenue |
|---|---|---|
| Logistics | €1.046.422,49 | 8,44% |
| Transaction costs | €426.721,51 | 3,44% |
| Marketing | €3.144.072,34 | 25,36% |
| Overhead | €534.946,76 | 4,31% |
| Total below gross profit | €5.152.163,10 | 41,55% |
That store's CM1, which is net revenue minus product cost, was €7.534.047,38 or 60,76% of net revenue. Its EBITDA was €2.381.884,28 or 19,21%. The distance between the two is the table above. A report that stops at gross profit hands you the first figure, and gross profit is CM1 at best, and only if the cost field was complete on the day of every sale. It is not exactly CM1 either: Shopify's net sales leaves shipping revenue out, so the two are the same shape rather than the same number.
To see that distance on one of your own products, a profit margin calculator walks a unit from its shelf price through VAT, goods, parcel and payment fee to what it actually contributes, which is the walk a gross-profit report stops after its first step.
Shopify's own help page for profit reports points merchants who need more than a static cost towards an accounting system or a reporting app. That is a fair description of where the boundary sits, written by the people who drew it.
What a complete answer needs
Four cost engines, and all four are bookkeeping rather than cleverness. Each is a short piece of setup you do once and then amend as prices move, which is the only ongoing work involved once the store is connected.
- Product cost per variant, dated, so that March is priced at March, with every missing cost named instead of assumed.
- Logistics per parcel: a rate card by zone, priced by weight or by parcel size, pick and pack, packaging, packaging EPR where it applies, and return processing on the day the refund is issued.
- Payment fees on what was actually charged: on Shopify Payments the fee Shopify reports for each payment, on every other method a percentage plus a fixed fee per transaction from your contract, including an order split across two payment methods, and any chargeback fee.
- Ad spend from every platform on the day it was spent, and fixed costs spread across the days they cover rather than landing whole on the day the invoice arrived.
Put those four under the revenue Shopify already records accurately and the statement keeps going: net revenue, then CM1 after the goods, CM2 after fulfilment and fees, CM3 after advertising, and EBITDA after the fixed costs. The Shopify profit calculator walks one month of your own figures down those same lines. A statement that stops at cost of goods sold answers a smaller question, and it answers it well. It is just not the question you were asking. Tools that assemble the full statement differ mostly in how far down it they go and whether their costs carry dates, and the comparison of Shopify profit tracking apps sets them side by side, with every price dated.