Audits · Checklist
MRR Accuracy Audit
Can you trust your MRR? Check subscription normalization, failed payments, refunds, and time handling.
About this audit
Most SaaS dashboards show a single MRR number with no indication of how reliable it actually is. This audit walks through the specific places MRR calculations commonly go wrong — subscription normalization, discounts, failed payments, pauses, time zones, currency, and refunds — so you can see exactly where your number might be inflated, deflated, or just wrong.
Each item below is Pass, Warn, or Fail. Critical and Warning items affect your score; Recommendation items are best-practice suggestions that don't count against you. At the end you'll get a score, a breakdown by severity, and a concrete fix for anything that needs attention.
Subscription Normalization
Why it matters: MRR is meant to represent a stable monthly run-rate. Counting a $12,000 annual payment as $12,000 of MRR in one month, then $0 for the next eleven, makes MRR spike and crash in ways that have nothing to do with actual business performance.
Impact: Any month with a cluster of annual renewals shows artificial MRR growth, and NRR/GRR trends calculated from that inflated base become meaningless.
How to fix: Divide annual payments by 12, biannual by 6, and quarterly by 3, and recognize that normalized amount each month for the length of the contract.
Automated by Dnoise
Why it matters: Usage-based revenue is naturally variable month to month. Counting the full invoiced amount as MRR in a single month overstates volatility and makes the trend line noisy and hard to act on.
Impact: MRR appears far more volatile than the underlying business actually is, which can trigger false alarms or mask genuine trend changes.
How to fix: Use a trailing average (commonly 3 months) of usage-based revenue to smooth the monthly MRR contribution from metered charges.
Manual
Why it matters: MRR is specifically a recurring revenue metric. A fee that's billed once and never again is not recurring by definition, and including it overstates the durable revenue base.
Impact: A single large onboarding fee can distort MRR for the month it's billed, and any growth-rate calculation based on that month will be inflated.
How to fix: Route one-time fees to a separate Non-Recurring Revenue line item, entirely outside the MRR calculation.
Automated by Dnoise
Why it matters: A negative recurring amount usually signals a data or integration bug — a credit or adjustment misclassified as a subscription, rather than a genuine plan.
Impact: Negative amounts silently reduce your total MRR without a clear, auditable reason, making the topline number harder to trust.
How to fix: Audit any subscription object with a negative recurring amount and reclassify it as a credit, refund, or adjustment outside the MRR calculation.
Manual
Why it matters: Duplicate subscriptions are usually the result of a failed upgrade/downgrade flow or a billing system bug, and they double-count revenue that doesn't actually exist.
Impact: MRR is overstated by the value of every duplicate subscription until it's caught and merged or cancelled.
How to fix: Run a periodic check for customers with multiple active subscriptions on the same product and consolidate or cancel duplicates.
Manual
Discounts & Coupons
Why it matters: A customer paying nothing is contributing nothing to recurring revenue, regardless of what plan they're nominally on. Counting their list price inflates MRR with revenue that doesn't exist.
Impact: MRR can be significantly overstated on any business running free promotions, lifetime deals, or 100%-off campaigns at scale.
How to fix: Calculate MRR from the actual amount billed after discount, not the plan's list price.
Automated by Dnoise
Why it matters: If MRR keeps counting the discounted rate after the discount has actually expired and full billing resumed, the reported MRR understates real revenue from month 4 onward.
Impact: Growth appears understated for customers who've graduated off a promotional rate, masking real expansion.
How to fix: Track discount end dates and recalculate the customer's MRR contribution at full price starting the billing period after expiry.
Manual
Why it matters: Without tracking expiration dates, discount reverts have to be caught manually or not at all, which is how the previous issue (stale discounted MRR) tends to happen in the first place.
Impact: No immediate MRR distortion by itself, but it's the root cause that makes the discount-revert issue likely to occur and hard to catch.
How to fix: Store coupon/discount end dates alongside the subscription so reverts can be automated or at least flagged for review.
Automated by Dnoise
Failed Payments & Dunning
Why it matters: A failed payment means the business hasn't actually collected that revenue yet. Counting it as clean MRR overstates cash actually flowing into the business.
Impact: This is one of the largest and most common sources of MRR inflation — most billing dashboards count subscriptions as active right up until full cancellation, ignoring the failed-payment period in between.
How to fix: Exclude subscriptions in a failed-payment state from clean/active MRR, and track them separately as at-risk revenue.
Automated by Dnoise
Why it matters: A subscription in dunning has an uncertain outcome — it may recover or it may churn. Treating it identically to a healthy subscription hides that uncertainty from anyone reading the MRR number.
Impact: Reported MRR includes revenue that has a real chance of disappearing within days, without any visibility into how much of the total is at risk.
How to fix: Tag dunning-state subscriptions separately and report an 'at-risk MRR' figure alongside clean MRR.
Automated by Dnoise
Why it matters: An invoice being issued doesn't mean cash has been collected. Counting pending invoices as revenue conflates billing activity with actual cash collection.
Impact: MRR can appear higher than the cash the business has actually received in the period.
How to fix: Only count invoices with a paid status toward clean MRR; track pending invoices as a separate collections metric.
Manual
Pause & Grace Periods
Why it matters: A paused subscription isn't generating revenue during the pause — including it overstates how much recurring revenue is actually being collected right now.
Impact: MRR is overstated by the value of every currently-paused subscription, and the overstatement grows if pausing is a common feature usage pattern in your product.
How to fix: Exclude paused subscriptions from Active MRR and track them as a separate 'paused' bucket.
Automated by Dnoise
Why it matters: A grace-period subscription is functionally the same risk category as one in dunning — the customer hasn't successfully paid, they're just still being given access while recovery is attempted.
Impact: MRR includes revenue from customers who may not actually convert back to paying, without flagging that risk anywhere in the reported number.
How to fix: Flag grace-period subscriptions as at-risk MRR, separate from confirmed clean MRR, the same way dunning subscriptions should be handled.
Automated by Dnoise
Time & Currency
Why it matters: Stripe stores all timestamps in UTC. If a calculation converts to local time before grouping transactions by month, transactions near month boundaries can be attributed to the wrong month.
Impact: MRR shows unexplained bumps or dips in the first few days of each month that have nothing to do with actual customer behavior — just timezone math.
How to fix: Standardize all timestamps to UTC before any date-based grouping or calculation, and never mix UTC and local timestamps in the same dataset.
Automated by Dnoise
Why it matters: A transaction at 11pm UTC on the 31st can fall in a different calendar month depending on which timezone is used to define the month boundary — this is a specific, common case of the broader UTC issue above.
Impact: For a business processing hundreds of transactions a day, timezone misalignment at month boundaries can shift dozens of transactions between reporting periods.
How to fix: Define every month boundary as 00:00:00 UTC on the first of the month, applied consistently across all historical and current data.
Automated by Dnoise
Why it matters: If some transactions use a spot rate and others use a fixed or stale rate, MRR combines dollar amounts that aren't actually comparable, distorting the total in ways that are hard to detect.
Impact: Reported MRR growth or decline can partly reflect currency fluctuation rather than real business change, especially for businesses with meaningful non-USD revenue.
How to fix: Document and consistently apply one exchange rate methodology (e.g. rate on the transaction date) across all currency conversion in the MRR calculation.
Manual
Why it matters: Adding $1,000 and €1,000 as if they were the same unit produces a number that doesn't correspond to any real amount of money.
Impact: The topline MRR figure is mathematically meaningless for any business with multi-currency revenue if this isn't handled.
How to fix: Convert every non-base-currency amount to your base currency before summing into a single MRR total.
Automated by Dnoise
Refunds
Why it matters: A refund is a real cash outflow. If it's not reflected in Net Revenue, the reported number overstates money the business actually keeps.
Impact: Net Revenue is overstated by the value of unaccounted refunds, which compounds if refund volume is meaningful relative to total revenue.
How to fix: Subtract refund amounts from Net Revenue in the period the refund is processed, not the period the original charge occurred.
Automated by Dnoise
Why it matters: A partial refund reduces revenue by exactly the refunded amount — treating it as a full cancellation removes far more revenue from the calculation than actually left the business.
Impact: Revenue and churn figures can both become inaccurate: revenue is understated by more than the real refund, and the customer may incorrectly appear as churned.
How to fix: Reduce Net Revenue by exactly the partial refund amount, and keep the underlying subscription's status unchanged if the customer remains active.
Manual
Audit Trail
Why it matters: Without event-level traceability, verifying an unexpected MRR movement means manually reconstructing what happened from raw billing data — slow, and hard to defend during an audit or investor due diligence.
Impact: No direct impact on the MRR number itself, but it significantly slows down catching and explaining any of the other issues in this audit when they occur.
How to fix: Log the specific Stripe event ID responsible for every MRR-affecting change (new subscription, cancellation, upgrade, etc.) alongside the change itself.
Automated by Dnoise
Why it matters: Reactivated customers typically have lower acquisition cost and different behavior than genuinely new customers — mixing them into New MRR overstates new customer acquisition efficiency and hides whether a win-back motion is working.
Impact: New MRR appears larger than genuine new-customer growth actually is, and CAC calculated from that inflated New MRR looks artificially efficient.
How to fix: Identify customers with a prior cancelled subscription and route their re-subscription revenue to a distinct Reactivation MRR line item.
Automated by Dnoise
Frequently Asked Questions
How is the MRR Accuracy score calculated?
Each Critical item is worth 5 points and each Warning item is worth 3 points, toward a maximum built from all Critical and Warning items in the audit. Passing an item awards full points, Warn awards half, Fail awards zero. Recommendation items are shown for guidance but don't affect the score.
Is my audit data saved anywhere?
Your answers are stored only in your browser's local storage, not on our servers. Closing the tab keeps your progress; clearing your browser data will reset it. Nothing here requires an account.
What's the difference between Warning and Recommendation?
Warning items are real issues that distort MRR if left unaddressed, just less severe than Critical ones. Recommendation items are best practices — skipping them doesn't produce an inaccurate MRR number, they just make your process more robust and auditable.
Want this checked automatically, every month?
Connect Stripe in read-only mode and Dnoise flags these issues automatically — no manual audit required.
Connect Stripe — free →