How to Calculate Revenue by Product in Stripe (And Why It’s More Complicated Than It Should Be)

If you’ve ever tried to answer a seemingly simple question—

How much revenue did Product A generate last month?

—you’ve probably discovered that Stripe doesn’t make this easy.

This isn’t a Stripe bug. It’s a mismatch between how Stripe models billing data and how operators think about revenue.

This post walks through:

• what “revenue by product” actually means in Stripe terms

• why common approaches fail

• how to build a defensible, repeatable product revenue report

What Stripe means by “product” vs what you mean by “product”

In Stripe, revenue does not live on the Product object. Stripe’s core objects are:

• Products – conceptual catalog items

• Prices – how a product is sold (amount, interval, currency)

• Invoice line items – where money actually appears

Revenue is always recorded on invoice line items, not products.

That distinction matters because a single product can:

• have multiple prices

• change prices over time

• be billed monthly, yearly, or usage-based

• appear multiple times on an invoice due to proration

If you try to sum revenue at the product level without resolving these relationships, your numbers will drift.

The most common (and broken) approaches

1) Export invoices and group by product name

This works until:

• prices change

• products are renamed

• discounts apply at the invoice level

• proration creates partial line items

You’ll might get a number, but it won’t be stable over time. Or, you won't even get a number because Stripe Invoice exports don't include line item details.

2) Group by price ID

This is technically accurate but operationally useless. Why?

• the same product often has multiple price IDs

• legacy prices stay in data forever

• business stakeholders don’t think in price IDs

You end up with a report that’s “correct” but not interpretable.

3) Use Stripe’s built-in reports

Stripe’s dashboard can show overall revenue trends, but it does not reliably answer:

• revenue by product

• net revenue after refunds

It’s designed for overview, not accounting-grade reporting.

What actually works: start from invoice line items

A reliable product revenue report starts with invoice line items as the source of truth.

Each line item contains:

• amount

• currency

• price ID

• product ID (via price)

• billing period

• proration flags

From there, you build your definition of product revenue.

Step 1: Define your revenue rule (before touching data)

Decide this upfront. Examples:

• Cash-based product revenue: sum of paid invoice line items in the period

• Invoice-based product revenue: sum of invoice line items created in the period

• Net revenue: subtract refunds and credits from the above

If you don’t lock this definition, every downstream report will disagree.

Step 2: Normalize prices back to products

Create a mapping layer:

• price_id → product_id

• price_id → product_name (stable internal name)

This absorbs:

• price changes

• legacy plans

• promotional pricing

Your report should group by product, not raw price.

Step 3: Handle proration explicitly

Proration creates line items that:

• represent partial service periods

• may be positive or negative

You must decide:

• include proration as revenue

• exclude it

• allocate it to the original product period

Ignoring proration is the fastest way to break trust in your numbers.

Step 4: Net out refunds and credits

Refunds almost never occur in the same period as the original sale. If your report includes sales but ignores later refunds, it will overstate product revenue.

Best practice:

• treat refunds as negative revenue

• attribute them back to the original product

Step 5: Produce a stable, repeatable table

A good output looks like:

This table should:

• be reproducible

• refresh without manual cleanup

• tie back to Stripe invoice IDs

Why this feels harder than it should be

Stripe gives you dependable raw data. What it does not give you is:

• opinionated aggregation

• business definitions

• historical consistency across pricing changes

That layer is your responsibility.

Key takeaway

Calculating revenue by product in Stripe is not about finding the right export. It’s about:

• choosing a revenue definition

• anchoring on invoice line items

• normalizing prices to products

• handling proration and refunds explicitly

Once those rules exist, the report becomes boring—and boring is exactly what you want from revenue numbers.

In the next post, we’ll tackle time-based revenue reporting and why “monthly” revenue means different things depending on which Stripe timestamp you choose.