ERP integrations: everything you need to know.

What is an ERP and why is integration so important?

An ERP (Enterprise Resource Planning) is the central administrative system of your organisation. It manages finance, inventory, purchasing, production and often HR. Well-known names on the Dutch market include SAP (S/4HANA, Business One, Business ByDesign), Oracle (NetSuite, Fusion Cloud, JD Edwards), Microsoft Dynamics (365 Business Central and Finance & Operations), AFAS, Exact (Online and Globe), Unit4 and, for scale-ups growing internationally, NetSuite.

An ERP does a lot on its own, but rarely everything. Marketing runs in HubSpot or Salesforce. The webshop sits in Shopify or Magento. Payroll runs through Nmbrs or Visma. Reports are built in Power BI or Tableau. Without integrations, someone keeps retyping orders, hours or customer details, with all the errors and delays that come with it. That's why a well-integrated ERP is the rule rather than the exception.

Why you should integrate your ERP

The question is rarely "whether", but almost always "when and how". Over the past few years we have built dozens of ERP integrations, and we keep seeing the same drivers.

Single source of truth

One place where the real figure lives. One place where customer details are correct. No more debates about whether the webshop, the CRM or the ERP is "right": the ERP is right, and the rest synchronises. This alone prevents a great deal of friction between sales, finance and operations.

Automating repetitive work

Orders that land in the ERP automatically. Supplier invoices that are read in automatically. Hours from a field-service app that end up in the payroll run. The effect is not only time saved, but also less pressure on people to type everything without errors.

Speed and growth

What works manually at a hundred transactions a day doesn't scale to thousands. Many growing organisations only discover during a peak that their administration has become the bottleneck. A good integration solves that structurally.

Reporting and management information

An integrated ERP feeds BI dashboards with reliable, up-to-date figures: real-time revenue, margins, stock turnover and debtor position, not just after month-end close, but now. For CFOs, this is often the real reason to start an integration project: not the immediate saving, but being able to steer on current numbers instead of a month-old picture.

Customer satisfaction and internal frustration

A less discussed but very real effect: staff who no longer have to retype data are both more productive and happier. Customers who see accurate stock on the webshop and receive correct invoices complain less. It is not a glamorous story, but in practice it is noticeable.

At the same time, an integration is not a disposable project. You are committing two systems to each other, and changing either one becomes more complex. Choosing a new webshop gets harder if that integration has deep roots in your processes. That's no reason not to do it, but it is a reason to approach it deliberately. Read also how we approach this with our smart API integrations.

Types of ERP integration

There are roughly five integration patterns you will encounter in practice. The right choice depends on data volume, speed, complexity and what the other systems support.

1. Direct REST/SOAP API

The other system talks directly to your ERP's API. For modern ERPs (NetSuite, Business Central, SAP S/4HANA via OData), this is the most common route. The advantage is full control and low latency. The downside is that you need to set up authentication, error handling, retries and version management yourself. For a more detailed explanation of what API integrations actually are, see our guide to what an API integration is.

2. iPaaS (Integration Platform as a Service)

Platforms such as MuleSoft, Boomi, Workato, Make or n8n take much of the plumbing off your hands: connectors, mapping, monitoring, retries. For mid-sized organisations with several SaaS tools, this is often a sensible choice. We compare both routes in depth in our guide API vs. integration platform. In short: iPaaS scales faster in breadth, while a direct API scales better in depth.

3. EDI

Electronic Data Interchange is the classic way to exchange B2B data between the ERPs of trading partners. Think EDIFACT or X12 messages for orders, delivery notes and invoices, still common especially in retail, logistics and wholesale. EDI is robust but heavyweight: validation rules per partner, VAN providers, AS2 tunnels. We often combine it with modern API layers to hide the complexity from the business.

4. File-drop

A simple route in which CSV, XML or JSON files are exchanged via SFTP or a shared folder. It works well for batch processes that run once or twice a day, and is often the only option when one of the two systems has no API. Points of attention: idempotency, error handling and clear agreements on who cleans up what.

5. Message queue / event bus

For higher volumes or stricter SLAs, we use Kafka, RabbitMQ, Azure Service Bus or AWS SQS. An event from the ERP lands on a bus, and every interested system consumes it at its own pace. The advantage: a failure in one consumer does not bring down the rest. The downside: heavier infrastructure and more operational discipline.

Typical ERP integrations

Every integration is different, but in practice a few patterns keep recurring. Below are the most common directions we build.

ERP ↔ CRM

Synchronising customer and contact data between Salesforce, HubSpot or Microsoft Dynamics CRM and your ERP. Sales sees open items and credit limits in the CRM, while finance sees the sales pipeline alongside actual revenue. The key decision: which side is leading for which field, and what you do in case of conflicts.

ERP ↔ e-commerce

Connecting webshops on Shopify, Magento, WooCommerce or a headless storefront to the ERP for products, prices, stock and orders. Orders flow from the webshop to the ERP, while stock and prices flow the other way. Real-time stock is the classic pitfall here: watch out for excessive load on the ERP API during peak moments.

