Pricing Strategy and Business Model Questions

Direct answer

A subscription charges a fixed recurring fee for access (per seat or per plan) regardless of how much the customer uses it. Usage-based pricing charges for what the customer consumes (API calls, documents processed, gigabytes stored), so the bill rises and falls with activity. Subscription makes revenue predictable and puts the growth lever in seats and plan upgrades. Usage-based ties revenue and cost to consumption and lets revenue expand without a sales conversation, at the price of volatile, harder-to-forecast revenue.

Which revenue metrics each one moves

Terms first: MRR is monthly recurring revenue and ARR is annual recurring revenue (the contracted, repeating part of revenue). ARPU is average revenue per user (or per account). NRR, net revenue retention, is this month's revenue from customers who were customers 12 months ago, divided by what those same customers paid 12 months ago, so it counts upgrades and downgrades as well as cancellations. GRR, gross revenue retention, is the same ratio with expansion ignored, so it can never exceed 100%.

Worked example

A document-processing product offers $2,000 per month as a flat subscription, or $0.02 per document processed. A customer processing 60,000, 100,000 and 160,000 documents in a month pays on the usage model:

• 60,000 x $0.02 = $1,200
• 100,000 x $0.02 = $2,000
• 160,000 x $0.02 = $3,200

At 100,000 documents a month the two models cost the same ($2,000 / $0.02 = 100,000 documents is the break-even volume). Below it the customer prefers usage pricing, above it the flat fee. For the seller the picture reverses: the flat fee earns $2,000 from the 160,000-document customer who costs the most to serve, while usage pricing earns $3,200 and tracks the cost.

Which customer each fits

• Subscription fits buyers who must fix an annual budget, use the product steadily and broadly (many people, similar frequency), and value predictability over paying exactly for use. Value that is hard to attach to a countable unit also pushes toward subscription.
• Usage-based fits buyers whose consumption is spiky or hard to forecast, teams that want to start small and prove value before committing (common with developer-led adoption), and products where each unit of use has a real marginal cost for the seller (infrastructure, model inference, data processing).
• Hybrids are common: a platform fee that includes an allowance, then overage per unit. They give the buyer a budget anchor and the seller predictable base revenue plus upside.

Trade-offs and pitfalls

• Reporting a usage-based business on MRR alone hides the risk. Track committed revenue separately from variable revenue, and watch usage per customer as a leading indicator of churn.
• Usage pricing needs trustworthy metering and invoices customers can reconcile; disputes over the meter cost real trust.
• A meter that customers feel punishes the behaviour you want (more use) suppresses adoption. Choose a unit the customer wants to grow.
• Subscription prices that ignore heavy users invite margin erosion; usage prices that ignore a buyer's need for budget certainty lose procurement-led deals.

Direct answer

Under my assumptions the annual-prepay discount is roughly cash-neutral in year one and gross-profit negative: it pulls $432,000 of cash forward on day zero, but the discount cuts ARR (annual recurring revenue, the yearly value of contracted subscriptions) by 4.0% and gross profit by about $13,400 at 2% monthly churn. On cash it breaks even when monthly-plan customers leave at about 1.94% a month (faster than that, annual collects more cash; slower, monthly does). On gross profit the break-even is higher, about 2.85% a month, because the discount permanently gives up $120 a year per converted customer. The customer's side of the trade is an implied return (the effective interest rate they earn by paying early) of about 26.5% a year on the cash they front, which is attractive to them. For larger customers, usage-based invoicing in arrears gives revenue that tracks value but later cash and more bad-debt exposure (the risk that some invoices are never paid), so I would offer a committed minimum with usage above it.

Inputs and definitions

• 1,000 customers, list price $1,200 a year ($100 a month), 70% gross margin (gross margin is revenue minus the cost of delivering the service, as a share of revenue), so cost to serve is $30 per active customer-month.
• Annual plan: 10% off, so $1,080 paid up front. Monthly plan: $100 billed at the start of each month.
• Assumptions that drive the answer, not given in the question: 40% of customers choose annual, monthly-plan customers churn (cancel) 2% a month, and annual customers cannot leave within the year.

Year-one model

