The SaaS metrics Stripe can answer—and the ones it cannot

Stripe contains the strongest evidence about the commercial side of a software business. It records payments, invoices, subscriptions, products, prices, refunds, and disputes. But it does not hand you one canonical SaaS dashboard.

You still need definitions.

Revinho's exact inclusion, currency, and reporting rules are documented in the methodology.

Revenue is a flow of money

For operating analysis, revenue often begins with successful payments and subtracts refunds in the reporting period. The exact choice may vary with accounting requirements, but the product definition must be stable and visible.

Store every amount as an integer in the currency’s minor unit. Ten euros is 1000 cents, not 10.00 in a floating-point field. Some currencies have no minor unit, so formatting must respect the currency rather than assuming two decimals.

Multi-currency businesses should preserve the original amount forever. A converted dashboard amount is a reporting view, not a replacement fact.

MRR is a normalized subscription snapshot

Monthly recurring revenue answers a different question: what is the normalized monthly value of qualifying active recurring commitments?

An annual plan needs to be normalized to a monthly amount. Quantity, discounts, trials, pauses, cancellation timing, and subscription state all affect the calculation. One-off payments should not appear in MRR.

Because MRR is a snapshot, it can rise even when cash collected in the period falls—and the reverse can also happen. That is not a contradiction.

MRR movements explain the change

A total is more useful when you can reconcile how it changed:

• New MRR from first-time subscriptions
• Expansion MRR from upgrades or added quantity
• Contraction MRR from downgrades
• Churned MRR from ended subscriptions
• Reactivation MRR from returning subscriptions

The movement categories should reconcile the opening MRR to the closing MRR. If they do not, you have found a definition or data-quality problem worth fixing. Revinho stores all five movement kinds; its current Revenue surface exposes new and churned MRR alongside the total.

Customers need lifecycle definitions too

“New customer” can mean a new Stripe customer object, a first successful payment, or a first active subscription. Those are not interchangeable.

For most SaaS operating views, a first successful commercial outcome is more meaningful than object creation. A customer record can exist without ever paying.

The same care applies to churn. Subscription cancellation requested today may take effect at the end of the billing period. Decide whether churn is recognized on request or when recurring access actually ends, then keep that rule consistent.

What Stripe cannot tell you alone

Stripe can prove that a customer paid. It usually cannot prove why they arrived.

To understand acquisition and content performance, you need context from systems such as GA4 and Search Console. Even then, not every relationship is deterministic. Aggregate trends can show that organic traffic and new MRR rose during the same period, but that is not automatically source-level attribution.

Use verified, modeled, and associated labels to make that distinction visible. Revinho's current acquisition and page context is associated; it does not present aggregate co-movement as source-level revenue attribution.

The minimum trustworthy revenue view

A compact founder view can begin with:

1. Revenue net of refunds
2. Current MRR
3. New, expansion, contraction, and churned MRR
4. New paying customers
5. A daily or weekly revenue trend
6. Product and plan mix
7. Freshness, currency, and definition notes

Each number should be reproducible from normalized Stripe records. That is the difference between a persuasive chart and a durable business fact.

Stripe documents its own configurable Billing analytics definitions, while its currency documentation explains the minor-unit convention used by the API. A trustworthy reporting layer should state where its operating definition differs from another dashboard rather than forcing the totals to agree.