Pricing simulation

The pricing simulation answers "how much should I charge for a subscription, and how many customers do I need?". It compares several pricing strategies side by side and shows, for each, what one customer earns, how many customers cover the costs, the month the business makes a profit, the month the money spent is earned back and how much money is needed until then. This page gives every formula it uses, what each symbol means, when the formula holds and a worked example.

How to read this page. Each formula is shown on its own line, followed by a table of its symbols with their units, the conditions under which it holds, what it says in plain words and a short example. All examples use the same small business, described next, so the numbers carry over from one formula to the next. The figures in the examples were produced by the platform's own engine.

The example business

A consumer app sells a subscription for €20 a month. Customers can also pay weekly or quarterly. Running the app costs €3,000 a month (the team), plus €2 a month for every paying customer (AI usage). Building it cost €10,000 before launch. The payment provider takes 3 % of every charge plus €0.25 per charge. Winning one customer costs €30 in marketing. In the first month 20 people sign up, 5 % more each month after that, and 6 % of customers cancel every month.

Inputs

These are the values a person (or the assistant on their behalf) gives. Every other quantity on this page is calculated from them.

A share is a number between 0 and 1: 0.06 means 6 %. Months are numbered from 1, the first simulated month, up to the horizon H (6 to 60 months, 36 by default).

Scenarios. Each strategy is calculated in three cases. The case changes three inputs before anything else is calculated: new sign-ups are multiplied by a factor f_N, churn by a factor f_c, and a number \Delta g is added to growth. The defaults are Conservative (f_N = 0.6, f_c = 1.3), Base (no change) and Optimistic (f_N = 1.4, f_c = 0.8, \Delta g = +0.01). A case whose churn would reach 100 % is refused.

Cost lines

