05 Dashboards & BI · Direct-to-consumer e-commerce
Making RTO make sense: an order-to-books process and dashboard for a Shopify D2C brand
Returns-to-origin were the single largest drain on this Shopify brand's margin and the single least understood number in its books. We designed the end-to-end process for how an order — and its return — is recorded, implemented the software to run it, and built a custom dashboard so the founder could finally see what RTO was actually costing and where.
- A defined process for recording orders, dispatches, deliveries and RTOs — the same way every time
- RTO recognised correctly in the books: reversed revenue, recovered inventory, the courier cost that stays
- A custom dashboard on live data: RTO rate by product, pincode, courier and payment mode
- Decisions on COD limits, courier allocation and product listings taken on numbers rather than instinct
- Founder's time redirected from reconciling returns to reducing them
The situation
Every D2C founder knows RTO is expensive. Few can say precisely how expensive, because a return-to-origin touches everything at once: the sale that was recorded is reversed, the stock that was dispatched comes back (sometimes), the courier charges for both legs, the cash-on-delivery amount never arrived, and the customer may or may not reorder. In this client’s books, RTOs were handled inconsistently — some reversed, some not, courier costs lumped together, inventory adjusted at stock-take — so the RTO rate in the Shopify dashboard bore no relationship to the RTO cost in the accounts, and neither could be trusted.
The founder’s pain was specific: she could not tell which products, which regions, which couriers, or which payment modes were producing the returns, and so could not act on them.
What we built
- The process first. A documented order lifecycle — placed, dispatched, delivered, RTO initiated, RTO received, restocked or written off — with a defined accounting treatment at each state. Revenue is recognised on delivery, not dispatch; an RTO reverses the sale, restocks the unit if it comes back saleable, and charges both courier legs to a dedicated RTO cost line.
- The software to run it. Shopify orders and the courier aggregator’s status feed connected to the accounting system, so state changes post their own entries. No manual reversal, no month-end stock plug.
- A custom dashboard. Built on the live data rather than Shopify’s summary: RTO rate and RTO cost by product, by pincode cluster, by courier partner, by prepaid versus COD, over time — alongside net margin after RTO for each. The numbers a founder actually needs to make a decision, in one screen.
What changed
Within the first cycle the dashboard showed what instinct had only suspected: a small set of pincodes and one courier accounted for a disproportionate share of returns, and COD orders in those areas were the worst of all. The founder restricted COD on those pincodes, reallocated the courier, and delisted two products whose RTO-adjusted margin was negative. The RTO rate fell, and — more importantly — the cost of the RTOs that remained was finally known and booked correctly.
The pattern
The dashboard is the visible deliverable, but it only works because the process and the accounting underneath it are right. Data that is recorded inconsistently cannot be visualised into sense. That order — process, then software, then dashboard — is how every BI and automation engagement we run is sequenced.
Next step
Have a process like this one?
Book a 30-minute discovery call. We scope the build, confirm what it changes, and give you a fixed-fee proposal within 48 hours.