Ask four people in a growing D2C brand what last month's revenue was and you will get four answers. The platform dashboard says one number. The ad accounts, added up, claim rather more. The finance sheet says something lower. The founder has a figure in their head that matches none of them.
Everyone knows about the gap. Almost nobody can say what it is made of. So it gets managed socially instead of structurally: people learn whose number to quote in which meeting.
That workaround holds right up until you try to automate something. Then the gap stops being awkward and starts being expensive, because software does not know which number to distrust.
The five places the numbers separate
Time basis. The platform counts an order when it is placed. Finance counts it when the money settles. Logistics cares when it ships. For a brand with a two-day dispatch and a seven-day settlement cycle, the same order appears in three different weeks depending on who is counting. At month end, that single difference can explain most of the gap on its own.
Cancellations and RTO. This is the big one in India. Published 2026 benchmarks put return-to-origin at roughly 20-30 percent for prepaid and 30-40 percent for cash on delivery. If your dashboard recognises revenue when the order is placed and never nets out what came back, you are not reporting last month, you are reporting an optimistic forecast of it. Address problems alone drive a substantial share of failed deliveries, which is the sort of thing that looks like a logistics metric until it shows up in your revenue line.
Attribution overlap. Every ad platform claims credit using its own window and its own rules, so the sum of platform-reported conversions routinely exceeds the number of orders you actually received. Add a common technical fault - the browser pixel and the server-side event generating different identifiers, so neither deduplicates - and a single purchase is counted twice by the same platform.
Definition drift inside the same word. Does revenue include shipping charged to the customer? Taxes? Discounts before or after? Marketplace commission? Two correct systems produce two correct, different answers because nobody wrote the definition down.
Catalogue and feed divergence. Price, title or availability on the product page differing from the merchant feed is both a reporting problem and a policy problem - Google treats a mismatch between page and feed as a violation that can suppress shopping ads. The same divergence that misreports your catalogue to a platform misreports it to you.
The one-week audit
This is deliberately manual, because the point is to find out where the truth breaks rather than to buy something.
Day one: pick a single closed month. Not the current one. A month where returns have settled and payouts have landed, so nothing is still in motion.
Day two: write the four numbers side by side. Platform revenue, sum of ad-reported revenue, settled cash from gateway and marketplace payouts, and finance's recognised revenue. Do not reconcile yet. Just put them in one row and look at the spread. Most brands find a double-digit percentage spread between the highest and lowest.
Day three: subtract the known deductions from platform revenue. Cancellations, RTO, refunds, discounts, shipping collected, taxes, marketplace fees, payment gateway charges. Work down from the platform number towards settled cash and see how much of the gap each line explains.
Day four: name what is left. Whatever remains after the known deductions is your actual data quality problem rather than a definitional one. This is the number worth caring about, and it is usually much smaller than the original spread and much more alarming, because nobody can explain it.
Day five: write one page of definitions. For your five most-used metrics, state the time basis, what is deducted, what is included, and which system is authoritative. Circulate it. Expect an argument - the argument is the deliverable, because it surfaces the two people who have been using one word for two things.
A brand that does this once stops having the monthly "whose number is right" conversation and starts having a much better one about which decisions are safe to automate.
The gap inside the gap: marketplace settlements
Brands selling on Amazon, Flipkart, Meesho or quick commerce carry a second reconciliation problem that behaves nothing like the first.
A marketplace order is recorded at one value and settles at another, after commission, fulfilment fees, storage, advertising recovered at source, returns processed weeks later, and occasional reimbursements for items lost in their network. The settlement statement arrives on the marketplace's timetable, not yours, and it rarely maps line by line to the orders you recorded.
The practical consequence is that channel profitability is usually guessed. A brand will know its blended margin and assume it holds per channel, when in reality one marketplace can be running materially below the blend once fees and returns land. Decisions follow the guess: more spend pushed to the channel that looks like it is working.
The fix is not elaborate. Pick one month, take the settlement statements, and compute realised margin per channel after every deduction - commissions, fulfilment, returns, advertising, reimbursements. One month is enough to establish whether your channels resemble each other. If they do, carry on with blended numbers. If they do not, that difference is the most valuable number in the business this quarter, and it was sitting in a statement nobody opened.
Do this before any conversation about scaling a channel. Scaling a channel whose true margin you have never computed is the most expensive version of this entire problem, because the error compounds with every rupee of additional spend.
Why this blocks automation specifically
Humans are good at silently correcting for bad data. An operations lead who knows the stock figure runs about five units optimistic simply orders accordingly. The correction lives in their judgment and nowhere else.
Automation has no such instinct. A reorder rule built on a stock number that is 88 percent accurate will place wrong orders confidently and repeatedly. Published benchmarks put order accuracy at roughly 85-92 percent without bin-level warehouse systems and above 98 percent with automated fulfilment - and the distance between those two figures is exactly the distance between automation that compounds and automation that creates cleanup work.
This is why data quality belongs before the automation roadmap rather than after it. We go into what to automate first in a practical ROI framework; the hidden prerequisite in that framework is that the inputs are trustworthy enough to act on.
It is also why a dashboard is rarely the answer to this problem. Reporting layers render whatever they are given. If the underlying records disagree, a prettier chart produces faster disagreement. The distinction between reporting and an operational decision layer is covered in from dashboards to decisions.
What good looks like
Not a single number everyone quotes. That is the wrong target, and chasing it produces a dashboard nobody trusts within a quarter.
What good looks like is three numbers with explicit jobs. Orders placed, for demand and marketing decisions. Orders delivered, for operations and inventory. Cash settled, for anything financial. Each one defined on paper, each one owned by a system that is authoritative for it, and each one expected to differ from the others by an amount you can explain.
When someone asks "what did we do last month", the right answer in a healthy brand is a question back: for which decision? That sounds pedantic until the first time it stops a reorder being placed against revenue that was returned.
The artefact that fixes most of this
Almost every brand we audit is missing the same one-page document: a written definition of each number that matters.
What counts as revenue, and at which event. Whether that figure is before or after returns, cancellations, shipping and tax. Which system is authoritative for it. Who is allowed to change the definition. Four lines per metric, ten metrics, one page.
It is unglamorous and it resolves a surprising share of the arguments, because most of those arguments are not about data quality at all. They are two people using one word for two different things, confidently, in the same meeting. Write the page before you buy a dashboard - otherwise the dashboard just renders the disagreement faster.
Where to start if you only do one thing
Net out RTO and cancellations from your headline revenue, and put the two figures next to each other where the team sees them daily.
For most Indian D2C brands that one change is the largest single correction available, it costs nothing, and it reframes every conversation that follows - because once the returned orders are visible, questions about courier mix, COD policy and address quality start getting asked by the people who can act on them.
If you want the audit run against your actual systems rather than self-assessed - the four numbers, the deduction walk, and what remains unexplained - book an operations diagnostic. We come back with your spread, the lines that explain it, and the definitions page your team can adopt as it stands.
