If you joined a PLG SaaS company as a finance leader, there's a good chance Stripe was already in use, often going back to when the first dollar was collected.

As companies scale, all those early Stripe configuration decisions can compound, leading to increasingly significant missing or miscategorized revenue and the need for custom MRR calculations. It's worth taking the time to ask questions early.

Stripe can be used by developers in so many different ways via its APIs, and small decisions made years ago by an early product team can turn into larger issues like inaccurate MRR and NRR reporting, and painful data audits and reconciliations between systems. If finance wasn't at the table when Stripe was implemented, here are five questions to ask your team:

Question 1: Do we actually know what our MRR is, and where it lives?

Many companies claim that "Stripe is their MRR source of truth," but they don't define what that means. Options include:

• Raw Stripe data via non-detailed Stripe UI exports

• Raw Stripe data via Stripe Sigma advanced SQL queries

• Transformed Stripe data in Excel, Sheets, ChartMogul, or a BI tool / ETL

• A manual data source driven by Stripe notifications, such as a spreadsheet or the Opportunity or Deal object in your CRM

There are valid reasons to use Stripe data as a starting point for creating a custom MRR calculation. For example, you may want to set custom rules for handling active MRR status for pending cancellations and reactivations. Or, you may need to work around Stripe limitations or MRR design decisions you disagree with. Stripe is such a robust platform that it can often do what the finance team wants; however, the product team needs to invest time in supporting the change.

Question 2: How are we handling mid-term changes (like adding users and proration)?

When a customer amends their subscription mid-cycle by adding seats or upgrading products, does that show up as MRR growth or just as an invoice?

• If you're relying on Stripe's proration engine, confirm that proration_behavior is enabled and that your team understands how proration amounts are applied to invoices. Review examples, especially where multiple changes occur within a period.

• If your team is using manual invoices for amendments, this simple workaround bypasses subscription-level logic entirely, disrupting the link between billing and MRR. You risk double-counting, missing revenue, and misclassifying upgrades.

• If your team is using the subscription.schedule object to plan future changes: Bravo! This is a best practice when planning future changes, like managing large-scale pricing updates, renewal terms, and time-based upsell agreements. Just make sure it's use is documented and consistently applied.

Question 3: Are we using Products and Prices in Stripe the right way?

Stripe separates Products (what you're selling) from Prices (how much and how often you charge). But many early-stage startups misuse them, treating Products as pricing tiers, duplicating Products instead of adding new Prices, or omitting key metadata. A few best practices:

(1) Use a single Product per offering (e.g. "Pro Plan") with multiple Prices (e.g. $99/month; $1,000/year). This simplifies upgrades, downgrades, and reporting.

(2) When pricing changes, create new Prices, not new Products. This keeps historical tracking intact and prevents product catalog clutter.

(3) Use consistent metadata (e.g. billing_frequency, region, internal SKUs) across both Product and Prices to support accurate reporting and integrations.

A clean Product and Price structure makes integration with HubSpot, NetSuite, and other systems far more scalable.

Question 4: What happens when a payment fails?

Stripe supports advanced failure handling, including automatic retries, pausing, and dunning workflows. But your revenue treatment during the "past due" phase, after a payment fails but before it's canceled, is what really matters:

• Are we recognizing MRR before payment is collected?

• At what point does product service and access stop? Are we consistent?

• How do we try to collect? When do we cancel delinquent subscriptions?

• Do we treat reactivations as churn reversal (within a time window) or new?

These edge cases can subtly, but significantly, distort your churn, expansion, and retention metrics.

Question 5: Are we connecting Stripe data to our CRM and accounting systems?

Without a formal bridge between your revenue source of truth (Stripe) and your customer source of truth (HubSpot, Salesforce, or NetSuite), Finance and GTM teams are likely cobbling together spreadsheets to fill the gaps.

Even if you're not fully automated yet, there are low-effort wins:

• Store Stripe IDs in your CRM

• Include CRM IDs (like HubSpot Company ID) in your Stripe metadata

• Begin mapping these IDs consistently, even if manually

These foundational connections help close your GTM/Finance data gaps over time and lay the groundwork for clean attribution, scalable reporting, and future automation.

Question 6: Are we collecting US state sales tax?

Whether it's via Stripe's tax solution or a partner like Avalara, you should be on top of US state sales tax. As you hit different revenue or employee thresholds in different states, you're liable for charging state sales tax. The longer you let it go, the more you're going to have to pay out of pocket to catch up. It's recommended to consult an accounting firm specializing in SaaS sales tax compliance for expert advice and filing help.