When last quarter’s MRR changes: restatements

You reported €312k MRR for March. In June the same dashboard says March was €309k. Nobody changed anything, nobody was told, and the board deck is already out. Of all complaints about subscription analytics this is the most common one, and it is usually not a bug.

Why the past changes

Recurring revenue is computed from data that keeps arriving:

• Late facts. A payment that failed in March is finally written off in May, and the tool decides the customer really churned in March.
• Identity. Two billing accounts turn out to be one company. Merged, the “new customer” of April and the “churn” of March disappear, because it was a move.
• Settings. Somebody changes the reporting currency, the time zone that decides where a month ends, or whether paused subscriptions count.
• Fixes. The vendor corrects how a kind of discount is handled, for every month at once.

Each of these is legitimate. The problem is not that the number changed. The problem is that it changed silently.

What finance does about this, and analytics rarely does

Accounting solved this long ago. A period is closed; after that its figures are final. If something later turns out to be wrong, the books are not quietly edited: there is a restatement, dated, with a reason, showing the figures before and after.

Applied to MRR that means:

1. Close a month a few days after it ends, when late payments of the last days have settled. Freeze its figures, and what every customer paid at month end.
2. Compare on every recalculation. Would the closed month come out differently today?
3. If so, record the restatement first: which month, when it was noticed, why (a merge, an import, late data from the billing system), the figures before and after, and the customers behind the difference. Only then show the new figures.
4. Tell someone. A notice where people look, a mail to whoever owns the numbers, and a machine-readable message for the reporting that copied the old figure.

What this buys you

• A number that was reported can be found again, even after it changed.
• “Why is March different?” has an answer with a date and a customer name, in seconds.
• Your own reporting can copy closed months once and only re-read the ones that were restated, instead of everything every night.
• The vendor cannot change your history without leaving a trace, which is the kind of promise worth asking any metrics tool for.

In sumwerk a month closes five days after it ends (you choose), every later difference is a restatement with its reason and the customers behind it, the owners get a mail, and the API says which months are final.