Stripe MRR vs QuickBooks Revenue: Why They Disagree

Your Stripe dashboard says $40,850 MRR. Your QuickBooks profit and loss for the same month says $42,676. Nobody has made a mistake, nothing is out of sync, and no amount of clicking will make the two numbers meet. They are answers to different questions, and the gap between them is computable to the cent.

This post works that reconciliation end to end: what each number actually measures, the four structural reasons they separate, and a line-by-line bridge from one to the other for a single month. If you have ever been asked "so which one is our revenue?" in a board meeting, the answer is both, and here is the arithmetic that says so.

Start a free trial and see how your Stripe activity lands in QuickBooks.

MRR is a run rate, not a revenue figure

Monthly Recurring Revenue is a forward-looking rate normalized to a month. It answers: if nothing changes from this instant, what does a month of recurring subscription revenue look like?

The normalization is the part that trips people up, and Stripe states it plainly: "an annual subscription for $1,200 only counts $100 towards your MRR." The customer paid $1,200. The run rate went up $100. Both facts are true simultaneously, and only one of them is a revenue event.

Stripe tracks the rate through events rather than balances. The subscription_item_change_events table, in Stripe's words, "tracks changes to subscription items that affect Monthly Recurring Revenue (MRR) and subscription quantities." Each row carries an mrr_change column that Stripe describes as "the positive or negative impact of an event on your MRR in the subscription item's settlement currency's minor unit (such as cents for USD)."

The vocabulary of those events is worth learning, because it tells you exactly what MRR does and does not notice:

Event type	What Stripe says it means
ACTIVE_START	"The subscription item started contributing to MRR."
ACTIVE_END	"The subscription item stopped contributing to MRR."
ACTIVE_UPGRADE	"The MRR contribution of the subscription item increased."
ACTIVE_DOWNGRADE	"The MRR contribution of the subscription item decreased."
ACTIVE_QUANTITY_INCREASE	"The quantity of the subscription item increased, but the MRR wasn't impacted."
ACTIVE_QUANTITY_DECREASE	"The quantity of the subscription item decreased, but the MRR wasn't impacted."

Two things follow from that table. First, the unit of account is the subscription item, not the customer and not the invoice. Second, MRR has no event type for "a customer paid us money." Payment is not an MRR event. Only a change in the recurring rate is.

The subscriber count works the same way. Stripe's own reference query carries the definition in a comment: "Stripe defines an 'active subscriber' as a customer with non-zero MRR." A customer who owes you $4,000 on an unpaid annual invoice and a customer paying $9 a month are both exactly one active subscriber.

QuickBooks revenue is a period measurement

Your profit and loss answers a different question: what did this business earn during this window, under the accounting basis this file is on?

That is backward-looking, bounded by dates, and indifferent to run rates. It also depends on a choice MRR never has to make, which is whether you are on cash or accrual basis and whether your file can express deferral at all. A $1,200 annual plan is $1,200 of March revenue on a cash-basis file and $100 a month for twelve months on an accrual file that defers properly.

So before comparing anything, know which basis produced the number you are comparing. Two businesses with identical Stripe accounts can show legitimately different revenue for the same month.

The four reasons the numbers separate

Every difference between ending MRR and booked revenue comes from one of four places. Each is computable.

1. Normalization

MRR restates every billing interval as a month. Revenue recognizes service as it is delivered. An annual plan sold mid-month contributes a clean $100 to MRR and a messy partial-period amount to revenue.

2. Point-in-time versus period

Ending MRR is a snapshot on the last day of the month. Revenue is a sum across all thirty or thirty-one days of it. A subscription that starts on the 10th contributes its full monthly rate to the month-end snapshot and roughly two thirds of a month to revenue. A subscription that ends on the last day of the month contributes nothing to the snapshot and a full month to revenue.

This is the single largest source of divergence in a growing business, and it grows with your growth rate. The faster you add customers mid-month, the further ending MRR runs ahead of booked revenue.

3. Amounts MRR ignores by construction

MRR tracks recurring subscription items. That leaves a lot of real revenue outside it:

• One-time implementation, setup, and onboarding fees.
• One-off invoice items added to a subscription invoice.
• Prorations from mid-cycle plan changes, which are one-time charges even though they arise from a recurring plan.
• Pure one-time charges from customers with no subscription at all.

Every one of those hits your profit and loss and moves MRR by zero. Note the asymmetry in the upgrade case: a mid-month upgrade raises MRR by the full monthly delta immediately, while the proration bills only the remaining days. MRR and revenue move in the same direction by different amounts.

