Why does last month's revenue change after you close the books?

On April 1 you pulled the numbers for March. Gross sales 48,210. Refunds 890. Net 47,320.

You closed the month, sent the figure to whoever needed it, and moved on.

Six weeks later someone asks for March again.

Net 45,140.

Nobody edited anything. Nobody opened the system and changed a number. The report is not lying to you. It is answering a different question than the one you think you asked.

(Figures throughout this article are illustrative.)

Where last month's revenue actually lives

Ask where March's revenue is stored, and in many e-commerce stacks the honest answer is: nowhere.

There is no row that says March revenue = 47,320. There is a query. It walks the orders, keeps the ones whose status currently reads paid or fulfilled, subtracts the ones that currently read refunded, and adds up what is left.

Status is a mutable field. That is the whole story.

A customer opens a dispute in May over an order placed in March. The refund goes through, and that order's status flips. Nothing about March was rewritten, but the set the query selects has changed, so the sum it returns changed with it.

Run the query on April 1 and you get one March. Run it on May 12 and you get another. Both are correct answers to the question the query actually asks — which is not what did March earn, but what do the orders that today still look like March orders add up to.

The photograph you thought you had

You thought you were holding a photograph of March. You were looking through a window at it, and the room kept changing.

A photograph is written once. Whatever happens to the room afterwards, it still shows what was there when the shutter closed. A window shows the room as it is right now, every time you look.

Derived figures are windows. They answer what is true now about the past. Accounting needs photographs. For a closed period you need a record of what was recognized and reported at the time — because that is the figure you reported, paid commission on, filed tax against, and repeated to your investor.

Which makes the failure easier to name than it first appears. The software is fine. A derived figure was asked to do a recorded figure's job, and it has no way to refuse.

The uncomfortable version is worth saying out loud, and it is not the one about accountants. Where the books are closed properly, March is settled: the period was filed, and nothing behind that date moves.

The difficulty is that March has more than one true number — what the closed books recognized, what the store's orders currently add up to, what cash actually arrived, what April's payout settled for March sales. These answer different questions, and they are allowed to differ. Two things then go wrong. Nobody writes down which question each figure answers. And the statutory figure was never designed to answer the question a business steers by week to week, so the number that matters most day to day is the one nobody ever recorded.

What a record looks like instead

The alternative is old and boring, which is roughly why it works. I have built this layer more than once, and the part that surprises people is how little of it is clever.

Every movement of money is written as an entry, and written twice — once against where the money came from, once against where it went. Within a currency the two sides sum to zero. That constraint is not bookkeeping decoration; it makes a whole class of errors detectable at write time instead of at year end.

Three properties do more work than the double entry itself.

An entry is immutable: once written, never edited, never deleted. A mistake is corrected by writing a new, opposite entry that references the original. The wrong number stays visible with its correction beside it, because the fact that you were wrong on April 1 is itself part of the record.

The balance is the sum of the entries, not a field somebody maintains. Nothing can be true of the balance that is not true of the entries underneath it.

And the period can be closed. After the close, nothing may be added behind that date. In this model, a refund arriving in May against a March sale becomes a May entry that references March, not a silent rewrite of March.

That last property is what fixes the example we started with. March stays at 47,320 forever, because that is what March was. The 2,180 of late refunds lands in May, where it actually happened, pointing back at the orders it reverses. Both months are true, and the relationship between them is visible instead of implied.

The obvious shortcut is to export the report every month and keep the file. It is better than nothing, and it fails for a specific reason: it stores the answer without the reasoning. When a figure is challenged you have to show which movements produced it, not a total somebody exported. A file also has no way to say that a May refund reverses a March sale — you end up with two documents that disagree and no rule for deciding which one wins.

Moving to a stricter system does not settle it either. An ERP will hold proper entries, but it only holds what reaches it. If the integration sends aggregates — revenue for March was this — then a mutable figure has been copied into a stricter place, and the strictness buys nothing. The number did not become more true on arrival. What should cross that boundary is events: this sale happened, this refund happened, this fee was charged. Totals are derived on arrival rather than shipped.

Where this quietly costs money

The reporting confusion is the symptom people notice first. It is rarely the expensive part.

If partner or affiliate payouts are a percentage of revenue, and revenue is a window rather than a photograph, the base moves after the payout has already been made. Either partners were overpaid and nobody is going to claw it back, or they were underpaid and will eventually work it out for themselves.

There is a specific conversation this creates, and it is worse than it sounds. A partner asks why their March payout was recalculated. You explain that a customer in another country filed a chargeback. What they hear is that their earnings depend on something they cannot see, verify or predict — and they are right. Without a record of what the rate and the base actually were at the moment of accrual, you cannot show them otherwise.

Currency behaves the same way. An order is placed at one rate and settles at another. If the model does not preserve the original transaction rate and the settlement information, that difference can disappear into an aggregate sales figure. Across a year and several gateways it becomes a line item you have never seen, sitting where realized FX belongs.

And if your management report keeps changing after the close, the close is not doing the job you think it is. The work has to be redone every time somebody asks, so teams rebuild the report in a spreadsheet and start treating that file as the real one. That is how a spreadsheet slowly becomes the unofficial source of truth.

If you want to know whether any of this applies to you, there is a two-minute version. Pull last month's revenue today. Then find the figure you sent out when you closed that month. If the two differ and nobody can say why, your revenue is a window.

Step back and this stops being a reporting preference. A company whose past can move turns every audit into an argument, cannot be diligenced without a rebuild, and has nothing stronger than a current opinion to offer a bank, a buyer or a tax authority. None of that matters at $200k of revenue. All of it matters the first time somebody with leverage asks you to prove a number.

None of this announces itself. No alert fires, no reconciliation breaks, nothing turns red. You ask for March and you get a number that is entirely correct as an answer about today. March itself was never written down anywhere. What you kept was the question, and the question keeps getting asked.