Your ERP Has the Data. Your CRM Has the Pipeline. Neither Knows What the Other Is Doing.

The integration meeting that shouldn't have to happen

Your ops lead pulls up the ERP to check project margins. Your account exec opens the CRM to see what was promised at close. Neither system talks to the other, so every project review starts the same way: someone screen-shares, someone else pulls up a spreadsheet, and a third person says "wait, that number doesn't match what I have."

The data exists. It's just in three places that don't know about each other.

This isn't a tooling problem — you already have tools. It's an architecture problem. The stack wasn't designed around how a project-based business actually moves: from deal to delivery, from promise to margin, from close to invoice.

Why the standard integration advice doesn't apply here

Most CRM-ERP integration guides assume a product company: order comes in, inventory goes down, invoice goes out. Clean, linear, event-driven. You can trigger a sync on a closed-won deal and call it done.

Project companies don't work that way. The deal closes, but the real work — scoping, resourcing, executing, adjusting — happens after. And that post-close work generates the data that actually determines whether the project was profitable.

So if your integration only fires at deal close, you've connected two systems at the one moment they naturally align and left them disconnected for the entire project lifecycle that follows.

What the data model has to reflect

The core issue is object mismatch. Most out-of-the-box CRM implementations treat the deal as the terminal object — it closes, it's won, it moves to a reporting column. But in a project company, a closed deal is the beginning of the operational record, not the end of the commercial one.

What you need is a CRM that treats the project as a first-class object — not a field stapled to a contact, not a note inside a deal, but a dedicated record with its own lifecycle, its own associated tickets, its own financial rollups, and its own connection to the ERP record that tracks execution costs.

The integration architecture that actually works looks like this:

• The deal object owns the commercial history — what was sold, to whom, at what scope, with what margin expectation
• The project object owns the operational record — resource allocation, milestones, incidents, change requests, delivery status
• The invoice object (custom or native) owns the financial movement — both outgoing costs and incoming revenue, associated to the project by a shared ID
• The ERP owns financial truth — it's the source of record for actuals, not the CRM
• The CRM displays a real-time rollup of what the ERP knows, without replicating it

The integration pattern that doesn't break

The cleanest integration between a CRM and an ERP in a project environment isn't full bidirectional sync. That creates two sources of truth, which means eventual conflict and the spreadsheet reconciliation meeting you're already having.

The pattern that holds is: one source of truth per data domain, connected by a shared identifier.

Your ERP owns the financial actuals — labor costs, vendor invoices, recognized revenue, tax records. Your CRM owns the operational and commercial context — what was scoped, what the client expects, what the delivery team is executing. The connection between them is a consistent project ID that lives in both systems.

When a deal closes in the CRM, a workflow fires that creates a project record and stamps it with the ERP project ID. From that point forward, any financial event in the ERP that references that ID surfaces as a rollup property inside the CRM deal or project record. No replication. No ETL pipeline. No nightly batch job that's six hours stale when someone needs the number in a 9am call.

The account exec opens the deal. They see: scope agreed at close, current delivery status from the project record, fees invoiced, fees outstanding, and margin against the original estimate — all pulled live from the ERP. No meeting required. No message to ops asking "how are we doing on this one?"

This isn't theoretical. In the BPS Glass implementation — a reseller with SAP and QuickBooks already running — the shared project ID lives in both systems as a consistent field. Every billing event in the ERP surfaces as a live rollup inside the HubSpot deal record. The ops team stopped getting margin questions from sales. The owner can see the full financial picture of any active project from anywhere, without asking anyone.

What this requires from your existing stack

This architecture assumes your ERP can expose data via API or webhook — which most modern ERPs (NetSuite, SAP, Odoo, even QuickBooks with the right connector) can do without custom development. It also assumes your CRM supports custom objects and rollup properties — which is why HubSpot is the implementation platform of choice here, not because of the logo, but because the data model is flexible enough to build this without workarounds.

The piece that usually breaks implementations isn't the API — it's the absence of a defined project ID convention. If your ERP auto-generates IDs in a format your CRM can't reliably match, or if project IDs are assigned manually by ops in an inconsistent format, the integration has no reliable join key. That has to be solved at the process level before any technical work begins.

The audit step — before implementation — is specifically to validate this: what identifiers exist in your current stack, are they consistent, and where do we need to standardize before connecting systems.

The handover problem this solves

There's a specific moment in every project company where information breaks down: the deal handover from sales to ops. The account exec knows what was sold. The ops team needs to know what was promised, what constraints exist, what the client relationship looks like. That transfer happens in a meeting — or a Slack thread — or a document someone forgot to update.

When the CRM is built correctly, the handover is a record, not a conversation. The project object inherits the deal context at close: scope, pricing, client contacts, pre-sales tickets, call notes, the proposal version that was signed. Ops opens the project record and has everything sales knew. The meeting still happens for relationship context — but it's not the only place the information lives.

This is what "connecting CRM and ERP" actually means in practice. Not a data pipeline. A model where every team can find what they need without asking someone else to go get it.

If you're evaluating how this would work in your stack

The technical details above are the implementation pattern we use for project-based companies — specifically the ones where the pain is fragmentation, not absence of tooling. If your current stack has the pieces but they're not talking to each other in a way that gives your team real-time operational clarity, that's the problem this solves.

The implementation for companies that sell projects is documented in full at sap-asap.mx/forcompaniesthatsellprojects — including the object model, the pipeline structure, and what the integration looks like before you commit to anything.