Choosing your ERP integration: iPaaS, API or point-to-point?

A new supplier joins. Marketing wants a second webshop. Finance asks for a report that pulls data from three systems. And before you know it, a question lands on your desk that sounds technical, but is really an architecture decision. Which ERP integration do you choose, and which do you deliberately leave out?

We notice that most organisations only ask that question once the third or fourth integration is on the planning. By then two are already built without a shared philosophy. The bill arrives a year and a half later, in support that becomes too expensive and in connections that break every six months whenever a vendor bumps their API version.

At ERP Company our 260+ specialists see that pattern almost weekly. This article puts the four main integration types side by side. Our aim is to help you choose with the same discipline you would apply to any major investment. The shortest honest answer first: more often than you think, the best ERP integration is no integration at all. And when you do build one, most of your cost over three years lives in the architecture, not in the tool.

When an integration adds value, and when it does not

Start with the counter-question before you sign off. Which concrete problem does this integration solve, and how big is that problem measured in working days lost or errors per year? If the answer is vague, it is too early to integrate.

Three patterns do create value. First, two systems holding the same master data that gradually drift apart. Second, a process repeated by hand across two systems several times a day. Third, a report that cannot be correct without the integrated data. In every other situation the honest conclusion is often that a manual weekly transfer is good enough, or that the two systems do not need to talk in the first place.

For the wider strategic angle, our hub on ERP integration and how systems work together is the natural starting point. It places the strategic question before the build question.

Four types of ERP integrations side by side

In practice you encounter four main types. A short definition and a rule of thumb for each.

Point-to-point. One system talks directly to another, often through a specific script or proprietary connector. Quick to build, cheap in the first twelve months. The catch is that every new connection grows the complexity quadratically. Four systems already need six lines of upkeep, five systems need ten. Works well for two or three systems that are stable for the long run.

File-based. Both systems exchange flat files, usually CSV or XML, over a network share or SFTP. Robust and simple, but almost always batch and therefore not real-time. Suitable when daily or hourly synchronisation is enough. Not suitable for customer data being edited in multiple places at once.

API or REST integration. One system calls an endpoint of the other, usually in JSON, through a structured contract. Real-time, scalable and standardised. The weakness sits in API-version stability on both sides. Works well for modern SaaS systems that actively maintain their API. Works less well when one of the two systems offers an API whose version shifts every six months.

iPaaS or middleware. A central layer (Boomi, MuleSoft, Workato or comparable hyperscaler platforms) absorbs all integrations. Each source and target system connects once to the hub. The upside becomes visible once you sit above four or five connected systems: fewer lines of upkeep, one place to monitor, reusable flows. The downside is licensing cost and a new specialism to bring in-house or via a partner.

A side-by-side overview

Type	Number of systems	Real-time?	TCO over 3 years	When to choose
Point-to-point	2-3 stable	Yes, direct	Low at start, rises fast	Small estate, few changes
File-based	2-many	No, batch	Low, predictable	Daily or hourly sync is enough
API/REST	2-many	Yes, scalable	Medium, depends on version stability	Modern SaaS, stable APIs
iPaaS/middleware	5+ or growing	Yes, scalable	Higher on licence, lower on support	Growing system estate

Which type fits depends on the number of systems to connect, the desired pace of change, and the maturity of your IT organisation. Four systems or fewer, stable and in production? Point-to-point or API will do. Five or more systems, or a growing estate? Then the iPaaS conversation is worth having properly.

What an ERP integration actually costs over three years

The quote shows a build price. Compare that with the real cost over three years, and you are looking at a different number.

In our work the three-year TCO of an ERP integration sits across four layers. Build costs are about thirty per cent: design, development, testing, first go-live. Support and monitoring come to thirty to forty per cent: incidents, small adjustments, version bumps. Repair after API changes on either side is often fifteen to twenty per cent: the work to keep the connection alive after each system update. The remaining fifteen to twenty per cent sits in indirect costs you rarely see on an invoice. Data issues that flow from the connection, double bookings, productivity loss while the connection stabilises. These figures come from our pattern recognition across many engagements, not from an external benchmark.