ERP ↔ accounting and invoicing

Some organisations run their operations in the ERP but keep their accounting separate in Exact, Twinfield or Yuki. Purchase invoices, sales invoices, bank transactions and general ledger mappings then flow between both systems. For public tenders and e-invoicing, a Peppol integration is often part of that layer.

ERP ↔ HRIS and payroll

Employee data from AFAS, Visma, Nmbrs or Workday enters the ERP for cost allocation, project staffing and authorisation. Hours and expense claims flow the other way, towards payroll processing. Most bugs arise with role changes (joining, leaving, contract changes), and that is where most of the time goes.

ERP ↔ BI and data warehouse

For management information, a nightly or near-real-time export to Snowflake, BigQuery, Synapse or a bespoke warehouse is common. Power BI, Tableau or Looker then sit on top of it. This is where data modelling matters: a raw ERP table is rarely ready for reporting as it stands.

ERP ↔ operational apps

Field service apps, warehouse scanners, shop-floor systems and customer portals all feed operational data into the ERP and read data back from it. We have a lot of experience with this. See, for example, our page on integrations within web development for concrete examples.

ERP ↔ logistics partners and marketplaces

For trading businesses, integrations with carriers (PostNL, DHL, DPD, Transsmart), 3PL warehouses and marketplaces (Bol, Amazon, eBay) form a separate category. Track-and-trace, customs declarations, return flows and commissions all come into play. Often a mix of direct APIs and EDI, sometimes routed through a transport management layer.

ERP ↔ document flows

Invoices, contracts, delivery confirmations and order confirmations are increasingly processed via Peppol or specialist document platforms (DocuSign, PandaDoc, Klippa, Basware). The integration ensures that an incoming invoice lands in the ERP as a draft purchase invoice, with the OCR results already pre-filled.

API's and pitfalls per ERP vendor

Not all ERPs are equally pleasant to integrate with. Below is a brief practical overview per platform. It is inevitably a snapshot, as vendors continually change their APIs.

SAP

SAP S/4HANA offers OData and REST APIs via SAP Gateway and, increasingly, via SAP BTP (Business Technology Platform). The pitfall: the documentation is extensive but scattered, and authorisations are complex (Communication Users, Scopes, RBAC). For older ECC installations you will still encounter RFC, BAPI and IDoc. These are workable, but specialists are scarcer.

Oracle NetSuite

NetSuite offers a SuiteTalk SOAP API, a newer REST API, and SuiteScript for in-platform logic. Token-Based Authentication is mandatory. The pitfall: rate limits are strict, and saved searches behave subtly differently from REST records.

Microsoft Dynamics 365 Business Central and F&O

Business Central has modern OData and custom API pages. Finance & Operations works via OData and the Data Management Framework for batches. Authentication is via Azure AD using OAuth2. The pitfall: per-environment configuration, and version upgrades that sometimes bring breaking changes.

AFAS Profit

AFAS offers GetConnectors (read), UpdateConnectors (write) and SubscribeConnectors (events). Well documented and reasonably tight on authorisation. The pitfall: custom fields require separate configuration on the AFAS side, and large datasets demand disciplined paging.

Exact Online and Globe

Exact Online has a REST API with OAuth2; volume and rate limits are restrictive for larger accounts. Exact Globe is a desktop product with different integration patterns (XML, ODBC, SDK). Do not simply combine the two.

NetSuite, Unit4, IFS and smaller vendors

For vendors with a less mature ecosystem, your own connectors or an iPaaS are often more practical. Always verify early whether the APIs actually support the objects and fields you need — brochure copy is not a contract.

How much does an ERP integration cost and how long does it take?

The cost and lead time of an ERP integration depend on four factors: the number of systems to connect, the complexity of the mapping (how many fields, how many exceptions), the operational requirements (real-time or batch, retries, monitoring) and organisational maturity (are there sandboxes, is there a product owner, is the documentation complete).

What we don't do: publish a fixed price on a page. ERP projects vary too much for that. What we do: after an introductory conversation and a brief scoping exercise, we give you an honest indication of complexity, lead time and budget, based on what we have built before. For the broader context of cost estimation, see also our page on getting a custom ERP system built.

Compliance, GDPR and audit trail

An ERP integration often moves personal data and financial data between systems. That brings serious obligations. There are three points you should consider explicitly before going live:

GDPR

Which personal data passes through the integration? Do you have a data processing agreement with every party, including the iPaaS provider? Is data stored in EU regions, or does anything leave the EEA? Logging should not record personal data unnecessarily; PII in error logs is a classic audit finding.

Audit trail

Every successful or failed transaction must be traceable: who sent what to which system, when, and what the response was. For SOX, ISO 27001 and internal financial audit work, this is not a nice-to-have but a requirement. Build audit logging in from day one, not as an afterthought.

Access control and secrets

API tokens, OAuth credentials and passwords belong in a secrets manager, not in an env file or YAML. Rotate them regularly. Give integration accounts minimal permissions (least privilege) — not the IT manager's service account.

Common mistakes

