ERP or CRM: what a company really needs to connect

In many industrial companies, a sales rep finds out what their customers have ordered once a month, in an Excel export prepared by sales administration from the ERP. Between two exports, they are selling blind. They follow up with an account that has just placed an order, and they do not see the one that has stopped ordering. Yet the information exists. It sits in a tool their team never opens.

This gap says more than the eternal “ERP or CRM, which one to choose?” debate. The question is badly framed. The two tools cover different needs and coexist in most structured organizations; neither properly replaces the other.

The real choice is about the connection: which data to move between the two, in which direction, how often, by which method. When this choice is made well, it puts the right data in front of sales, marketing and customer service teams. When it is avoided, it produces double data entry, wrong reports and sales reps who are informed a month late.

Here is how we scope these decisions in our projects: the four flows that justify a connection, the work to do before the technical part, the available integration methods, and what makes a synchronization last over time.

Why the ERP/CRM confusion persists

The boundary between the two tools has never been perfectly clear, and this is what keeps the confusion alive. Some CRMs have expanded over time toward billing, advanced automation, sometimes inventory management: they cover ERP functions, without the depth. Conversely, many ERPs offer a CRM module designed as an add-on to their range rather than as a sales tool: sales teams rarely adopt it.

A real CRM has limited ERP functions. A real ERP has disappointing CRM functions. Neither meets the need well when asked to do the other's job.

What we see working in the field has a name, best of breed: each tool in its role. The CRM handles the customer relationship (marketing acquisition, sales management, customer service); the ERP handles everything CRMs structurally do badly (billing, purchase orders, inventory, supply chain, manufacturing, industry-specific business processes). Put together this way, the ERP-CRM pair becomes the backbone of the business, instead of two systems competing for the same role.

Pushing an ERP to act as a CRM is expensive in custom development, for a result inferior to what a CRM on the market offers. Extending a CRM to an ERP's business logic leads to the same conclusion, the other way around. In both cases, the company pays for a tool that reaches neither the depth of one nor the simplicity of the other. Many CRM change projects actually start there: a tool pushed outside its role ends up being replaced.

Four flows that justify an ERP-CRM connection

Each organization has its own flows; yet four families of cases come up in most of the CRM integration projects we carry out.

The quote-to-order cycle. The sales rep works in the CRM: accounts, contacts, opportunities, quotes with electronic signature. Except that the quote must rely on a reliable product catalog, with up-to-date references and availability, and this catalog lives in the ERP, which pushes it to the CRM through a regular synchronization. Once the quote is signed, an automation creates the order on the ERP side, where all the follow-up takes place: preparation, delivery, status. This information then comes back to the CRM, and the sales rep tracks their orders without changing tools.

Orders taken on the ERP side. Common in industry and healthcare: the customer does not always go back through the sales rep. Restocking, consumables, purchase orders sent directly to sales administration and entered in the ERP. Without feeding this back to the CRM, you are back to the monthly export from the introduction: a portfolio managed blind. Feeding back who ordered, when and what, even partially, lets the sales rep react to a drop in orders or seize a cross-selling opportunity within the week, not at the next export.

Billing and collection. The ERP issues invoices and tracks payments. Feeding these statuses back to the corresponding opportunity in the CRM changes two things. The sales rep sees the late payment and can follow up with their customer by phone, often more effective than an automatic reminder email. And customer service has the same information when facing a customer disputing an invoice, without digging through a tool that is not theirs.

Staffing and training. In IT services and consulting firms, a deal won in the CRM triggers the assignment of consultants in the HR ERP. In training organizations, participant management lives in a specialized ERP; feeding this data back to the CRM lets marketing work on pre-training (reminders, invitations) and post-training (satisfaction, re-enrollment).

One point already separates these four cases: the frequency each one needs. A product catalog can be synchronized once a night without bothering anyone. The creation of a customer account the sales rep needs to continue their sale cannot wait until the next day.

Scope before connecting

Most projects that go off the rails rushed this step to get to configuration faster. Before writing a single line of connector, the question to settle is simple to state and demanding to document: who does what, in which tool, why, and when.

Business uses follow from this mapping, and the data actually needed follows from the uses. A purely marketing project does not need billing data. A customer service project does not necessarily need payment details. Synchronizing “everything available” by default produces the opposite of a useful system: a database polluted with data nobody uses, heavier to maintain, slower to evolve.

The technical rule that follows fits in one line: the fewer objects, flows and properties you synchronize, the more maintainable the system remains. The right synchronization is the simplest one that covers the need, not the most complete one.

Then comes the most useful and most often neglected exercise: confronting the ambition with the reality of processes. A classic case, almost a trap: “the sales rep signs the quote in the CRM, everything goes automatically to the ERP, the account is created and the invoice is sent to the customer”. Technically feasible. Except that real billing is rarely that simple: payment in three installments, invoice at the end of the project, a customer purchase order to wait for, credit checks and company registration number verification that the sales rep never handles. The synchronization can work. It cannot invent a company registration number or retrieve a purchase order that does not exist yet.

“Very often, people imagine use cases that can work technically, but that cannot work in light of your processes,” sums up Christian Neff, CEO of Markentive.

These confrontations justify producing, before any technical work, a detailed flow diagram: what happens on the customer side, on the CRM side, on the ERP side, in what order, through which manual or automatic action. Three questions are systematically settled there: the order in which objects are created (some ERPs require the company to exist before the contact), duplicate handling, and the source of truth. On this last point, looking for a single master is a false debate. The date of the last order naturally lives on the ERP side, the date of the last sales interaction on the CRM side: the answer is decided field by field.

