Building a Supply Planning and Inventory Model in Anaplan: Netting, Lead-Time Offsets, Safety Stock, and Rough-Cut Capacity

The demand plan is the easy half. Once a consensus forecast exists, someone still has to answer the harder question: can we actually make or buy it, and what does it cost us in inventory to say yes? That is supply planning, and in most Anaplan estates it is either missing entirely or living in the ERP's MRP run, where planners can see the output but cannot model an alternative.

This tutorial builds the supply side of S&OP in Anaplan: netting demand against supply, a rough-cut capacity check, time-phased inventory projection with safety stock and days-of-supply targets, planned order generation with lead-time offsets, and an exception workbench that tells a planner what to look at on Monday morning. It assumes you already have a demand planning model producing a consensus forecast by item and location, and that you are comfortable with SUM, LOOKUP, OFFSET, POST, and cumulate-style time logic.

Scope this before you build anything

Supply planning models fail when they try to become the ERP. Anaplan is not a replacement for a deterministic MRP engine running nightly at SKU-plant-day granularity. What it is good at is the tactical horizon — weekly or monthly buckets, 3 to 24 months out, where planners run scenarios, negotiate with suppliers, and decide whether to add a shift.

Write down the boundary explicitly:

Decision	Anaplan	ERP / APS
Tactical supply/demand balance, 3–24 months	Yes	No
Capacity and constraint scenarios	Yes	Rarely
Inventory target setting and policy	Yes	No
Firm purchase order release	No	Yes
Daily shop-floor scheduling	No	Yes

If the requirement list includes the bottom two rows, push back before the design workshop, not after user acceptance testing.

Step 1: Dimensions and the planning grain

Keep the grain coarser than the demand model if you can. A common shape:

• SKU — production list, loaded from the item master, with properties for Item Type (Finished, Sub-assembly, Raw), UOM, Standard Cost, ABC Class, Sourcing Rule.
• Location — plants, distribution centres, and supplier-managed nodes in one list, with a Location Type property.
• SKU x Location — do not create this as a combination list unless the sparsity demands it. Start with the two lists as separate dimensions on the transactional modules and measure the cell count. If under 20% of intersections are valid, convert to a numbered list of valid ship-from/ship-to combinations sourced from the item-location master.
• Time — weekly buckets for the first 13 weeks, monthly beyond, implemented with two time ranges rather than one long weekly range. This is the single biggest cell-count decision in the model.
• Supply Source — a small list: On Hand, Scheduled Receipts, Firm Planned Orders, Planned Orders, Alternate Source.

The Sourcing Rule property matters more than people expect. Make it a list-formatted property pointing at a Sourcing Rules list (Make, Buy, Transfer, Co-pack), because the netting logic branches on it and you want that branch resolved by a LOOKUP, not by a text comparison inside a weekly-grain formula.

Step 2: The supply and demand input layer

Build three input modules, all at SKU x Location x Time:

SUP01 Demand Requirements — imported from the demand model or the data hub. Line items: Consensus Forecast, Firm Orders, Dependent Demand, Total Requirement. Keep Firm Orders separate from forecast because the consumption logic in step 3 needs both.

SUP02 Supply Elements — Opening On Hand (loaded once, at the first bucket only), Scheduled Receipts (open POs and work orders from ERP, time-phased by promise date), Firm Planned Orders (planner-entered, respected as-is), and In Transit.

SUP03 Planning Parameters — SKU x Location, no time dimension unless your policies genuinely change by period. Line items: Lead Time Weeks, Order Multiple, Minimum Order Qty, Safety Stock Days, Target Days of Supply, Shelf Life Weeks, Yield %, Frozen Horizon Weeks.

Parameters without a time dimension is a deliberate choice. If you dimension policy by time you quadruple the module and invite planners to maintain a parameter grid nobody audits. Handle genuine seasonality of safety stock through a formula on the days-of-supply calculation instead.

Step 3: Forecast consumption

Before netting, resolve the double-count between booked orders and forecast. The standard rule is that firm orders consume forecast within the current bucket, and unconsumed forecast carries or dies depending on your business.

Net Demand =
  MAX(Firm Orders,
      IF Consume Forward? THEN Consensus Forecast + Prior Unconsumed
      ELSE Consensus Forecast)

Implement Prior Unconsumed as a separate line item with PREVIOUS()-style logic so the carry is visible and a planner can see where it came from. Hiding consumption inside a single compound formula is the fastest way to lose an argument with the demand planner.

Step 4: Time-phased projection and safety stock

This is the core module, SUP10 Inventory Projection, at SKU x Location x Time. Line items in calculation order:

1. Opening Inventory = previous period's Closing Inventory, with the first bucket seeded from SUP02.Opening On Hand.
2. Gross Requirement = SUP03 Net Demand plus dependent demand exploded from the BOM (step 6).
3. Scheduled Supply = Scheduled Receipts + In Transit + Firm Planned Orders.
4. Safety Stock Target = average forward daily demand over the next N buckets × Safety Stock Days. Use a forward rolling average, not a trailing one — safety stock should protect the demand you are about to face, not the demand you already served.
5. Projected Available Balance = Opening Inventory + Scheduled Supply − Gross Requirement.
6. Net Requirement = MAX(0, Safety Stock Target − Projected Available Balance).
7. Planned Order Receipt = net requirement rounded up to the order multiple and floored at minimum order quantity, divided by Yield %.
8. Closing Inventory = Projected Available Balance + Planned Order Receipt.

Two traps here. First, the circularity: closing inventory feeds next period's opening, which is fine in Anaplan's time dimension but breaks if you try to put the whole chain in one line item — keep them separate. Second, rounding. Order Multiple logic wants CEILING-style arithmetic:

Planned Order Receipt =
  IF Net Requirement <= 0 THEN 0
  ELSE MAX(Minimum Order Qty,
           ROUND(Net Requirement / Order Multiple, 0, UP) * Order Multiple)
  / MAX(Yield %, 0.0001)

The MAX on yield is not decoration. A blank yield on one new SKU will otherwise produce infinity and a red model.

Step 5: Offsetting for lead time

A planned order receipt in week 20 with an 8-week lead time is a planned order release in week 12. Use OFFSET with a negative lead time:

Planned Order Release = OFFSET(Planned Order Receipt, -Lead Time Weeks, 0)

OFFSET needs a uniform bucket, which is why the mixed weekly/monthly time range from step 1 matters. If you split weekly and monthly horizons, calculate releases in each range separately and consolidate into a reporting module, or express lead time in days and offset against a daily-equivalent index. Decide this in design; retrofitting it is a rebuild.

Then check the releases that fall inside the frozen horizon or, worse, in the past. Any release date earlier than today is a late order — an alert, not a plan. Surface it:

Past Due Release? = Planned Order Release > 0 AND Period Start < CURRENTPERIODSTART()

Step 6: Dependent demand and BOM explosion

For make items, a planned order release on a parent creates dependent demand on components. A single-level explosion covers most tactical models:

• Build a BOM numbered list with properties Parent SKU, Component SKU, Qty Per, Scrap %.
• Module SUP20 BOM Explosion at BOM x Time: Component Demand = Parent Planned Order Release (via LOOKUP) * Qty Per * (1 + Scrap %).
• Aggregate back with SUM into SUP01.Dependent Demand on the component SKU.

Multi-level BOMs are where model builders get ambitious and models get slow. Anaplan has no native recursion. The workable pattern is a low-level code: precompute each SKU's BOM level in the data hub, then run the netting module once per level, level 0 through level N, with N fixed at the actual depth of your product structure — usually three or four, rarely more. Each level is a module copy; it is verbose but it is fast and debuggable, which beats clever.

Step 7: Rough-cut capacity

Supply plans that ignore capacity are wish lists. Add a Resources list (lines, work centres, key suppliers, container slots) and a Routing module giving hours or units of each resource consumed per unit of SKU.

SUP30 Capacity Load at Resource x Time:

• Required Capacity = SUM over SKUs of planned order receipts × rate per unit.
• Available Capacity = shifts × hours × efficiency, planner-editable.
• Utilisation % and Over/Under.

Do not attempt to automatically level the load. Tactical planning wants the overload visible so a human decides whether to add a shift, pull the order earlier, or move volume to an alternate source. Automated levelling in Anaplan turns into an optimisation problem — and if you genuinely need it, that is an Anaplan Optimizer job with an explicit objective function, not a nest of IF statements.

Step 8: Inventory targets and the working capital view

The planning output is only half the value. The other half is what it costs. Add SUP40 Inventory Analytics at SKU x Location x Time:

• Projected Days of Supply = closing inventory ÷ forward average daily demand.
• Excess Qty = MAX(0, Closing Inventory − Target DOS × forward daily demand).
• Shortage Qty = MAX(0, Safety Stock Target − Projected Available Balance) before planned orders.
• Inventory Value = closing inventory × standard cost, rolled up by ABC class and category for the finance conversation.
• Obsolescence Risk = flagged when projected days of supply exceeds remaining shelf life.

This module is what gets the model funded. A supply plan that also shows the CFO a $4m reduction in projected inventory value is a very different business case from one that only reschedules purchase orders.

Step 9: The exception workbench

Planners do not want a grid of 40,000 SKU-locations. They want the 60 rows that need a decision this week. Build SUP50 Exceptions with boolean flags and a single ranked list:

Exception	Rule
Stockout projected	Projected available balance < 0 in any bucket
Below safety stock	PAB < safety stock target
Past-due release	Release date before current period
Capacity overload	Resource utilisation > 100%
Excess inventory	DOS > target DOS × 1.5
Expiry risk	DOS > remaining shelf life
Unplanned new item	Demand exists, no planning parameters loaded

Rank exceptions by value at risk, not by count. Then build a UX page with the ranked exception list on the left, the time-phased projection for the selected SKU-location on the right, and planner input line items — Firm Planned Order, Override Safety Stock Days, Alternate Source?, Planner Note — directly editable. That one page is the product. Everything in steps 1 to 8 exists to populate it.

Performance notes

Supply models are usually the largest thing in a planning estate. The habits that keep them fast:

• Split the weekly and monthly horizons into separate time ranges and only apply weekly grain to the near-term modules.
• Use a valid SKU-location numbered list rather than two full dimensions once sparsity drops below roughly 20%.
• Calculate forward rolling averages once in a helper module and LOOKUP them; do not recompute a rolling window inside five different line items.
• Keep boolean exception flags in a module whose line items are all booleans — mixing booleans with number and text formats in one large module inflates the block size.
• If netting at true SKU-day-plant grain is genuinely required, this is the archetypal Polaris workload: sparse, deep, and wide. Evaluate the engine choice before you build, not after the workspace fills.

Where this fits with the demand side

A demand planning model and a supply planning model are two halves of one S&OP process, and the handshake between them is a process design question, not a technical one. Agree the cadence — demand consensus locks on day 8, supply response publishes on day 12, the executive S&OP meeting reviews the gap on day 15 — and build the model's version and snapshot logic to match that calendar. A supply model that recalculates continuously during the review meeting produces arguments, not decisions.

Build the netting engine right, keep the grain honest, and put the exception workbench in front of planners early. The rest is parameters.

---

QuanticPlanning builds and rescues Anaplan supply chain models — demand planning, supply and inventory, capacity, and S&OP integration. If you are scoping a supply-side build or trying to get an existing one performant, get in touch.