How Your CRM Should Talk to Your ERP (Without Becoming Another Source of Truth You Can't Trust)

The problem isn't that your tools are disconnected. It's that nobody decided which one tells the truth.

You have a CRM. You have an ERP. You probably have QuickBooks, NetSuite, SAP B1, or something custom that finance refuses to give up. Maybe a project management tool on top. The vendor who sold you each one promised "easy integration."

So now your sales team updates a deal in HubSpot. Operations updates the same project in the ERP. Finance updates the invoice in QuickBooks. Three updates, three timestamps, three slightly different versions of the same reality.

The question nobody asked during implementation: which system owns which field? When the deal amount in the CRM doesn't match the invoice total in the ERP, who's right?

If you can't answer that in one sentence per field, you don't have an integrated stack. You have three databases pretending to talk to each other while your team manually reconciles the differences in their heads.

Why "native integrations" almost never solve this

Most CRM-ERP integrations sold off the shelf are bidirectional sync: change something in System A, it copies to System B. Sounds clean. It's a trap.

Bidirectional sync without a designated source of truth means conflicts. Sales updates the deal value in the CRM. Finance updates the invoice amount in the ERP. The sync runs. Which one wins? The last one written? The one with the most recent timestamp? The one with the higher permission level? In practice, the answer is: whichever the integration vendor decided, and you find out when your numbers stop matching.

The second problem is replication. Native integrations copy data across systems. Now the same customer record exists in three places. When the customer changes their billing address, you have three records to update — and if the sync breaks for a day, you have three records that disagree until someone notices.

The pattern I've seen across implementations: companies spend more time fixing sync errors than they ever spent doing manual reconciliation. They moved the problem; they didn't solve it.

The model that actually works: ID-based integration with explicit ownership

The architecture is straightforward when you state it clearly:

One system owns each domain. The ERP is the source of truth for financial data — invoices, payments, costs, margins as recorded. The CRM is the source of truth for commercial data — deal stages, customer interactions, pipeline. Project management owns delivery state — milestones, hours, deliverables.

Each record carries a shared ID across systems. When a deal closes in the CRM, it generates an ID. That ID lives on the corresponding invoice in the ERP, the project record in your delivery tool, and any related ticket. Nothing is replicated. The ID is the bridge.

When the CRM needs to display financial data — say, total invoiced versus total billed on a deal — it pulls it from the ERP using the ID. The CRM doesn't store the number. It displays it. If finance corrects an invoice, the CRM reflects the correction automatically because it was never holding a copy.

This is the difference between integration and synchronization. Integration means systems reference each other. Synchronization means systems copy each other. Reference scales. Copy creates entropy.

What this looks like in HubSpot specifically

In a properly architected HubSpot implementation for a project-based business, the deal object holds the commercial reality: stage, owner, expected value, close date, associated contacts. The deal has a custom property — usually called something like erp_deal_id — that matches the project or order ID in the ERP.

Invoices live in the ERP. In HubSpot, you create either a custom "Invoice" object or reuse the native invoice object as a reference layer — each invoice record carries the same erp_deal_id and the invoice number from the ERP. The actual invoice document, payment status, and accounting entries stay in the ERP where they belong.

Then you build a rollup property on the deal: sum of all invoice amounts where erp_deal_id matches. Now the sales director opens a deal and sees real-time margin — invoiced versus committed cost — without leaving the CRM and without anyone manually updating a field.

The integration itself can run through middleware (Workato, Make, Zapier for simple cases) or direct API calls. The middleware choice matters less than the architectural decision: which system owns what, and what ID connects them.

The questions to ask before any integration project starts

Before you let anyone configure a single webhook, you need clear answers to these:

Which system is the source of truth for each data domain? Not "both" — one. If you can't pick one, the integration will fail.

What's the shared ID, and where does it originate? Usually the ERP generates it on order creation and the CRM stores it as a property. Sometimes the reverse. Either works; ambiguity doesn't.

What's the failure mode? If the integration breaks for 24 hours, what happens? If you don't know, you'll find out at the worst possible time.

Who owns the integration after go-live? Most integrations are built once and abandoned. They drift. Someone needs to own monitoring and fixes.

If your current vendor can't answer these without hedging, they're going to sell you sync and call it integration. You'll find out in six months when your numbers stop matching.

What this means for your evaluation process

If you're evaluating CRM implementation partners right now, the integration question is where most of them collapse. They'll say "yes, we integrate with [your ERP]" and show you a connector. That's not the answer.

The right question is: "Show me how you decide which system owns which field, and walk me through what happens when finance corrects an invoice after a deal closes." If the answer is technical and specific — IDs, references, ownership rules — you're talking to someone who's done this before. If the answer is about features and connectors, you're talking to someone who's going to sell you sync.

A well-architected HubSpot implementation for a project-based business treats integration as a design decision, not a configuration step. The model — which objects exist, which fields live where, how IDs connect them to the rest of your stack — gets defined and approved before anything is built. You can see the full model and architecture here, including how the integration layer is structured before implementation begins. By the time you're configuring HubSpot, the architecture decisions are done.