This scoping is counted in weeks, not months: two to three for a standard scope, built around a business workshop and a technical workshop. An integration project that starts with choosing the connector has already made a bad decision.

Which integration method to choose

Then the method has to be chosen. The options range from the lightest to the heaviest, and they should be examined in that order.

The native connector should be checked first: when it exists (HubSpot with Business Central or Odoo, for example), it can be set up in a few clicks, without code, with its own alert system. Its limit is structural: it imposes its own uses, and a single piece of data it cannot handle is enough to block the entire use case.

The webhook or direct API suits simple, non-critical flows, in real time, with no infrastructure to host. Quick to set up, often without code. Its limit: reprocessing. The data must arrive in the right format, ready to use.

The cloud-hosted middleware (Lambda functions on AWS, Azure Functions) takes over when objects do not map one to one, typically when the ERP distinguishes invoice, order and project where the CRM only sees an opportunity with a status. It transforms, aggregates and reprocesses data at will. The price: technical skills, internal or external, to be mobilized over time.

No-code or low-code iPaaS tools (Make, Zapier, Power Automate, OIC at Oracle) occupy the middle ground: accessible without a developer, with execution tracking and built-in queues. A serious option for mid-sized organizations that do not want to weigh down their information system, but whose actual running cost can sometimes be high.

ETL keeps its place for very large volumes, reliable and proven, rarely in real time. SFTP batch file transfer remains for older ERPs that do not expose an API: real-time uses become out of reach, but most flows remain possible.

A last option, less often mentioned, is worth knowing: RPA. It does not move data through an API; it reproduces the data entry an operator would do, screen by screen. Less elegant technically, it remains robust and makes it possible to connect systems that cannot be connected by any other means.

The absence of a native connector between two given tools is not the warning sign people think: it is mostly a vendor marketing argument. Most of the ERP-CRM integration projects we carry out do without one.

What silently breaks a sync

Most synchronization errors remain invisible to the end user. A field length exceeded, an API temporarily unavailable, an unmet business dependency (an opportunity created without the associated company being complete): none of this appears on screen. The flow stops silently, and teams only notice that tracking is no longer updating, without understanding why.

Hence two separate mechanisms to plan. A real-time alert channel, often as simple as a dedicated Slack or Teams channel that receives the details of each error. And monitoring of the flow itself: if nothing has gone through for two hours while the synchronization usually runs continuously, someone needs to know the same day.

An anecdote comes up often in our projects, almost always in the same form: a user deletes a property from a form, convinced they are cleaning up a useless field. This property conditioned the entry of data into the ERP. The whole synchronization stops, for a reason that has nothing technical about it. This kind of incident is not fixed with more code: it is prevented through governance, and through monitoring that flags the anomaly before it settles in.

Synchronization frequency is decided on a business criterion, not on a technical preference. If an opportunity created in the CRM takes three days to exist on the ERP side, the sales rep is blocked for three days. The need for real time shows in this kind of consequence, not in a general desire for modernity.

Then there is the question of volume: how many objects created per day, what seasonal peaks, what growth to absorb over the next two or three years. A synchronization that holds at 1,000 orders a day and breaks at 10,000 has only half solved the problem.

Deployment, for its part, is planned in small structuring flows, tested and put into production one by one, never as a big bang. A test plan that lists the expected cases and the planned behavior in each tool lets business teams validate before go-live rather than discover gaps afterwards.

Who really leads the project

Connecting an ERP to a CRM, SAP or Oracle on one side, Salesforce or HubSpot on the other, has become almost a technical commodity today. What separates a project that holds from one that degrades within six months lies elsewhere: who decides what gets connected, who maintains the flow in production, who arbitrates when two departments disagree about the data.

“These two worlds need to talk to each other. A project manager who understands the language of IT teams as well as that of business teams: that is the translator role we take on for our clients,” explains Camille Saute, RevOps consultant and technical project manager at Markentive.

Three conditions come up in projects that last. First, real collaboration between IT and business teams, where each makes the effort to speak the other's language: a poorly worded business detail can hide a real technical limit, and a poorly explained technical limit comes across as a refusal. Second, a sponsor at management level, often the CIO, who is truly involved and not just the one who signed off the launch. Finally, a maintenance resource planned from the scoping stage, not discovered six months after go-live when nobody is available anymore to evolve a flow that has become critical.

A last, less comfortable remark: the quality of the integration does not make up for an ERP whose management was already shaky before the project. Duplicates and unresolved processes on the ERP side mechanically flow into the integration you are trying to build.

The Kerialis case: the ERP connected to HubSpot via API

Kerialis, a provident institution with 85 employees, was living exactly the scenario described in the introduction: fragmented data, no shared tool between sales and marketing teams, and business information locked in legacy tools.

The project followed the logic of this article. HubSpot was deployed as the CRM and shared foundation for the teams, sales and marketing processes were structured upfront, then data flows between business tools (ERP, subscription funnel) and the CRM were integrated via API, with flow maintenance ensured after deployment.

The results, detailed in the full customer case: ten times more opportunities created since the flow between the subscription funnel and HubSpot was set up, 300% more sales activities logged compared with the previous year, and 12% more new leads generated through the website.

The Kerialis team's testimonial on video:

Learn more

• CRM integration: our offer: scoping, configuration and IS integration by a team of experts.
• HubSpot CRM and Sales training: securing adoption by sales teams once the flows are in place.