AI for D2C brands in India: a ground report

Most writing about AI in ecommerce assumes the hard part is deciding what to do. In the Indian D2C brands we have spoken to, the hard part is finding out what already happened. This post is a plain account of what they described and what the platforms and the rules actually do: why the numbers never agree, which parts of that gap software genuinely closes, and which part of the job stays with the founder.

Four systems, and nothing joins them#

An Indian D2C brand runs on four record-keepers that each tell a different version of the same day.

The store records an order at the moment it is placed. The payment gateway records a settlement, net of fees, on a different date and in a different batch. The courier records a delivery, a return, or a COD remittance on a third timetable entirely. The marketplace records its own version of all three. There is no common identifier running through them, so joining them is a reconstruction rather than a lookup.

One Indian D2C order is recorded by the store, the gateway, the courier and the marketplace on four different dates, with no identifier running through all four

Some of this is structural. Shopify Payments is not available in India, so every Indian store settles through a third-party gateway, which is exactly why the order list and the bank credit never line up on their own. Razorpay and Cashfree both hold final RBI authorisation as payment aggregators, granted on 19 December 2023 and listed on the RBI's own register. That made the rails stable. It did nothing to make the reports agree, because they were never designed to.

The gateway settles one net credit per cycle. That single bank line contains dozens or hundreds of orders, minus platform fees, minus GST on those fees, minus refunds, minus chargebacks, plus adjustments from previous cycles. Decomposing it back into orders is the job, and it is a job most brands do by hand or not at all.

A single gateway settlement credit contains many orders, less platform fees, less GST on those fees, less refunds and chargebacks, plus adjustments from earlier cycles

This is worth being precise about, because it changes what AI is for here. Nothing is blocked. There is no portal refusing to cooperate and no token in a USB port. The data exists, it is just scattered across four formats on four schedules with no key. That is a matching problem at volume, which is the kind of problem software has been good at for decades and which models have recently made much easier, because the formats keep changing and the exceptions are written in prose.

What no system can do is invent a remittance that never arrived. Where a courier's COD payment is genuinely short, matching surfaces it and a person has to go and argue about it. Any vendor claiming their AI reconciles payouts end to end is worth one question: what does it do when the courier says the shortfall is correct.

Shopify does not know it is in India#

The store itself is the weakest link, and this is under-discussed because it reads as a criticism of a product most brands are happy with.

Shopify does not produce a GST-compliant invoice for an Indian seller. It applies a single combined tax figure and does not determine whether a sale is intra-state or inter-state, which means it does not split CGST and SGST against IGST. Every Indian store therefore runs a third-party invoicing app on top of it, and most founders discover this after their first quarter rather than before.

It goes further than a missing feature. Shopify's own India GST help page still describes four rates of 5, 12, 18 and 28 per cent. That structure stopped existing on 22 September 2025, when the 12 and 28 per cent slabs were abolished. The official documentation for the platform running a large share of Indian D2C is describing a tax regime that ended ten months ago.

The practical consequence is that a brand cannot treat its store as the source of truth for tax. It has to be treated as one input among four, which is a different architecture from the one most brands have.

The rates most brands have wrong#

Alongside the matching problem sits a quieter one. A set of rates changed recently, and a large amount of the advice online still quotes the old numbers.

The 194-O cut came through the Finance No. 2 Act 2024, as ClearTax sets out. The TCS cut to 0.5 per cent came through Notification 15/2024 Central Tax, split as 0.25 per cent CGST and 0.25 per cent SGST on an intra-state sale. The small-seller registration exemption runs through Notification 34/2023 Central Tax, effective 1 October 2023, and covers goods only.

These are lookups, not judgements, and they belong in a system that computes rather than a model that generates. A brand that lets a chatbot decide its TCS rate has misunderstood what the tool is for.

