How to see profit per order on Shopify (India: after RTO, COD and GST)
Most Indian D2C founders can tell you last month's revenue to the rupee and can't tell you which orders made money. That isn't carelessness — it's that the number is genuinely hard to assemble. Your storefront knows the sale, the courier knows the RTO, the gateway knows its cut, and your accountant knows the GST, and none of them talk to each other. Here's what actually has to be subtracted, why RTO breaks the arithmetic that works fine in the US, and how to get to a per-order profit figure you'd be willing to make decisions on.
Why Shopify's profit report doesn't match your bank account
Shopify's built-in profit reports work off the 'cost per item' you've entered against each product. Revenue minus cost of goods, per line. That's a gross-margin report, and for a US store shipping prepaid orders it's a reasonable first approximation.
For an Indian store it isn't close, because the costs that decide whether an order made money mostly land after checkout: the courier bill, the COD collection fee, the gateway cut, the return leg when it comes back, and the marketing spend that bought the order in the first place. None of those are in the cost-per-item field, so none of them are in the report.
The practical symptom is familiar — a healthy-looking margin in the dashboard and a bank balance that disagrees. The report isn't wrong; it's answering a narrower question than the one you're asking.
The costs you have to subtract in India
Product cost is the easy one. Then, in rough order of how much damage they do: forward shipping, the COD collection fee your courier or gateway charges as a percentage of order value, the payment gateway fee on prepaid orders, packaging, the marketing cost of acquiring that order, and any discount or coupon applied.
Then the two that most spreadsheets miss. RTO — the order that ships, fails to deliver, and comes back — costs you the forward leg, the return leg, packaging and handling, and earns nothing. And GST, which is on the sale, not on your margin: the tax collected isn't yours, and treating gross revenue as though it were is one of the more common ways a brand talks itself into a loss-making SKU.
Returns after delivery sit somewhere between the two: you've paid to ship it out and back, and you may or may not be able to resell the item depending on the category.
Why RTO breaks the maths that works elsewhere
In a prepaid market, a failed order is an edge case. In India, with a meaningful share of orders on cash on delivery, RTO is a structural cost — and it doesn't hit the order it belongs to. The order that came back shows up as a cancellation. The cost of it lands on your P&L. Nothing connects the two.
The consequence is that RTO is a tax paid by your successful orders. If a batch of ten COD orders ships and some come back, the ones that did deliver have to carry the shipping, return and handling cost of the ones that didn't. That's why profit per delivered order matters more than profit per placed order, and why a channel or a pincode or a category with a high RTO rate can be losing money at a margin that looks perfectly healthy on paper.
It also means the lever isn't only 'reduce RTO'. It's knowing which cohorts carry it — because a product line that's fine on prepaid and underwater on COD is a pricing and payment-nudge decision, not a courier problem.
The calculation, end to end
Start from what you actually received, not what you invoiced. Take the order value, subtract the GST component to get your real revenue. Subtract cost of goods. Subtract the gateway fee on prepaid, or the COD collection fee on COD. Subtract forward shipping and packaging. Subtract the discount. Subtract the attributed marketing cost. What's left is contribution per order.
Then apply the RTO share. Take the total RTO cost for a cohort — forward plus return plus handling on every order that came back — and spread it across the orders in that cohort that did deliver. That gives you contribution per delivered order, which is the number that tells you whether the cohort is worth having.
Run it per SKU, per channel and per payment method rather than as one company-wide average. The average will almost always look fine; the whole point is to find the cohorts underneath it that don't. A brand with a 30% blended margin routinely has product lines at 60% subsidising product lines at zero — and no way to see it.
Why a spreadsheet stops working
The maths above isn't hard. Assembling the inputs is. Orders live in Shopify, RTO status lives with the courier, fees live in gateway settlements, ad spend lives in Meta and Google, and COGS lives in a spreadsheet someone updates when they remember.
So the reconciliation happens monthly, by hand, and by the time it's done the decision it should have informed is three weeks old. Worse, it's done at the aggregate level, because doing it per SKU per channel by hand isn't realistic — which strips out exactly the resolution that made it worth doing.
The fix isn't a better spreadsheet. It's having orders, inventory, delivery status and cost sitting in one database, so profit per order is a query rather than a monthly project.
Seeing it on one screen
This is the problem Retail Commerce OS was built around: orders, inventory, customers, billing and delivery on one database, so the question 'which orders actually made money' has an answer you can look at rather than assemble.
Because delivery and RTO status live in the same system as the order and its costs, contribution per delivered order is available per SKU, per channel and per payment method — not once a month, but now. That's what 'see your whole business on one screen' means in practice: not a prettier dashboard, but the costs and the revenue finally being in the same place.
Shopify stays your storefront — this is the back-office layer that syncs with it two-way. And you don't have to move anything to start: it runs alongside the tools you already use, so you can get the visibility first and decide what to consolidate later, if ever.