Methodology · rNPV Engine

rNPV Engine

Risk-adjusted net present value (rNPV) is the core calculation behind every PhaseFolio valuation, and it applies to any clinical-stage asset regardless of indication. The engine builds a probability-weighted decision tree: it discounts development costs at the WACC and weights them by the probability of reaching each stage, projects a revenue lifecycle (S-curve ramp, plateau, loss-of-exclusivity erosion) net of COGS, SG&A, and tax, weights that revenue by the cumulative probability of approval, and discounts everything to the present. The probability-of-success inputs, clinical stage normalization, IRA terminal-value treatment, cost priors, and development-path semantics are documented in their own sections; this section documents how they are combined into a single number.

01

What rNPV is, and why it leads

A probability-weighted decision tree, not a success-assumed DCF.

Risk-adjusted net present value is the standard valuation method for clinical-stage drug assets. A naive discounted-cash-flow model assumes the product reaches market; an rNPV model does not. It treats development as a sequence of gated bets — each clinical phase succeeds with some probability — and weights every future cash flow by the probability that the program is still alive to receive it. Costs are spent whether or not the program ultimately succeeds, so they are weighted only by the probability of reaching the stage that incurs them; revenue arrives only if the program is approved, so it is weighted by the cumulative probability of approval.

This calculation is the spine of the platform and it is indication-agnostic: the same arithmetic values an oncology antibody, a rare-disease gene therapy, or an anti-infective small molecule. What changes between assets are the inputs — the per-stage probabilities, the revenue and cost assumptions, the exclusivity profile — not the method. This section is the assembly: how those inputs become one risk-adjusted number. The probability inputs are calibrated and validated separately (PoS Calibration, Backtest Methodology); the terminal-value treatment under the Inflation Reduction Act has its own section; the cost priors live in the COGS, SG&A, and Tax benchmark sections.

The engine is deterministic and version-stamped. Every figure here is produced by engine 2.8.0, which is embedded in every signed export so a reader can reproduce the exact calculation.

02

Cumulative probability of success

The product of per-stage probabilities from the current phase through approval.

Each development stage carries a probability of success (PoS). The cumulative probability that the asset reaches market is the product of the per-stage probabilities — clearing Phase I tells you nothing unless you then clear Phase II, Phase III, and regulatory review.

Equation 1 — Cumulative probability of success
cumulative_PoS = ∏i PoSi
the product across all stages i from the asset's current phase through approval.

The PoS values themselves come from the indication × modality × biomarker benchmark matrix and, where the engine has a validated drug-specific multiplier, are adjusted in log-odds space. That derivation — including the multiplier-governance gate that decides which signals are allowed to move a probability — is documented in the PoS Calibration section and is deliberately out of scope here. The rNPV engine consumes the resulting per-stage probabilities as given.

03

Development costs — discounted and risk-adjusted

Each stage's spend, discounted at the WACC and weighted by the probability of reaching it.

Each stage has a cost and a duration. The engine discounts each stage's cost to present value at the weighted average cost of capital (WACC), timing the cash outflow at the midpoint of the stage rather than its start or end, then weights it by the cumulative probability of reaching that stage.

Equation 2 — Risk-adjusted development cost
discount_factori = 1 / (1 + WACC)(tstart,i + di/2)
risk_adj_costi = costi × discount_factori × cumulative_PoS_at_entryi
total_risk_adjusted_cost = ∑i risk_adj_costi
where tstart,i is the elapsed years before stage i, di its duration, and cumulative_PoS_at_entryi the product of every prior stage's probability.

cumulative_PoS_at_entry is the product of the probabilities of every prior stage — the cost is incurred if and only if the program survives to enter the stage, so it is not discounted by the stage's own probability. An optional launch cost is modeled as a single outflow twelve months before approval, discounted and weighted by the probability of reaching the final stage.

04

The revenue lifecycle

S-curve ramp, plateau, and loss-of-exclusivity erosion, net of COGS, SG&A, and tax.

On approval, the engine builds an annual revenue schedule with three phases:

  • Ramp. Revenue climbs from launch toward peak over a user-set number of years. The default shape is an S-curve preset interpolated onto the chosen ramp length; a linear ramp is also available. The final ramp year reaches the stated peak.
  • Plateau. Revenue holds at peak for the remainder of the on-market window.
  • Loss-of-exclusivity (LOE) erosion. Near the end of exclusivity, revenue erodes. Small-molecule erosion is steep (a generic cliff: revenue falls to roughly a tenth of peak and then declines further); biologic erosion is gentler (retaining about 85% per year, reflecting biosimilar dynamics).

The on-market window is exactly the asset's exclusivity period: erosion happens within that window, eroding its final years, rather than being appended as extra years. This is a deliberate modeling choice (corrected in engine 2.0.0) so that turning a patent cliff on can only ever reduce value relative to holding peak — never increase it.

Gross revenue is then converted to the after-cost, after-tax figure the valuation discounts. The operating margin is additive — the IB-standard convention — so cost of goods and SG&A are each taken as a share of gross revenue, and tax is applied to the operating result.

Equation 3 — Net revenue per year
net_revenuey = gross_revenuey × (1 − COGS% − SG&A%) × (1 − tax_rate)
the engine requires COGS% + SG&A% ≤ 1 so the operating margin is never negative.

