How to Reconcile Stripe Revenue With CRM Deals

Last updated: 10 September 2026.

Start with the question behind the mismatch

Sales says September bookings were $14,000. Stripe shows an October payment of $5,500. Someone asks which system is wrong.

Neither number is necessarily wrong. The sale might cover an annual subscription billed quarterly, plus implementation and tax. Comparing those totals without the contract and billing schedule creates a false incident.

Choose the question before choosing the source:

• Did the customer buy what sales recorded? Compare contract lines with the booked deal.
• Did we invoice the agreed amounts? Compare scheduled billings with finalized invoices and adjustments.
• Did we collect what was due? Compare invoice obligations with payment allocations, credits and remaining balances.
• What affected the Stripe balance? Use balance transactions, including fees and refunds.
• What reached the bank? Reconcile payouts and bank receipts separately.

These are operational reporting questions. Recognized revenue requires its own accounting policy and supporting system; a CRM-to-Stripe join does not establish it.

If different teams already use the same word for all five measures, fix the warehouse and customer-data model before adding another dashboard. A technically correct sum can still answer the wrong question.

Keep the original measures intact

Create separate measures called booked contract value, invoiced amount excluding tax, customer payments, refunds and net balance activity. Add the currency, event date and inclusion policy to each definition.

For HubSpot, the default deal Amount represents deal value. Its calculated ARR, MRR and TCV properties use line-item information rather than simply reusing Amount. Close date can also reflect expected dates or automation associated with stage changes. Do not assume that any one of those properties represents cash collected. HubSpot's deal-property definitions explain the distinctions.

For Stripe invoices, total_excluding_tax is a different basis from total, and amount_due can reflect customer balance adjustments. Preserve these fields with their definitions instead of renaming them all revenue. Stripe's invoice object documents the amount and status fields.

The reporting contract should answer four questions in ordinary language:

1. Which event makes a record eligible?
2. Which timestamp assigns the reporting period?
3. Which amount includes or excludes tax, discounts and adjustments?
4. Which identifier lets a reviewer reach the source record?

A chart labelled “Revenue: $50,000” answers none of them. “Finalized invoice value excluding tax, less issued credits, by invoice date, USD” gives the reader something they can challenge and reproduce.

For recurring run rate, use a separate MRR data model. Dividing this month's collected cash by a guessed subscription term will not repair mismatched definitions.

Build a relationship bridge, not an email join

Email can help investigate an unmatched record. It should not decide which commercial agreement earned a payment.

One company may have several billing contacts, Stripe customers or subsidiaries. A contact can change email. A CRM company can contain an initial deal, an expansion and a renewal, all connected to one ongoing subscription.

Model the relationships explicitly:

• An internal customer ID maps to source customer IDs.
• A commercial agreement ID maps to the relevant CRM deal and contract lines.
• Agreement lines map to subscription items or one-time billable items.
• Invoice lines connect to the applicable billable item.
• Payment allocations connect payments to invoices.
• Balance transactions connect processing activity to the relevant payment or adjustment.

Include the Stripe account and live/test environment in source keys. Preserve merged CRM record IDs when your extraction provides them. Keep effective dates where an agreement replaces an earlier one.

A payment-to-invoice relationship should support allocation rather than assuming one payment always belongs to one invoice. Stripe's Invoice Payment object records an invoice, payment, allocation amount and status; its documentation also addresses a PaymentIntent associated with multiple invoices. Stripe Invoice Payment reference.

For a legacy database, introduce the bridge gradually. Start with exact source IDs already present in the CRM. Investigate the remainder and record how each mapping was established. A manually approved mapping is more defensible than a fuzzy email match silently presented as fact.

Metadata can carry your internal agreement ID, but validate it on the object you actually extract. Stripe does not universally propagate metadata across related objects; documented exceptions include one-time snapshots. A customer-level field should not be assumed present and current on every invoice or charge. Stripe metadata documentation.

Work through one complete reconciliation

Consider this illustrative USD-only contract. The amounts, tax and processing fee are invented inputs for the example, not a Stripe price quote or tax recommendation.

On 28 September, sales closes:

• Annual subscription: $12,000, billed as four $3,000 instalments.
• Implementation: $2,000, billed with the first instalment.
• Booked contract value excluding tax: $14,000.

On 1 October, the first invoice contains $5,000 before tax and $500 tax. The customer pays $5,500 on 3 October. Assume a $165 processing fee appears in the balance activity.

On 10 October, an approved $500 service credit plus $50 associated tax is returned as one $550 refund. There are no other fees, FX movements, disputes or adjustments in this fixture.

As of 14 October, the bridge is:

1. Original booked contract value is $14,000.
2. Original first invoice excluding tax is $5,000.
3. Future scheduled instalments excluding tax total $9,000.
4. Issued credit excluding tax is $500, making net invoiced value $4,500.
5. Customer cash received is $5,500; the refund is $550; net customer cash is $4,950.
6. Net balance activity from these specified transactions is $4,950 minus $165, or $4,785.

Each step answers a different question. The original contract bridge is $14,000 = $5,000 + $9,000. The invoice adjustment bridge is $5,000 − $500 = $4,500. The cash bridge includes tax, so it does not equal the invoice figure excluding tax.

September bookings and October cash also belong to different reporting periods. Moving the deal's close date to October would conceal the commercial history.

The credit does not automatically rewrite original bookings. Record it as an adjustment and determine whether the commercial contract was also amended. If your business reports net bookings after amendments, publish that separate policy and preserve the original agreement.

Finally, $4,785 is balance activity in this example, not an assertion about a bank deposit. Payout timing and other account activity can produce a different bank amount.

Treat credits and refunds as connected events

A credit note and a refund can describe different parts of the same adjustment. Subtracting both from a single cash measure can double-count the reduction.

Stripe credit notes decrease an invoice obligation. They can also bring an open invoice's remaining amount to zero, changing its status to paid without recording a payment. For paid invoices, the credit can be allocated through a refund, customer balance credit or an outside refund. Stripe credit-note documentation.

In the example, the $500 credit excluding tax reduces the invoiced-value measure. The $550 refund reduces the cash measure. Neither should be subtracted a second time simply because both source objects arrived in the warehouse.

Store the relationship between the adjustment and its settlement. If you cannot identify the connection, flag it for review rather than using an equal amount and nearby timestamp as conclusive proof.

This also explains why “invoice status = paid” is an inadequate cash test. Inspect the supporting payment and adjustment records. Fully credited invoices and cash-funded invoices can require different treatment in marketing reports.

Use balance activity for the processing layer

Stripe's Balance report covers activity affecting the Stripe balance in settlement currency. Its itemized data can expose identifiers such as balance transaction, charge, invoice and customer, alongside gross, fee and net amounts. It also provides customer-facing amount and currency fields. The report is not itself a transaction-to-payout reconciliation. Stripe Balance report documentation.

Use those identifiers to descend from a discrepancy to the underlying activity. Retain both original customer currency and settlement currency when FX is involved.

Do not join invoice lines directly to every balance transaction and then sum invoice totals. That creates a multiplication problem: one invoice with several lines and several payment or refund records can appear many times.

Aggregate each measure at its own grain first. Then connect the aggregates through the bridge for presentation. Keep a count of source IDs before and after each join so a new relationship cannot silently inflate totals.

Make exceptions useful to the person fixing them

A reconciliation job should produce a queue with reasons, not a single red percentage.

Useful reasons include:

• No commercial agreement: a real self-service purchase may be allowed to exist without a sales deal. Route it to the agreed self-service category.
• No billing relationship: the CRM deal is present, but its agreement ID has not reached the subscription or invoice mapping.
• Timing difference: a signed agreement is correctly awaiting its billing date or payment due date.
• Amount-basis difference: one side includes tax, implementation, credits or a different contract term.
• Duplicate association: the same invoice has inherited two full-value deal mappings.
• Incomplete source extraction: missing invoice lines or payment allocations prevent a valid comparison.
• Unexplained adjustment: a credit, refund or dispute exists without an identified commercial context.

Each exception needs the affected amount, currency, source IDs, first-seen date, owner and next action. “Revenue mismatch” is not an actionable reason.

Set tolerances narrowly. Currency rounding may justify a small residual. It does not justify accepting unmatched customer records or an unexplained percentage of annual contract value.

Open full diagram

Preserve history when you repair the system

A sales operations fix can change an association today without changing what the report showed last month. Keep an audit record of the mapping, who approved it, when it took effect and which periods were restated.

Separate a source correction from a reporting-policy change. Correcting a wrong agreement ID is different from deciding to exclude tax starting this quarter. The latter requires a new metric definition and a documented comparison policy.

For teams building a Stripe and HubSpot integration, establish property ownership before enabling bidirectional updates. A reconciliation report should identify a discrepancy; it should not quietly overwrite the deal amount with a payment total.

Review exceptions by both count and value. Fifty unmatched $10 purchases and one unmatched $50,000 agreement need different attention. Track newly created, resolved and ageing exceptions separately so a growing backlog cannot hide behind a stable match rate.

Start with one billing pattern and a complete month. Add annual prepayments, instalments, amendments and multiple currencies as explicit cases. A smaller model with explained differences earns more trust than a broad report that hides uncertainty behind a matching total.