customers = 1000
list_annual = 1200.0
monthly_price = list_annual / 12          # 100.0 per month
annual_price = list_annual * 0.90         # 1080.0 paid up front
gm = 0.70
cost_per_cust_month = monthly_price * (1 - gm)   # 30.0 per active customer-month
monthly_churn = 0.02                      # assumption: 2% of monthly-plan customers leave each month
take_up = 0.40                            # assumption: 40% of customers choose annual

def monthly_plan_cash(n, churn, months=12):
    # billed at start of each month; churners leave before the next bill
    active = n
    cash = 0.0
    cust_months = 0.0
    for m in range(months):
        cash += active * monthly_price
        cust_months += active
        active *= (1 - churn)
    return cash, cust_months

# A: everyone on monthly
cashA, cmA = monthly_plan_cash(customers, monthly_churn)
gpA = cashA - cmA * cost_per_cust_month
# B: 40% annual (locked 12 months), 60% monthly
n_ann = customers * take_up
n_mon = customers - n_ann
cash_mon, cm_mon = monthly_plan_cash(n_mon, monthly_churn)
cashB = n_ann * annual_price + cash_mon
cmB = n_ann * 12 + cm_mon
gpB = cashB - cmB * cost_per_cust_month
print("A all monthly: cash %.0f  gross profit %.0f" % (cashA, gpA))
print("B 40%% annual: cash %.0f  gross profit %.0f" % (cashB, gpB))
print("cash timing: annual cash at day 0 = %.0f" % (n_ann*annual_price))
# ARR (annualised recurring revenue) at start of year, contracted price basis
arrA = customers * list_annual
arrB = n_ann * annual_price + n_mon * list_annual
print("ARR start: A %.0f  B %.0f  (%.1f%%)" % (arrA, arrB, (arrB/arrA-1)*100))

# customer side: prepay costs 1080 now instead of 100 now + 100 at months 1..11
# extra cash out at t0 = 1080-100 = 980; saves 100 in each of months 1..11 = 1100
def npv(r):
    return -980 + sum(100/(1+r)**m for m in range(1,12))
lo, hi = 0.0, 1.0
for _ in range(100):
    mid = (lo+hi)/2
    if npv(mid) > 0: lo = mid
    else: hi = mid
r_m = lo
print("customer implied monthly return %.2f%%, annualised %.1f%%" % (r_m*100, ((1+r_m)**12-1)*100))

# break-even monthly churn: monthly-plan year-one cash per starting customer equals 1080
lo, hi = 0.0, 0.5
for _ in range(100):
    mid = (lo+hi)/2
    c,_ = monthly_plan_cash(1, mid)
    if c > annual_price: lo = mid
    else: hi = mid
print("break-even monthly churn for equal year-one cash: %.2f%%" % (lo*100))
# break-even monthly churn for equal year-one gross profit per starting customer
# (annual customer: 1080 - 12 x 30 cost = 720; monthly customer: 100 - 30 each active month)
lo, hi = 0.0, 0.5
for _ in range(100):
    mid = (lo+hi)/2
    c, cm = monthly_plan_cash(1, mid)
    if c - cm*cost_per_cust_month > annual_price - 12*cost_per_cust_month: lo = mid
    else: hi = mid
print("break-even monthly churn for equal year-one gross profit: %.2f%%" % (lo*100))
# sensitivity of B-A cash and GP to churn
for ch in (0.005, 0.01, 0.02, 0.04):
    ca,cma = monthly_plan_cash(customers, ch)
    cmo,cmm = monthly_plan_cash(n_mon, ch)
    cb = n_ann*annual_price + cmo
    ga = ca - cma*cost_per_cust_month
    gb = cb - (n_ann*12+cmm)*cost_per_cust_month
    print("churn %.1f%%: cash A %.0f B %.0f diff %.0f | GP A %.0f B %.0f diff %.0f" % (ch*100, ca, cb, cb-ca, ga, gb, gb-ga))

Output:

A all monthly: cash 1076416  gross profit 753491
B 40% annual: cash 1077850  gross profit 740095
cash timing: annual cash at day 0 = 432000
ARR start: A 1200000  B 1152000  (-4.0%)
customer implied monthly return 1.98%, annualised 26.5%
break-even monthly churn for equal year-one cash: 1.94%
break-even monthly churn for equal year-one gross profit: 2.85%
churn 0.5%: cash A 1167544 B 1132526 diff -35018 | GP A 817281 B 778368 diff -38912
churn 1.0%: cash A 1136151 B 1113691 diff -22461 | GP A 795306 B 765184 diff -30122
churn 2.0%: cash A 1076416 B 1077850 diff 1433 | GP A 753491 B 740095 diff -13397
churn 4.0%: cash A 968226 B 1012935 diff 44710 | GP A 677758 B 694655 diff 16897

