ARR = eligible MRR × 12. You calculate annual recurring revenue by annualizing the monthly recurring subscription revenue eligible for inclusion at your reporting cutoff. It is a current annualized subscription run rate, not cash collected or guaranteed future revenue. Start with the recurring amounts actually in effect, rather than total invoices or contract values.
The practical work is deciding what belongs in that monthly base. Below, you'll see how discounts, effective plan changes, churn timing, and variable usage affect ARR calculation, how to keep one-time charges out, and how to reconcile your ending subscription snapshot with the movements in an ARR bridge.
Table of Contents
- What ARR Means for a Subscription Business
- The Core ARR Formula and a Worked Example
- Adjusting ARR for Discounts, Churn, and Mid-Cycle Changes
- Calculating ARR for Usage-Based and Hybrid Pricing
- Monthly vs Annual Calculations and the ARR Bridge
- Reporting ARR Without Misleading the Room
- Putting It All Together This Week
What ARR Means for a Subscription Business
A founder can open two dashboards and get two different answers because one screen shows this month's recurring billings and the other shows a broader run rate that includes contracts, renewals, and change events.
Annual Recurring Revenue, or ARR, is the annualized run rate of your eligible recurring subscriptions. The common shortcut is MRR × 12, as the ARR meaning guide from Creem shows, and it holds only when MRR follows the same eligibility rules and reporting cutoff.

