At most SMEs, the problem isn't a lack of software. It's that there's too much of it, and none of it knows about the others. The order sits in the webshop, the invoice in the invoicing software, the customer in the CRM, the stock in the warehouse system — and one person holds these four together by copying data back and forth. This article is about how to connect them properly, and what to watch out for so it doesn't turn into even bigger chaos.

The hidden cost of copying data

When the same data has to be entered in two places, three things happen. Time is lost — potentially hours a day. Errors creep in — a mistyped address, a wrong tax ID, a missed line item. And worst of all: the truth disappears. If the CRM and the invoicing software have different customer addresses, which one is correct? At that point you can no longer trust your own data, and every decision needs to be double-checked first.

The real value of integration isn't the time saved — it's having a single source of truth for every type of data.

Step one: map out what flows where

Before talking about any technology, draw your systems on a sheet of paper and draw arrows between them: what data, in which direction, how often. This drawing usually reveals two things right away: there's an arrow or two going in circles, and there's one person every arrow passes through.

Then mark the owner for each data type: where does it authentically originate? Product data typically in the warehouse or ERP system, customer data in the CRM, the order in the webshop, the invoice in the invoicing software. Wherever you can't name a clear owner, that's where the most conflicts will arise later.

The four typical connections

Webshop → invoicing

An automatic invoice on order confirmation, with the correct tax ID, VAT rate, and line items, emailed to the customer. The pitfall here is cancellations and correction invoices: if you don't plan for this in advance, every complaint stays manual work.

Webshop → CRM

A new buyer becomes a contact, the order becomes history. This is what makes reaching out to returning customers meaningful, since you can see who bought what and when. The pitfall is duplication: if you only match on name, three different "John Smith"s become one.

ERP system → webshop

Stock and price sync. This is the most common real pain point: overselling (selling a product that's out of stock) means direct customer loss. Here, sync frequency is the key question — hourly sync is enough for a lot of cases, but it can fall short during campaign periods.

Everything → reporting

One shared place where the numbers come together. You don't need an expensive BI tool for this; often a well-structured data table and a few automated queries are enough.

How do you connect them?

Webhooks, whenever possible

The best solution is when the source system itself speaks up when something happens: "a new order arrived." This is instant and doesn't needlessly burden the systems. If the software you use supports webhooks, always choose this option.

Scheduled polling, when necessary

If there's no webhook, what's left is timed polling: "what's changed since the last run?" It's important to actually only fetch the changes, not everything — otherwise it becomes slow and expensive after a few thousand records.

Always use a middle layer

Don't connect the systems directly to each other. If everything talks to everything, then with five systems you already have ten connections to maintain, and replacing just one of them throws everything off balance. A middle integration layer — whether that's n8n, a custom service, or an integration platform — means every system only talks to one thing, and when something changes, you only need to update it in one place.

What almost everyone gets wrong the first time

• No unique identifier. If you don't store which invoice in the invoicing software corresponds to order 1234 in the webshop, you can't match them up, and you can't fix things either.
• No retry logic. APIs sometimes don't respond. If the process simply loses the data at that point, an order will quietly go missing.
• No idempotency. If a webhook fires twice, it shouldn't create two invoices. This has to be solved in advance, not after the fact.
• No log. When a customer says they never received an invoice, you need to be able to check exactly what happened and when.
• No alerting. You need to find out about an error through a human channel — email or chat — not buried in a server log.

Gradually, not all at once

Integration projects die when you try to do everything at once. The pattern that works: pick the one arrow on your drawing that involves the most manual work, connect it properly, with error handling and logging included, then measure it for two weeks. Then move on to the next one. This way, every step produces a tangible result, and the system is never left in a "half-finished" state.

If you also have a colleague who spends a significant part of their day copying data around, it's worth taking a look at this. Reach out to us — we'll map out your system landscape together, and tell you which arrow is worth tackling first.