The COGS%, SG&A%, and tax-rate defaults are sourced priors keyed on modality and commercial model (COGS, SG&A, Tax); the IRA Maximum Fair Price cliff is applied to gross revenue from the Year-9 (small molecule) or Year-13 (biologic) cliff onward before costs are taken. Multi-market assets are modeled as a sum of per-geography schedules with their own launch timing and revenue shares.

05

Discounting to present value

WACC, annual compounding, revenue discounted from the end of development.

Every cash flow is discounted to present value at the WACC with annual compounding. Revenue is discounted from the end of the development period — peak sales arriving years after a long Phase III are worth far less than the same sales arriving sooner, which is why duration assumptions matter as much as magnitude.

Equation 4 — Revenue present value
revenue_PV = ∑y net_revenuey / (1 + WACC)(Tdev + y)
where Tdev is the total development time (the sum of all stage durations) and revenue year y runs from 1.
06

The rNPV equation

Probability-weighted revenue minus probability-weighted cost — plus the Unadjusted NPV reference.

The headline value combines the probability-weighted revenue with the probability-weighted cost.

Equation 5 — Risk-adjusted NPV
rNPV = (revenue_PV × cumulative_PoS) − total_risk_adjusted_cost
Unadjusted NPV = revenue_PV − total_discounted_cost (revenue and cost both at certainty).

Alongside the risk-adjusted number the engine reports an Unadjusted NPV: the value the asset would have if approval were certain. The gap between the Unadjusted NPV and the rNPV is the clinical-risk discount — the part of the headline value that the probability of failure removes. It is shown as a reference, not the headline, because for a pre-approval asset it overstates value by assuming success.

When a deal structure is attached (royalty, milestone, or profit-split), the engine first builds the same revenue and cost series, then transforms it into the partner's economic position — royalties on gross net-sales, milestones recognized at their trigger gates, profit-split on net revenue — and the rNPV is the deal-adjusted value rather than the full-product value. The deal math reads from the same authoritative revenue series as the headline, so a royalty calculation and the deterministic rNPV never disagree.

07

Monte Carlo and expected NPV

The distribution behind the point estimate — and why the mean, not the median, is the central value.

The deterministic rNPV is a single point estimate built from point-estimate inputs. Because clinical outcomes are binary and the inputs are uncertain, the true distribution of value is wide and not symmetric — most paths end at or near zero (failure) while a minority reach the full commercial value. PhaseFolio runs a Monte Carlo simulation that samples the uncertain inputs and re-evaluates the model many times to produce that distribution, applying the IRA cliff inside each iteration so every draw carries the correct terminal compression.

The defensible central estimate of a Monte Carlo run is the expected NPV (eNPV) — the mean of the simulated distribution — not the median. Because the distribution is bimodal (a large mass near zero plus a commercial-success mode), the median can sit in the empty middle and misrepresents the asset; the mean correctly reflects the probability-weighted average outcome and reconciles with the deterministic rNPV. Confidence bands (for example the 10th-to-90th-percentile range) are reported to convey the spread rather than implying false precision in the point estimate.

08

Sensitivity analysis

A one-at-a-time tornado that ranks the highest-leverage assumptions.

To show which assumptions drive the value, the engine runs a one-at-a-time (tornado) sensitivity: each input is varied across a plausible range while the others are held at their base case, and the resulting swing in rNPV is ranked. This isolates the highest-leverage assumptions for a reviewer to challenge. It is deliberately one-at-a-time rather than a global sensitivity analysis, so it does not capture interaction effects between simultaneously varying inputs — a known limitation stated below.

09

What the engine consumes

The rNPV engine is the assembly point for inputs documented and sourced elsewhere.

Engine inputDocumented in
Per-stage probabilities and durationsPoS Calibration; Backtest Methodology
Peak revenue, ramp shape and length, exclusivity, WACCAnalyst assumptions
COGS%, SG&A%, tax-rate priorsCOGS / SG&A / Tax benchmarks
IRA modality class and MFP discountIRA Terminal-Value Framework
Development-path semantics (no silent input change)Development Path Templates
Exact-label stage structure (work packages mapped to canonical PoS gates)Clinical Stage Normalization
Optional deal structure and comparator deal termsSEC EDGAR Deal-Term Extraction
Source linkage for every load-bearing inputEvidence Standards
10

Limitations

What the engine does, and what it deliberately does not, capture.

  • Point-estimate inputs. The deterministic rNPV is only as good as its inputs; it does not itself express uncertainty. The Monte Carlo distribution is the place to read uncertainty, and even that samples the assumptions the analyst provides.
  • One-at-a-time sensitivity. The tornado holds all-but-one input fixed and therefore does not capture interactions between simultaneously varying assumptions.
  • Annual granularity. Cash flows are modeled annually with midpoint-timed development costs; intra-year timing is not modeled.
  • Stylized LOE erosion. The small-molecule and biologic erosion curves are stylized defaults, not asset-specific generic-entry forecasts; an analyst with a specific LOE view should override them.
  • Decision support, not a fairness opinion. The engine is built for portfolio triage, asset stress-testing, and term-sheet work. It is not calibrated for IFRS-13 / US-GAAP fair-value reporting, Section 409A valuations, or litigation-grade damages; treat any output as a working model a qualified valuation professional must independently challenge.
§

References

Methodology version: methodology@2026-06-19 · Last updated: 2026-06-19 · Version history →