Reading the numbers

• Cash flow. The annual plan collects $432,000 (400 customers x $1,080) on day zero instead of over twelve months. Over the year total cash is about equal at 2% churn. Cash flow timing improves even where the total does not, which has a value (less working capital needed, meaning less cash tied up to fund day-to-day operations, and a lower chance of running short).
• ARR. Converted customers are contracted at $1,080 rather than $1,200, so ARR falls by 40% x 10% = 4.0%. ARR is a contract-price measure, so the discount shows immediately even though cash is front-loaded. Revenue is recognised at $90 a month for these customers; the unearned part of the prepayment sits on the balance sheet as deferred revenue (cash received for service not yet delivered). Bookings (value of contracts signed) and cash exceed revenue early in the year.
• Break-even churn, cash. A monthly-plan customer yields the same year-one cash as an annual one when monthly churn is 1.94%. Above that, annual wins on cash; below it, monthly wins. Hand check: a monthly customer pays $100 x (1 + (1 - c) + (1 - c)^2 + ... + (1 - c)^11) = 100 x (1 - (1 - c)^12) / c. At c = 1.94%, (1 - 0.9806^12) / 0.0194 = 10.80, so $1,080, exactly the annual price.
• Break-even churn, gross profit. The same idea applies to gross profit: an annual customer earns $1,080 - 12 x $30 = $720, a monthly customer earns $70 a month while active, so 70 x (1 - (1 - c)^12) / c = 720, which gives 2.85%. Between 1.94% and 2.85% churn, annual collects more cash but earns less gross profit (at 2% the table above shows +$1,433 cash and -$13,397 gross profit); above 2.85% annual wins on both. 'Pays' therefore means different things at different churn rates, which is why the two measures are kept apart.

Sensitivity to the assumption the result is most sensitive to (monthly churn): from the output, annual minus monthly cash is -$35,018 at 0.5% churn, -$22,461 at 1%, +$1,433 at 2% and +$44,710 at 4%; gross profit difference is -$38,912, -$30,122, -$13,397 and +$16,897.

The customer's side

Prepaying costs $980 more up front than paying the first month ($1,080 vs $100) and saves $100 in each of the next 11 months ($1,100). That is an implied return of 1.98% a month, about 26.5% a year compounded (1.0198^12 = 1.265). Hand check: the monthly rate r is the one at which 100 x (1 - (1 + r)^-11) / r = 980. At r = 2% the left side is 978.7, just under 980, so r is slightly below 2%, and 1.98% gives 979.8. The cost of money is the return the customer could earn or save by holding the cash elsewhere, such as the interest on a loan or a line of credit. If the customer's cost of money is lower than that and they are confident they will keep the product, annual is rational; a customer who is unsure should stay monthly. The annual offer also sells risk transfer: they accept a 12-month lock-in in return for the discount.

A caution on who takes the offer

The model assumes annual takers resemble everyone else. In reality customers who choose annual are the loyal ones who would have stayed anyway, so the discount is partly given away, and the true effect is worse than the table. Measure take-up by cohort (a group of customers who joined in the same period) and compare churn of annual versus monthly cohorts, and keep the discount at a level that buys real behaviour change (for example, convert customers in their highest-churn months, or offer it only at renewal).

Usage-based monthly invoicing for larger customers

Usage-based billing charges for what is consumed and invoices after the month ends (in arrears).

Cash timing comes from simple arithmetic: with service spread evenly across the period, the average service day is mid-period, so prepaying 360 days means cash arrives about 180 days early; usage is billed at month-end and paid 30 days later, about 15 + 30 = 45 days after the average usage day. For a customer using $1,500 a month, up to about $3,000 is outstanding at any time. My recommendation for larger customers: a committed annual minimum billed in advance, with usage above the commitment billed monthly in arrears, and credit checks and payment-term limits for the arrears part. Model the customer's cost under usage in a spike month so they do not face bill shock (a surprisingly large invoice that damages trust).

Trade-offs and pitfalls

