ARPU Formula

ARPU  = MRR / paying customers          (per account)
ARPA  = MRR / accounts                 (same as ARPU in most B2B SaaS)
ARR per customer = ARPU × 12

LTV             = ARPU × gross margin / monthly churn
CAC payback     = CAC / (ARPU × gross margin)

Note the first line: in B2B SaaS the denominator is a customer account, not a person. "User" is a consumer-subscription term that survived into B2B usage; if one account has twenty seats, dividing by twenty produces a number that says nothing about pricing power. When the denominator really is individual users — a consumer app with per-seat billing — say so explicitly.

The denominator decides what the metric means. Three choices are common and only one is usually right:

• Paying customers at the start of the period — the standard. It matches the revenue base and is comparable with churn benchmarks, which also use an opening population.
• Paying customers at the end of the period — understates ARPU in a growing business, because revenue earned from customers acquired mid-period is divided by a larger closing count.
• All registered or active users — appropriate only for a freemium business that wants revenue per user across the whole funnel. It will be far lower than ARPU per payer, and mixing the two definitions in one trend line is meaningless.

Pick one, write it next to the number, and keep it for every period you report. A definition change is a restatement of history, not a new data point.

A product bills $99/month on the standard plan and $1,800/year on the annual plan. At the start of the month it has 320 monthly customers and 160 annual customers:

monthly plan MRR = 320 × $99        = $31,680
annual plan MRR  = 160 × $1,800 / 12 = $24,000
total MRR                             = $55,680
paying customers                      = 480
ARPU = $55,680 / 480                  = $116

The annual customers paid $288,000 in cash during the year, but their monthly revenue contribution is $150 each, not $1,800. Dividing cash collected by a monthly customer count is the single most common way ARPU gets inflated by a factor of twelve.

If the same product also has 1,200 free users and you want revenue per active user, the calculation is $55,680 / 1,680 = $33. Both figures are valid; they answer different questions and should never be plotted on the same line.

The two terms are often used interchangeably, and in most B2B SaaS they are the same number: revenue divided by customer accounts. The distinction matters when a business sells both to individuals and to companies:

• ARPU — revenue per user. Natural for self-serve and consumer products where one payer equals one user.
• ARPA — average revenue per account. Natural for B2B, where one account contains many seats and expansion shows up as a rising ARPA rather than a rising user count.

If you report ARPA, also state whether the account count includes free or trial accounts. An ARPA that quietly includes non-paying accounts is an ARPU with a misleading name.

Three adjustments keep ARPU comparable across periods:

• Annual and quarterly plans are normalised to a monthly figure (price ÷ 12 or ÷ 3). Annual prepayment improves cash flow but does not change ARPU; if cash is what you care about, that is a cash-collection metric, not ARPU.
• Usage-based and overage revenue is recurring and belongs in the numerator, but label it. A product whose ARPU grows only because of burst usage is different from one growing through price or seat expansion.
• Setup, onboarding and professional services fees are one-off. Either exclude them or report "ARPU including services" as a separate figure. Folding them in makes a single strong quarter look like a permanent pricing improvement.

ARPU is not an end in itself. It is the revenue input to the two unit-economics calculations investors actually ask about. At an 80% gross margin and 2% monthly churn, the arithmetic works out as follows — these are derived values, not survey data:

The point of the table is the sensitivity: doubling ARPU halves CAC payback and doubles LTV, while doubling CAC does the opposite. A small ARPU error therefore changes every downstream conclusion. Work through your own figures with the LTV:CAC calculator, or see the LTV:CAC guide for what the resulting ratio should be.

• Annual revenue divided by monthly customers. Inflates ARPU by up to twelve times. Normalise first.
• One-off fees in the numerator. Setup and services revenue makes ARPU jump in the month it is billed and fall back afterwards.
• All users in the denominator for a paid product. Free, trial and churned accounts drag ARPU down and make it look like a pricing problem when it is a definition problem.
• End-of-period counts. In a growing business this understates ARPU; in a shrinking one it overstates it. Use the opening count.
• Blended ARPU hiding segment collapse. If enterprise ARPU falls while self-serve grows, the blended average can rise. Segment by plan and by cohort before drawing conclusions.
• Mixing currencies. Convert everything to the reporting currency at a stated rate, or report each currency separately.

ARPU is an average, and averages hide distribution. The same $116 can come from 480 customers paying $116 or from 20 customers paying $2,500 and 460 paying $7. Only the per-plan breakdown tells you which business you have.