System integration: connect ERP, web shop and accounting

ERP, web shop, accounting and CRM are connected through interfaces: directly via API, through a scheduled file export, or via middleware that mediates between several systems. More important than the technology are three decisions: which system owns which master data, what happens to records that fail, and who notices when a connection stops working.

In many SMEs the main applications have grown one by one over the years. The web shop was added at some point, accounting runs at the tax adviser or in its own program, and sales picked the CRM. These systems are often connected only through people who retype, export and re-import data. That works as long as volumes are small and nobody is off sick. Each of these hand-offs is a break in the flow of information where time is lost and errors creep in.

What data typically flows between ERP, web shop, accounting and CRM?

Before discussing technology, a simple overview helps: which data has to move from where to where, and how current it needs to be. Web shop stock levels updated only once a day can lead to selling goods that are no longer there. Customer master data in accounting, on the other hand, rarely needs to be correct to the minute.

• From ERP to web shop: products, prices, stock levels, delivery times
• From web shop to ERP: orders, customer details, payment status
• From ERP to accounting: outgoing invoices, credit notes, receivables
• Between CRM and ERP: contacts, companies, quotes, order status
• Back to the customer: shipping confirmation, tracking number, invoice

API, file export or middleware: which approach fits?

Direct API connection

An API is a programmable interface through which a system offers or accepts data. Most current web shops, CRM systems and cloud accounting tools have one. A direct API connection is timely and flexible, but depends on the vendor keeping the API stable. When an API version changes, the connection has to be adapted.

File export and import

Older inventory systems and many accounting solutions exchange data via files such as CSV or XML, exported at set times and imported into the target system. File exchange is simple and reliable, but not real-time and sensitive to format changes: an extra column or a different date format can make an entire import fail.

Middleware as a mediating layer

Once several systems exchange data with each other, connecting every application directly to every other one becomes hard to manage. Middleware sits in the middle, receives data from one system, transforms it and passes it to the others. This can be a workflow tool like n8n, an integration platform or a purpose-built integration layer. The advantage: error handling, logging and monitoring live in one place, and a new system only needs to be connected once.

Why does master data ownership have to be settled first?

Master data ownership means that exactly one system is the authoritative source for each type of data. If a product price is maintained in both the ERP and the web shop, the two will sooner or later overwrite each other and nobody knows which price is valid. The decision is organisational, not technical, and it has to be made before the first line of code is written.

• Products, prices and stock: usually the ERP or inventory system
• Contacts and sales opportunities: usually the CRM
• Bookings and open items: accounting
• For each data type, record where it is changed, where it is sent and who may change it

What happens when a record cannot be transferred?

Every interface eventually meets data that does not fit: an order with a product the ERP does not know, an address without a postcode, an invoice in an unexpected currency. What matters is what happens next. A good integration does not simply stop, nor does it silently drop the record; it moves it to an error list, reports it and keeps processing the remaining records.

• Keep failed records visible instead of silently discarding them
• Log traceably which record was sent where and when
• Prevent duplicate transfers, for example when a run is repeated after an error
• Set a clear rule for who reviews and corrects failed records

Why does every integration need monitoring?

Integrations rarely fail loudly. An expired access token, a changed API version at the web shop provider or a full disk on the server is enough, and data stops flowing. Without monitoring nobody notices until orders are missing or stock levels are wrong. Monitoring here means: every run is logged, missing or failed runs trigger an alert, and that alert reaches someone who is responsible.

How do you approach connecting systems step by step?

1. 01Take stock: which applications are in use, and which APIs and export options do they offer?
2. 02Sketch the data flows: which data has to go from where to where, how often and how current?
3. 03Define master data ownership: pick the leading system for each data type and keep maintenance there.
4. 04Choose the connection type: API, file exchange or middleware – depending on the systems, data volume and number of participants.
5. 05Define error handling: what happens to records that do not fit, and who corrects them?
6. 06Test with real special cases and run it in parallel with the existing manual process for a while.
7. 07Set up monitoring and documentation before the manual route is dropped.

When does custom software make more sense than an interface?

In most cases it is better to connect existing standard software cleanly than to replace it with custom development. Custom software only pays off when a core process cannot be mapped with standard products, or when the connections need so many workarounds that a dedicated tool becomes simpler. Even then the rule stays the same: interfaces instead of isolated solutions – custom software has to be able to talk to the ERP, accounting and the rest.

How NDVDL connects your systems for you

NDVDL starts with your processes, not with a product list. We come to your business and look at which applications are in use, where data is entered twice and who retypes what today. You then receive a written proposal with clear master data ownership, a suitable connection type and defined error handling, built on your existing systems.

After implementation, NDVDL operates and maintains the interfaces: monitoring, responding to error alerts, adapting to vendor API changes and keeping the documentation current. You have one fixed contact person who knows your network, servers and the connections between your applications.