Comparing This Month to a Month You Remember

There is a specific mechanism here, and it is worth understanding because it explains the direction of the error so reliably. A month is not stored as a month. It is stored as a handful of moments: the three days that felt enormous, the week the shop was full, the day a large order landed, the slow stretch nobody would describe. When somebody says last month was about four and a half lakh, they are not estimating a distribution. They are estimating the sum of the moments, and they are omitting the rest of the month entirely.

The result is not random. It is biased upward, every time, and the bias grows with the size of the memorable events. A month with one quiet fortnight is the month most likely to be remembered as a good one, because the quiet fortnight is exactly the part that leaves no trace in memory while the busy weekend does.

The day count in that example is the hidden variable. A month with 30 days, 26 of them recorded, and a month with 24 days recorded, are not comparable as totals, and the reason is structural rather than a matter of anybody doing anything wrong. A closure, a holiday, a two-day stock-taking stop, or a month where four days genuinely had no transactions will all do it, and each of them changes the day count without anything changing about how the business performed.

So an honest comparison carries both figures and lets the reader see the denominator. That is not pedantry. It is the difference between a month that got smaller and a month that had fewer days in it, which look identical in a total and are completely different situations.

Read that list and notice which items are about the records and which are about the report. Most are about the records. That matters because a period that was not stored properly cannot be rescued later by a better report: if last month is only available as a live recomputation, then every correction made since changes last month too, and the comparison becomes a comparison between two different moments of history.

The restatement item is the one teams tend to skip, and it is the one that causes the most confusion later. When a figure is corrected after the fact, the honest thing is to keep both: the value as first reported, and the corrected value with a reason and a date. Overwriting quietly means that anyone who remembers the first value is left looking like they misremembered. They did, in a sense, but the useful part of the disagreement was the correction itself.

A comparison is two claims joined together, and it is only as strong as the weaker join. If this month counts something the last month did not, the comparison is not a comparison. The usual ways this happens are all mundane and all avoidable, which is good news.

The first is the cutoff. A month that closes on the first of the month in one branch and on the last in another gives two different totals that both look right. The second is the business day. Where a shift runs past midnight, the day it belongs to is a decision, and if it is made differently in two places the day counts diverge for reasons that have nothing to do with trading. The third is status. Cancelled documents, credit notes and draft documents are included in one month and excluded in the next, and the difference shows up as performance.

The fourth is tax, and it is the one that most often makes a comparison look like a growth story when nothing of the kind happened. If a figure is read inclusive of tax and the previous one exclusive, the change is a change of basis. Nothing about the business moved. This is worth being careful with because the 18% GST rate is the obvious tool for making the point concrete, and it is used here only to keep an invoice total checkable by hand, not as tax or compliance advice.

Consider a single illustrative invoice. Taxable value 1,00,000, tax at 18% of that value, and therefore a tax line of 18,000, giving a document total of 1,18,000. Read as two invoices of 1,00,000 each, the pair is 2,00,000. Read as two invoice totals of 1,18,000 each, the pair is 2,36,000. Check it: 1,18,000 + 1,18,000 = 2,36,000. The difference between the two readings is 36,000, which is 18,000 twice, and it is a difference of basis rather than a difference in trading.

The obvious next step is to divide one by the other and print the result, and this article declines to do it, because a ratio invites the reader to treat a basis change as a performance change without looking at which basis was used. The fix is not a cleverer number. It is one stated basis, used on both sides, with tax shown separately from the taxable value on the face of the report. Whether a given invoice is correct, correctly classified and correctly filed remains a question for your own chartered accountant. NoxOrigin does not file GST returns or any other statutory return.

It is possible to store both periods carefully and still produce a comparison that misleads, because the two numbers can be individually impeccable and jointly incomparable. The per-day example earlier is the cleanest case: both months are correctly totalled, both are correctly bounded, and the comparison still flips depending on which measure is used.

The other common case is composition. A total can be flat while everything underneath it changed: the same month-over-month figure produced by one customer paying earlier and another paying later, with nothing different about the business. A total is a statement about a sum, and a sum can be stable for reasons that have nothing to do with what you would want to know.

The remedy is not a better total. It is a comparison that carries its denominator, its basis and its composition. In practice that usually means the report shows the total, the day count, and a small number of lines that explain movement, rather than a single headline number with a change attached to it. A reader who can see that collections rose while billings fell, or that one invoice moved from this month to next, is far better equipped than one handed 22,600 and an arrow pointing down.

The practical change is small. When a month closes, keep the closed figure with its definition, its membership rule, its day count and its boundary dates, and compare to that stored figure next month rather than to a recollection of it. The comparison then has a fixed left-hand side, which is the only way it can be checked by somebody who was not in the room.

It also changes the tone of the conversation. Instead of last month was better than we were told, the discussion becomes last month closed at 4,18,600 across 26 recorded days, and this month has closed at 3,96,000 across 24, so we lost 22,600 of total and 400 a day. That sentence can be argued with, because every part of it is on the page.

Two limitations belong here. Where a business has more than one location, a consolidated figure is the sum of two things measured differently, which is a subject of its own, and a per-day or per-location view is the first place to look when two branches disagree. And a month that contained a closure, a stock count or a genuine trading stoppage is not comparable to a month that did not, no matter how carefully both are stored. The honest move there is to say so in the report rather than to quietly include the month.