Margin intelligence

Model the deal before it becomes a liability

A structure agreed on a blank spreadsheet is a hypothesis. Modelled against real historical volume, it is a decision.

The same problem, stated twice

Once for the person who owns the P&L, once for the person who owns the systems. Neither column is a summary of the other.

The financial problem

The tier you granted was priced against a forecast, not a distribution.

Thresholds set without reference to the actual volume distribution either pay out on business you would have won anyway, or never trigger at all.
Stacked programmes are designed independently and their combined effective rate is rarely calculated before launch.
Commitments granted on a customer projection settle against reality, and the shortfall surfaces at annual review.
Supplier negotiations happen without a defensible view of what that supplier is actually worth to you.

The technical problem

The history needed to model the deal is not queryable in the time available.

Modelling against three years of line-level history means a query that takes hours, so it is done on aggregates or not at all.
Programme rules are prose, so a stacked combination has to be re-implemented in a spreadsheet each time.
Supplier spend is fragmented across entities and item hierarchies, so a consolidated position is a project.
There is no way to compare two structures against the same volume without building both by hand.

What RevUpra does

Inside deal modelling

Structure modeller

Flat, tiered, volume, growth and lump-sum modelled against your own historical transactions.

Sweet-spot recommendation

The threshold that maximises net margin given the actual volume distribution.

Stacked effective rate

What the combination really costs on the transactions that qualify for all of it.

Scenario comparison

Two or three structures side by side on identical volume.

Supplier intelligence

Spend, year-on-year movement, health and profitability scoring per partner.

Accrual preview

The liability this structure would have generated last year, before you sign it this year.

Benchmarks

What good looks like

Use this as a self-assessment. If you cannot produce one of these numbers for your own programme, that is itself the finding.

Deal modelling benchmarks
Metric	Typical today	Target
Programmes modelled before launch	35 – 60%	>95%
Stacked effective rate calculated pre-launch	Rare	Standard
Deals with modelled net contribution pre-approval	30 – 55%	>95%
Time to model a structure	Days	Minutes

Ranges are indicative benchmarks drawn from published channel-incentive and pricing research together with our own implementation experience. They vary widely by programme complexity, channel depth and data quality — treat them as the opening question in a diagnostic, not a guarantee.

The point of modelling is not precision — it is that the conversation about a threshold happens against a distribution rather than against an opinion.

Leak points

What this closes

The leak points from our taxonomy that this module addresses directly.

Price erosion & discount stacking

“Every discount was defensible. The stack was not.”

Financially

List price, then a contract discount, then a volume break, then a ship-and-debit, then a year-end rebate. Each concession was approved on its own merits; nobody ever saw the pocket price at the bottom of the stack, which on some lines is below cost.

Technically

Discounts are applied in different systems at different times — order entry, billing, and post-transaction settlement — so no single record holds the fully-loaded net price. Reconstructing it means joining three systems after the fact.

Typical cost: 1.5% – 4.0% of net revenue
Benchmark: Disciplined programmes keep pocket-price variance within a ±3% band per customer segment.

How it closes: Price triangulation resolves invoice price, net-net pocket price and contract price into one number per transaction — visible before the deal is signed.

See the module →

Accrual drift

“The liability on the balance sheet is not the liability you owe.”

Financially

Rebate accruals are estimated from last year’s rate on this year’s volume. When the true settlement lands, the difference is a true-up nobody forecast — an earnings surprise in either direction, and an audit finding waiting to happen.

Technically

The accrual is a spreadsheet calculation run monthly, disconnected from the transaction detail. There is no way to drill from the balance-sheet number back to the lines that created it, and no locked period to stop the base data from moving underneath it.

Typical cost: 10% – 30% true-up variance at settlement
Benchmark: A transaction-level accrual holds settlement variance under 2%.

How it closes: Accruals are computed in-database from the transaction lines themselves, against locked accounting periods, and every posted number drills back to its source rows.

See the module →

Contract drift

“You are operating a version of the deal nobody signed.”

Financially

The signed agreement says one rate; the system was configured with another, or an amendment was agreed by email and never applied. Every transaction from that point is priced or accrued wrongly, and the exposure compounds silently until renewal.

Technically

The contract is a document and the configuration is data, and nothing binds them. Amendments arrive as redlined attachments; applying them to the running configuration is a manual re-keying step with no verification.

Typical cost: 0.5% – 2.0% of contracted revenue
Benchmark: Best practice is zero drift — every executed term traceable to the clause that created it.

How it closes: The contract is the front door. Terms are mashed live from the deal, redlined with attribution, executed, and the executed version is what the engine runs.

See the module →

Terminology

Terms on this page, defined

Plain-language definitions with the reason each one tends to leak.

Tiered rebate ↗: A rebate whose rate increases as cumulative volume crosses defined thresholds.
Growth rebate ↗: A rebate paid on the increase in volume over a prior-period baseline, rather than on total volume.
Retroactive rebate ↗: A rebate where crossing a threshold applies the higher rate to all qualifying volume from the start of the period, not just the volume above the threshold.
Take-or-pay ↗: A commitment where the customer must purchase a minimum volume or compensate for the shortfall.
Pocket price ↗: What you actually keep from a transaction after every on-invoice and off-invoice reduction.

Open the full terminology library →

See what RevUpra can recover for you.

Thirty minutes, tailored to your programmes. We walk an agreement through modelling, contracting, accrual, claim and settlement using examples close to your own — and model an indicative ROI against your volumes.

Book a demo Read the leak map