In a subscription business, ARR is close to a fact. You have a price, a quantity, and a term, and the number falls out of the contract with very little room to argue about it.
Add consumption to the model and that stops being true. One signed contract can produce several different recurring revenue numbers, and every one of them is defensible in front of a board. Everyone is talking about whether to price on usage. Almost no one is talking about what usage pricing does to the number you report, or to the person reading it.
One contract, three numbers
Take a hybrid contract. A $2,500 monthly commit floor, $0.12 per document above the floor, and a customer running about 28,000 documents a month.
The floor is contracted. The customer owes $2,500 a month no matter what they consume, so $30,000 a year is deterministic. That part behaves like subscription ARR.
The usage is not. 28,000 documents at $0.12 is $3,360 a month, which annualizes to roughly $40,000. So when someone asks for the ARR on this account, is it the $30,000 you can hold the customer to, or the $40,000 they are currently running at? Pull trailing twelve-month billings and you may get a third number, depending on how the usage ramped. One contract, three numbers, all defensible.
The drop that isn't a drop
Now watch what happens when nothing actually changes.
Say usage settles to 18,000 documents a month. At $0.12 that is $2,160, which is under the floor, so the customer still pays the $2,500 floor. The contracted position has not moved. It is still $30,000 a year.
But a team reporting on run-rate just watched this account fall from $40,000 to $30,000, a 25 percent drop, and now there is a churn conversation about a customer who is paying exactly what they committed to. The customer did nothing a contract would recognize as a change. Depending on which number you adopted as ARR, you either had a quiet quarter or a fire drill.
This is not a reporting problem
The instinct is to fix this with a reporting standard. Pick run-rate, write it down, apply it everywhere. That works until the first contract that does not fit the standard, and in a usage model most of them do not fit.
It is not a spreadsheet problem either. A more careful spreadsheet still has to decide, every time someone updates it, which number is the real one. The decision just moves to whoever touched the file last.
The decision has to live somewhere more durable than a report or a habit. It has to live in the contract.
The fix is a property of the contract
The line is not complicated. The commit floor is contracted, so it is ARR. Volume times rate is a projection, so it is a forecast. The forecast can sit next to the number. It is not allowed to become the number.
When I had to model this for real, I did not put that rule in a board template or a footnote. I put it in the contract record itself. The commit floor is the only thing that flows into ARR. The consumption math is shown beside it, marked as a projection, and it never rolls in.
The form is not the point. The point is that the line between contracted and projected is a property of the contract, so it holds when I am not the one looking at the number.
Why it survives diligence
This matters most at the moment you least want it to.
A diligence team is going to ask how you arrived at your ARR. If the honest answer is that consumption got blended into it through a method nobody ever wrote down, the number does not survive the question. The teams treating "what is the difference between these numbers?" as a real question are the ones whose numbers hold up when someone finally asks.
The ones treating it as semantics may not feel the difference today. They will feel it in twelve months, in a room where the number has to be right.