Why your systems drift apart, and what to do about it
An order shows as paid in the webshop but stays open in the ERP. A customer updates their address in the portal and the parcel still goes to the old one. Differences like that cost more than a bit of clean-up. A wrong email goes out, someone makes a call based on numbers that are off, and trust in your own systems starts to slip.
What strikes us about these reports is that the integration itself is usually not broken. Companies run on a stack of systems, each with its own logic, its own field names and its own pace. Webshop, CRM, accounting, inventory, planning tool, app, customer portal. As long as things are quiet, none of that shows. It is the busy week, the update or the order that runs slightly differently that reveals whether the agreements between those systems were written down anywhere or only lived in someone's head.
Where it usually goes wrong
Syncing is more than pushing a record from A to B. You need to settle which system wins in case of doubt, when a change gets processed, what happens when that fails, and how you handle duplicate or conflicting data. Miss one of those four and your systems will drift apart. Not straight away, but inevitably.
Nobody decided which system is right
This is the one we see most. A customer can change their phone number in the CRM and in the portal. If both sides write back without a fixed rule, the winner is not the newest change but whichever one happens to arrive last. A correction disappears without anyone noticing, until a colleague calls a number that has been dead for months.
So assign an owner per type of data. The CRM for customer details, the ERP for invoices and stock, the webshop for orders. That split does not have to be sacred, but it does have to be written down somewhere. Without an owner, a conflict between two systems is not an incident, it is a matter of time.
APIs have bad days too
An API is not a promise that every request is executed immediately and without limits. There are caps on the number of calls, there is maintenance, and sometimes a request simply hangs. The annoying part of a time-out is that you do not know whether the other side did nothing or processed the change halfway.
An integration that gives up after the first error will not survive that. A well-built integration retries with increasing intervals, tracks per message how things ended, and makes sure the same order is not created five times over. That last part is called idempotency: sending the same request twice results in exactly one change. It sounds like a detail for developers, but it is the difference between a hiccup and a double delivery.
The change goes unnoticed
Plenty of integrations poll every fifteen minutes for whatever changed since the last round. That works fine, until two systems sit in different time zones, a modification date is only kept to the minute, or a record is saved for good somewhat later. A change that lands right on the boundary between two rounds slips through. You will not find it in the logs either, because nothing went wrong. Nothing happened at all.
Webhooks help, because the source system signals you right away. But a signal can also get lost, arrive twice, or turn up out of order. In practice a combination works best: webhooks for everything that has to be fast, plus a reconciliation run that periodically compares what both systems believe and straightens out the differences.
Same field name, different meaning
A field called status tells you nothing on its own. In one system it means the order is paid, in another that the parcel has shipped. The same goes for currencies, VAT rates, product variants and customer types. The data can arrive perfectly intact while the meaning got lost on the way, and you find out when the revenue report stops adding up.
A mapping from field A to field B is not enough for that. Also record which values are allowed, how exceptions are translated, and what the receiving system does with a value it does not recognise. Silently ignoring it is almost always the wrong choice, setting it aside and flagging it almost always the right one. With international sales or bundled products, that translation layer is not a side issue, it is half the work.
An update knocks out a silent assumption
Vendors change API versions, make fields mandatory and replace authentication methods. A plugin update or a release of your own backend can do the same. If the integration runs on assumptions nobody wrote down, you hear about it once orders start piling up. Usually on a Friday afternoon.
Version control, a staging environment and decent monitoring take care of this. Not every change has to become a project. But anything touching a critical data flow deserves a test somewhere harmless before it reaches production.
Catch it before your customer does
A successful API call does not mean the data is correct. Technical logging tells you a message arrived, not that the right amount was booked. So measure at the business level as well. Does the number of paid orders in the webshop match what the ERP processes? Is the stock in the warehouse structurally out of step with what shows online?
Separate the incident from the pattern. Two minutes of delay is fine. An order that still has not gone through after an hour needs someone to look at it. Stock that updates once a night can work perfectly well for a wholesaler and at the same time be useless for a webshop that keeps selling sold-out items because of it.
Put those limits on paper in plain language. Which data has to be right almost immediately, what can follow later, and who reviews the exceptions? Otherwise you end up in the conversation where IT says the integration is working while customer service keeps taking calls. Both true, and that is exactly the problem.
What actually makes an integration reliable
A new integration platform is rarely the answer. An existing connection can often be saved with better error handling and a bit more visibility. Sometimes you need a custom solution, because the off-the-shelf plugin was never built for an order process like yours. What makes sense depends on the volume of data, the damage a mistake causes and how fast the process genuinely has to be.
Start with an honest inventory. Not just of the systems, but of the actual data flows: what goes where, along which route, how often and under which business rule? Pay particular attention to the Excel import someone runs every Monday, the mailbox where order lists come in, and the little script that was meant to be temporary. Those are integrations too, they are just not on anyone's diagram.
Any setup that holds up has at least four things in it:
- An owner per type of data, with a fixed rule for conflicts.
- A queue, so a system that is briefly down does not cost you changes.
- Retries plus a place where messages land when they genuinely need a human.
- Monitoring on the technical side and on the numbers: counts, amounts, stock differences.
Then test the exceptions above all. What happens when a customer pays twice? When a product disappears from the catalogue while orders are still open? When a return comes in before the order has been processed? When an external API goes quiet for an hour? Walk through those scenarios in advance and an outage gives you a procedure instead of a crisis.
Real time or on a schedule
Real time belongs to data a customer sees directly or that touches money: stock, payments, access rights. It is worth the effort there, even though it asks more of your infrastructure and error handling. Reports, historical data and changes without immediate consequences can happily ride along in a scheduled run.
The trap is treating real time as a badge of quality for everything. Processing that completes within five minutes, with a visible status and automatic recovery, is worth more to most processes than a direct connection that folds under peak load. Speed you only reach on quiet days is not speed.
Manual clean-up is a metric
An employee fixing something now and then is no disaster. But once people are looking up orders, comparing customer records and correcting stock every day, you are paying off a technical problem in hours. With an added risk: after a while only one person knows which discrepancies are normal. When they go on holiday, the knowledge goes with them.
Treat that manual work as a signal. Which error comes back every week? Where is the status field that would let anyone see how far an order has got? Which system gives you too little information to fix a problem quickly? Often a small internal overview, a clearer error message or one targeted change to the integration is enough to win back hours a week.
At LJPc we therefore look beyond the connection between two systems, to the process running on top of it. Development, hosting and management belong together as far as we are concerned. When an integration stutters under pressure, someone has to be able to look at the application, the database, the queue and the infrastructure without three parties pointing at each other first.
An integration that is set up properly does not draw attention. Your people see information that adds up, customers get the right status, and the exceptions reach someone who can do something about them. That is not luck and it is not a luxury. It is the result of a few clear choices, checks you can go back and read, and someone who fixes problems before they pile up.