Usage-based billing deserves its own flag. Stripe lists metered billing among the factors in its MRR calculation without publishing the treatment, so if a meaningful share of your revenue is metered, do not assume the two figures relate the way they do for flat-rate plans. Measure it before you rely on it.

4. Currency

If you sell in more than one currency, MRR is converted and restated. Stripe's reference query carries an explicit fx_adjustment_mrr column for the portion of a month's MRR movement that is nothing but exchange-rate drift, and the docs note that with customers in different currencies "you'll need to perform foreign currency exchange calculations."

QuickBooks does not restate closed revenue when rates move. So in a multicurrency business, part of your MRR change every month corresponds to no economic event at all. Isolate that column before you try to explain a variance.

The bridge, with real numbers

Here is one month, fully worked. A USD SaaS business on accrual basis with proper deferral. March has 31 days. Beginning MRR on February 28 was $40,000, all of it monthly-billed plans.

Four subscription events land in March:

Date	Event	MRR effect
Mar 3	New annual plan, $1,200 paid upfront	ACTIVE_START +$100
Mar 10	New monthly customer at $500/mo	ACTIVE_START +$500
Mar 18	Existing customer upgrades $300 to $800/mo	ACTIVE_UPGRADE +$500
Mar 31	Customer at $250/mo reaches end of term	ACTIVE_END -$250

Ending MRR is $40,000 + $100 + $500 + $500 - $250 = $40,850.

One more thing happened in March that produced no MRR event: a $2,000 one-time implementation fee, invoiced and earned on March 12.

Now compute March revenue independently, service-period by service-period:

• The existing base, $40,000. All monthly plans, all serving the full month, including the $250 subscription that runs to March 31. March revenue: $40,000.00
• The annual plan. $1,200 over 365 days, serving March 3 through March 31, which is 29 days. $1,200 x 29/365 = $95.34
• The new monthly subscription. $500 for the period March 10 through April 9, a 31-day period of which 22 days fall in March. $500 x 22/31 = $354.84
• The upgrade proration. The $500 monthly delta covering March 18 through March 31, 14 days of a 31-day month. $500 x 14/31 = $225.81
• The implementation fee. Earned in March. $2,000.00

Total March revenue: $40,000.00 + $95.34 + $354.84 + $225.81 + $2,000.00 = $42,675.99

And the bridge between the two figures:

Ending MRR, March 31                              40,850.00

Normalization and timing
  Annual plan: MRR $100 vs 29 days earned             (4.66)
  New monthly sub: MRR $500 vs 22 days earned       (145.16)
  Upgrade: MRR $500 delta vs 14 days prorated       (274.19)
  Term-end sub: out of MRR, full month earned         250.00

Revenue MRR does not track
  One-time implementation fee                       2,000.00

March revenue per QuickBooks                      42,675.99

That reconciles exactly, and every line names a mechanism rather than a plug. This is the artifact worth building once and keeping: not a reason the numbers differ, but a schedule that says by how much and why.

The signs are instructive. Three lines are negative because ending MRR counts a full month for subscriptions that served a partial one. One line is positive because revenue counts a full month for a subscription MRR has already dropped. In a month with heavy late-month signups, the negative lines dominate and MRR sits well above revenue. In a month with heavy month-end churn, it inverts.

Two traps in the data itself

Before you reconcile anything, know that the MRR number you read can depend on where you read it.

The Dashboard and the table can legitimately disagree. Stripe is explicit that subscription_item_change_events "provides more up-to-date data than the source driving the MRR metrics on the Billing overview in the Stripe Dashboard," and that as a result "the data for the last and current day's MRR here could be more accurate and could differ from what you see in the Dashboard." If you query the table on the 1st and someone else screenshots the Dashboard, you can both be right and still disagree. The newer subscription_item_change_events_v2_beta table shares the same schema and, per Stripe, "maintains a 3 hour freshness in Sigma and a 7 hour freshness in Stripe Data Pipeline," with the caveat to "allow all data to settle (48-hours maximum) before consuming this data incrementally."

For close work, that settling window matters more than the freshness does. Pull your MRR bridge two days after month end, not two hours.

The month boundary is timezone-dependent. The table carries two timestamps. Stripe documents event_timestamp as "the UTC timestamp" and local_event_timestamp as a timestamp "in your local timezone, typically the timezone of the person who created your Stripe account." Stripe's own reference query buckets months on local_event_timestamp.

