Monthly vs Quarterly Revenue in Stripe: What Actually Counts

If you ask three people for “monthly revenue” from Stripe, you’ll often get three different numbers.

Not because anyone is wrong, but because Stripe exposes multiple timestamps, and each one answers a different business question.

This post explains:

• which Stripe dates exist and what they actually mean

• why monthly and quarterly revenue numbers drift

• how to choose the right timestamp for your reports

Stripe does not have a single “revenue date”

Stripe records revenue-related activity across several timestamps. The most important ones are:

• Invoice created date

• Invoice finalized date

• Payment succeeded date

• Charge created date

• Service period start/end (for subscriptions)

Each of these can produce a valid, but different, monthly or quarterly revenue number.

Invoice created date: what you billed

Using invoice creation date answers the question:

How much did we bill in this period?

Characteristics:

• includes invoices that may not be paid yet

• aligns well with sales activity

• common for bookings and pipeline-style reporting

Problems:

• overstates cash if invoices go unpaid

• mismatches revenue and cash timing

Payment succeeded date: what you actually collected

Using payment success date answers:

How much cash did we collect in this period?

Characteristics:

• clean for cash flow reporting

• easy to reconcile with bank deposits

Problems:

• annual prepayments distort monthly revenue

• upgrades and proration can spike single months

• does not reflect service delivery

Charge created date: a lower-level view

Charges are tied closely to payments but can diverge when:

• invoices contain multiple charges

• retries occur

• partial payments happen

Charge dates are rarely the right choice for high-level revenue reporting, but they matter for reconciliation.

Service period dates: what you actually earned

For subscriptions, Stripe records a service period on invoice line items.

Using service period answers:

What revenue should be recognized in this period?

Characteristics:

• smooths annual plans across months

• aligns revenue with delivery

• required for accrual accounting

Problems:

• requires allocating line items across time

• not available on all Stripe objects by default

• more complex to implement

Why quarterly revenue often “doesn’t match” monthly totals

A common confusion:

• Monthly revenue (payment-based) ≠ Quarterly revenue (invoice-based)

Reasons include:

• invoices created in one quarter but paid in another

• annual plans paid upfront

• refunds applied later

• proration adjustments crossing boundaries

If different reports use different timestamps, totals will never reconcile.

Pick one definition per report (and document it)

Good Stripe revenue reporting follows a simple rule:

One report → one timestamp → one definition

Examples:

• Monthly cash revenue: payment succeeded date

• Quarterly billed revenue: invoice created date

• Monthly recognized revenue: service period allocation

Once chosen, every downstream calculation must use the same rule.

How to implement this cleanly

Best practice:

1. Anchor on invoice line items

2. Store the relevant Stripe timestamps explicitly

3. Pre-aggregate by month or quarter

4. Never mix timestamps in the same report

This prevents silent drift as your data grows.

Key takeaway

Stripe gives you the raw ingredients for monthly and quarterly revenue, but it does not choose the recipe.

If your numbers feel inconsistent, the problem is usually not Stripe. It’s an undefined, or inconsistently applied, time dimension.

In the next post, we’ll look at revenue by customer and why even that breaks down once refunds, multiple subscriptions, and identifiers enter the picture.