“Our systems don’t talk to each other, so people re-key the same data.” The cost shows up as slow orders, typos that reach customers and two systems that never quite agree. Order matters: connect systems before deciding who owns the data and you move the mess around faster.
The process in five steps:
- Map every re-key by following one real record from first entry to final report.
- Pick a system of record for each field and clean up duplicates.
- Choose the lightest connection that will hold: built-in connector, Zapier-style tool, custom integration or one shared database.
- Make failures visible with logs, alerts, retries and a unique key per record.
- Put a number on the manual work to judge what it’s worth to stop re-keying data.
Where double data entry hides: map every re-key
Duplicate data entry between systems is rarely one big task. It’s a dozen small hops nobody counts, because each takes a few minutes. Find them all before you shop for a connector.
Common places re-keying hides
- The same order, job or customer typed into two systems, such as an order portal and accounting.
- A nightly CSV export that someone tidies up and imports somewhere else.
- A spreadsheet in the middle: the “master list” copied out of one system and pasted into another.
- Emailed purchase orders and PDFs typed in by hand.
- Field updates texted to the office, then retyped. (“Our contractors need to do this from their phones.”)
- Monthly reports built by lining up exports from two systems in a spreadsheet.
Follow one record from start to finish
Walk a common record, such as a customer order, through its whole life: quote, order, pick, ship, invoice, payment, report. At every hop where a person copies data, write down:
- From which system to which system, and which fields
- Who does it, and how often (per day, week or month)
- Roughly how many minutes it takes each time
- What goes wrong (typos, missed updates) and what that causes downstream: a wrong shipment, a late invoice, a report nobody trusts
Ask the people who do the work, not only their managers: the person who re-keys orders every morning knows about the second spreadsheet no process document mentions. The finished list is your integration scope, and the minutes column is your business case.
Pick a system of record for each piece of data
Before you connect anything, decide which system owns each piece of data. The system of record (your source of truth) is the one place a field is created or changed; every other system gets a copy. It’s usually the system where the data is created or approved: accounting for invoice status, the CRM for sales contacts, the shipping system for tracking numbers.
Decide field by field, not system by system. One customer record can have its billing address owned by accounting and its sales contact owned by the CRM.
One owner, many readers is the pattern we designed into Just A Menu, our own platform: a restaurant edits its menu once and publishes it to QR menus, TV menu boards, print, its website and an API.
The trap: two systems overwriting each other
If a field can be edited in both systems and a two-way sync copies changes back and forth, someone’s update can quietly disappear. As Microsoft’s SQL Server documentation puts it, “a conflict would occur if the same data was changed in both data stores in the time between synchronizations” (Microsoft Learn). Make each field editable in one place, or write explicit rules for which change wins.
Example (hypothetical): an ownership map for a distributor
A field-by-field map for an industrial-supply distributor with an order portal, accounting software, a CRM and a warehouse system. Not client data.
Every direction in that map is one-way, on purpose: one-way syncs are simpler to build, test and trust. Two-way sync should be a deliberate decision with conflict rules, not a default.
Clean up before you connect
Connecting systems full of duplicate customers and inconsistent product codes copies the problem into both. Agree on a shared key for each record type (customer number, order ID, SKU), merge duplicates, and turn free-text fields that drive rules into pick lists. This decides whether the integration can match records at all.
Your options for connecting business systems so data is entered once
Start with the lightest option that will hold up. Here’s how the four common approaches compare.
The fourth option is easy to overlook. If people re-key between a spreadsheet and a system that can’t follow your process, the simplest fix may be one tool that does the whole job. Our guide to signs you’ve outgrown spreadsheets covers that decision, and custom internal tools is the service behind it.
Not sure which option fits your systems?
Bring the list of systems and the re-keys you found. Your first call is with an engineer, and if an off-the-shelf connector will do the job, we’ll say so.
When no-code connectors stop being enough: Zapier vs custom integration
Zapier-style tools are a good first move: quick to set up and visible to the team that relies on them. They stop being enough when:
- The event you need isn’t available. With no trigger for “order approved” or no action for “update this custom field,” a person ends up back in the loop.
- Rules depend on several fields at once. Customer type, location, job status and approver turn one automation into a branching maze that’s hard to test.
- Volume grows. Zapier counts each successful action as a task, and the number of tasks your account can use depends on your plan (Zapier’s help center). For a high-volume sync, that pricing can become the deciding factor.
- Records have to be matched. When systems don’t share an ID, matching customers by name and address needs real logic and a review queue for near-misses.
- Timing matters. Polling triggers check for new data on an interval rather than as it happens (how Zap triggers work). If a delay of minutes causes problems, check which kind you’re getting.
- A missed sync is expensive. When a dropped order costs real money, you need behavior you can test and monitor, not a history screen someone has to remember to check.
A sensible setup can mix both: automations for simple hops, a custom integration for the flow that carries orders or money. For the wider trade-off, see low-code vs custom software, and for how we connect systems through their APIs and databases, see API integration services.
How to know if a sync fails silently
The risky integration is the one that stops quietly, unnoticed until a customer calls. Whatever you choose, build these in from the start:
- A log of every run: what moved, what was skipped and why.
- An alert to a named person when a run fails or doesn’t run at all.
- Retries for temporary failures. Zapier can replay errored runs, automatically on some plans (Zapier on replaying Zap runs); custom code should retry with a pause between attempts.
- A unique key per record (the order ID, not the order total), so a retry updates the existing record instead of creating a duplicate.
- A review queue for records that need a decision, such as an unknown customer code.
- An owner after launch: vendors change APIs and retire old versions, and someone has to keep up. That’s part of software maintenance and support.
Connecting older systems that have no API
No API doesn’t have to mean re-keying forever. These are the usual ways in, from safest to riskiest; have an engineer look at the system before picking one.
- Its own export and import. A scheduled job produces or picks up the files the system already handles, checks them and logs the result.
- Read-only access to the database. A read-only account or views feed other systems without putting the old data at risk. On SQL Server, change tracking records which rows changed, so a sync can pick up only new and updated records instead of rereading everything (Microsoft Learn).
- A small API in front of the database. A thin, authenticated service exposes only the records other systems need, with your rules applied, instead of handing out direct database connections.
- Writing into the old database. Only after mapping every screen, report and scheduled job that touches those tables, and after checking whether the vendor, if there is one, supports direct writes.
- Screen automation. Software that types into the old screens like a person. It can break whenever a screen changes, so treat it as a temporary bridge.
If the old system is itself why everyone re-keys (it’s hard to use, can’t be reached from a phone or no longer fits your process), connecting it may only postpone the real fix. Legacy application modernization can replace one screen or workflow at a time while the old system keeps running.
Reporting from one source of truth
Reports are only as trustworthy as the data under them. When dashboards read from the systems of record, through views or a reporting database, the numbers come from one place and nobody rebuilds them by hand each month.
That design is easiest to get right when an application is new. For Chelten House, a fourth-generation food manufacturer (sauces, dressings, condiments), we built a custom application where operators record production performance, product traceability and equipment downtime, planned vs unplanned, with causes and durations. Its data is stored in SQL Server and supports their Tableau reporting. Read the Chelten House case study.
Whether an application is new or already running, three decisions make its data report-ready:
- Codes and pick lists instead of free text, so “Net 30,” “net30” and “N30” don’t become three rows in a report.
- Times and durations stored one consistent way, so reports don’t guess at formats.
- Reporting views kept separate from the tables the app writes to, so a heavy dashboard doesn’t slow the screens people work in. Our SQL Server schema guide shows this in a sample design.
What re-keying costs you, and how to estimate it
The cost of double data entry is more than typing time. Count all of it:
- Time: minutes per re-key, times how often, times how many people.
- Rework: the share of entries that need fixing, times how long a fix takes.
- Error costs: a wrong shipment, a credit memo, a billing line that never gets invoiced.
- Delay: orders, jobs and invoices that wait until someone gets to the re-keying.
- Dependence: the process stalls when the one person who knows it is out.
Example (hypothetical): pricing one re-key
Not client data; use your own numbers. Three people each re-key 25 orders a day from an order portal into accounting, at 4 minutes per order. That’s 300 minutes, or 5 hours, every day. Over 250 working days, it’s 1,250 hours a year. If 2% of those orders need a 20-minute fix, add 125 hours. The total is 1,375 hours, about two-thirds of one full-time person’s year at 2,000 hours. At a loaded cost of $35 an hour (an example, not a benchmark), that’s roughly $48,000 a year spent moving data that already exists.
Run your own numbers in the automation ROI calculator: choose the “Re-keying between systems” preset, enter your people, frequency, minutes, loaded hourly rate and rework rate, then add the share of the work automation would remove and a build estimate if you have one to see the payback period. Nothing you type is sent anywhere unless you choose to send it to us.
Where AI checks fit once your systems are connected
Once records flow through one path instead of five manual hops, there’s a natural place to add checks. An AI check could read each incoming record and flag what a careful person would: an order whose quantities don’t match the quote, a purchase order number in the wrong format, a free-text note that mentions a rush. A person still makes the call on anything flagged.
Connect the data first; bolted onto a re-keying process, an AI check is just another screen. Then read how to add AI to your existing business software or see our approach to AI integration for existing systems. More practical reading for operations and IT teams is in our guides.