Integers, one floor, and every contribution returned with its name on it.

The arithmetic

Integer cents. Integer basis points. One floor, at the end.

Every money value in this model is an exact integer number of cents, and every probability is an integer number of basis points — ten thousand of them to the whole. Not a decimal type, not a float, not a percentage with two places. The reason is not fastidiousness. A forecast is a sum of thousands of small products, and a rounding rule applied at each step produces a total that is wrong by an amount nobody can locate afterwards, because every individual line looks fine.

The effective probability of a deal is the per-deal override when one is set, and otherwise the stage default. A deal with no stage at all has no probability basis, and rather than guessing one the engine reports zero and the forecast excludes the deal entirely. Expected revenue is then the amount times that probability, divided by ten thousand, floored once, at the end.

Expected revenue on one deal, worked in integersValue

Deal amount, in integer cents12,345.00 dollars, held as an integer1234500

Per-deal probability overrideNot set on this deal — so the stage default is usednone

Stage default probability, in basis points33.33 percent, held as an integer3333

Effective probabilityThe override when set, else the stage default3333

Amount × effective probabilityAn integer product, no float anywhere4114588500

Divided by 10000 and floored ONCE411458.85 becomes 411458 — the dropped fraction is dropped deliberately, at the end, once411458

The engine’s own arithmetic on one worked example. Note what is not here: no decimal type, no floating-point multiply, and no stored expected-revenue column. The weighted value is recomputed from the amount and the probability every time it is read, which is why it cannot fall out of step with either of them. The example is chosen so the fraction is visible: the true product divides to a value ending in point eight five, and the engine floors it once, at the end, rather than rounding at each step.

The consequence that matters commercially is the one in the last row of that figure: expected revenue is never stored. It is derived on read, every time, from the amount and the probability. There is no column holding a weighted value that somebody edited the amount under six weeks ago. The single most common way a pipeline report goes wrong is a denormalised number that stopped agreeing with its inputs, and the only reliable fix for that is not to have the column.

The same discipline runs into the line items on a deal. A line that references a real plan or a real catalog item is server-priced: any price the client sent is discarded and nulled, because the catalog is the only authority on what something costs. A custom line — no plan, no catalog reference — must carry a non-negative integer anchor, and a line with a missing or malformed one is refused by name rather than defaulted to zero. On the advertising side, a package discount is held in basis points and the subtotal is computed server-side, with the module’s own comment stating flatly that a client-supplied total is never trusted.

And the forecast’s exclusions are as deliberate as its inclusions. Won and lost deals are out, because a forecast is probable future revenue and a closed deal is neither probable nor future. A deal whose stage identifier does not resolve is skipped rather than counted with a default probability — a dangling reference is a data problem, and quietly assigning it a fifty-fifty chance is how a data problem becomes a revenue projection.