Standalone selling price is a population, not a number

A bundled deal has to be split. Platform, onboarding, premium support, sold together for one number. Allocating that number across the three promises requires knowing what each one sells for on its own.

Both major platforms will store that figure and allocate with it. NetSuite carries fair value price lists supporting SSP, VSOE, ESP and TPE. Acumatica allocates its reallocation pool in proportion to fair value price. Enter a number, and the arithmetic downstream is handled.

The number is the problem.

A field asks for a point, the evidence is a distribution

Standalone selling price is meant to be the price at which you would sell that promise separately to a similar customer in similar circumstances. That is a claim about your actual sales behaviour, and it is answered by looking at what you actually charged.

When you look, you do not find a number. You find a spread. Onboarding sold at $18,000 to one customer, $12,000 to another, bundled and effectively free to a third. The output of that exercise is a range, a method for deriving a representative point from it, and a decision about which transactions belonged in the population at all.

The field wants the point. The evidence is everything that produced it.

Where list price quietly stops working

The usual shortcut is to set SSP to list price. That holds up for as long as list price is what people pay.

It stops holding up in the ordinary course of selling. A product is discounted heavily and consistently to land a segment. A module is never sold on its own, so there is no observed standalone price to point at. A promise is given away in every enterprise deal as a closing concession, which means its observed price in that population is close to zero. That is a fact about your discounting, not about the item's value.

None of that is a problem in itself. Estimation is expected when a promise is not sold separately, and there are recognised approaches for it. The problem is that the shortcut and the derivation produce the same-looking number in the same field, and nothing in the record distinguishes them.

What the derivation has to carry

Four things, and all four are inputs rather than outputs:

The population. Which transactions were used. Which were excluded, and on what basis. An SSP derived from every sale including the free-in-a-bundle ones is a different figure from one derived only from standalone sales, and both are defensible if the choice is stated.

The window. Twelve months, four quarters, since the last price change. Pricing moves, so a derivation with no time bound is a derivation that silently ages.

The method. Median, weighted average, a range with a stated point within it, or an estimate where no standalone sales exist. Stated once, applied the same way at each refresh.

The date it was set. Because the allocation on a contract signed in March should reflect what was known in March, not what the field happens to hold today.

That last one is where this connects to everything else. Both platforms apply fair value price changes to new obligations going forward. That is the right default. It also means the figure in the field today is not necessarily the figure that produced the allocation you are being asked to explain, and reconstructing the old one from a field that has been overwritten is not possible.

What a refresh looks like when it works

Periodic, scheduled, and boring. Pull the population for the window. Apply the stated method. Compare the result to the figure in use. Where it has moved beyond a threshold you set, update it, record the date, and leave the prior figure in place as history rather than replacing it.

The output is a small document per promise: here is the price, here is the population it came from, here is the window, here is the method, here is when it was set, here is what it was before.

The judgement in all of this stays with your accountants. Which method suits which promise, what counts as a similar customer, when an estimate is more faithful than a thin observed population. Your auditors test that judgement. What the system owes both of them is that the answer is written down, dated, and still recoverable after the field has moved on.