• Mixing bases: compare monthly vs annual on cash, gross profit and ARR separately, never one against another.
• Do not call the discount a cost-free financing source: it costs the equivalent of the customer's 26.5% return.
• Ignoring renewal: annual customers face a renewal decision once a year, so renewal management matters more.

Direct answer

I would price on value first, using the module's measurable labour savings as the anchor, and use the other two approaches as guard rails: cost-plus sets the floor (the price must clear the cost to deliver at a healthy gross margin, meaning revenue minus cost to deliver, as a share of revenue) and the competitive alternatives and the buyer's do-nothing option (keeping the manual process and buying nothing) set the ceiling the market will accept. The price is a share of the value delivered, so the buyer keeps most of the benefit. I would offer three tiers sized by volume: Departmental, Business Unit and Enterprise-wide.

How the three approaches compare for enterprise deals

Worked example: deciding the price

Suppose the module automates document handling. A reference buyer processes 12,000 documents a month. Discovery with customers suggests each document takes 6 minutes less, and a loaded labour cost (salary plus overheads) is $45 an hour. These are assumptions to confirm in a pilot.

• Time saved: 12,000 x 6 minutes = 72,000 minutes = 1,200 hours a month
• Monthly value: 1,200 x $45 = $54,000
• Annual value: $54,000 x 12 = $648,000
• Price at a 20% share of value: 0.20 x $648,000 = $129,600 a year, so the buyer keeps $518,400 and pays back in $129,600 / $54,000 = 2.4 months

Cost check: if serving one document costs $0.25 (illustrative), 12,000 documents a month for 12 months is 144,000 documents, so $36,000 a year, which is about 28% of the price, leaving a gross margin of about 72%. Competitive check: what the buyer would otherwise pay (more headcount, or a rival tool) must sit above $129,600 for the case to hold.

How I choose the share. The 20% is not a rule of thumb. It answers two questions. First, how much value must the buyer keep for the business case to survive their finance review? At 20% the buyer keeps $518,400 and gets $5.00 back for every $1.00 spent ($648,000 / $129,600), a case that finance can approve without a long debate. Second, what do the alternatives allow? If the buyer's best alternative costs $200,000 a year, $129,600 is below it and the module also wins on price. If the alternative costs $110,000, a 20% share is above the ceiling, so the share must fall to about 17% ($110,000 / $648,000) or the premium must be justified by differentiation. So I start at 20% as a working position, test 15%, 20% and 25% in pilots, compare win rate and the discount requested, and keep the share that earns the most per deal won while staying above the cost floor. Enterprise-wide gets 15% because a larger absolute price ($324,000) draws procurement scrutiny and more of the estimated value is uncertain, so the buyer needs a bigger margin of safety.

The three tiers

The Enterprise value is 40,000 x 6 / 60 = 4,000 hours a month x $45 x 12 = $2,160,000, and 15% of that is $324,000. Payback is 2.4 months for the first two tiers and 1.8 months for Enterprise-wide ($324,000 / $180,000 monthly value). The volume discount costs margin but stays above the floor: serving 40,000 documents a month at $0.25 is $120,000 a year, 37% of $324,000, a gross margin of about 63% against 72% for Business Unit.

Sensitivity: what the price depends on most

The result is most sensitive to minutes saved per document. If the real saving is 3 minutes, not 6, the Business Unit value halves to $324,000 and the same $129,600 price captures 40% of it, with payback stretching to 4.8 months. So I would sell with a pilot that measures the saving on the buyer's own documents, and price against the measured number.

Pitfalls

• Quoting the buyer's whole saving as the price. The buyer must keep most of it or the deal does not clear their internal hurdle.
• Ignoring discounting behaviour in enterprise deals: set the tier prices so a discount still clears the cost floor.
• Counting savings that are not cashable (they do not reduce what the buyer actually spends), such as freed hours that are never redeployed.

Direct answer

I would not flip the whole book. I would run a capped pilot with two or three customers where the savings are already measured, price it as a share of independently verified savings with a floor (our minimum fee, covering cost to serve) and a cap, and keep per-seat as the fallback. Outcome-based pricing only works where the outcome can be measured, attributed to the product and audited by someone the customer trusts.

Pilot selection

Pick customers on measurability, not on enthusiasm:

