Reference
How do we stop entering the same data twice?
The short answer
Duplicate entry comes from systems that were each chosen well and never connected. The fix is not always more integration — some duplicates disappear by consolidating, others by changing who enters what. Where integration is right, the questions that matter are which system is authoritative for each field, whether the connection is point-to-point or routed, and who is responsible when a feed fails silently.
Decide what is authoritative first
Before building anything, settle which system owns each piece of data. One system is authoritative for the employee record, one for hours, one for benefit elections. Where two systems both believe they own a field, an integration will faithfully propagate a conflict.
This is a governance decision rather than a technical one, and skipping it is why integrations that work correctly still produce disagreement.
The connections that actually matter
Time to payroll, which is the highest-volume and highest-consequence feed you will run. Payroll to general ledger, without which finance reconciles manually forever. HR to benefits carriers, one feed per plan. Single sign-on and directory provisioning. Time clocks to the time system.
Carrier feeds cause the most avoidable pain, because a feed that silently stops is not discovered by an alert — it is discovered by an employee at a pharmacy counter being told they have no coverage. Establish who owns each feed, how failures surface, and what the remediation path is.
Point-to-point or routed
Direct connections between each pair of systems are cheaper to start and become the reason you cannot replace any single component later without touching everything attached to it. Routing through something reconfigurable costs more initially and preserves the ability to change one thing.
At mid-market scale, point-to-point is frequently the right call for a handful of connections and the wrong one beyond that. What matters is making it a decision rather than an accumulation.
Failure has to be visible
The dangerous failure is not the feed that errors loudly. It is the one that stops running and reports nothing, because nobody notices absence. Every integration needs a monitored success signal and a named owner, and both are routinely omitted because the connection worked when it was built.
Sometimes the answer is not an integration
Some duplicate entry disappears by consolidating two systems into one. Some disappears by changing who enters what — a manager entering a change once in the authoritative system, rather than HR re-entering it downstream. Both are cheaper than building and maintaining a connection.
Ask what the duplicate entry costs before deciding what to spend fixing it. A connection that costs more to maintain than the entry it removes is a common and avoidable outcome.
| Connection | If it fails | Failure visibility |
|---|---|---|
| Time → payroll | Wrong pay, at scale | High — noticed immediately |
| Payroll → general ledger | Manual reconciliation forever | Medium — finance notices |
| HR → benefits carrier | Employee has no coverage | Low — until someone needs care |
| HR → directory / SSO | Access not provisioned or revoked | Medium, and a security issue |
| Clocks → time system | Missing punches | High — at approval |
Common questions
Should we build integrations ourselves?
How do we monitor a feed we did not build?
Is an API better than a file transfer?
Where this sits
This page supports Technology — the practice that does this work.