ARR is not the same thing as total revenue on the income statement. GAAP revenue follows recognition rules, while ARR is a forward-looking operating metric for recurring subscription value.
That means ARR leaves out anything that does not describe the repeatable base you can plan around.
What ARR includes and excludes
Practical rule: a charge belongs in ARR when the customer has a current obligation to pay it again on a set cycle.
An active subscription still counts even if its next renewal needs a customer decision. A one-time service stays out, even if the same customer might buy it again.
| Charge type | In ARR? | Why |
|---|---|---|
| Active subscription fees | Yes | Recurring obligation on the current plan |
| Recurring seat or feature add-ons | Yes | Billed every cycle with the plan |
| Maintenance or support | Yes, when contracted to recur | A service, but it recurs by contract |
| Implementation, onboarding or consulting | No | One-time, even if bought again |
MRR is normalized across invoice frequencies, so an annual plan counts as one twelfth in every month, whichever month you invoiced it. Billing or collection timing moves invoice and cash totals while subscription MRR and ARR stay put.
Two dashboards agree only when both use the same active-contract base, effective prices and reporting cutoff.
Multiplying mismatched inputs by 12 just annualizes the mismatch, so fix the inputs and finance, sales, and the board can share one number.
For the retention side of the picture, Querio's guide to customer-success metrics is a useful companion once you have the ARR baseline right.
The Core ARR Formula and a Worked Example
The simplest way to calculate ARR is still the most common starting point, ARR = MRR × 12 as shown in Creem's ARR explainer. That shortcut works when your monthly recurring revenue is clean, stable, and stripped of non-recurring items. It gets dangerous when a month includes a large one-off deal, a temporary promotion, or a customer upgrade that hasn't fully settled yet.
The CFI reference illustrates a rollforward from opening ARR, with no separate renewal ARR term. That movement-based view differs from calculating a closing snapshot by summing each customer's ending recurring subscription amount. The point is not to make the model fancier, it's to make each movement visible so the board can see what changed.
A spreadsheet layout that holds up
For the bridge, start with opening ARR so every line is in annual units. Then separate the movements that changed that base during the month or quarter.
A clean worksheet usually has one line for the opening run rate and one line for each driver.
- Opening ARR: the annualized recurring base at the beginning of the period.
- New ARR: the annualized recurring value added by new customer contracts that started during the period, rather than their cash receipts or total contract value.
- Expansion ARR: the incremental annualized recurring value from upgrades, seat adds, or higher tiers—not the customer's full post-change subscription value.
- Churned ARR: the annualized recurring value lost when customers left during the period, measured when their recurring subscriptions ended.
- Contraction ARR: the annualized decrease in recurring value from downgrades or reduced usage floors, not the remaining value of those subscriptions.
That's the difference between a number that looks right and a number a CFO can defend. Founders who keep the change log clean usually spend less time reconciling the board deck at the end of the month.
Adjusting ARR for Discounts, Churn, and Mid-Cycle Changes
ARR moves when an account's effective recurring price, plan or active status changes. A discount is the gap between list price and what the customer actually pays each period.
A mid-cycle upgrade changes the run rate on its effective date, separately from the prorated invoice. Churn enters the bridge once, on the date service actually ends.
Discounts should be reflected at the actual transaction price, not the list price. If a customer signs a contract with a permanent discount, ARR should reflect the discounted recurring amount because that's the repeatable base. Temporary promotions are different. They belong in ARR only while the discount is active, then the run rate needs to be reset when the promotion ends.
A second example with real movement
Say a small SaaS company starts the month with three customers and $30,000 in recurring monthly revenue. One customer renews on an annual plan with a 20 percent discount off list price.
That discount alone doesn't tell you the account contracted. If they paid a discounted price last year too, the new effective price could be flat or even higher.
Another customer upgrades mid-cycle, and a third sends a cancellation notice before the next billing period. The month then works out like this:
Ending MRR = $30,000 + upgrade increment + discounted account's monthly price change − churn effective by the reporting cutoff.
To fill that in, you need these account-level inputs:
- Discounted account: its new effective monthly recurring price minus its prior one. A lower price produces a negative change.
- Upgrade: the monthly increment between old and new plan, and the date it took effect.
- Cancellation: the account's recurring amount and its service-end date.
The prorated charge on the upgrade invoice stays out of MRR. Only the new plan's recurring price, minus the old one, enters the run rate.
A cancellation notice changes nothing until service ends. If that date falls after the cutoff, the account stays in this month's base.
Then annualize ending MRR.
That's the main reporting trap in month-to-month ARR work. A team that books churn at the account level and again at the revenue line level will understate the base. A team that only records gross additions and forgets contraction will overstate it. The cleanest convention is to log every change once, at the moment the contract economics change, and keep the bridge consistent each month.
For teams that need a deeper operating lens on lost revenue and retention patterns, churn analysis from Creem is a natural next read if you're reconciling a messy customer book.
Calculating ARR for Usage-Based and Hybrid Pricing
Usage-based ARR calculation requires an estimate of repeatable consumption, not just an annualized bill. If you multiply one spiky month's usage by 12, you can overstate the business.
For predictable aggregate usage, Ordway's guidance describes GAAP-recognized usage revenue from the most recent quarter × 4 as the most common approach. Its alternatives include last month × 12 for stable usage and trailing twelve months for seasonal usage. These are usage-run-rate conventions, not a universally safer ARR rule.
Pick and disclose the method that fits your usage pattern. Label uncommitted recurring usage as an estimated run rate, separate from committed subscription fees and usage minimums. Every estimate still needs non-recurring charges excluded and unusual consumption assessed. For hybrid plans, count usage already covered by the base fee or committed minimum only once.