• The savings metric is one the customer already tracks in its own system of record (its authoritative database, such as the finance ledger or cloud bill) (for example cloud spend per workload, handling cost per support ticket, scrap rate), with at least 12 months of history.
• Our product is the dominant cause of change. A customer running three other cost programmes at once makes attribution impossible.
• A named finance owner on their side agrees to the measurement method, not only the business sponsor.
• Low seasonality or a volume driver we can normalise (adjust for, so growth is not mistaken for savings), such as cost per unit of work rather than total cost.
• Enough expected savings that the fee is mostly the variable share, not the floor (see the worked example).

Contract terms

• Baseline: trailing 12 months, expressed per unit of workload so growth or a bad quarter does not look like savings or losses. The normalisation formula is written into the contract. Example (illustrative): baseline cloud spend is $4,800,000 over 1,200,000 jobs, so $4.00 per job. In the contract year the customer runs 1,500,000 jobs and spends $5,200,000, which is $3.4667 per job. The clause reads: verified savings = (baseline cost per unit minus actual cost per unit) x actual units = ($4.00 - $3.4667) x 1,500,000 = $800,000. Equivalently, expected spend at the old rate is 1,500,000 x $4.00 = $6,000,000, less actual $5,200,000. Total spend rose $400,000, yet verified savings are $800,000, and the fee at a 25% share is $200,000, today's per-seat amount.
• Fee: a percentage of verified savings, plus a floor and a cap per year. The floor covers our cost to serve; the cap makes the customer's maximum bill knowable.
• Measurement period and true-up: monthly estimate, quarterly true-up (a settlement that corrects the monthly estimates to the final verified figure), annual reconciliation.
• Exclusions: savings from supplier price changes, reorganisations or one-off write-offs do not count.
• Data rights and dispute path: we get read access to the source metric; disputes go to the customer's finance owner and ours, then to a named third-party verifier.
• Exit: either side can revert to per-seat at renewal, so the pilot is reversible.

How savings are measured and audited

1. Compute savings from the customer's source of record, not from our own telemetry, so we cannot be accused of grading our own homework.
2. Where possible keep a counterfactual (what would have happened without our product): a group of workloads or sites not onboarded, so savings are the difference against a live comparison group, not against a historical guess.
3. Share the calculation on a dashboard both sides can open, with the formula visible.
4. Allow an independent verifier to re-perform the calculation once a year or on dispute.

Who carries which risk

Internal incentives

• Sales compensation: paying commission on forecast savings rewards optimistic baselines. Pay on the contracted floor at signature and the remainder as verified fees are collected.
• Customer success and solution architects: measure them on verified savings delivered, so they steer the customer toward the outcome, not toward seat count.
• Finance: the fee is variable and uncertain, so revenue timing and any limit on recognising it need review with finance before the first contract is signed (under revenue accounting rules such as ASC 606, estimates of variable consideration, meaning revenue whose amount is not fixed at signing, are generally recognised only to the extent a reversal is unlikely; confirm the treatment with the finance team).
• Existing seat revenue: decide up front whether pilot customers' per-seat revenue is replaced or protected, otherwise account teams will refuse to nominate good customers.

Worked example

Illustrative deal: today the customer pays per-seat, 200 seats at $1,000 a year, which is $200,000 a year. Proposed outcome fee: 25% of verified savings, floor $100,000, cap $400,000 a year.

SHARE, FLOOR, CAP = 0.25, 100_000, 400_000   # 25% of verified savings, floor and cap per year
SEAT_PRICE, SEATS = 1_000, 200               # today's per-seat deal: $200,000 a year

def fee(verified_savings):
    return min(CAP, max(FLOOR, SHARE * verified_savings))

print("Per-seat deal:", SEATS * SEAT_PRICE)
for savings in [200_000, 400_000, 1_000_000, 1_600_000, 2_400_000]:
    f = fee(savings)
    print(f"verified savings {savings:>9,}  fee {f:>9,.0f}  customer keeps {savings - f:>9,.0f}")

Output:

Per-seat deal: 200000
verified savings   200,000  fee   100,000  customer keeps   100,000
verified savings   400,000  fee   100,000  customer keeps   300,000
verified savings 1,000,000  fee   250,000  customer keeps   750,000
verified savings 1,600,000  fee   400,000  customer keeps 1,200,000
verified savings 2,400,000  fee   400,000  customer keeps 2,000,000

