Why US State Taxes Distort Your SaaS Metrics
Sales tax on software subscriptions is now active in more than 30 US states, and the rates range from 2.9% in Colorado to over 9% in certain Tennessee jurisdictions. If you are calculating MRR directly from Stripe's charge totals without stripping tax, your reported revenue is higher than your actual recurring product revenue — and the distortion compounds every time you add customers in high-tax states.
This is not a compliance problem. It is a measurement problem. A founder reviewing month-over-month MRR growth might see a 4% increase and attribute it to a pricing change or a successful acquisition campaign. If that month also happened to see customer growth concentrated in Texas or New York — states with meaningful software tax obligations collected through Stripe Tax — a portion of that apparent MRR lift is tax pass-through, not revenue growth.
The fix is not complicated, but it requires deliberate separation: gross charge volume, tax collected on behalf of states, and net subscription revenue must be tracked as three distinct figures. Dnoise calculates each from raw Stripe events so the number you see in your MRR line is the number your accountant and your investors would agree represents actual product revenue. Every calculation uses a formula you can inspect — no normalization layer sits between your Stripe data and what Dnoise reports.
Tracking MRR Across US States Correctly
Knowing your total MRR is useful. Knowing which US states your MRR comes from tells you something operationally important: where your growth is concentrating, whether your pricing holds across different regional markets, and which customer segments are churning fastest. For a bootstrapped SaaS with 200–2,000 customers scattered across the country, this is often the first cohort cut that reveals a real pattern.
State-level MRR breakdowns from Stripe require matching subscription metadata against the billing address on each customer record. Dnoise does this automatically and surfaces the result as a readable breakdown — not as a raw export you paste into a spreadsheet. If a customer's billing address changes mid-subscription (common when a startup moves or a user updates their card), the attribution updates accordingly. Click any state's MRR figure and you see the individual Stripe subscriptions behind it.
If your business collects revenue in currencies other than USD from international customers alongside your US base, Multi-Currency Analytics in Dnoise handles the currency normalization separately, so your US-denominated MRR is never muddied by exchange rate movement on the same view. The two calculations stay clean and independent.
State-level concentration also matters for churn analysis. If your California MRR is holding while your New York cohort is churning at twice the average rate, that is a signal worth investigating — whether it points to a vertical, a pricing sensitivity, or a support gap. According to B2B SaaS Churn Benchmarks 2026, median monthly churn for SMB SaaS sits around 2–3%, but regional variance within a single product can swing well outside that band depending on customer mix.
See your US MRR broken down cleanly — tax stripped, state by state.
Dnoise connects read-only to Stripe and calculates from raw events. No spreadsheet. No data export. Setup takes under two minutes.
No credit card. Read-only access. Setup in 2 minutes.
Unit Economics That Hold Up Under Scrutiny
The unit economics that matter most for a US-market SaaS — LTV, CAC payback period, net revenue retention, and gross revenue retention — all depend on a clean MRR number as their foundation. If your MRR includes tax pass-through, every derived metric inherits the distortion. LTV gets inflated. NRR looks better than it is. CAC payback appears shorter than it actually is.
NRR above 110% is the benchmark that separates top-quartile SaaS businesses from the median, and it is the figure that sophisticated investors examine first in any fundraising conversation. But NRR is only meaningful if expansion MRR is calculated against a baseline that reflects true product revenue. A customer who upgraded their plan and whose state started collecting software tax in the same month will show an inflated expansion figure unless tax is stripped before the comparison is made.
Gross Revenue Retention is the complementary figure — it measures how much of last period's MRR you kept, ignoring any expansion. Our GRR Guide walks through exactly how this is calculated and what a healthy GRR floor looks like by SaaS category. Dnoise surfaces both NRR and GRR from your Stripe data with formulas you can trace back to individual subscription events. If a number looks wrong, you can click through to the exact Stripe records that produced it.
For CAC payback, the critical input from the revenue side is gross margin on subscription revenue — which again requires knowing actual subscription revenue net of tax and net of payment processing fees. Dnoise separates Stripe processing fees from gross charge volume so your margin denominator is accurate from day one.
Failed Payments in the US Market
Failed payment rates in the US typically run between 2.5% and 4% of subscription renewal attempts, with higher failure rates among annual plans renewing on card-on-file credentials that are 12 months old. This is involuntary churn — revenue that was committed by the customer but lost to a card decline — and it is consistently the most recoverable category of churn for a bootstrapped SaaS to address.
Before you can address it, you need to see exactly where it is happening. Dnoise surfaces failed payment events from Stripe in real time — organized by which customer, which subscription, how many consecutive failures, and what the accumulated revenue at risk looks like. The Stripe Failed Payments Recovery Guide covers the retry logic and dunning mechanics in detail. The starting point is always the same: find the revenue worth recovering before it becomes a closed subscription.
US customers on annual plans represent a specific failure pattern worth watching separately: a single annual renewal failure is worth 12× a monthly failure in recovered revenue potential if addressed in the retry window. Dnoise flags these distinctly so you know where to focus your dunning effort first.
Know what failed last night before your first meeting of the day.
Dnoise processes Stripe webhooks in real time and organizes failed payment data by customer, subscription age, and revenue at risk — so you can act on the right ones first.
No credit card. Read-only access. Setup in 2 minutes.
What Dnoise Shows You
Every metric Dnoise surfaces is traceable to a raw Stripe event. There is no intermediate data warehouse, no normalization layer, and no proprietary scoring that obscures how a number was produced. Here is what you see from day one, with no feature tiers and no sales call required:
- MRR broken down by new, expansion, contraction, churn, and reactivation — with tax stripped and each component linked to the underlying Stripe subscription events that caused it.
- US state-level MRR attribution, updated as billing addresses change, so your geographic concentration is always current rather than a stale export.
- Failed payment tracking organized by customer, subscription, consecutive failure count, and revenue at risk — flagging annual renewals separately from monthly.
- Net Revenue Retention and Gross Revenue Retention calculated from clean MRR — no tax inflation in the baseline or the comparison period.
- Stripe processing fee separation so your gross margin denominator is accurate when you calculate CAC payback or LTV.
- Real-time webhook processing — what happened in Stripe last night is visible in Dnoise this morning, not tomorrow after an overnight sync.
To understand how Dnoise connects to Stripe and what the calculation pipeline looks like end to end, see How It Works. The connection is read-only — Dnoise cannot move money, modify subscriptions, or take any action in your Stripe account. You can delete the API key from Stripe at any time.
Frequently Asked Questions
Does Dnoise handle Stripe Tax automatically, or do I need to configure something?
If you have Stripe Tax enabled on your Stripe account, Dnoise detects tax line items on charge events automatically and strips them before calculating MRR. You do not need to configure anything separately. If you collect tax outside of Stripe Tax — for example, manually invoiced tax amounts — you can flag those line items during setup and Dnoise will exclude them from subscription revenue calculations. The formula Dnoise uses is visible in the metric detail view so you can verify the logic against your own Stripe records.
How does Dnoise assign MRR to US states when customers have multiple addresses on file?
Dnoise uses the billing address on the Stripe customer record as the state attribution for MRR purposes — which is the same address Stripe Tax uses to determine tax jurisdiction. If a customer updates their billing address mid-subscription, the attribution updates going forward from that point. Historical MRR figures retain the state attribution that was current at the time of each billing event, so your state-level trend data reflects what was actually billed to each address rather than retroactively reassigning revenue.
My Stripe account has both US and international customers. Will the US state breakdown mix in foreign revenue?
No. Dnoise separates customers by billing address country before applying US state attribution. Customers with non-US billing addresses appear in your geographic breakdown under their respective countries and are excluded from the US state view entirely. If you want to see all revenue normalized to USD across all geographies in a single view, Multi-Currency Analytics handles that separately without contaminating the US state breakdown.
Is the read-only Stripe connection genuinely limited — or does "read-only" just mean you don't intend to write?
The connection uses a Stripe restricted API key that is scoped to read permissions only. Stripe's permission model enforces this at the API level — a restricted key with read-only scope cannot initiate charges, modify subscriptions, issue refunds, or take any other write action regardless of what the application connected to it attempts to do. You create the restricted key in your Stripe dashboard, you control its permissions, and you can delete it from Stripe at any time. Dnoise never asks for a full secret key.
How is Dnoise different from just building a Stripe dashboard in Metabase or Redash?
A Stripe dashboard you build in Metabase shows you numbers. Dnoise tells you what changed and why. The operational difference is that Dnoise processes Stripe webhooks in real time and surfaces the specific events — the new subscription, the upgrade, the churn, the failed payment — that explain every movement in your MRR. You are not looking at aggregate totals and reverse-engineering the cause. You are reading a clear account of what happened, with a click path to the exact Stripe records. Building that yourself in a BI tool requires significant ongoing maintenance as your Stripe data model evolves. Dnoise handles that so you do not have to.
Connect once. Know what changed in your US revenue every morning.
Dnoise connects read-only to Stripe, strips tax from your MRR, breaks revenue down by US state, and surfaces what matters — before you open Stripe. Free to start. No credit card.
No credit card. Read-only access. Setup in 2 minutes.
See Also
- Multi-Currency Analytics — normalize revenue across USD and non-USD customers without contaminating your US state breakdown.
- How It Works — the full walkthrough of how Dnoise connects to Stripe, processes events, and calculates metrics.
- Stripe Failed Payments Recovery Guide — how to find and act on involuntary churn before it closes.
- B2B SaaS Churn Benchmarks 2026 — where your monthly and annual churn rates stand against the current market.
- GRR Guide — how gross revenue retention is calculated and what a healthy floor looks like for your SaaS category.
- CAC Payback Guide — how clean MRR and gross margin flow into your CAC payback calculation.