Building a Trade Promotion and Revenue Growth Management Model in Anaplan: Price Waterfall, Lift, Accruals, and Claims

Most Anaplan revenue models stop at gross sales. A demand plan says how many units will move, a quota model says who is accountable, and a SaaS revenue model tracks ARR. But in consumer goods, food and beverage, and any business that sells through retail or distribution, the interesting money lives below gross sales: list price, discounts, off-invoice allowances, scan funding, billbacks, slotting fees, rebates, and co-op marketing. That stack — the gap between gross and net — is trade spend, and it is typically the second-largest line on the P&L after cost of goods sold.

Trade promotion planning and revenue growth management (RGM) are the disciplines that manage it. They are also chronically under-modeled: most teams run promotions in spreadsheets, accrue trade spend on a flat percentage, and discover the true cost of a promotion months later in a deduction claim nobody can tie back to an agreement.

This tutorial builds a trade promotion and RGM model in Anaplan: the price waterfall, the promotion grain, volume lift and cannibalization, accruals, settlement and claims reconciliation, and post-event ROI. It assumes comfort with lists, subsidiary views, SUM/LOOKUP, and time-phased modules. A demand planning model upstream is useful but not required.

The one design decision that determines everything: the promotion grain

Before creating a single list, decide what a single promotion row represents. Nearly every failed trade model failed here.

The grain that works in practice is one row per promotion event, where an event is a unique combination of:

• Customer (the retailer or distributor, at the level you actually negotiate with)
• Product group (the level you actually promote — usually a brand-size or a pack group, not an SKU)
• Tactic (the mechanic: feature-and-display, TPR, BOGO, e-commerce coupon)
• Time window (start and end dates, which rarely align to fiscal periods)

Use a numbered list for events, not a multi-dimensional module. A Customers × Products × Tactics × Weeks module is combinatorially enormous and about 99.9% empty: you promote a fraction of your portfolio at a fraction of your customers in any given week. A numbered Promotion Events list with properties for customer, product group, and tactic keeps the model sparse and lets one customer run 400 events a year while another runs six.

List: Promotion Events   (numbered, production list)
Properties / line items:
  Customer            (list: Customers)
  Product Group       (list: Product Groups)
  Tactic              (list: Tactics)
  Start Date          (date)
  End Date            (date)
  Status              (list: Draft / Submitted / Approved / Executed / Settled / Cancelled)
  Agreement Ref       (text)

The cost of the numbered-list grain is that events do not naturally live in time. You pay for that once, in Step 4, with a phasing module — and you get a model that stays fast forever.

Step 1: The dimensional skeleton

List	Type	Notes
Customers	Hierarchy	Banner → Customer Group → Channel → Region. Negotiation happens mid-hierarchy; plan there.
Products	Hierarchy	SKU → Product Group → Brand → Category. Promote at Product Group.
Tactics	Flat	Each mechanic, with a default funding type and default lift curve.
Trade Elements	Flat	The waterfall steps: every discount and allowance type, in order.
Promotion Events	Numbered, production	The event grain above.
Time	Native	Weekly. Promotions run in weeks; monthly time destroys the model's usefulness.

Weekly time is not optional for trade. A two-week feature starting on a Thursday cannot be represented in monthly buckets, and retail data arrives weekly. Build weekly with monthly and quarterly rollups enabled, and use a Time Ranges definition to keep weekly detail confined to the current and next plan year rather than spanning ten years of history.

Step 2: The price waterfall

The waterfall is the backbone. Model it as a single module dimensioned Customers × Product Groups × Time, with the Trade Elements list driving the deduction steps through a line item subset — or, if you want the steps visible as line items for reporting, as an explicit ordered stack:

Gross Sales Volume        (units)
List Price                (per unit)
Gross Sales               = Gross Sales Volume * List Price

  Less: On-Invoice Discounts
  Less: Off-Invoice Allowances
  Less: Scan / Coupon Funding
  Less: Billbacks
  Less: Volume Rebates
  Less: Slotting and Listing Fees
  Less: Co-op Marketing

Total Trade Spend         = SUM of deduction steps
Net Sales                 = Gross Sales - Total Trade Spend
  Less: COGS
Gross Margin              = Net Sales - COGS
  Less: Logistics to Serve
Net Contribution          = Gross Margin - Logistics to Serve

Trade Rate %              = Total Trade Spend / Gross Sales
Realized Price / Unit     = Net Sales / Gross Sales Volume

Two rules for the waterfall:

1. Every deduction step traces to a source. Each step should be the sum of either promotion events, a standing agreement, or a manual accrual — never a plug. A step that cannot be decomposed is a step nobody will trust at settlement time.
2. Keep the order configurable. On-invoice versus off-invoice treatment differs by customer and by country, and it affects net revenue recognition. Driving the order from the Trade Elements list rather than from line item sequence saves a rebuild when a new market comes on.

Step 3: Event economics

PR02 Promotion Event Economics, dimensioned by Promotion Events:

Base Volume (Event Window)   = SUM of weekly baseline over the event's weeks
Promoted Price               = List Price * (1 - Total Discount %)
Discount Depth %             = 1 - (Promoted Price / Everyday Price)
Lift %                       = from the lift model (Step 5)
Incremental Volume           = Base Volume * Lift %
Promoted Volume              = Base Volume + Incremental Volume

Spend Rate / Unit            = funding per unit, by tactic
Fixed Spend                  = display fees, ad fees, listing costs
Variable Spend               = Promoted Volume * Spend Rate / Unit
Total Event Spend            = Fixed Spend + Variable Spend

Incremental Net Sales        = Incremental Volume * (Promoted Price - variable trade)
Incremental Margin           = Incremental Net Sales - (Incremental Volume * Unit COGS)
Event ROI                    = IF Total Event Spend = 0 THEN 0
                               ELSE Incremental Margin / Total Event Spend
Payback?                     = Event ROI > 1

Note the discipline of measuring against baseline, not against total promoted volume. A promotion that sells 10,000 units where the baseline was 9,000 sold 1,000 incremental units, and the entire cost of the promotion — including the discount given on the 9,000 units that would have sold anyway — is the investment. Models that credit total volume against incremental spend produce ROIs above 1 for every promotion ever run, which is how a trade budget quietly triples.

Step 4: Phasing events into weeks

This is the bridge between the numbered-list grain and the time-phased waterfall. Build PR03 Event Phasing, dimensioned Promotion Events × Time:

In Window?        = Week Start >= Start Date AND Week Start <= End Date
Weeks In Event    = SUM over Time of In Window?
Week Weight       = IF NOT In Window? THEN 0
                    ELSE Shape Factor / Total Shape Factor
Phased Volume     = Promoted Volume * Week Weight
Phased Spend      = Total Event Spend * Week Weight

Shape Factor comes from the tactic: a feature-and-display typically front-loads into week one, while a straight TPR spreads evenly. Store the shape on Tactics × Week-in-Event and look it up rather than hard-coding a curve.

Then aggregate to the planning grain in PR04 Spend by Customer Product Week, dimensioned Customers × Product Groups × Time × Trade Elements:

Event Spend    = SUM of Phased Spend over Promotion Events,
                 mapped by Customer, Product Group, and funding element
Event Volume   = SUM of Phased Volume, mapped the same way

One aggregation module, read by everything downstream. The Promotion Events list never appears in the waterfall logic again.

Step 5: Lift, cannibalization, and the pantry effect

Lift is where most trade models are either naive or overbuilt. A pragmatic three-tier approach works well:

Tier 1 — Tactic default. Each tactic has a default lift %, set by trade marketing. Crude, but it lets the model run on day one.

Tier 2 — Elasticity curve. Lift as a function of discount depth, by product group and tactic:

Lift % = Base Lift % * (1 + Depth Elasticity * (Discount Depth % - Reference Depth %))

Store Base Lift %, Depth Elasticity, and Reference Depth % on Product Groups × Tactics as data owned by the analytics team. Cap the result — unbounded elasticity formulas produce 900% lift on a deep discount and nobody catches it until the plan is approved.

Tier 3 — Fitted lift from post-event actuals. Once you have two or three cycles of executed events with measured lift, feed the fitted coefficient back into Tier 2. Keep Lift Source as a line item on the event so a planner can see whether a number came from a default, a curve, or history.

Then handle the two effects that make trade ROI look better than it is:

Cannibalization %   = share of incremental volume stolen from
                      non-promoted products in the same category
Forward-Buy %       = share of incremental volume pulled from
                      future periods (pantry loading / retailer stockpiling)

Net Incremental Volume = Incremental Volume
                       * (1 - Cannibalization %)
                       * (1 - Forward-Buy %)

Model the forward-buy effect explicitly as negative volume in the weeks following the event, not just as a haircut. The post-promotion dip is real, it hits supply chain hard, and a demand plan that ignores it will over-forecast the week after every major feature. If your demand planning and S&OP model consumes this output, phasing the dip properly is the single highest-value handoff between the two models.

Step 6: Budget, accrual, and the liability

Trade spend is a liability the moment a promotion is executed, not when the retailer claims it. TR05 Trade Accrual, dimensioned Customers × Product Groups × Time × Trade Elements:

Committed Spend       = Event Spend for Status >= Approved
Accrual (Period)      = Committed Spend phased into the weeks of performance
Accrual Balance       = Accrual Balance (Prior) + Accrual (Period) - Settled (Period)
Settled (Period)      = actual deductions and payments from AR / AP
Variance              = Accrual (Period) - Settled (Period)
Aged Over 90?         = Accrual Balance where the event ended more than 90 days ago

The Aged Over 90? line item is the one finance will care about most. Unsettled accruals for long-closed promotions are either money owed that nobody has claimed, or an over-accrual that should be released to the P&L. Publish it as a page with a drill to the underlying events, and review it monthly.

On the budget side, keep three separate concepts and never collapse them:

Concept	Grain	Meaning
Trade Budget	Customer × Period	What was authorized
Committed	Customer × Period	Approved events, whether or not executed
Actual Settled	Customer × Period	What was actually paid or deducted