That picture changes the conversation. An integration that looks fifteen per cent cheaper on the quote can end up forty per cent more expensive over three years if the architecture does not fit your estate. For the wider cost reasoning, our note on the cost structure of an ERP project is a useful starting point for your business case.

Five questions before you let an integration get built

Before an integration lands on the roadmap, we run through these five questions as standard. Each answer is a signal for the architecture choice.

How many systems do you connect today, and how many within three years?
Is the data needed in real-time, or is an hourly or daily batch enough?
Will both owners keep their API version stable for at least twelve months?
Who carries final responsibility for support and monitoring after go-live?
What is the scenario if this integration is down for three days?

Three or more times “it is unclear” means you are not ready to choose. The wish is there, the architecture is not. Good architecture never follows an ad-hoc build request; it precedes it.

How to choose an ERP integration that holds up over time

A future-proof architecture starts small, but with a principle. Three choices make the difference between a setup that still works in three years and one you have to rebuild then.

One source of truth per data domain. Customer data, product data, stock, finance: each lives in one system. Changes travel from that source to the consumers, not the other way around. That stops the same customer from carrying three different addresses across three systems.

Standards over custom work where you can. Modern API standards, standardised data models, reusable flows. Custom work belongs in the rare places where your business process is genuinely distinctive. Not in standard order integrations.

Monitoring from day one. An integration that is not monitored breaks without anyone noticing. Because end users only flag the issue when the error is visible in their work, weeks can pass between the break and the fix. Build monitoring at the same time as the integration.

For organisations who want more support here, our page on independent guidance for integration and architecture is the frame in which we work this out for clients.

When you are better off not building an integration

Honest advice includes the opposite of the quote. Three situations call for not building.

The problem you are solving is small in working days per month. A few hours of manual work per week is cheaper than an integration you have to keep alive for three years. Do the maths before you sign off.

The two systems are likely to be consolidated or replaced within twelve to eighteen months. An integration you tear down then is investment without return.

There is no clear owner for the integration after go-live. An integration without an owner falls behind on monitoring, updates and clean-up. Do not build it, or fix ownership first.

Frequently asked questions

What is the difference between iPaaS and point-to-point integration?

Point-to-point builds a direct connection for each pair of systems; iPaaS uses a central layer that each system connects to once. Below four systems, point-to-point is usually cheaper. From five systems onwards iPaaS scales better because upkeep stops rising quadratically.

When do I choose an API integration over file-based exchange?

Choose API when real-time data is needed and both systems offer a stable, well-documented API. Choose file-based when an hourly or daily sync is enough, or when one system lacks a mature API. Robustness often outweighs speed.

How much does an ERP integration cost over three years?

Build costs are typically thirty per cent of the three-year total. Support and monitoring account for thirty to forty per cent, repair after API changes for fifteen to twenty, and indirect costs such as data issues for another fifteen to twenty. Compare on the three-year total, not the build quote.

What are the signals that an integration is not working well?

End users who keep correcting data between systems by hand, periodic outages after a vendor update on the other side, and no owner who can explain how the integration works. Two or more of these together signal that the architecture needs revisiting.

To close: integrating is an architecture decision

An ERP integration looks like a technical ticket and is often handled that way. In reality it is an architecture choice with effects that work through your support load and the controllability of your data estate for three to five years. Treat it as architecture and the sum of your integrations supports where your organisation is heading. Done ad-hoc, you pay twice over three years for what you could have bought once.

Would you like your integration architecture tested independently, without us trying to sell you a specific iPaaS product? We are happy to spar, even if the outcome is that you should not build a particular integration. Written by ERP Company, with more than 260 independent specialists across the Netherlands and Belgium. For deeper reading our article on iPaaS combined with an ERP implementation is a logical next step.