Double Data Entry: Finding Every Point, and Deciding What to Connect First

Double entry costs twice: in the time to retype, and in the errors created when the copy goes wrong. A typical business has three to six such points, and most of them appeared without anyone deciding - simply because one system was added and nobody connected it to the previous one.

Finding every point in an hour

Trace one piece of data - an order, a customer, a payment - from the moment it enters the business until it reaches the books. Every time somebody types something that already exists elsewhere, that is a point.

In most businesses one or two rows in that table explain most of the duplicated work - not all of them.

What to connect first

Not the most complex but the most frequent. The formula is the same as in any efficiency work: frequency times duration, weighted by risk - because an address error costs a redelivery, while an error in an internal note costs nothing.

In practice, in many Israeli businesses the first connection is between the order system or CRM and the invoicing software, simply because that is where the two painful points sit: typing customer details and typing amounts. The full calculation is in what manual work costs.

Before connecting - check whether it can be eliminated

Connecting is a solution, but not always the cheapest one. Three questions first:

• Is the second system needed at all? Sometimes people type into a spreadsheet nobody reads any more.
• Can the entry move to the customer? A link where they fill in their own details removes the first typing entirely.
• Can you export and import once a week instead of typing daily?

The second is the strongest in businesses taking orders by phone and WhatsApp: instead of typing after the customer, send them a link that writes the data straight into the system. It is also more accurate, because customers type their own address correctly.

What breaks connections

• A different identity key in the two systems - the number one cause.
• Mandatory fields present on one side and not the other.
• Formats - phone, date, currency.
• Nobody defined the master, so both sides overwrite each other.
• No monitoring, so a dropped connection is discovered a week later.

The first takes you back to square one: without a shared key - usually a normalised phone number or company number - the connection creates duplicates instead of saving typing, which is exactly what duplicate customer records between systems describes.

What to do when connecting is impossible

Not every system can be connected, and not every connection is economically justified. Three alternatives that work:

1. Batch export and import daily or weekly instead of continuous typing.
2. Type in one place only, with the second reading from it when needed.
3. Drop one of the systems - often the best option and rarely considered.

The third deserves serious consideration. When a system exists only to produce one report you could produce elsewhere, connecting to it is an investment in preserving something you could simply close.

How to measure that it worked

Two numbers: how much time per week goes into moving data between systems, and how many errors were found in a month that originated in copying. Both are measured before and after, and the second is the persuasive one - because it translates directly into customers who did not receive what they ordered.

What to expect: the connection will not remove all the time. There is always residual work checking and handling exceptions, and that is fine. A good connection reduces the time substantially and reduces errors to nearly zero - and that is the result to measure against, rather than an expectation of no work at all.

What happens when a connection fails silently?

That is the scenario that turns a connection from an asset into a risk. When manual typing stops working, somebody notices immediately; when an automated connection stops, everything looks fine - there are simply no new records on the other side, and nobody notices until a customer asks.

So every connection needs two things besides itself: an alert when it fails, and a periodic check that it is genuinely transferring. The second sounds unnecessary and is not: a connection can run successfully and transfer zero records because of a change on the other side, and that looks exactly like success.

The practical check is counting: how many records transferred this month, against how many were created at source. A consistent gap means something is being filtered out along the way, and it is usually precisely the exception somebody keeps typing manually without reporting it.

What to do with the typing that remains

Something always remains - an exception, a special customer, an order that arrived in a different format. The mistake is treating that as a failure of the connection; the right response is to treat it as a list. When the manual cases are recorded for a month, it nearly always turns out two or three types explain all of them.

Then you can decide what to do with each: extend the connection, change the process producing the exception, or leave it manual deliberately. The third is entirely legitimate - what is not legitimate is not knowing it exists.

Sources

• How to improve business efficiency
• Israel Tax Authority - information for businesses