When Stripe and your CRM disagree: finding the real source of truth

When finance says the money landed in Stripe but sales cannot see a matching deal in HubSpot—or a donor receipt never created the record your nonprofit expects—the instinct is to blame the CRM. In most teams I work with in Melbourne, the CRM is doing what it was told; the problem is that more than one system thinks it owns the same story.

Stripe holds the authoritative truth for *money moved*. Your CRM holds the authoritative truth for *relationship stage, tasks, and pipeline*. Xero or another ledger often holds *recognised revenue and tax*. When those boundaries blur—duplicate webhooks, half-migrated Zaps, or a form that creates a contact while Checkout creates another—you get the feeling that “nothing talks to anything.” The goal of this guide is calmer triage: decide which system should win for which event, then trace why the line broke.

These patterns show up across gyms on subscriptions, clinics taking deposits, and charities running campaigns. Names are anonymised; the mechanics are the same.

You do not need to read JSON payloads. You need a timeline for one known payment: time, amount, customer email, and what you expected to happen in the CRM.

In Stripe, open the payment and check Events (or Logs in older navigation)—note whether your CRM or middleware received a `200` response. In HubSpot, Zoho, or your tool of choice, search the contact by email and read activity/history around the same minute. If you use Zapier, Make, or Cloud Functions, open that run log for the same window.

Screenshot the three timestamps side by side. If Stripe fired at 10:02 and your CRM last saw anything at 09:40, you already know the break is after Stripe, not “CRM randomness.” If Stripe shows repeated delivery attempts with `4xx`, the receiving URL or auth is the smoking gun—not marketing attribution.

Subscriptions and cards on file: Stripe customer and subscription IDs should drive “is this person paying us right now?” Replicate status into the CRM as *read-only fields* updated by automation, not manual edits.

Pipeline and tasks: The CRM should own stages until a deal is closed-won. After that, finance might own the invoice record in Xero—but the CRM should still reflect outcome for reporting.

Donations and campaigns: The payment provider plus the official receipt email is the compliance anchor; the CRM should mirror donor history for stewardship. Pick one place staff are allowed to “fix money” and document it.

When two systems both try to be the master for the same fact, reconciliation spreadsheets appear—that is a symptom we unpack in the spreadsheet reconciliation guide.

Healthy plumbing has three properties: idempotency (the same webhook twice does not duplicate), replay (you can re-send a missed event safely), and alerting (silent failure is treated as an outage). You might achieve that with native Stripe→CRM features, with a thin integration layer, or with a small function—depends on your sprawl.

This article will not replace a scoped repair, but it should stop you from debating “which SaaS is bad” when the issue is ownership and observability.

Bring someone in when duplicates are systemic, when finance cannot close the month because CRM and Stripe disagree on revenue, or when you have retried webhooks and still see intermittent `5xx` with no owner. If the triage above takes more than an hour for a single payment class, your integration path probably needs a proper map—not another patch.