Your web application and your management software hold the same information, entered twice. Customers, products, sometimes orders. Someone bridges the gap by hand, and that person ends up being the fragile point of the whole organisation.
Connecting the two is an ordinary development project. What makes it drift is five decisions that look incidental and determine everything.
First decision: the direction of flow
This is the question that changes the cost of the project most.
A read-only link displays information living in your management software inside your application. Nothing is changed in the ERP, there is no accounting risk, and a good share of the irritation disappears: no more retyped customer records, no more stale prices, no more approximate stock.
A write link creates or changes data in your management software from the application. It touches your accounts, it needs sign-off from whoever keeps them, and it means respecting every internal rule the ERP enforces.
Many companies ask for writing and discover, once the scope is written down, that reading already solved 80% of their problem. Starting there shortens the time to go-live and surfaces data discrepancies before they get expensive.
Second decision: which side is authoritative
A customer address exists on both sides. A salesperson corrects it in the application, an assistant corrects it in the ERP, each on their own and on the same day. Which one wins?
With no written answer, the last write wins, which means someone’s correction disappears without them knowing. The problem shows up months later, as an invoice sent to an old address.
The answer should not be uniform. Price is authoritative in the ERP, job progress is authoritative in the application. That list is written field by field, and it is business work more than technical work.
Third decision: the matching rule
How do you know the customer in the application and the customer in the ERP are the same company?
The name gets spelled three different ways, so it settles nothing. The email address changes. The registration number is reliable but often missing on one side. The rule you choose directly determines how many duplicates you will find in six months.
This work means looking at your real data, not a theoretical sample. On almost every project, this step uncovers pre-existing duplicates nobody had noticed.
Fourth decision: the rhythm
Data fetched live on every screen assumes your management software answers quickly and stays available all day. An hourly or overnight synchronisation tolerates a delay and puts far less load on your servers.
The answer depends on use. Stock shown to a customer placing an order has to be fresh. A cumulative revenue figure on an internal dashboard copes perfectly well with a day’s delay.
That choice weighs more on cost than the volume of data exchanged, and it is reversible: you can speed things up later, rarely the other way round.
Fifth decision: behaviour on failure
This is the most frequently forgotten point, and the one that separates a link lasting three years from one abandoned after six months.
The network drops. The ERP is mid-backup. A required field is missing. An order is refused because the customer’s account is on hold.
Three questions to settle: do we retry, and how many times? is anyone told, and who? can you see, from outside, the date of the last successful exchange?
A link that fails silently produces two systems drifting slowly apart. Nobody notices until a discrepancy shows up in a figure, and manual reconciliation then costs more than the original build.
What is not development work
Two points are settled before any code is written.
Access. A dedicated technical account, with permissions limited to the tables and operations required, beats borrowing a user’s login. The same principle applies to the data itself: moving only what the application needs limits exposure, and how long that data is kept on each side falls under the same rules. Ask at the scoping stage, not the day before go-live.
Your existing integrator. They know your configuration, they manage your permissions, they will see the traffic in the logs. Involving them from the start avoids blockages at the most awkward moment.
What the first run almost always uncovers
A link exposes the real state of your data, and that discovery is part of the project rather than an obstacle to it.
Duplicates come first. The same customer entered twice with a comma of difference, a company that changed name with both records still live, an individual recorded under a maiden name and a married one. Those duplicates already existed, nobody saw them, and meeting a second system makes them visible all at once.
Incomplete records come next. A record with no postcode goes unnoticed in the ERP, where nobody uses it for despatch, and blocks an order in the application that calculates shipping.
Then the unwritten conventions. The salesperson who types “URGENT” in capitals at the start of a description, the product reference carrying a year to separate two models, the comment field used as a second address line. These practices work while a human is reading; a program ignores them or breaks on them.
Finding this on a read-only flow costs a few hours of clean-up. Finding it on a write flow, once incorrect documents have reached customers, costs a great deal more.
What we do
We write those five decisions in plain language, with you, before developing. The document states what the link does, what it does not, in which direction, at what rhythm, and what happens when a submission fails.
You approve it, you receive a fixed quote, and the link arrives in batches you see working. We always plan for retries and for a visible trace, because a silent link always costs more than the development itself.