Why Does My Revenue in HubSpot Not Match My Stripe Data?

When your HubSpot dashboard shows one Revenue number and Stripe shows another, the instinct is to assume one of them is wrong. But both systems are usually correct—they're just answering different questions.

The problem is not that HubSpot and Stripe use different data sources. The problem is that "Revenue" is a business term that requires a clear definition—and most organisations never define it explicitly. Instead, they let each tool define "Revenue" on its own terms, then spend hours every month reconciling the differences by hand.

This is metric debt. And it erodes trust faster than any technical issue ever could.

A metrics-first approach solves this by defining "Revenue" once—as a governed business metric with a clear owner, calculation logic, and data lineage—then ensuring that every system, dashboard, exploration, AI query, and CSV export pulls from that single source of truth. The underlying data source can change over time (from HubSpot to Stripe to a warehouse), but the definition stays consistent and the users stay aligned.

The Real Problem: Revenue Is a Business Definition, Not a Data Field

Revenue is not simply a column in a database. It is a business concept with layers of nuance that require definition:

Who owns the definition? Is it Finance? Sales Operations? The CFO?

What does "Revenue" mean in your business? Is it cash collected? Invoices issued? Bookings closed? Revenue recognised under IFRS, U.S. GAAP, or ASPE accounting standards?

Which events count? Do refunds reduce Revenue? Are discounts applied before or after the total? Are taxes included or excluded?

What timing rule applies? Do you count Revenue when the deal closes, when the invoice is sent, when the payment is captured, or when it hits your bank account?

How do you handle currency? If you operate in multiple currencies, at what exchange rate and on what date do you convert to your home currency?

Where does the data come from? HubSpot? Stripe? QuickBooks? A data warehouse? And when that source changes, does the definition change with it?

Without clear answers to these questions—documented, owned, and certified—every team will define "Revenue" differently. HubSpot will default to one interpretation. Stripe will default to another. Finance will build a spreadsheet with a third. And reconciliation meetings will consume entire afternoons.

Why HubSpot and Stripe Show Different Numbers

HubSpot and Stripe are both capable of counting records and summing currency values. The mismatch happens because they are designed to track different stages of the revenue lifecycle—and most organisations never clarify which stage their "Revenue" metric should reflect.

What HubSpot Typically Tracks

HubSpot is a CRM. It tracks sales commitment: deals moving through a pipeline, opportunities closing, and forecasted amounts.

When you see "Revenue" in HubSpot, it often reflects:

• The Amount field on deals marked as "Closed Won"
• The date the deal moved to "Closed Won" or another stage
• The value entered by the sales team at the time of the close

This is bookings or committed revenue. It tells you what your sales team has sold, not what your bank account has received.

What Stripe Typically Tracks

Stripe is a payment processor. It tracks cash collected: charges captured, invoices paid, and payouts settled.

When you see "Revenue" in Stripe, it typically reflects:

• Successful charges or captured payments
• The date the charge was created or the payment was confirmed
• The amount after refunds, disputes, and potentially fees (depending on how you query the API)

This is cash revenue or collected revenue. It tells you what money has actually moved, not what deals were closed.

The Gap Between Commitment and Collection

The two systems answer fundamentally different questions:

• HubSpot: "What did we sell this month?"
• Stripe: "What cash did we collect this month?"

For many businesses, these numbers diverge significantly:

• A deal closes in March, but payment terms mean the customer pays in April. HubSpot shows the Revenue in March; Stripe shows it in April.
• A customer pays a deposit upfront and the balance on delivery. HubSpot shows the full deal amount at close; Stripe shows two separate charge events.
• A customer pays annually in January for a 12-month contract. Stripe shows the full cash amount in January; under accrual accounting, Revenue is recognised monthly over the year.
• A refund is issued in June for a sale that closed in March. HubSpot still shows the deal as Closed Won; Stripe nets the refund against June Revenue.

Neither system is wrong. They are measuring different things—and your business needs to decide which definition of "Revenue" matters for which purpose.

The Hidden Cost: Manual Reconciliation Invites Human Error

When "Revenue" is not defined as a governed metric, teams export CSVs from both systems and try to reconcile them manually. This process is fragile, time-consuming, and error-prone.

Mismatched keys. Deal IDs in HubSpot rarely match charge IDs in Stripe. Teams join on customer email or company name and introduce duplicates or mismatches.

Inconsistent time ranges. One export covers "this quarter." The other covers "the last 90 days." Totals never align.

Date granularity traps. HubSpot uses Close Date. Stripe uses Charge Created or Payout Date. A single day's misalignment can shift a month's total by thousands of dollars.

Version drift. Someone tweaks a formula in a spreadsheet. Another person copies an outdated file. Suddenly your "Revenue" number changes, and no one remembers why.

Unauditable logic. The reconciliation rules live in someone's head or in an email thread. When that person leaves, the knowledge leaves with them.