The reason is simple. ARR should represent repeatable run-rate revenue, not a lucky month of heavier consumption. Whichever estimation window you choose, exclude non-recurring charges such as onboarding fees and assess unusual consumption before annualizing it. A one-time overage spike should not inflate the estimated recurring usage line. For hybrid plans, count usage already covered by the base fee or committed minimum only once. The board should see the repeatable base and a clearly identified usage estimate, not a peak that won't repeat.
What belongs in the recurring base
Hybrid pricing usually has two parts, a seat-based subscription and a variable usage layer. The subscription piece is easy. The usage piece needs judgment, because some consumption is predictable enough to annualize and some isn't.
If the usage pattern is stable, add it as an estimated usage run rate next to the committed base. Usage already covered by the base fee or a committed minimum counts once, inside the base.
If it swings because of implementation, seasonality, or a one-off customer event, it belongs in a separate line.
A simple operating rule helps keep this clean:
- Include committed minimums: contracted floors and base platform fees. Stable usage above them goes in the estimated line.
- Keep the window consistent: use the same annualization method each reporting period so changes reflect usage rather than a switch in calculation.
- Exclude the spike: do not turn one unusual month into a year-long story.
- Keep onboarding separate: setup fees and similar charges should stay outside ARR.
For hybrid businesses, Creem's usage-based billing guide is useful when you need to keep the billing model and the finance model aligned. The board slide should show the recurring base clearly, and the working model can carry the extra detail underneath.
Monthly vs Annual Calculations and the ARR Bridge
Finance teams usually compute ARR every month even when customer contracts are annual, because the business changes monthly. Waiting until year-end hides churn timing, delays expansion visibility, and makes forecasting harder than it needs to be. Monthly ARR also gives you a clean bridge from one period to the next, which is easier for non-finance leaders to read than a block of raw invoices.
Reporting monthly doesn't change how a contract counts. Contract term and invoice frequency are separate from how often you report.
For an eligible fixed-price subscription, divide the effective recurring amount by the service term in months, then multiply by 12. One-time charges stay out.