That last clause deserves a moment. The timezone your MRR months are cut on is not a deliberate accounting setting. It is an artifact of who signed up for the Stripe account. If that person was in a different timezone from your books, a subscription that starts late on the 31st can land in a different month in Stripe than it does in QuickBooks. Pick one timestamp, write down which one, and use it every month.

One smaller trap worth knowing: Stripe warns that "some user actions can create multiple events, so you could see an event with an event_type of ACTIVE_END on one item and then immediately an event with an event_type of ACTIVE_START on another item for the same subscription_id." A plan swap looks like churn plus new business if you count events instead of netting mrr_change per customer. That single mistake will make your churn number look catastrophic and your new-business number look great.

What to actually do at close

1. Pull ending MRR and the month's mrr_change events from subscription_item_change_events (or the v2_beta table), bucketed on one timestamp column you have chosen deliberately. The Sigma queries worth having at month end cover the SQL surface for this.
2. Separate the four movement types yourself: new, expansion, contraction, churn. Net mrr_change per customer per day first, so plan swaps do not read as churn.
3. List every non-recurring amount invoiced in the month. Setup fees, one-off invoice items, prorations. This is the line item most bridges forget, and in an implementation-heavy business it is the largest one.
4. Build the bridge above once, as a template. Month two takes ten minutes.
5. Isolate FX if you bill in more than one currency, and never let exchange drift sit inside a churn or expansion number.

The deeper point is that neither number is trying to be the other. MRR is the best available answer to "what is this business worth per month going forward." Your profit and loss is the only acceptable answer to "what did this business earn." A company that reports MRR as revenue will eventually have that conversation with an auditor. A company that cannot explain the gap in a single schedule will have it with an investor first.

If your Stripe revenue is not landing in QuickBooks cleanly enough to run this comparison at all, that is a different and more fixable problem. See how Acodei syncs Stripe to QuickBooks, or start a free trial.

Frequently asked questions

Why is my Stripe MRR higher than my QuickBooks revenue?

Usually mid-month signups. Ending MRR counts a full month for every active subscription on the last day of the month, including one that started on the 28th and earned three days of revenue. Add an annual plan or two, which contribute a normalized twelfth to MRR rather than the amount collected, and the two figures separate further. Build the bridge in this post and the gap resolves into named lines.

Does Stripe MRR include one-time charges and setup fees?

No. MRR tracks changes to recurring subscription items, and Stripe's event vocabulary has no event for a one-time amount. Setup fees, one-off invoice items, and proration charges all hit your profit and loss without moving MRR at all. In businesses with meaningful onboarding fees this is often the single largest reconciling item.

Is MRR the same as recognized revenue for an annual plan?

No, and this is the clearest case. Stripe states that "an annual subscription for $1,200 only counts $100 towards your MRR." Under accrual basis with deferral your books also recognize roughly $100 a month, but they start from the service period rather than from a normalization rule, so a plan sold mid-month recognizes a partial first month while MRR carries the full $100 from the day it starts.

Why does my MRR differ between the Stripe Dashboard and Sigma?

Because they read different sources. Stripe documents that the subscription_item_change_events table "provides more up-to-date data than the source driving the MRR metrics on the Billing overview," so recent days can differ between the two and the table is the more current of them. For close work, wait for the data to settle rather than reconciling against a figure that is still moving.

Should I report MRR or QuickBooks revenue to investors?

Report both, and label them. MRR is a run-rate metric and belongs in the growth narrative alongside new, expansion, contraction, and churn. Revenue is an accounting output and belongs in the financials. What you should never do is present one as the other, or present an MRR figure you cannot bridge to your profit and loss on request.

Does a customer on an unpaid invoice still count in MRR?

Stripe lists delinquency among the factors in its MRR calculation but does not publish the treatment, so the honest answer is to measure it in your own account rather than assume. What is documented is the subscriber definition: "Stripe defines an 'active subscriber' as a customer with non-zero MRR," which is independent of whether that customer has paid.

Which timestamp should I use to cut MRR months?

Pick one and document it. Stripe offers event_timestamp, "the UTC timestamp," and local_event_timestamp, which is "in your local timezone, typically the timezone of the person who created your Stripe account." Stripe's own reference query uses the local column. The risk is not that either is wrong, it is that your Stripe months and your QuickBooks months get cut on different boundaries and nobody writes it down.