Your accountant is working through the other half of this. The GST portal changed how input credit is claimed in October 2025, and the reconciliation a CA now runs on your behalf depends on decisions being made weeks before the return is filed. We set that out in AI for chartered accountants in India. If the brand is a private limited company, the annual ROC calendar sits on top of both, and AI for company secretaries in India covers what that involves.

The margin arrives six weeks late#

Most Indian D2C brands do not have an operations team. They have one person who does everything, and that person has usually built a spreadsheet they are quietly proud of and slightly afraid of.

The founder's problem is not that the spreadsheet is slow. It is that nobody knows the real margin. Gross margin is easy. The number after gateway fees, shipping, returns, RTO, marketplace commission and TCS is not, and it arrives weeks after the decision it was supposed to inform.

Returns are where most of it goes. Shipway's ShipNotes report, covered by MediaBrief, puts the RTO rate on COD orders at around 26 per cent against under 2 per cent on prepaid. Every COD order is a weighted coin flip, and the cost of the flip appears nowhere in the store's reporting.

RTO rate on COD orders in India runs at about 26 per cent against under 2 per cent on prepaid orders

The uncomfortable part is worth saying before a brand pays for anything. Attributing returns properly to the products that caused them almost always makes the true per-order margin worse than the dashboard implies, and on a category running at a 26 per cent RTO rate the correction is large enough to move a product line from profitable to not. Founders we have spoken to describe learning this late, usually about a line they were attached to. The number is useful precisely because it is unwelcome, and a brand that wants confirmation of what it already believes should not do this exercise.

Nobody raises a ticket#

Customers do not use the tracking page. They message the number printed on the packaging at 11 pm asking where their order is. Suppliers do not log in to a vendor portal. They send a photograph of a delivery challan. The courier's local contact resolves more in one phone call than the support dashboard does in a week.

Ecommerce software has repeatedly died on this. The product assumed the customer would self-serve and the supplier would maintain their own records, and neither did, because the customer wants an answer and the supplier is driving.

The automation has to sit behind the channels that already exist. A message arrives on WhatsApp, gets matched to the order, and gets answered with the real courier status rather than a template. A supplier's photographed invoice gets read and posted against the right purchase order. From the outside nothing looks different, which is the correct outcome.

What the numbers cannot tell you#

Once the matching works, a model can compute contribution margin per SKU faster than anyone and rank every product that loses money after returns.

It cannot tell you which of those loss-making SKUs is the reason customers come back for the four that make money. It cannot tell you whether a 26 per cent RTO rate in a category means stop selling there or means fix the address capture at checkout. It cannot tell you that a supplier who is late twice a year is still the right supplier because he carried you through a stockout.

Those are decisions about what the business is, and they are made with information that is not in any of the four systems. The reconciliation exists to make room for them, not to replace them.

What a month would look like instead#

Set against the way the four systems behave today, here is what the matching part could look like. Gateway settlements, courier remittances and marketplace payouts are pulled as they land and matched against orders automatically, so exceptions surface the same week rather than at the quarter close. Supplier invoices arriving as photographs are read and posted against the right purchase order. Customer messages are matched to orders and answered with live courier status. The real per-order margin, after fees, shipping, returns and TCS, is available on a Tuesday.

Arguing with a courier over a short remittance still goes through a person. What comes back is the days that used to go into finding the short remittance in the first place.

If you run a D2C brand#

Take one COD order from last month and follow it all the way through by hand: the store record, the gateway settlement, the courier remittance, the return if it came back, the TCS credit, and what actually reached your bank. Then multiply the time that took by your monthly order count.

Most founders have never done this even once. The number at the end is usually not the number in the dashboard, and the gap is the thing worth understanding before anyone shows you software.

This is the kind of work Miror does with D2C brands: working out how the data actually moves between your store, your gateway and your couriers, then building the matching around that rather than around a generic connector. If you want to talk through what your own reconciliation looks like, write to us or message us on WhatsApp. One real week of settlements is usually enough.