Somewhere in your business, the same information gets typed in twice. An order comes in and gets entered into the job system and the accounts package. A new customer gets set up in three places. A payment gets recorded once by the bank feed and once by a person.
Nobody designed this. It accumulates whenever a new system arrives without anyone deciding which system owns what — and once it's there it's invisible, because re-keying doesn't feel like a task. It feels like using a computer.
Why it costs more than the time
The time is the obvious cost and the smallest one. Three bigger ones:
Divergence. Two systems now hold the same fact, and eventually they disagree. Somebody amends one and not the other, and there's no mechanism to notice. From that point you have two versions of the truth and no way to tell which is right.
Delay. Re-keying happens in batches, because that's how humans work. So the second system is always behind by however long the batch cycle is, and anyone relying on it is working with stale information without knowing it.
Attention. Data entry is exactly the kind of low-value, high-concentration work that displaces higher-value work — and it usually lands on someone senior enough to be trusted with it.
The fix starts with a decision, not software
For each important piece of information, decide which system owns it. Not stores it — owns it. The single place where it is correct by definition, and from which every other copy derives.
One line per entity: Customers — owned by X. Orders — owned by Y. Invoices — owned by Z. Stock — owned by W. Everything else is a copy, and copies are never edited directly.
This document takes twenty minutes and is the most useful thing you can produce before any integration work. Half the difficulty in these projects is that two systems both think they own customers.
Then pick the direction
Once ownership is settled, each flow becomes one-directional, which is what makes it safe to automate. Customer created in the owning system, pushed everywhere else. Order created in the owning system, pushed to accounts. Nothing flows both ways.
Two-way sync sounds better and is dramatically harder: the moment both ends can change the same field, you need conflict rules, and conflict rules are where these projects go to die. Almost every real requirement is satisfied by one-way flow plus a clear owner.
What to do about the things that can't connect
Occasionally a system genuinely can't be written to. There are three honest options and it's worth choosing deliberately rather than drifting.
- Change the order of work so the un-connectable system is the owner, and everything else derives from it.
- Keep a manual step but shrink it — generate a file that gets imported, rather than a person retyping from a screen.
- Replace it — reasonable if it's causing several of these problems, but a bigger decision than it looks.
What doesn't work is scraping a system that doesn't want to be read. It breaks silently, usually in the week you've stopped keeping the manual version.
Keep the human where judgement lives
Not everything that looks like re-keying is re-keying. Sometimes a person is transforming as they go — deciding which code something belongs to, spotting that a customer name is wrong, catching that a quantity looks improbable. That's judgement wearing data entry's clothes, and automating it away loses something real.
The test: could a rule describe what they're doing? If yes, automate it and let them check exceptions. If the answer is "it depends", keep them in the loop and automate the mechanical part around them.
Working out what it's costing you
Before deciding whether to fix it, put a number on it — because the number is usually a surprise.
Take one duplicated flow and count the occurrences per week, the minutes each takes, and the loaded hourly cost of whoever does it. Loaded means salary plus employer's NI, pension, holiday cover and overheads — usually somewhere between 1.25 and 1.4 times raw salary.
An order re-keyed forty times a week at ninety seconds each is an hour a week, which sounds trivial. It's fifty-two hours a year, and if it's landing on someone whose loaded cost is £40 an hour, that's £2,000 for one flow. Most businesses have four or five.
Then add the parts nobody counts. How often does a re-keying error reach a customer, and what does putting it right cost — not just the correction, but the phone call and the goodwill. How long is the second system behind the first, and what decisions get made on the stale version in between.
Duplicated entry is nearly always done by someone trusted, because you don't hand data entry to a new starter when a mistake reaches a customer. So the hourly cost is high and the opportunity cost is higher — that person is not doing the thing only they can do.
The three shapes a fix takes
Once you know who owns what, the actual build is one of three things, in ascending order of effort.
1. Push on create
Something is created in the owning system and immediately appears in the others. Order raised in the job system, invoice draft created in the accounts package. Simplest, safest, and it covers most of the value.
The detail that matters: the receiving system needs to store the source system's identifier against the record, so that if the same event fires twice you update rather than duplicate. Without that, every retry creates a mess.
2. Reconcile on a schedule
Where instant isn't necessary, a scheduled comparison is more robust than a push. Every hour, ask the owning system what changed and apply those changes onward.
This is quietly better than real-time for most business data, because a missed run self-heals on the next one. A missed push is gone.
3. Present rather than copy
The one people forget. Sometimes the second system doesn't need the data at all — somebody just needs to see it while working there. A read-only panel showing the customer's live position from the owning system removes the duplication without moving anything.
Cheapest of the three, and it's the right answer more often than people expect.
The traps worth knowing about
Partial records. The owning system may hold less than the receiving one needs — no VAT code, no nominal code, no delivery instruction. Decide up front whether the automation fills a default, leaves it blank for a human, or refuses the record. Silently guessing is how bad data spreads.
Deletions. Creates and updates are easy; deletes are not. If something is removed in the owning system, does it disappear downstream or does it linger? Most systems handle this badly by default. Decide deliberately.
The person who edits the copy anyway. Someone will amend the downstream record because it's the screen they're in. If the sync then overwrites their change, they lose trust in the whole thing immediately. Either lock the fields that are owned elsewhere, or make it obvious on screen which ones are copies.
Two systems that both think they're in charge. The most common blocker, and it's political rather than technical. Two departments each believe their system is the customer master. That conversation has to happen with a decision at the end of it, and no amount of software will avoid it.
How to start this week
Write the ownership map. One page, one line per entity, agreed by whoever runs each system. Then list the places each fact currently gets typed, and count the duplicates.
Most businesses find three or four flows worth automating and one uncomfortable conversation about which system is really in charge. The conversation is the valuable part — and it's the one thing no supplier can do for you.