Reading it: the fee equals today's $200,000 when verified savings are $800,000 (25% of $800,000). At $1,000,000 of savings we earn $250,000 and the customer keeps $750,000. At $200,000 of savings the floor lifts our fee to $100,000, which is 50% of the savings, so the floor must sit well below what the customer expects to save or they will reject it. At $2,400,000 the cap binds and we leave money on the table in exchange for the customer's confidence.

Trade-offs and pitfalls

• Revenue per customer swings from $100,000 to $400,000 in this example against a flat $200,000, so forecasts need ranges (revenue is lumpy: uneven from period to period).
• Both sides are tempted to argue about the baseline. Writing the formula before the first dollar of savings exists is the single most valuable step.
• Where the metric cannot be audited, do not use this model. A hybrid (smaller seat fee plus a gain share, where the vendor takes a share of savings) is the fallback.
• I would stop the programme if verified savings keep landing below $400,000 (the point where the floor starts to bind in this example) or if baseline disputes consume more account-team time than the fees justify.

Direct answer

As posed, the customer already owns the $300,000 licence, so that money is spent whichever option they pick (a sunk cost) and the real comparison is $60,000 a year of maintenance against $120,000 a year of subscription. Over the three-year term the vendor collects $180,000 under maintenance and $360,000 under subscription, so the subscription brings the vendor $180,000 more revenue and cash, and costs the customer $180,000 more (PV at a 10% discount rate: $164,132 against $328,264). I would advise this customer to stay on maintenance unless the subscription adds something the licence does not (hosting, new modules, more users), because the extra $60,000 a year otherwise buys nothing they lack. The vendor's reason to propose it is the extra revenue, and the customer will see that.

For a buyer choosing from scratch between the $300,000 licence plus maintenance and the subscription, the picture is the opposite. Over three years the perpetual option brings the vendor $480,000 and the subscription $360,000, so subscription is $120,000 lower in nominal terms (face-value dollars, not discounted) and the vendor's year-1 cash is weaker. For that customer, subscription costs $120,000 less over three years. The two break even at five years of use (undiscounted), and about seven years at a 10% discount rate, assuming the subscription renews at $120,000 and maintenance stays at $60,000 after year 3. I would advise that new buyer to take subscription if they expect to use the product for fewer than about five years or value upgrades and flexibility, and perpetual if they will run it unchanged for seven or more.

Vendor revenue and cash for the customer who already owns the licence

The licence payment is already in the past, so only the recurring payments differ.

The vendor gains $60,000 a year, and the customer pays it. The numbers below build the new-buyer comparison first, because it shows how the two options behave over a long horizon.

Definitions and assumptions

• Perpetual licence: a one-time payment of $300,000 for the right to keep using the software, plus maintenance (support and updates) of $60,000 a year.
• Subscription: $120,000 a year for three years, with support and updates included.
• Assumptions: all payments are made at the start of each year; maintenance starts in year 1; the same product and support are delivered in both options; the discount rate is 10% a year (illustrative), used to compare cash at different dates (present value, PV, is the value today of future cash).

Vendor revenue and cash over the term for a new buyer

Revenue equals cash here because everything is billed in advance and the term starts on the first day of the year. In practice the licence is generally recognised when delivered (a point in time) and maintenance and subscription over time, so in a mid-year start revenue and cash would differ; the finance team decides the treatment.

Computation

rate = 0.10  # illustrative annual discount rate

def perpetual_cash(years):
    # licence + first-year maintenance up front, then maintenance at the start of each later year
    return [300_000 + 60_000] + [60_000] * (years - 1)

def subscription_cash(years):
    return [120_000] * years

def pv(flows):
    return sum(f / (1 + rate) ** t for t, f in enumerate(flows))

for label, flows in [("Perpetual", perpetual_cash(3)), ("Subscription", subscription_cash(3))]:
    print(label, "cash by year start:", flows, "total:", sum(flows), "PV at 10%:", round(pv(flows)))

for years in range(1, 11):
    p, s = perpetual_cash(years), subscription_cash(years)
    note = ""
    if sum(p) <= sum(s): note += " <- undiscounted: perpetual now at or below subscription"
    if pv(p) <= pv(s): note += " <- discounted: perpetual now at or below subscription"
    print(years, "years: perpetual", sum(p), "subscription", sum(s), note)

# Customer who already owns the licence: only maintenance vs subscription is in play
print("Already-owned case, 3 years: maintenance", 3 * 60_000, "subscription", 3 * 120_000,
      "extra cost of subscription:", 3 * (120_000 - 60_000))
