Your cost was wrong for months — what can still be fixed

Start with what you can still get. The cost was wrong since spring, you have found it, and the damage is not evenly spread — most of it is recoverable, and one part is not.

• From today, the number can be right, and every sale after that reports correctly.
• The true history can be rebuilt, outside Shopify, from data you already have: your orders export tells you what sold and when; your invoices tell you what those units actually cost. Margin recomputed that way is the number your accountant wants, and it is the one to use for the months in question.
• What cannot be done is making Shopify's own profit report restate a sale it has already recorded. We measured that on 15 October 2026: editing the cost did not move an order that was already in the report. Nothing in Shopify offers to recalculate an older month either, though that part is an absence in the documentation rather than something we tested.

That is the whole shape. The rest of this page is how to do the recoverable part properly.

The report does not go back — what we measured, and how to see it in your own store

Two things Shopify states:

"Profit is reported only for products and variants that had cost recorded at the time they were sold."

"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."

Neither actually answers the question, which is worth being precise about. The first gates whether there is a figure, not which figure a later report uses. The second calls the field static and the report "only relevant to a specific point in time", which can be read either way — and published advice elsewhere does read it the other way, saying every report prices history at whatever the cost field holds today. So the documentation left it open, and we settled it with a store.

What the test was, so you can judge it. One product at €20.00 with its cost recorded as €5.00, one paid order, and Shopify's own Gross profit by order report showing €15.00. The cost was then edited to €15.00 on the product page and confirmed there after a reload. The report was re-read three times over the following minutes, with its own "Last refreshed" stamp moving after the change — 2.30, then 2.31 — and its totals row never moved from "Net sales with cost recorded €20.00 · Cost of goods sold €5.00 · Gross profit €15.00". Had the report restated, that same row would have shown €5.00 profit instead of €15.00. Consistent with it, the report's own query reads product and variant titles at the time of sale — though it is the figure, not a field name, that settles the cost.

The limits of what that proves: one store, and one order from the same day whose sale had been recorded before the cost was changed. A month already closed was not tested separately. The mechanism is the same either way — the cost is read when the sale happens — but if your own case is the spring, test the spring.

The two-minute check in your store. Change one variant's cost by an obvious amount, then open an order for that variant in the profit report for the period you actually care about, and see whether the margin moved. If it did not, the months in question are yours to rebuild and the rest of this page is how. If it did move, your historical margins shift every time anybody edits a cost — a bigger problem and a different one, and worth telling us about.

A cost read once, at the sale, is also why the damage is invisible rather than loud. Nothing errors. The reports keep producing confident numbers about a business with different margins than yours.

Rebuilding the months that were wrong

This is bookkeeping, not configuration, and it is genuinely doable in an afternoon for most shops.

1. Export the orders for the period. You need order date, product, variant, quantity and what it sold for.
2. Write down what those units actually cost you. From supplier invoices — and if the cost changed mid-period, use the date each delivery landed to decide which cost applies from when.
3. Recompute margin by multiplying out. Units sold at each true cost, subtracted from the revenue for the same lines.
4. Keep the workings. Whoever asks about these months later — an accountant, a buyer, a lender — will want to see how the number was reached, and Shopify will not be showing it.

Do the count before you decide how much this matters. A cost that was wrong by two per cent on a slow line is not worth an afternoon. One that was wrong by thirty per cent on your best seller changes what you thought the business earned, and that is worth doing properly.

Months of margin you cannot trust? Describe what you need rebuilt →

Fixing it forward, without breaking it again

Update the field, and then deal with the reason it went stale — because the same gap will do the same thing again. Shopify holds one static cost per variant and nothing recalculates it when your buying price moves; that is its own problem, and it has its own page: keeping cost per item right when your buying price moves.

One thing to get right in passing: a variant with no cost at all does not report as zero margin — it drops out of the profit report entirely. If some of your catalogue has an empty Cost per item, those sales were never in the numbers you have been reading, which is a different problem from a wrong number and often a bigger one.

How it was wrong changes what you do

Three different faults get described with the same sentence, and they need different work.

The cost was stale. It was right once and the buying price moved. The rebuilt history needs the date each new price started, and margin before that date is fine — so the work is bounded by when the price actually changed, not by when you noticed.

The cost was blank. Those sales are not wrong in the profit report; they are absent from it. That means the totals you have been reading were about a smaller business than yours, and the rebuild is about adding lines rather than correcting them.

The cost was on the wrong basis. A case price typed into a field that means one unit, a figure that included freight while everything else excluded it, a supplier price in another currency. This is the one that usually goes unnoticed longest, because the number looks plausible — and it is the one where the rebuilt figure differs most from what you assumed.

Whichever it was, the correction going forward is the same one screen. The recovery work is not, and it is worth naming which of the three you have before starting.

Which part is yours

What Shopivibe does

You describe the outcome you want: "keep our cost right as prices move, and tell me when a product's margin drops below what we agreed."

Be exact about the two halves, because Shopify's own report does not restate one of them.

Going forward, the cost stays written. Once a delivery's price is known to your store, it goes onto every variant it applies to and stays there, without anybody opening products one at a time. What still has to reach the store is the price you were charged. Since Shopify's October 2026 API version an app can read a purchase order you raised in the admin, but nothing can create one, and a price that arrives by email or on an invoice is still a row you keep. One row per delivery, instead of a spreadsheet and a reminder.

Backwards, the rebuilt history is the deliverable. Shopify's report keeps the cost it had at the sale, so it keeps the answer it already gave — what is built for you is the recomputation described above, set up with a person once from the exports and invoices you have, and then kept as a report you can hand to an accountant, alongside Shopify's rather than inside it.

Shopivibe solves the problem in your store and keeps what it adds maintained, including when Shopify changes something underneath. If the app cannot complete your request on the spot, somebody at Shopivibe takes it on straight away and has it working in your store within 24 hours, included in the plan at no extra charge. Shopivibe is free during early access, with 3,500 credits included. Credits beyond the included 3,500 cost $0.06 each.

Know what the real margin was? Describe the report you need →