An ARR bridge starts with opening ARR, adds new logo ARR and expansion ARR, then subtracts contraction and churned ARR. Every line uses annual units.
An unchanged renewal is already inside opening ARR. Only its price or scope change shows up, as expansion or contraction.
That format tells the story of the month in one view. Built properly, ending ARR matches the ending subscription base summed account by account.
Reading a bridge without overcomplicating it
Suppose you start the month at $600,000 ARR. You add new ARR from deals that went live this month, gain some expansion from existing customers, and lose some revenue to churn.
Deals signed but not yet live stay in a separate line until service starts.
The bridge should show each movement separately, not as one blended change. That way, sales can see whether growth came from new logos or existing accounts, and finance can spot whether churn is dragging the base.
A board member doesn't need a full contract dump. They need to know whether the business is growing because the top of the funnel is healthy, or because current customers are expanding fast enough to offset losses. The bridge answers that in one glance.
To turn the bridge into a growth rate, use ARR growth = (ending ARR − opening ARR) ÷ opening ARR × 100%.
Label the window as monthly, quarterly or year over year, and use the same ARR definition at both ends.
A positive rate doesn't prove retention is healthy. Expansion can cover heavy churn, so read the churn line before you trust the total.
If opening ARR was zero, the percentage is undefined. Report the absolute increase instead.
Build the bridge monthly, not quarterly. Waiting too long turns the story into a postmortem instead of a forecast tool.
A clean dashboard can do this without new software. The data already exists in the CRM, billing platform, and spreadsheet model.
For each account, pull the contract start and end dates, the effective recurring amount, and the date each change took effect.
If you use Creem, its metrics API returns gross monthlyRecurringRevenue in cents. Convert it to currency units, apply your ARR eligibility rules and annualize it. Keep fee-adjusted netMonthlyRecurringRevenue separate.
Then check that opening run rate plus the movements equals ending run rate, and that the rollforward matches the story your team tells out loud.
Reporting ARR Without Misleading the Room
Board conversations get messy when the ARR number is technically right but operationally confusing. The safest approach is to lead with one definition and footnote the exceptions.
Say exactly which subscriptions count, for example active contracted subscriptions at the cutoff date, excluding free trials.
If backlog, deferred revenue, or committed but not yet live contracts exist elsewhere in the model, keep them separate so nobody mistakes them for run rate.
The biggest reporting mistake is blending three measures that answer different questions:
- Subscription billings: what you invoiced in the period.
- Recognized subscription revenue: what you earned under accounting rules.
- ARR: the forward-looking run rate of the active subscriptions your policy counts.
If your usage estimate starts from recognized revenue, footnote it as a calculation input. ARR still is not GAAP revenue, and if you blur the lines, the room will spend the meeting untangling definitions instead of discussing the business.
When one line of the bridge looks weak, it tells you where to dig:
- Weak new ARR: look at acquisition and how many signups or trials convert to paid.
- Weak expansion ARR: check whether customers are adopting recurring add-ons and upgrades.
- Rising contraction ARR: find which accounts cut seats or moved to a lower plan.
- Rising churned ARR: read the cancellation reasons and split out subscriptions lost to failed payments.
Fix the business behind the movement. Changing the calculation rules to make a line look better only moves the problem into diligence.
Checks before an external update
- Confirm the definition: use the same ARR treatment every month.
- Separate backlog: don't fold unstarted contracts into run rate.
- Net out churn once: avoid counting the same loss in two places.
- Footnote discounts: show where permanent or temporary discounts change the base.
- Call out one-time fees: keep services, onboarding, and setup outside the figure.
If you want to automate the recurring model instead of maintaining it by hand, formula automation with GPT for Work can help teams speed up spreadsheet workflows. That still doesn't replace discipline, though. Automation only works when the source fields are clean and the finance team agrees on the rules.
The best board-ready ARR number is boring in the right way. It reconciles, it rolls forward cleanly, and it doesn't surprise anyone in diligence. If that's not true, the number may still be useful internally, but it isn't ready for the outside room.
Even then, it answers one question. ARR does not show cash you can spend, profit, or the revenue you will actually book next year, and each of those needs its own check:
- Cash: collections and payout timing.
- Profit: costs and margins.
- Forecasts: retention assumptions.
If you sell through a merchant of record, reconcile each transaction to its payout separately. Tax collected, platform fees and payout timing all change what lands in the bank, so payout totals never stand in for subscription run rate.
Putting It All Together This Week
Run the ARR check at your agreed reporting cutoff, once the period's billing and contract-change data has landed and before errors have time to hide.
Pull the latest dashboard, compare opening ARR to ending ARR, and make sure every new deal, upgrade, downgrade, and cancellation landed in one bucket only.
Then verify whether the model treated discounts, churn timing, and usage spikes the same way it did in the previous period.
The three decisions that matter most are simple. First, pick one ARR definition and keep it consistent. Second, separate backlog and one-time revenue from run rate. Third, review the ARR bridge before forecast updates, because the bridge usually reveals the problem before the final number does.
If you're using a spreadsheet-heavy process today, the fastest win is to clean the source fields before you add more formulas. Subscription billing, proration, effective plan changes, and automated receipts make reporting easier because the recurring base is captured closer to the transaction. If those records are already clean, fix a formula error in the model rather than replace your billing platform.
For teams that want a system built around that flow, Creem centralizes checkout, subscriptions, tax handling, and revenue tooling so ARR can be tracked alongside the subscription records that feed it. Its merchant-of-record role means it sells to buyers on your behalf and handles VAT, GST, sales tax, invoices, and chargebacks alongside billing.
Creem's metrics API supplies gross monthlyRecurringRevenue, netMonthlyRecurringRevenue after estimated fees, and active subscription counts; monetary fields are returned in cents. Convert eligible gross MRR to currency units, annualize it, and check the result against your ARR bridge. The API does not return a native ARR field. Use gross MRR for this article's subscription run rate and label any separately reported net measure. Your team still sets the ARR inclusion rules and reconciles the reporting cutoff.
Run Billing and ARR From the Same Records
For SaaS and AI teams selling worldwide, Creem is the legal seller on each sale. We collect and remit VAT, GST and sales tax for buyers in 190+ countries, and handle invoices and chargebacks. Subscriptions with trials, seat changes and dunning run alongside meters and prepaid credit wallets for usage pricing.
It's built for founders who want the recurring number to reconcile without manual cleanup, so your next board review starts with a figure you can defend.
The standard plan costs 3.9% + 40¢ per successful transaction, with tax, invoicing, compliance and dispute handling included. No monthly or setup fees.
Because Creem remits the VAT on each renewal, the subscription amounts in your records are revenue you can annualize, not tax you owe. Try Creem, and your first month of renewals is already an ARR base, with no tax lines to strip out.
