Skip to content

Avoiding duplicate data entry: typical causes

Typing the same detail in twice costs more than time. It creates two versions, and from then on nobody knows for certain which one applies. This text names the causes and the ways out.

  • Who it is forAdministration, departments, management
  • LevelPractice
  • Reading timeabout 6 minutes
  • Last updated16 October 2026

What you will learn

  • Four causes from which duplicate entry arises
  • What it actually costs
  • Four ways out, from the simplest to the most elaborate
  • The question that must be answered before any solution

Four causes

  • Two systems, no connection. The classic: the shop knows the order, the merchandise management system does not.
  • The system cannot do something, so a spreadsheet appears alongside — and is maintained too.
  • Information arrives as free text: by email, by telephone, on paper. Someone transcribes it.
  • An evaluation needs data in a form that no system provides. So someone assembles it anew every week.

None of these causes is an organisational failing. All of them arise because someone bridges a gap — and that is precisely why they do not disappear when you forbid them.

What it costs

The typing time is the smaller part. The consequences are more expensive:

  • Two versions: when they differ, someone has to decide which one applies — and only someone who knows both can do that.
  • Transcription errors: a wrongly transferred digit often goes unnoticed until it takes effect.
  • Delay: between entry and transfer there is a waiting time in which the second system is misinformed.
  • Dependence on one person: whoever does the transfer is the only one who knows its quirks.

Four ways out

  • Structure the input: what arrives as free text today arrives through a form. Often the cheapest solution — it removes the cause rather than the consequence.
  • File exchange: one system writes a file, the other reads it, usually overnight. Robust, possible anywhere, up to a day old.
  • Interface: the systems talk to each other directly, with validation and feedback. The cleanest way, requires coordination.
  • Abolish the second entry: sometimes the second system does not need the detail at all — it has just "always had" it.

The fourth way is rarely examined and is surprisingly often the right one. The question is not "how do we transfer this", but "who needs this detail, and for what".

An example from practice

The question that comes before any solution

Which system leads? When data differs, one side has to win, and before the first reconciliation runs. Without this decision, a reconciliation overwrites both sides in turn, and the state becomes worse than before.

One business maintained prices in the specialist software and promotional prices in a spreadsheet. Sales looked at the spreadsheet first because it was more up to date. After a year, the prices in the specialist software no longer matched for a third of the articles. Technically the solution was a reconciliation — in business terms it was the decision that the specialist software leads and the spreadsheet only evaluates.

Common misconceptions

Not necessarily. A spreadsheet is a good tool for calculating and sorting. It just should not be the place where data is maintained — it is filled, not maintained.

Usually not. Letting the existing ones talk to each other is the smaller intervention and the lower risk.

Higher timeliness costs effort and produces more error cases. For many processes, the state of this morning is exactly right.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and concept design and writes here about decisions that come up in real projects.