Every manual fix becomes another tribal rule. Over time, these rules accumulate—undocumented, inconsistent, and impossible to audit. That is metric debt, and it is why executives stop trusting the numbers.

Define Revenue Once: The Metrics-First Approach

A metrics-first platform solves this by treating "Revenue" as a governed business metric—not a data field—and ensuring that every consumer of that metric pulls from the same certified definition.

Here is what that looks like in practice.

Level up data-driven decision making

Make metric analysis easy for everyone.

Get Started Now

1. Decide on One Canonical Definition of Revenue

Before you connect any data sources, answer these questions:

What does "Revenue" mean in your business? Cash collected? Invoices issued? Bookings closed? Revenue recognised under your accounting standard?

Who owns this definition? Typically the CFO, Controller, or Head of Finance. That person is accountable for the metric's accuracy and must approve any changes.

Which events count? Are refunds subtracted? Are discounts applied before or after? Are taxes included or excluded?

What timing rule applies? Do you count Revenue when the deal closes, when the invoice is sent, when the payment is captured, or when it settles in your bank account?

How do you handle currency? If you operate in multiple currencies, specify the exchange rate source and the date on which conversion happens.

Document these decisions. This is your Revenue metric definition, and it becomes the contract that every system must honour.

2. Map the Right Data Source to Your Definition

Once you have defined "Revenue," identify which data source best reflects that definition.

If your definition is cash collected: Stripe is the natural source. Use successful charges or captured payments, subtract refunds and disputes, and apply your chosen timestamp (charge created, charge captured, or payout date).

If your definition is invoices issued: Stripe invoices or QuickBooks invoices are the natural source. Use the invoice finalised date and the invoice total.

If your definition is bookings or committed revenue: HubSpot deals marked as Closed Won are the natural source. Use the deal amount and the close date.

If your definition is recognised revenue under IFRS or ASPE: Your accounting software (QuickBooks, Xero, NetSuite) is the natural source, as this typically requires revenue recognition schedules that neither HubSpot nor Stripe handle natively.

The key insight: the data source is implementation, not definition. Your "Revenue" metric may start by pulling from HubSpot today. Tomorrow, as your business grows, you might move the underlying data to Stripe. Eventually, you might consolidate everything in a data warehouse like Snowflake and pull from there. The end user should never know the difference—they are querying the same metric, with the same definition, governed by the same owner.

3. Build the Metric Layer

In a metrics-first platform like PowerMetrics, you define "Revenue" as a metric with the following properties:

Name: Revenue
Owner: CFO or Head of Finance
Definition: Cash collected from customers for goods or services delivered, net of refunds and disputes, in home currency (CAD).
Calculation: Sum of Stripe successful charges where status = succeeded, minus sum of refunds where status = refunded, converted to CAD using daily exchange rates from source X.
Time grain: Charge captured date, aggregated by day/week/month.
Dimensions: Product line, customer segment, sales rep (if tracked via metadata).
Data source: Stripe Charges API (current); may migrate to Snowflake in future.
Certification status: Certified by Finance on 2025-02-15.
Audit trail: Changes to this metric require CFO approval and are versioned.

Once this metric is defined and certified, every dashboard, exploration, AI query, and CSV export pulls from this single definition. There is no ambiguity. There is no reconciliation. There is one "Revenue," and it is trusted.

4. Surface the Metric Everywhere

Now that "Revenue" is defined as a governed metric, you can use it consistently across every surface:

Dashboards: Build executive dashboards, sales dashboards, and financial dashboards—all querying the same "Revenue" metric.

Explorations: Business users can slice "Revenue" by product line, customer segment, or time period without redefining the calculation.

AI queries: When someone asks, "What was our Revenue last quarter?" the AI queries the certified "Revenue" metric and returns the governed answer.

CSV exports: When Finance needs to export Revenue data for board reporting, the CSV reflects the same definition the CEO sees on the executive dashboard.

The benefit is not just consistency—it is trust. When everyone knows they are looking at the same definition, debates end. Reconciliation meetings disappear. Teams move from arguing about the number to analysing what the number means.

What About Bookings, Cash, and Recognised Revenue?

Most organisations need more than one Revenue metric. You might need:

Bookings Revenue: Deals closed in HubSpot, reflecting sales commitments.
Cash Revenue: Charges collected in Stripe, reflecting actual money movement.
Recognised Revenue: Revenue recognised under your accounting standard, typically from QuickBooks or Xero.

The metrics-first approach does not force you to pick one. It forces you to define each one clearly and ensure they are not confused with each other.

Define three separate metrics:

• Revenue (Bookings)
• Revenue (Cash Collected)
• Revenue (Recognised)

Each metric has its own definition, owner, data source, and certification status. Dashboards can show all three side by side, labelled clearly, so stakeholders understand what they are comparing.

The mistake is calling all three "Revenue" without qualification and then wondering why the numbers do not match.

Where PowerMetrics Fits