Budget Remaining     = Trade Budget - Committed
Over Commitment?     = Committed > Trade Budget

Block event approval when Over Commitment? is true, using Dynamic Cell Access on the Status line item rather than relying on a planner noticing a red cell. Soft controls do not hold in a quarter-end funding scramble.

Step 7: Claims and deduction reconciliation

This is the operational grind that separates a trade model from a trade system, and it is where the payback usually is.

Build a Claims numbered list loaded from AR deductions or customer billbacks:

Claim Ref, Customer, Claim Amount, Claim Date,
Claimed Event Ref, Claimed Period, Product Group

Then a matching module:

Matched Event         = LOOKUP on Claimed Event Ref, fallback to
                        customer + product + overlapping period
Match Confidence      = Exact / Probable / Unmatched
Accrued For Event     = accrual balance on the matched event
Claim vs Accrual      = Claim Amount - Accrued For Event
Disputable?           = Claim vs Accrual > Tolerance
                        OR Match Confidence = "Unmatched"
                        OR Matched Event Status = "Cancelled"

A UX page filtered to Disputable? with the matched event's agreement reference, approved spend, and executed volume next to the claim is the entire business case for many trade projects. Unvalidated deductions in consumer goods routinely run in the low single-digit percentages of gross sales; recovering a fraction of that dwarfs the cost of the model.

Step 8: Post-event analysis and the RGM view

Close the loop. PE06 Post Event, dimensioned Promotion Events:

Planned Volume / Spend / ROI    = snapshot at approval (a versioned copy, not live)
Actual Volume                   = from POS or shipment actuals over the window
Actual Baseline                 = statistical baseline over the same window
Actual Lift %                   = (Actual Volume - Actual Baseline) / Actual Baseline
Actual Spend                    = settled spend on the event
Actual ROI                      = actual incremental margin / actual spend
Forecast Accuracy               = 1 - ABS(Actual - Planned) / Planned
Repeat Recommendation           = Repeat / Modify / Retire

Snapshot the plan at approval into a Plan (Approved) version. Comparing actuals against a live plan that planners have since edited produces meaningless variance, and it is the most common reason post-event analysis gets abandoned after two quarters.

On top of the event view, the RGM layer looks across the whole commercial mix — the five levers most RGM programs manage:

1. Pricing — list price architecture and price-pack alignment
2. Promotion — depth, frequency, and mechanic effectiveness
3. Mix — product and channel mix shift
4. Trade terms — the standing, non-promotional funding stack
5. Assortment — listings, delistings, and shelf productivity

Build a Price-Pack Architecture module at Product Groups × Customers with price per unit, price per volume-equivalent, and price-index-to-competitor, so a planner can see when a promotion on one pack size undercuts the everyday price of another. That cross-pack cannibalization is invisible at event level and is where RGM earns its keep.

Performance and build notes

• Weekly time plus wide hierarchies is the size risk. Confine weekly detail with Time Ranges and aggregate to monthly for anything that does not need weeks.
• Never calculate on the Promotion Events list beyond event economics and phasing. Aggregate once into the customer-product-week grain and read that everywhere else.
• Use subsidiary views aggressively. Price and elasticity data does not need weekly dimensionality; spend does.
• Lift is sparse, baselines are dense. Keep the baseline module separate from the promotion modules so a full baseline recalculation does not drag event planning with it.
• Archive settled plan years. Executed events, claims, and settlements accumulate faster than anything else in the model.

Common mistakes

Modeling promotions as a dense multi-dimensional module. The combinatorial grain looks tidy in a design document and is unusable at scale. Numbered list, every time.

Measuring ROI against total volume. Incremental margin over total spend, with the discount on baseline volume counted as cost. Anything else flatters every promotion you run.

Monthly time. Promotions are weekly events and retail data is weekly. Monthly trade models cannot answer the questions they are built for.

No approval snapshot. Without a versioned plan-at-approval, post-event analysis is unfalsifiable and dies quietly.

Ignoring forward buy. The post-promotion dip is real volume moved between periods. Omitting it inflates promotional lift and misleads the supply plan.

Treating claims as a finance problem. The accrual, the agreement, and the claim have to live in the same model or reconciliation stays a spreadsheet exercise forever.

A sensible phase-one scope

If you are starting from spreadsheets, resist building all of the above in release one. A defensible first phase:

1. The price waterfall at customer × product group × month, reconciled to the GL.
2. The promotion event list with tactic-default lift and manual spend rates.
3. Weekly phasing and accrual with the aged-balance page.
4. Budget versus committed control with DCA on approval.

That alone replaces the spreadsheet, gives finance an accrual it can defend, and produces the executed-event history you need before elasticity or fitted lift means anything. Add claims matching in phase two, once the accrual is trusted; add the RGM price-pack layer in phase three, once someone owns the analytics.

---

Trade spend is usually the least-governed large number in a consumer goods P&L, which makes it one of the highest-return Anaplan use cases available — and one of the least frequently built well. If you are scoping a trade promotion or revenue growth management build, or you have a trade model that has outgrown the way it was originally structured, get in touch and we will walk through the grain decisions with you before you commit to a design.