How to Calculate Shopify Profit

Calculating Shopify profit is not difficult arithmetic. What makes it go wrong is that the inputs live in five different systems, arrive on five different schedules, and are each reported in a slightly misleading unit by default.

So the work is mostly assembly. Get the five inputs onto one row per order, in the right order, and the number falls out.

The five inputs, and where each one lives

Net sales comes from Shopify, but not from the headline figure. The order total in the admin includes tax and shipping charged. Both need stripping out: tax is money held for a government, and shipping charged is best netted against the label rather than counted as revenue.

Cost of goods comes from the cost per unit on each variant. The trap is averaging — using one blended COGS across the catalogue makes every product look identically profitable, which is the specific thing you are trying to disprove.

Shipping cost comes from the carrier or 3PL, not from Shopify. Shopify knows what you charged. Only the invoice knows what the parcel weighed, whether it went to a remote postcode, and whether it was re-weighed after collection.

Payment fees come from payout statements. They are deducted before the money reaches you, which is precisely why they get forgotten: nobody ever writes a cheque for them.

Ad spend comes from each platform, for the identical date range you used for orders. Mismatched date ranges are the most common reason two people calculating the same month get different answers.

Deciding what counts as a per-order cost

Before subtracting anything, settle one question: does this cost change when one more order ships?

If yes, it belongs above contribution margin. Shipping labels, payment fees, packaging, pick-and-pack, transaction taxes — all scale per order.

If no, it belongs below. Rent, salaries, app subscriptions, your Shopify plan, the designer’s retainer — these are the same whether you ship 400 orders or 900.

Ad spend sits awkwardly between the two and deserves its own decision. It is not strictly per order, but it is not fixed either. The usual treatment is to keep it below contribution margin, then compare contribution margin per order against acquisition cost per order as a separate check. That way one number tells you whether the unit economics work and another tells you whether the marketing does.

Getting this split right matters more than getting any single cost exactly right. A cost in the wrong layer makes both layers lie.

Choosing your period, and sticking to it

Use the same date boundaries for every input, and decide whether an order belongs to the period by its order date or its fulfilment date. Either convention works. Mixing them does not.

Order date is the more common choice and the easier one to defend: the sale happened, so the costs of that sale belong to it, even if the parcel left three days later and the carrier invoiced a fortnight after that.

The consequence of choosing order date is that a period stays open for a while. Costs keep arriving for orders that are already counted, which is the subject of a whole separate page — the costs that land late.

Doing it per order instead of per month

It is tempting to work in monthly totals: total net sales, total COGS, total shipping, one subtraction at the end. It is faster and it produces a defensible store-level number.

It also hides everything worth finding.

A monthly average cannot show you that free shipping is unprofitable above a certain weight, that one discount code sells only your lowest-margin SKU, or that a specific region costs twice as much to serve. Those findings only exist at order level, because they are differences between orders, and averaging is the operation that destroys differences.

The practical compromise: calculate at order level, report at monthly level. The totals reconcile either way, and the order-level detail is there when the total looks wrong.

Checking the answer before you trust it

A profit figure assembled from five systems needs one reconciliation, or a transposed column can survive for months.

The cheapest check is against cash. Take the payouts that actually landed in the bank for the period, add back refunds paid out separately, and compare against net sales minus payment fees. The two will not match exactly — payouts lag by days and straddle the period boundary — but they should land within a percent or two. A larger gap usually means tax or shipping charged is still sitting in the revenue line.

The second check is coverage. Count the orders with no COGS attached. Every one of them is being treated as pure margin, and a handful of uncosted variants can move a monthly figure by more than any of the refinements above.

Run both before showing anyone the number.

How long this takes, and when to stop doing it by hand

The first month takes an hour or two. Later months are quicker because the exports and formulas already exist.

The real cost is not the hours. It is latency. A number rebuilt monthly is, on average, two weeks stale, and it is only ever consulted after the decisions it should have informed. Most stores discover an unprofitable product or a bad shipping rule months after they could have.

The threshold where a manual calculation stops being reasonable is roughly where any of these becomes true: the catalogue is large enough that per-variant COGS is unmanageable by hand, orders ship from more than one place or carrier, refunds are frequent enough to keep reopening closed months, or more than one person needs to trust the same number. Below that, a careful spreadsheet is genuinely fine, and it is a better starting point than software you have not yet learned to check.

Doing it without a spreadsheet

The Shopify profit calculator runs this exact ladder for a single order in the browser — no signup, no email — and shows each deduction rather than only the total.

For every order rather than one, and from costs that update themselves, see best Shopify profit analytics apps.