PowerMetrics is a metrics-first analytics platform designed to help organisations define, govern, and share business metrics like "Revenue" without building a data warehouse or writing custom pipelines.

Connect both systems. Use built-in connectors to pull data from HubSpot and Stripe. See HubSpot connector documentation and Stripe connector documentation.

Model once. Build clean data feeds for deals, charges, refunds, and payouts. Map deals to charges using customer email, account ID, or custom metadata. Apply formulas, filters, and joins without writing code.

Define the metric. Create "Revenue" with your chosen logic—whether that is cash collected from Stripe, bookings from HubSpot, or recognised revenue from QuickBooks. Specify the owner, the calculation, the time grain, and the dimensions. Certify it so teams know this is the standard.

Track over time. Compare periods, set goals, and alert when Revenue shifts beyond expected thresholds or when refund rates spike.

Distribute with context. Publish dashboards for Finance, Sales, and the executive team—all querying the same underlying "Revenue" metric. Add descriptions, lineage, and audit logs so everyone understands where the number comes from.

Adapt as you grow. When you eventually migrate data from Stripe to a warehouse like Snowflake, update the data source in the "Revenue" metric definition. The metric name, the calculation logic, and the user experience stay the same. Users continue querying "Revenue" without knowing—or caring—that the plumbing changed.

Trusted by over 25,000 companies to make faster, confident decisions with shared metrics.

Quick Self-Check Before You Change Anything

Before you try to reconcile HubSpot and Stripe manually, ask yourself:

Have you defined what "Revenue" means in your business? If not, you are comparing two undefined terms and hoping they match.

Do you know which data source reflects your definition? If your definition is "cash collected," Stripe is the right source. If your definition is "bookings," HubSpot is the right source. If you are pulling from the wrong source, the numbers will never align.

Are your date ranges and time zones aligned? A deal closed on 31 March at 11pm PST might appear in HubSpot as March but in Stripe as April if Stripe uses UTC.

Are you using gross, net of fees, or net of refunds in Stripe? Stripe can return amounts before fees, after fees, or net of refunds depending on how you query the API. If HubSpot shows gross deal amounts and Stripe shows net-of-fees amounts, they will never match.

Do multi-currency deals get converted with a consistent rule? If you close a deal in EUR and collect payment in EUR, you need a consistent exchange rate and date policy to convert both to your home currency.

Can you trace today's total back to individual charges or deals? If someone questions the Revenue number, you should be able to drill into the underlying transactions and show exactly how the total was calculated.

If any answer is "no" or "I'm not sure," your definition lives in spreadsheets and tribal knowledge—not in a governed metric. Fix the definition first. Then the reconciliation becomes trivial.

FAQ

Can you make HubSpot match Stripe 1:1?

Only if you align your definition of "Revenue" to one of them and ignore the other. HubSpot tracks deals and commitments; Stripe tracks payments and cash. These are different stages of the revenue lifecycle. A small delta will always remain unless you redefine one system's "Revenue" metric to match the other's data—at which point, why have two systems?

The better approach is to define separate metrics: "Revenue (Bookings)" from HubSpot and "Revenue (Cash Collected)" from Stripe. Label them clearly. Use the right one for the right purpose.

How do subscriptions affect this?

Stripe records monthly charges for recurring subscriptions. Your CRM might store the full annual contract value on a single closed deal. If your "Revenue" definition is cash collected, use Stripe's monthly charges. If your "Revenue" definition is bookings, use the CRM's annual amount. If your "Revenue" definition is recognised revenue under accounting standards, use your accounting software's revenue recognition schedule.

Do not try to make Stripe's monthly charges add up to HubSpot's annual deal amount—they measure different things.

What about payouts to the bank?

Payouts group charges and fees on a different schedule than charges themselves. Use payouts for cash operations (understanding when money hits your bank account). Use charges or invoices for Revenue tracking (understanding when customers paid you). Most businesses define "Revenue" based on charges, not payouts.

Our accountant says Revenue should follow IFRS or ASPE. How does that fit?

Revenue recognition under IFRS, US GAAP, or ASPE typically requires schedules that spread a single payment over multiple periods (e.g., annual subscription paid in January but recognised monthly over 12 months). Neither HubSpot nor Stripe handles this natively. Your accounting software (QuickBooks, Xero, NetSuite) is the right source for recognised Revenue. Define "Revenue (Recognised)" as a separate metric from "Revenue (Cash Collected)" and "Revenue (Bookings)."

What if I change data sources later—say, moving from Stripe to Snowflake?

In a metrics-first platform, you update the data source in the "Revenue" metric definition without changing the metric name, the owner, or the business logic. Users continue querying "Revenue" the same way they always have. The only thing that changes is the plumbing—and that change happens behind the scenes, managed by your data team, without disrupting anyone's workflow.

This is the structural advantage of defining metrics as business concepts rather than data fields. The definition is portable. The source is not.