Modelling deal terms

A deal records what was offered and what was agreed as versioned term sets of typed terms. Once a term set is proposed or agreed, it is frozen: a draft cannot be modelled. "Model these terms" takes that frozen set and one of the asset's full-ownership scenarios, and maps the terms it can value onto that scenario's deal structure. The result is a new scenario (a partner case, not the asset's base case unless a user later sets it so) that pins the exact term-set version it followed. The source scenario is never changed.

The mapping is a pure, versioned function: term-model mapping v5. Every term in the set gets an outcome, modelled or not modelled with a reason; no term is ever dropped silently, and every approximation the mapping makes is returned as a named assumption shown beside the result.

From mapping v5, on rNPV model 4.1.0, the mapping values the terms your organisation pays as well as those it receives. A term your organisation pays that the model cannot value refuses the set rather than being left out, because leaving it out would overstate your side (sections 04 and 08).

The deal-structure type the mapping writes follows the three modes the rNPV wizard already uses, plus one for terms your organisation pays: a profit share gives Profit split (with your organisation's cost share carried across, and any terms it pays subtracted); otherwise, when your organisation pays an upfront, milestone, royalty or purchase price, it gives Licensee, net of terms paid (section 08); otherwise no cost share, or an explicit 0% share for your organisation, gives Royalty or license-out; a 100% cost share for your organisation gives Milestone and royalty. Every "Royalty or license-out" scenario carries the assumption that the licensee bears all development and launch costs, because the model treats that deal type as licensee-funded regardless of the modelled cost share.

From mapping v5 only a term your organisation receives, or one it is not a party to or that is scoped elsewhere, is listed this way. A term your organisation pays on the modelled asset is valued or refuses the set (section 04), because leaving it out would overstate your side.

A territory-limited royalty or profit share is modelled only against the scenario's geography entries that are inside its territory, never against worldwide revenue by default. When it applies, the kept geographies' peak revenue is scaled to their combined share of the scenario's total peak sales, and their shares are renormalised to still sum to the whole. Rights retained outside the licensed territory are not part of the resulting scenario at all.

This restriction is an approximation, not an exact re-derivation of a per-territory deal:

• The US IRA price cap applies to US revenue only (model 4.0.0). Leaving the United States out of the territory drops the cap from the model; keeping it in applies the cap to the kept US geography (or to rest of world when no kept geography covers the US), not to the other kept regions. Scenarios modelled on earlier models applied it to every kept region.
• When the source scenario uses the epidemiology builder, the modelled scenario fixes peak revenue at the builder's calculated result, scaled to the kept share, and turns the builder off.
• When a royalty's territory is wider than its governing license grant's, the modelled revenue is restricted to the grant's narrower territory instead.

On the licensee basis (section 08) the modelled revenue is restricted to the territory of the license grant your organisation receives, in the same way; after a cash purchase with no grant, the whole scenario is kept. A royalty your organisation pays is charged on all the revenue the model values, so its territory must hold every kept geography; if it covers only part of them, the set is refused (paid_royalty_territory_partial) rather than overstating the royalty.

Each kept region keeps its own launch delay. From rNPV model 3.0.0, royalties, royalty tiers, sales milestones and the profit-split pro-forma follow each kept region's revenue share and launch, so a region that launches later than the lead market earns its modelled revenue later too. Term-model mapping v1 on model 2.9.0 timed all deal revenue from the lead launch; the Methodology M3 record of this section describes it.

• A milestone triggered by the completion of a numbered phase lands at the end of the scenario's stage with that exact phase number.
• A milestone triggered by the start of a numbered phase lands at the end of the previous stage (a Phase 1 start lands at the end of the last preclinical stage, if the scenario has one).
• Regulatory approval, first commercial sale, and a completed regulatory review all land at the end of the scenario's last stage. When that last stage is an actual NDA/BLA review stage, this is exact; when the scenario has none, the last stage stands in for approval instead, and the mapping names this as an assumption. A regulatory-approval or first-sale milestone tied to a jurisdiction lands at that same point whatever its jurisdiction: the mapping does not time a US approval apart from an EU one, and names this as an assumption.

A milestone whose matching stage is not present in the source scenario is not modelled, never guessed at a nearby stage.

A milestone your organisation pays is timed by the same rules, with one difference: an approval, first-sale or regulatory-review milestone it pays lands at the end of the scenario's NDA/BLA review stage. With no such stage it is refused rather than timed at the last stage: a later, less likely payment would understate what your organisation owes and so overstate its value. A paid milestone the model cannot time, or whose stage is not in the scenario, also refuses the set (paid_milestone_not_timed) instead of being listed as not modelled.

• A profit share cannot be modelled without a cost-share term alongside it.
• Without a profit share, and when your organisation pays nothing, its cost share must be 0% or 100%; a partial cost share (0% to 100%) is refused because the model cannot represent it with a royalty.
• On the licensee basis (section 08) your organisation bears the share of development cost its cost-share term states, any share from 0% to 100%. With no cost-share term the set is refused, except after a cash purchase, where the buyer bears development cost and the mapping names that assumption.
• A capped cost share is refused outright; the model needs a plain percentage share.
• At most one cost-share term can be modelled at a time.
• Whichever side pays a cost-share term bears that share of development costs; your organisation's share is the contract share when it pays, and one minus that share when it receives it.
• Every "Royalty or license-out" scenario still carries the assumption that the licensee bears all development and launch costs, whatever cost share was modelled, because the model's treatment of that deal type is hard-coded.

With no profit share, the mapping writes the licensee basis: your organisation values the asset as if it owned it, on the revenue inside the license grant it receives (section 05), bears the share of development cost the terms state (section 07), and subtracts every term it pays.

• An upfront or a cash purchase price your organisation pays counts in full at the valuation date, whatever its due date, with no tax saving.
• A milestone it pays has the same timing and probability weighting as a received one (section 06), with no tax saving.
• A royalty it pays is charged on gross net sales, tiered or flat, weighted by the probability of approval and discounted like revenue, and counted after tax: each year it costs the royalty less the tax rate times the smaller of the royalty and the year's operating profit. Under a profit split the saving is capped at your organisation's share of operating profit.

With a profit share, the same paid terms are subtracted within the profit split, with the profit share's own cost-share rule (section 07). The result lists each paid term with its value after tax and its tax saving; if the valuation service does not return a line for every paid term, the action is refused and nothing is written. The rNPV methodology describes the calculation in full.

This tax treatment differs from reality in four ways, shown wherever a value with paid terms is:

• Received terms before tax, paid royalties after tax: a royalty your organisation receives counts in full, while the same royalty paid costs less after its tax saving, so a licensor's and a licensee's values for one deal do not add up to the full-ownership value.
• No tax saving on paid lump sums: a paid upfront, purchase price or milestone is not tax-deductible in the model, which understates your organisation's value.
• Royalty tax saving capped at operating profit: the saving on a paid royalty is limited to each year's operating profit and is not carried forward.
• Paid royalties run for the whole forecast: a royalty term that ends earlier is not modelled, so the royalty paid is overstated.

A scenario modelled from deal terms follows those terms: the deal structure, the geography split and peak revenue, the epidemiology inputs, and whatever decides where a modelled milestone lands (the stage list and names, whether an NDA/BLA review stage exists, and the development-stage plan's work packages, stage labels and PoS gates) cannot be edited by hand on that scenario. Probability of success, costs, durations and every other input the terms did not set stay editable, including the PoS, costs and durations inside the development-stage plan.

To change the modelled economics, change the terms (a new term-set version) and model them again; modelling always creates a new scenario rather than editing the pinned one. Forking a pinned scenario breaks the pin: the fork is an ordinary, unpinned scenario that no longer follows the terms and can be edited freely.

This section is carried by M10, which documents rNPV model 4.1.0. The mapping itself is versioned separately: term-model mapping v5. Mapping v5 values the upfronts, milestones, royalty and cash purchase price your organisation pays (section 08), on the licensee basis or within a profit split, and refuses every paid term it cannot value; a set with no paid term gets the same scenario inputs as under v4. Mapping v4 refused a set in which your organisation pays an upfront, milestone or royalty on the modelled asset (paid_terms_not_modelled), where earlier mappings listed that payment as not modelled (paying_side); every set it still modelled got the same scenario inputs as under v3. Mapping v3 does not model an upfront or milestone that is not allocated to one indication plan when the asset has more than one included plan, and no longer returns ira_applied_to_whole_schedule, because model 4.0.0 applies the IRA cap to US revenue only. Mapping v2 dropped deal_revenue_at_lead_launch, because model 3.0.0 times deal revenue from each kept region's own launch. A scenario modelled under an earlier mapping keeps the model version and values it was computed with.

From mapping v5 a modelled scenario's deal structure can carry the terms your organisation pays, as model 4.1.0 inputs that the scenario's REST and MCP payloads show like any other input. No export, REST or MCP surface adds the term set or the mapping itself to its payload.