Your order data lives in the ERP, your orders in the shop, your contacts in the CRM, and at the end of the month everything lands at your accountant's once more. As long as someone reconciles these records by hand, you are working with four versions of the truth instead of one. ERP integration connects your ERP system with the rest of your applications, so data flows automatically instead of being exported and typed back in.
Which connection is right for you depends less on the ERP itself than on the number of systems that need to talk to it. This one figure decides the effort, the cost, and whether the setup is still maintainable in two years.
Key takeaways:
ERP integration means connecting your ERP system with the other applications in your company, so data moves between them automatically instead of being transferred by hand. The goal is a state in which your shop and CRM work with the same numbers as the ERP.
The interface is the single technical line between two systems, while integration describes the result across all of them. That sounds academic but decides a lot. In a project, you are either talking about one connection or about the question of which data will be maintained where. Often the confusion starts even earlier, with the question of what belongs in the ERP and what belongs in the CRM.
More important than the terminology is what hangs off the ERP, because this is the system where your steering comes together. If the stock levels there are half a day old, that does not hit the IT department. It hits purchasing, planning and the promise you just made to a customer. With current order and payment data, your liquidity planning also becomes more reliable, because it calculates on the actual state instead of the state of the last transfer.
Technically, every connection runs through the same four steps. Data is read from the source system, translated into the target format, checked for completeness and written into the target system. How often that happens, every five minutes or once a month, is a business decision rather than a technical one.
This is where an honest look at the status quo pays off. An export that a colleague pulls every Friday and imports on Monday is already an interface. It just runs through a person instead of a line, and it fails when that person is on holiday.
The bigger part of the work rarely sits in the technology anyway. It sits in the question of which system has the last word on a field. If the address can be edited in both the ERP and the CRM, the system that wrote last wins, and afterwards nobody can say which version was correct. A field always belongs to exactly one system. Everyone else reads along.
In a Bitkom survey, 53 percent of German companies said they struggle to manage their digitalisation. A large share of these problems sits between the systems rather than inside them. The reason can be calculated.
If you connect every system directly to every other one, the number of connections grows according to the formula n²−n divided by 2. Run the numbers for your own setup. Three systems means three connections, five systems already means ten, eight systems means twenty-eight. You add one system and get as many new interfaces as you had systems before.
This curve explains why integration projects in mid-sized companies typically tip over in year three. The first two connections are built quickly and run reliably, because they are manageable and usually looked after by the same person. From the fourth or fifth onwards, nobody remembers which connection needs touching when a field changes, and every change to the ERP drags a test round through half the company.
The effort also shifts quietly from building to operating. Building a single connection is manageable. Keeping twelve of them current is a permanent job. This shift shows up in no quote, because quotes price the build and leave the maintenance to next year's budget.
Planning for this early saves you the expensive rebuild later. The question to settle is mainly the point at which you switch to a clean architecture. We consider three connected systems the threshold where the switch pays off, and ideally before the fourth connection is built.
The common assumption is that there is one modern way and several outdated ones. In practice the types exist side by side, because they solve different jobs, and a typical mid-sized company ends up running two or three of them at the same time.
| Type | Format | Real time | Effort | Typical use in an SME |
|---|---|---|---|---|
| REST API | JSON over HTTPS | yes | medium | shop and ERP, CRM and ERP, shipping providers |
| Vendor connector | vendor-specific | mostly yes | low | standard cases with a ready-made app |
| Middleware / iPaaS | cross-format | yes | higher at the start | from three systems, central monitoring needed |
| EDI | EDIFACT, VDA | no, in batches | high | when a major customer requires it |
| File export | CSV, XML | no | very low | monthly handover to accounting |
The column that gets misread most often in the mid-market is the third one. Real time always sounds like the better option, but it costs operation, monitoring and error handling. For the monthly handover to your accountant, an end-of-month export is enough, and whoever builds it live anyway pays for a freshness nobody uses. The usable rule of thumb is to measure freshness by the damage stale data causes, and not by what is technically possible.
The vendor connector deserves a second look, because the mid-market dismisses it too quickly. ERP systems like Odoo ship many connections as ready-made modules, and the vendor takes care of maintenance and adaptation to new versions. That is exactly the effort that quietly stays with you in a custom build and becomes more expensive than the licence over the years. Even among the common ERP systems for SMEs, the range is wide, from a handful of connectors to a full app store.
One route is missing from the table on purpose, direct access to the ERP database. It looks like a shortcut, but it bypasses the system's validation logic and breaks with every version upgrade. We advise against it.
When is it worth jumping from individual connections to a central solution? The answer follows from the formula above. As long as you are coupling two systems, a direct connection is faster to build, cheaper and easier to understand. From the third system onwards the balance tips, because every additional connection increases the number of links faster than the number of your systems.
| Starting point | Recommendation | Why |
|---|---|---|
| One shop, one ERP | direct REST API | one connection, no hub needed |
| Three or more systems | middleware | one connection per system instead of quadratic growth |
| Monthly handover to accounting | file export | no live requirement, minimal operation |
| Major customer requires EDI | EDI in addition | mandatory format, does not replace the other connections |
Middleware brings advantages that rarely appear in a quote and make the difference in daily operation. You see in one place which transfer failed, you maintain field mappings centrally, and you can swap a system without touching all the others.
The price is a higher initial investment and one more piece of infrastructure that can itself fail. We regularly see companies take this step too late and then have to take it under time pressure.
In practice, most setups end up as a mix anyway. The critical systems run through the middleware, while the monthly export to accounting stays a simple direct connection, because a hub adds nothing there. This mix is the cheapest option in most companies, as long as you consciously decide which connection belongs in which category.
And do not start the migration with the most complicated connection. Take a mid-sized, well-understood connection through the middleware first, gather experience with field mappings and error alerts, and move the critical systems afterwards.
Picture a trading company with forty employees in Winterthur. ERP, shop, accounting and a CRM are in place, and this year's budget covers one proper integration. IT suggests the shop, because stock levels keep causing trouble there. Management thinks of accounting, because the month-end close eats three days every time.
In most cases, the connection between ERP and CRM delivers more. The reason is unspectacular. Order data from the ERP is the only reliable statement about what a customer has actually bought. Without it, your sales team works with intentions. With it, they work with history, open items and reorder cycles.
This connection is also the one with the most ready-made paths. HubSpot, for example, offers a bidirectional sync through Data Sync that reconciles standard and custom objects in both directions, including field mapping and conflict rules. For common ERP systems there are ready-made apps in the marketplace, and where none fits, the route runs through a private app.
What matters is the direction per field. The customer master usually belongs to the ERP, the communication history to the CRM, and prices should only ever be maintained in one place. Settling this up front spares you the situation where two systems keep overwriting each other.
For the trading company from the example, this means an uncomfortable order of priorities. The shop keeps its nightly stock sync for now, the accounting close is still served by an export, and the budget goes into the connection that takes work off the sales team every single day. The jammed stock levels are more visible, but the revenue lever sits in the order data inside the CRM.
Why does marketing almost never appear in ERP projects? The integration is treated as a matter for IT, purchasing and finance, and that is exactly why the revenue lever hidden in the order data stays untouched. An ERP knows who bought what, when, at what price, and how often they came back.
With this data, segmentation becomes a calculation instead of a guess. You can address customers by actual revenue, trigger reorder campaigns at the right interval, and stop campaigns for products that are no longer in stock. The reverse direction pays off too, because campaign data in the ERP shows which channel brought the orders with the better margin.
In practice this takes less than most people assume. Three fields are enough to start, a customer number as the unique key, the last order with date and amount, and the product master with availability. Check first how healthy that data is. With that in place, you can put your marketing automation on real numbers instead of assumptions.
A day-to-day example shows the difference. Without order data, you send a reorder campaign to every contact in a category and hope the timing works. With order data, you know the average interval between two orders per product and trigger the campaign exactly when the customer's supply runs low. The copy stays the same. The occasion becomes a different one.
The same mechanism protects you from embarrassing sends. A product flagged as unavailable in the ERP should leave the running campaign, and existing buyers should stop seeing the first-purchase track. Both run through the connection that is being built anyway.
In our view, this is the most underrated part of an ERP integration. It costs little extra effort while the connection is being built, and it is hard to retrofit later, because the field mapping has to be opened up again.
Quotes for integrations vary widely because they rarely contain the same thing. A ready-made connector from a marketplace sits in a different price class than a custom build with field mapping, a test environment and error handling, and both are called an integration in the quote. Always ask about ongoing operation as well, because that is where the larger share of the cost builds up over the years. That way you separate the wheat from the chaff early.
As a rough orientation from our projects, these orders of magnitude have become established.
Take these ranges as a way into the conversation and not as a quote, because the operation behind them is what decides the real cost.
Run the numbers on your current state once, with your own assumptions. Say two people spend three hours a week each transferring data by hand and you calculate with CHF 80 per hour internally. Then the manual route costs you around CHF 480 per week. This figure only applies to your company, and that is exactly why it works as the baseline for every quote you compare.
For evaluating the integration after go-live, four metrics have proven useful:
Before signing, five points belong in writing in the quote.
These five questions separate solid quotes from optimistic ones. The last one gets skipped the most, and it decides whether a mistake in the field mapping is a correction or an incident involving real customer data.
The choice of connection is rarely a matter of taste. It follows from the number of your systems, from the actual need for freshness, and from the question of who owns which field. Whoever settles these three points before the first quote gets comparable offers and a setup that still holds after the next system change.
Which connection would take the most work off your team starting tomorrow? If the answer points towards your CRM, that is your starting point. We set up ERP and CRM integrations regularly, as a Odoo Partner and in other system landscapes alike, and we take care of the data orchestration behind them. Get in touch.
A REST API usually transfers data as JSON over HTTPS and suits ongoing exchange between two systems, for example between a shop and an ERP. EDI is a heavily standardised format for business documents between companies, mostly in EDIFACT or VDA and often in batch mode. EDI almost always enters the picture when a large retail or industrial customer requires it contractually.
The rule of thumb is a threshold of three systems to connect. Below that, a direct connection is cheaper and faster to implement. Above it, the number of individual connections grows quadratically and the maintenance effort grows with it. Middleware is also worth it earlier if you need central monitoring and error alerts.
The price depends on the interface type, the data volume, the number of fields and whether a ready-made connector exists. As an orientation, marketplace apps often stay under CHF 2,000 a year, custom REST API connections land in the four-figure range and EDI connections sit above that. Always budget the ongoing operation as well, meaning monitoring, adjustments at version upgrades and support.
A standard connection through an existing connector is often live within a few weeks. Custom interfaces take longer, because field mapping, test data and acceptance make up the larger part of the time. The schedule is usually determined by clarifying which system owns which field, and only rarely by the programming itself.
If a connector covers your systems and your fields, buying is almost always cheaper, because maintenance and compatibility stay with the vendor. A custom build pays off for special logic that no standard product covers, such as company-specific pricing or approval processes. Check beforehand whether that special logic could live in the ERP itself instead.
With point-to-point connections, practically every integration has to be rebuilt, because each one hangs directly off the old interface. If everything runs through middleware, you ideally swap only the one connection to the ERP and leave the other systems untouched. This is one of the reasons a central architecture pays off earlier when a system change is on the horizon.