Every cost is a line with a name, a category (Marketing, Personnel, Infrastructure, ... or the user's own), an amount and an active period: fromMonth and toMonth (inclusive, month numbers with 1 = the first simulated month, or YYYY-MM). A line without fromMonth starts in month 1; without toMonth it is ongoing. A 60 EUR campaign for the first two months is {fromMonth: 1, toMonth: 2}, so F_1 and F_2 include it and F_3 does not. A one-time line with fromMonth is paid in that month (part of O_t) instead of up front (part of I).

In plain words. Each month's costs are the lines that are switched on in that month, added up.

Where this page writes F and V without a month, it means the lines still active in the last simulated month: the cost base the business settles at. The per-customer figures below use them.

costChanges edits single lines without resending the lists: add, update or remove a line by name (case does not matter; a unique partial name also matches), with months as a duration from the start month. The assistant's finance.update_pricing_costs tool sends these; the canvas's cost table sends the edited lists. Lines carry their own placeholder flag, so editing one illustrative line leaves the others marked.

Pricing strategies

A strategy is one set of plans a customer can choose from. Given only a monthly price, the weekly and quarterly plans are derived from it and the global billing mix applies. When a strategy states a weekly or quarterly price, only the plans it names (plus the monthly plan) are offered and the global mix is shared out over them, unless the strategy gives its own mix. addPricePoints adds strategies next to the existing ones (a strategy with the same name replaces the old one; placeholder prices are dropped once the user gives a real one); at most six are kept.

Per customer

These formulas describe one average paying customer once the business has settled. They do not depend on the month.

Weekly and quarterly prices

In plain words. A weekly payer pays the monthly price plus the weekly premium, spread over the 4.33 weeks of an average month. A quarterly payer pays three months at once, minus the discount.

Valid when. The strategy gives only a monthly price. When it states a weekly or quarterly price, that price is used as it is and these formulas are skipped.

Example. P_w = 20 \times 1.1 / 4.33 = €5.08 a week; P_q = 3 \times 20 \times 0.9 = €54 a quarter.

Billing mix of a strategy

In plain words. When a strategy offers only some plans, customers who would have chosen a missing plan are shared out over the offered ones in proportion to the global mix, so the shares still add up to 1.

Valid when. The strategy states its own weekly or quarterly price and gives no mix of its own. With only a monthly price the global mix applies unchanged; with its own mix, that mix applies.

Example. A strategy with monthly and quarterly plans only: m_m' = 0.55 / 0.75 = 0.733 and m_q' = 0.20 / 0.75 = 0.267.

Average revenue per paying customer

In plain words. Each plan's price is turned into a monthly amount, and the three are averaged with the share of customers on each plan as weights.

Valid when. The mix adds up to 1. Quarterly payments count as revenue spread evenly over the quarter, not as cash on the day of payment; that is slightly conservative because it ignores the benefit of being paid early.

Example. A = 0.25 \times 5.08 \times 4.33 + 0.55 \times 20 + 0.20 \times 54/3 = 5.50 + 11.00 + 3.60 = €20.10.

Payment fees per customer

In plain words. The provider takes a share of every euro charged plus a fixed amount every time a card is charged. Weekly plans are charged more often, so they cost more in fixed fees.

Example. \chi = 0.25 \times 4.33 + 0.55 + 0.20/3 = 1.70 charges a month, so \varphi = 0.03 \times 20.10 + 0.25 \times 1.70 = 0.603 + 0.425 = €1.03.

Margin per customer

In plain words. What a customer pays, minus what it costs to serve them and to take their payment. This is the money that pays for the fixed costs and for winning new customers.

Valid when. Always calculated. If M \le 0, every extra customer loses money; the platform then shows no break-even customer count and no "users needed" figure, because no number of customers can cover the costs.

Example. M = 20.10 - 2.00 - 1.03 = €17.07 per customer per month.

Customers needed to cover fixed costs

In plain words. How many paying customers you need at the same time for their margins to pay the monthly fixed costs.

Valid when. M > 0. It leaves out the cost of winning customers, so a growing business needs more customers than this to be profitable (see the next formula).

Example. C^{*} = 3{,}000 / 17.07 = 175.7 paying customers.

Lifetime margin of a customer

In plain words. If 6 % of customers leave each month, the average customer stays 1/0.06 = 16.7 months. Over that life they leave their monthly margin each month.

Valid when. 0 < c < 1 and churn is the same every month. Future money is not discounted, so for long customer lives this is optimistic. With c = 0 there is no finite lifetime value and the platform shows none.

Example. \mathit{LTV} = 17.07 / 0.06 = €284.53 per customer.

What a trial sign-up brings

In plain words. Every sign-up pays the trial price once, minus the payment fee on it, and uses the product for the trial days, which costs the running cost for that part of a month.

Valid when. The strategy has a trial. For a free trial (T = 0) there is no charge and so no fee, and \tau is just the negative running cost. Without a trial, \tau = 0, T = D = 0 and k = 1.

Example. A €3 trial for 7 days with 30 % conversion: \tau = 3 - (0.03 \times 3 + 0.25) - 2 \times 7/30.42 = 3 - 0.34 - 0.46 = €2.20.

Users needed per month

In plain words. This answers "how many users do I need a month?". Each sign-up becomes a paying customer with probability k; that customer then earns their lifetime margin minus what it cost to win them; the trial adds \tau. Enough sign-ups to cover the fixed costs every month is the answer.

Why it holds. When customer numbers settle, as many customers leave each month as join, so c\,C = k\,N and C = kN/c. Monthly profit is then C\,M + N(\tau - k\,\mathit{CAC}) - F = N\left(k\left(\frac{M}{c} - \mathit{CAC}\right) + \tau\right) - F, which is zero at N = N^{*}.

Valid when. c > 0 and the denominator is above 0. If each sign-up is worth less than it costs (the denominator is 0 or negative), no number of users covers the costs, and the platform shows no figure. The answer describes the long run: it says nothing about how long it takes to get there.

Example. Without a trial: N^{*} = 3{,}000 / (284.53 - 30) = 11.8 new customers a month, which settles at 11.8/0.06 = 196.4 paying customers. That is more than the 175.7 of C^{*} because the €30 to win each replacement customer must also be paid. With the €3 trial: N^{*} = 3{,}000 / (0.3 \times 254.53 + 2.20) = 38.2 sign-ups a month, settling at 190.9 paying customers.

Month by month

From here on the simulation runs month t = 1, 2, \dots, H and every quantity has a month index. The scenario factors are already applied to N_1, g and c.

Sign-ups and paying customers

In plain words. Sign-ups grow by the same percentage every month. Each month a share c of last month's customers leaves, and the sign-ups who convert join.

Valid when. Growth is steady. Sign-ups who convert count as paying from the month they sign up, and new customers do not churn in the month they join. Customers are expected values, so they can be fractional (59.46 customers means "about 59").

Example. n_1 = 20, n_2 = 21, n_3 = 22.05. Starting from no customers: C_1 = 20, C_2 = 20 \times 0.94 + 21 = 39.8, C_3 = 39.8 \times 0.94 + 22.05 = 59.46.

Revenue and profit

In plain words. Revenue is what paying customers pay plus the trial charges. Profit is each customer's margin, plus what the trials bring, minus the cost of winning the new customers, minus fixed and one-off costs.

Valid when. Always. Without dated cost lines it simplifies to \Pi_t = C_t\,M + n_t\,(\tau - k\,\mathit{CAC}) - F.

Example. Month 1: R_1 = 20 \times 20.10 = €402 and \Pi_1 = 20 \times 17.07 + 20 \times (0 - 30) - 3{,}000 = 341.44 - 600 - 3{,}000 = -€3{,}258.56. Month 2: \Pi_2 = 39.8 \times 17.07 - 21 \times 30 - 3{,}000 = -€2{,}950.53.

Cumulative cash

In plain words. Start at minus the up-front investment and add each month's profit.

Valid when. Always. Revenue is treated as cash in the month it is earned (no payment delays); that is a simplification the full forecast does not make.

Example. K_1 = -10{,}000 - 3{,}258.56 = -€13{,}258.56; K_2 = -13{,}258.56 - 2{,}950.53 = -€16{,}209.09.

Results

Break-even month and payback month

In plain words. Break-even is when a month pays for itself. Payback comes later: the losses of the months before break-even and the up-front investment must be earned back too.

Valid when. The month falls within the horizon; otherwise the platform says "not within the horizon". The first month that qualifies is taken, even if a later month dips below zero again (for example because of a one-off cost).

Example. Break-even in month 12, payback in month 25.

Money needed and return

In plain words. The money needed is how far cumulative cash falls before it turns around: the amount someone has to put in. The return compares the cumulative cash at a month with that amount.

Valid when. \mathit{Fund} > 0; with nothing needed there is no return to report. An ROI of 0 means the money has just been earned back; a negative ROI means it has not yet.

Example. Cumulative cash is lowest at −€29,229.70, so \mathit{Fund} = €29{,}229.70. \mathit{ROI}_{12} = -1.00 (nothing earned back yet), \mathit{ROI}_{24} = -0.04 (almost there) and \mathit{ROI}_{36} = 93{,}460.66 / 29{,}229.70 = 3.20: by month 36 the business has returned the money needed plus 3.2 times as much again.

Suggested price

In plain words. The lowest whole monthly price at which the base case pays back within the target (18 months by default). The platform tries prices one by one, starting at the running cost per customer rounded up, and keeps the plan structure of the newest strategy: its trial stays as it is, and the weekly and quarterly prices move with the monthly price. The suggestion is added to the comparison. The trace explains the newest strategy the user gave (or the suggestion while prices are still placeholders).

with P_0 = \max\left(1, \lceil V + f_0 \rceil\right), the running cost and fixed fee per customer rounded up.

Valid when. A price up to five times the dearest strategy, or €500 above the first price tried if that is higher, pays back in time; otherwise there is no suggestion. When even the lowest price tried pays back in time, the suggestion says so: costs and growth are then covered at any price, and the price should be chosen from what customers will pay.

Example. With the example business and only the €20 strategy, the suggestion is €27 a month: it pays back in month 18, while €26 takes until month 19.

Revenue table

Besides price strategies, a simulation can hold a revenue table (revenueStreams): one stream per source of revenue, such as a paid trial, a monthly or quarterly subscription, a one-off product or a free bonus. Together the streams form one more strategy (named revenuePlanName, default "Revenue plan") that is compared, charted, exported and reported like the others; it is the explained strategy unless another is picked. The engine code is calc/pricing_revenue.py; the Excel export repeats it with live formulas on the "Revenue plan" sheet.

New customers of a stream

In plain words. A stream people join directly follows its listed numbers and then grows. A stream fed by other streams (a subscription after a trial, say) takes a share of their new customers, possibly some months later.

Example. A €3 trial with 100 new customers listed and 5 % growth: 100, 105, 110.25. A monthly plan joined by 30 % of trial users in the same month: 30, 31.5, 33.08.

Active customers, charges and revenue

In plain words. A quarterly customer is charged when they join and again every three months, if they are still there, so the cash arrives when it is actually paid rather than spread over the quarter. Starting customers of a stream are charged in month 1.

Example. A €54 quarterly plan joined by 10 % of trial users one month later, with 5 % churn: new customers 0, 10, 10.5, 11.03, 11.58; charges 0, 10, 10.5, 11.03, and in month 5 the new customers plus the renewals of month 2, 11.58 + 10 \times 0.95^3 = 20.15, so revenue in month 5 is 20.15 \times 54 = €1{,}088.10.

Totals of the revenue plan

In plain words. Revenue is added up over the streams. The cost to win a customer applies only to customers who join a stream directly (a trial user who later subscribes was already paid for). Profit, cumulative cash, break-even, payback, money needed and ROI then follow exactly as for the price strategies. Churn is multiplied by f_c of the case (at most 0.99) and growth gets \Delta g.

The strategy's per-customer figures (revenue and margin per paying customer, customers to cover fixed costs) are read off the last simulated month. "New customers needed per month" holds today's mix of directly joined streams constant until customer numbers settle and asks how many cover the fixed costs.

Traceability

Every result carries a trace: one node per input and formula with its LaTeX formula, the same formula with this simulation's numbers, a plain-language explanation, the nodes it depends on and the matching Excel formula. The canvas draws the nodes as a diagram and renders the formulas with KaTeX. The Excel export (GET /pricing-simulations/{id}/export) uses named input cells (Price, Churn, FixedCosts, ...) so every derived cell is a formula a reader can follow and change. The Costs sheet lists every line with its category and months; each month's fixed and running costs are SUMPRODUCT formulas over the lines active in that month.

Versions

In an assistant conversation each request sends only what changed; the control plane merges it onto the latest version's input (objects merge, lists replace) and stores the result as the next version, with input hash, model and engine versions. Inputs the person supplied stop being flagged as placeholders. With "preview": true the result is calculated but not stored: the canvas recalculates live while the person edits the cost table and stores a version only when they save.

Saved simulations

Any version can be saved with a name, tags and a note (PATCH /pricing-simulations/{id}, from the canvas or the assistant's finance.save_pricing_simulation); "savedName": null removes it from the list. Saving never changes the calculation. GET /pricing-simulations/saved?q=&tag= lists the newest saved version per name with headline figures (strategy, new customers needed per month, payback, money needed), and the web app's Planning → Pricing simulations page opens one back in its conversation. "Continue from vN" copies an older version as the newest so the canvas and the assistant keep working from it.

Importing an export

Planning → Pricing simulations → Import from Excel or PDF rebuilds a saved simulation from a file the app exported (POST /pricing-simulations/import reads it and stores nothing; POST /pricing-simulations/import/save saves the checked input as version 1 of a new conversation, tagged "imported"). The engine's reports/pricing_import.py does the reading:

• Exports made since the import exists carry the full input (a hidden "Simulation data" sheet in the workbook, an attached simulation-input.json in the PDF), so they come back exactly, every strategy included.
• Older workbooks, in all three layouts so far, are read from their named input cells, the Costs sheet and the Model sheet's months; they rebuild the reported strategy to the cent. A workbook holds one strategy in one scenario, so the other strategies and the target payback are listed as missing, and scenario figures are turned back into base figures with the standard scenario factors.
• Older PDFs are read from their text with pypdf (best effort): every strategy compared, costs, fees, the assumptions and the placeholder list. Percentages are printed rounded, and a cost group with more than four lines comes back with its extra lines summed into one.

Whatever cannot be read is filled with the illustrative figures and flagged as a placeholder; the preview lists what was recovered, what is missing and any caveats before anything is saved.

Using a simulation in planning

POST /pricing-simulations/{id}/planning-preview lists, in plain words, what would be written to the planning inputs for one strategy and one case; POST /pricing-simulations/{id}/planning applies it (human only, edit_model) and creates a draft assumption set and a draft scenario, which it calculates. Nothing is approved.

Lines that are still placeholders are left unticked (the sign-up channel always stays, so the product gets customers). A revenue driver tied to a product feeds only that product's price plans, with the mix normalised within the product; channels without a product feed the plans of products that have no channel of their own (see forecast).

For developers

Sources: apps/finance-engine/src/finance_engine/calc/pricing.py (calculation and trace; _Unit holds the per-customer formulas, _project the month-by-month loop, _combo the results, _recommend the suggested price), calc/pricing_revenue.py (revenue table), reports/pricing_xlsx.py (Excel export with live formulas), apps/finance-control-plane/.../pricing/Pricing.kt (versioned storage and merging), apps/finance-mcp-server (finance.simulate_pricing) and the assistant canvas in apps/finance-web/src/app/pages/pricing-canvas.ts. All arithmetic is Decimal; results are rounded to cents (customers to 0.1, ratios to 4 places) only on output. Keep this page in sync with any change to those files.