Average Revenue Per Account (ARPA): What It Is and How to Grow It

Your account count is climbing every month, but when finance closes the books, the average revenue per account line hasn't moved, or worse, it's slipping. That gap between "we're growing" and "we're not monetizing better" is exactly what average revenue per account (ARPA) is built to expose, and it's one of the few SaaS metrics that sits squarely between the product and pricing decisions a growth leader owns and the revenue reporting a finance leader has to defend.

Quick answer

Average revenue per account (ARPA) is a company's total recurring revenue divided by its total number of active accounts in the same period, usually expressed as monthly recurring revenue (MRR) per account.[1] It tells you how much value you're extracting per customer relationship, separate from how many customers you have, and it moves when packaging, pricing, and expansion decisions work (or don't).

What ARPA is and why it matters

ARPA is a deceptively simple ratio: recurring revenue over active accounts. The formula is ARPA = MRR ÷ total active accounts, and it can be annualized by substituting ARR for MRR.[1][2] What makes it useful isn't the arithmetic, it's what it isolates. Total MRR growth can come from two places only: more accounts, or more revenue per account. A company can add logos every month and still have a monetization problem if ARPA is flat or falling, because it means new revenue is arriving at a lower average value than the base it's diluting.

That distinction matters most to whoever owns pricing and packaging decisions, typically a product or growth leader, because ARPA is one of the clearest signals of whether those decisions are working. It matters to RevOps and finance too, since ARPA feeds directly into revenue forecasting and investor reporting. But it's rarely framed as a shared metric between the two functions, which is part of why it tends to get tracked inconsistently or not at all outside of a quarterly finance close.

How ARPA actually moves in a subscription business

A single blended ARPA number hides more than it reveals. Four distinct levers move it, and treating them as one number makes it hard to tell which lever is actually working.

Tier and packaging design

How you group features into plans determines what a typical account pays. A pricing ladder with too much value in the entry tier suppresses ARPA no matter how well sales performs, since customers have no reason to move up. This is a packaging decision, not a sales execution problem, which is why it usually sits with product and growth rather than with revenue operations.

Usage-based and bundled pricing

Accounts on flat, seat-based pricing generate the same revenue whether they use the product lightly or heavily. Layering in usage-based components or bundles ties revenue to actual consumption, which is one of the more direct ways to lift ARPA on accounts that are already expanding their usage. Revvly's usage-based pricing guide covers how this works mechanically for subscription businesses that don't want to rebuild their billing stack to support it.

Expansion execution (upsell and cross-sell)

Existing-account expansion, not new-logo volume, is usually the bigger ARPA lever once a company has scale. ChartMogul's own analysis of SaaS growth patterns found that for businesses with an ARPA above $1,000 a month, roughly 40% of revenue added comes from expansion rather than new business.[1] Net revenue retention and ARPA are closely related for exactly this reason. Our breakdown of what makes NRR compound over time is a useful companion read if expansion is the lever you're trying to pull.

Discounting and downgrade leakage

Every discount approved outside of a documented pricing policy, every downgrade that goes untracked, and every legacy grandfathered account quietly drags ARPA down. This lever doesn't show up as a dramatic single event, it shows up as a slow erosion that's easy to miss without segment-level tracking. Left unmanaged long enough, this is the same erosion covered in when to sunset grandfathered pricing.

Segment ARPA before you trust it

The single biggest mistake in reading ARPA is treating it as one number. Wall Street Prep's guide to the metric recommends splitting it into new ARPA (accounts acquired in the current period) and existing ARPA (the established base), specifically because blending the two can mask a real problem.[2] A company can show flat total ARPA while existing accounts are expanding nicely and new accounts are landing at a steadily lower price point, a pattern that only shows up once you segment.

Geckoboard's KPI documentation flags a related failure mode: ARPA can become a vanity metric on its own, since a handful of unusually large or small accounts can skew the average and produce a false read in either direction.[3] The fix in both cases is the same. Segment ARPA by plan tier, by cohort or signup vintage, and by region if you sell into multiple currencies, and read the blended number as a summary, not a diagnosis.

A short worked example, using illustrative figures, shows why this matters. Imagine a company with 500 accounts and $150,000 in MRR, a blended ARPA of $300. If 400 of those accounts are on a legacy tier averaging $200 and 100 are on a newer, usage-based tier averaging $700, the blended number tells you nothing about which segment is actually driving growth, or which one needs a packaging fix.

Why ARPA usually lives in a spreadsheet, and why that's a problem

For most subscription businesses, ARPA gets rebuilt manually at each finance close: export billing data, export the account list, join them in a spreadsheet, and segment by hand if anyone bothers. That workflow means the number a product or growth leader sees is already weeks old by the time it reflects a pricing change, and it's rarely broken out by tier or plan without a separate ad hoc request. That's a symptom of the fragmented-stack problem covered in our piece on the revenue stack: billing, plan/tier data, and revenue reporting living in three different places instead of one system that can compute ARPA by segment on demand.

A subscription intelligence platform that keeps modular pricing and revenue dashboards in the same system removes that lag. Because pricing changes, plan assignments, and usage-based charges all flow through the same billing layer, ARPA by tier, cohort, or region reflects the current state of the business rather than last quarter's export, and a pricing change shows up in the ARPA trend within the same billing cycle instead of at the next close.

A short evaluation checklist

Before you trust a single ARPA number, or evaluate whether your current tooling can track it properly, check whether you can answer these:

Why this is a shared metric, not a finance-only one

ARPA sits at an awkward organizational seam. Finance needs it for forecasting and board reporting. Product and growth teams make the packaging, tiering, and usage-pricing decisions that actually move it. When the two functions look at different versions of the number, usually because product is working from usage analytics and finance is working from a billing export, disagreements about whether a pricing change "worked" become disagreements about whose spreadsheet is right instead of a shared read on the same trend line. Closing that gap is less about picking a side and more about making sure both functions are reading ARPA off the same underlying billing and usage data, segmented the same way, updated on the same cadence.

Frequently asked questions

What is average revenue per account (ARPA)? ARPA is the average recurring revenue a company generates per active account, typically calculated monthly by dividing total MRR by the total number of active accounts.[1] It's sometimes used interchangeably with average revenue per user (ARPU), though the two can differ when a single customer controls multiple accounts.

How do you calculate ARPA? Divide monthly recurring revenue by the total number of active accounts in the same period: ARPA = MRR ÷ active accounts. Substitute annual recurring revenue for MRR to get an annualized figure.[2]

What's the difference between ARPA and ARPU? ARPA measures revenue per account, which fits B2B SaaS where one business customer is one account regardless of how many people use it. ARPU measures revenue per individual user, which matters more when a single customer purchases multiple seats or licenses and you want to know the per-seat economics.[1][2]

What is a good ARPA for a SaaS company? There's no universal benchmark, since ARPA is a function of your pricing model and target customer size, a company selling to small teams and one selling to enterprise accounts will have very different "good" numbers. Geckoboard's guidance is to track ARPA against your own historical trend rather than an industry figure, and to pair it with net revenue retention and account growth so you can tell whether it's moving for a healthy reason.[3]

Why would ARPA fall even while account count is growing? This usually means new accounts are landing at a lower average price than the existing base, dragging the blended number down even as total accounts and possibly total MRR rise. Segmenting into new-account ARPA and existing-account ARPA is the fastest way to confirm whether that's what's happening.[2]

How often should ARPA be recalculated? Monthly at minimum, aligned to your billing cycle, since that's the cadence most subscription businesses use for MRR itself. Companies making frequent pricing or packaging changes benefit from tracking it closer to real time, since a monthly-only view can hide the effect of a mid-cycle change for weeks.

Can Stripe alone track ARPA by plan or segment? Stripe's billing tools capture the underlying payment and subscription data, but segmenting that into new-versus-existing ARPA, or breaking it out by tier and region, typically requires exporting it into a spreadsheet or a separate analytics layer, since that segmentation isn't a built-in billing report.

Sources

1. ChartMogul, "Average Revenue Per Account (ARPA)," SaaS Metrics Library. https://chartmogul.com/saas-metrics/arpa/
2. Wall Street Prep, "Average Revenue Per Account (ARPA) | Formula + Calculator," updated September 17, 2024. https://www.wallstreetprep.com/knowledge/average-revenue-per-account-arpa/
3. Geckoboard, "Average Revenue Per Account (ARPA)," KPI Examples. https://www.geckoboard.com/resources/kpi-examples/average-revenue-per-account-arpa/

Frequently asked questions