The technical pitfalls we encounter most often — and which you can avoid by thinking about them in advance.

• No idempotency: the same order is sent twice because of a retry, and your customer receives two invoices. Every write operation should have an idempotency key.
• No versioning: your ERP vendor publishes API v2 with breaking changes and your integration grinds to a halt. Pin versions, schedule upgrade windows and monitor deprecation headers.
• No monitoring: a fault is only discovered when finance calls to say orders are missing. Always build in alerts on success rate, latency and queue depth.
• No retry strategy: system B is briefly unavailable; without exponential back-off and a dead-letter queue, you lose the messages that arrived at exactly that moment.
• No rollback plan: you release a new version and orders are processed incorrectly. Without feature flags or version pinning, reverting is a nightmare.
• Tight coupling: the ERP and CRM are so tightly interwoven that one cannot function without the other. A queue or event bus between them prevents a single fault from bringing everything down.
• Ignoring master data: customer numbers, product codes and ledger accounts drift apart between systems. Agree on a source of truth per dataset, not per system.
• No sandbox discipline: testing in production because the test environment is "not up to date". Invest in good test data — it pays off quickly.

How does an integration project begin?

We always start with a short discovery phase before building anything. During a half-hour introductory call we gather the key answers: which systems, which data, which direction, which frequency, which security requirements, which volume. On that basis we produce a brief scoping document that makes the architecture, assumptions and approach clear. Only then do we move into sprints with concrete deliverables: first the minimal working integration, then robustness, monitoring and extensions.

What we want to know during discovery

A few examples of questions we ask early on: which ERP product and version are you running? Is there a test environment, and how does it differ from production? Which licences do you have for the API layer (some vendors charge extra for API volume)? Who in your organisation is the functional owner of the data? Which integrations already exist, and is there documentation for them? How often does a transaction occur, and what is the maximum peak? Which compliance requirements apply (GDPR, ISO 27001, NEN 7510, sector-specific)? The answers shape the architecture more than the choice of technology does.

The role you play yourself

An ERP integration touches finance, IT, operations and often HR. A single internal contact person is rarely enough — we work best with a product owner who can make decisions, plus a subject-matter reviewer for each domain. The richer that consultation, the less rework there is. In our experience, organisations that think this through in advance save a great deal of time during implementation.

What you can expect from us

Experience with the major ERP platforms, a team that builds rather than merely advises, and a way of working in which you remain the owner of the code and the architecture. No black boxes, no lock-in to a specific iPaaS where that isn't necessary. We deliver documentation, monitoring dashboards and a transferable codebase — so that you, or another partner, can continue the work later without being held hostage.

From experience, most projects start small: one critical integration where most of the pain lies. Only once that is in place and stable does it expand to the second and third. A big-bang project in which everything is integrated at once sounds efficient on paper but rarely turns out well. We almost always advise against it.

Frequently Asked Questions

What exactly is an ERP, and when do I need one?

An ERP is the central system for your administrative and operational business processes: finance, inventory, purchasing, sales, production and often HR. Once you outgrow loose spreadsheets and small packages, and figures no longer match between departments, an ERP becomes relevant. Which one you choose depends on your sector, international presence and desired flexibility — SAP and Oracle for larger or more complex organisations, Business Central, AFAS and Exact for SMEs and mid-sized companies, NetSuite for cloud-first scale-ups.

Should I choose a direct API integration or an iPaaS?

There is no universal answer. A direct API suits you if you need one deep integration between two systems that you intend to keep using over the long term: you get maximum control and minimal latency. An iPaaS is stronger if you want to connect several SaaS tools quickly, have limited in-house operations capacity, or want standard flows without custom code. Many organisations combine the two: critical real-time integrations direct, peripheral ones via an iPaaS. Our guide API vs. integration platform goes deeper into the trade-offs.

Roughly what does an ERP integration cost?

Honest answer: it varies too much to capture in a single figure on a general page. A simple integration takes a few sprints; a production architecture with monitoring and an SLA is a project of several sprints. After a short scoping exercise we can give you an honest estimate for your specific situation, with nothing hidden and nothing inflated.

What about GDPR and privacy in ERP integrations?

Any integration that carries personal data falls under the GDPR. Key points: data processing agreements with all parties (including the iPaaS provider), data storage within the EEA unless you explicitly agree otherwise, no personal data in error logs, an audit trail of who sent what and when, and least-privilege access for integration accounts. For healthcare organisations, NEN 7510 applies; for financial institutions, DORA requirements.

How does an integration project start with Appfront?

It starts with a 30-minute introductory call in which we map out the current situation, goals and constraints. That is followed by a scoping document covering architecture, assumptions and approach. Only then do the sprints begin: first the minimal working integration, then robustness and monitoring, then extensions. You can always start with one specific pain-point integration and scale up later.

What if my ERP vendor doesn't have a good API?

Then we look at alternatives: file drops via SFTP, ODBC connections, database replication, or an adjacent integration product from the same vendor. For older on-premises systems this is common practice. It works, but discipline around error handling and monitoring becomes more important precisely because the vendor offers less support.