print("Already-owned case, PV at 10%: maintenance", round(pv([60_000] * 3)), "subscription", round(pv([120_000] * 3)))

Output:

Perpetual cash by year start: [360000, 60000, 60000] total: 480000 PV at 10%: 464132
Subscription cash by year start: [120000, 120000, 120000] total: 360000 PV at 10%: 328264
1 years: perpetual 360000 subscription 120000 
2 years: perpetual 420000 subscription 240000 
3 years: perpetual 480000 subscription 360000 
4 years: perpetual 540000 subscription 480000 
5 years: perpetual 600000 subscription 600000  <- undiscounted: perpetual now at or below subscription
6 years: perpetual 660000 subscription 720000  <- undiscounted: perpetual now at or below subscription
7 years: perpetual 720000 subscription 840000  <- undiscounted: perpetual now at or below subscription <- discounted: perpetual now at or below subscription
8 years: perpetual 780000 subscription 960000  <- undiscounted: perpetual now at or below subscription <- discounted: perpetual now at or below subscription
9 years: perpetual 840000 subscription 1080000  <- undiscounted: perpetual now at or below subscription <- discounted: perpetual now at or below subscription
10 years: perpetual 900000 subscription 1200000  <- undiscounted: perpetual now at or below subscription <- discounted: perpetual now at or below subscription
Already-owned case, 3 years: maintenance 180000 subscription 360000 extra cost of subscription: 180000
Already-owned case, PV at 10%: maintenance 164132 subscription 328264

In the perpetual rows above, the first payment of 360,000 is the $300,000 licence plus the first year's $60,000 maintenance; later years are maintenance only. The perpetual option is a front-loaded cash profile: 75% of the three-year cash (360,000 of 480,000) arrives in year 1, against one third for subscription.

What the vendor sees

• Year 1 cash is $240,000 lower with subscription ($360,000 vs $120,000), and over three years $120,000 lower.
• Year-by-year and cumulative cash differ. In each year from year 2 the subscription brings $120,000 against $60,000 of maintenance, so the perpetual option's lead in cumulative cash shrinks by $60,000 a year (from $240,000 after year 1). The lead disappears at year 5, when cumulative cash is equal at $600,000 each, and from year 6 the subscription's cumulative cash is ahead.
• A subscription also gives a renewal moment every year (more churn risk, and more upsell chances).

What the customer sees

• Three-year cost: $480,000 against $360,000, so subscription is cheaper by $120,000 (PV at 10%: $464,132 against $328,264, a gap of $135,868).
• Break-even: five years undiscounted, seven years discounted. After that perpetual is cheaper. Hand check of the three-year PV: perpetual = 360,000 + 60,000 / 1.1 + 60,000 / 1.21 = 360,000 + 54,545 + 49,587 = 464,132; subscription = 120,000 x (1 + 1/1.1 + 1/1.21) = 120,000 x 2.7355 = 328,264. At six years the perpetual PV (587,447) is still above the subscription's (574,894), and at seven years it is below (621,316 against 642,631), which is why the discounted break-even is seven years.
• A customer who already owns the licence compares only $60,000 a year of maintenance with $120,000 a year of subscription, which is $180,000 more over three years. For that customer I would recommend staying on maintenance unless the subscription brings something the licence does not (hosting, new modules, more users).

Advice

For a customer who already owns the licence, stay on maintenance unless the subscription adds real capability (the $180,000 gap over three years is the price of that). For a new buyer with an uncertain horizon, I would advise subscription: it is $120,000 cheaper over the term, lowers the upfront commitment and moves the risk of a poor fit onto the vendor. My assumption is that technology refresh cycles are often shorter than five years, which is a view and not a measured figure. I would flip to perpetual if the customer will run this stable system for seven or more years, has capital budget (money set aside for one-off purchases that stay on the books as an asset) but a squeezed operating budget (money for recurring running costs, which a subscription is charged to), or needs the software to run unchanged in a closed environment.

Pitfalls

• Comparing the three-year totals only is misleading: the perpetual option keeps delivering value after year 3, so the decision hinges on how long the customer will use it.
• Compare on the same basis: both options must be annual in advance, with the same support level.
• The most sensitive assumption is the use horizon; a shift from five to seven years changes the answer.