The hidden tax of copying data between systems

In 60 seconds: Every time someone retypes a customer, order, payment, or shipment into another system, the company pays in labor, corrections, waiting time, and lost traceability. Measure that tax by following one data object from its source to the final report and counting each re-entry, transformation, exception, and delay. Use observed volumes and times instead of borrowed savings benchmarks. Then choose the smallest mechanism that addresses the cause: synchronization for stable fields, events for changes that trigger work, desktop automation for a legacy interface, and cleanup for inconsistencies already created. The first pilot should move one object between two systems, in one direction, with an exception queue and a log.

Administrative activity can look like progress even when the underlying case has not moved. Sales records an order, the warehouse copies its details to prepare a shipment, collections re-enters the balance, accounting converts an export, and management assembles the report in Excel. Teams becomes an informal record of clarifications.

Each handoff may be short. Together they create an operating cost that rarely appears as a separate line in the accounts. Call it the re-entry tax: the work required to enter, convert, check, and reconcile data that already existed.

What the re-entry tax includes

The calculation starts with typing time and adds:

• finding the correct record and converting its format;
• checking required fields before work can continue;
• fixing duplicate records, amounts, dates, or addresses;
• waiting for someone to confirm which version is valid;
• reconstructing who changed a value and why;
• delayed work when an order, payment, shipment, or report is held up.

Lost traceability deserves its own line. When a figure changes across a Teams message, an Excel workbook, and the accounting system, it may be impossible to establish which value was approved at a given time. The cost extends beyond copying. It affects the company’s ability to explain a decision and recover the process after an error.

Follow one data object from end to end

Choose a specific object, such as an approved order, and reconstruct its path from real records. Start with what the team does today instead of the ideal process diagram.

Stage	Data coming in	Manual work	Data going out	Evidence worth keeping
Sale	Customer, products, quantities, price, and address	Complete fields and confirm terms	Approved order	Opportunity ID, version, and approver
Order	Approved commercial data	Re-enter codes and adapt formats	Order in the operating system	Source and destination IDs
Payment	Invoice, due date, and bank reference	Find the document and apply the receipt	Updated balance	Transaction ID and owner
Shipment	Released order and address	Recheck address, stock, and carrier	Prepared shipment	Time, status, and tracking number
Report	Sales, payment, and shipment states	Export, convert, join, and correct	Management workbook or report	Cutoff time, sources, and filters

For every transition, record where the data originates, who may modify it, which identifier survives the handoff, and which rule allows the case to advance. Include the exception channel. A Teams message can resolve today’s case, but it is not a traceable state if the decision never returns to the appropriate system.

The map often exposes two different problems. Sometimes valid data is copied because the systems do not communicate. In other cases, nobody has decided which system owns the field or what the field means. Integration can address the first problem. The second needs a data decision before automation.

A calculator based on your own data

Observe a representative period and complete this table. If a value is unknown, label it as an assumption. Do not replace it with an external benchmark.

Variable	How to obtain it	Type
V = cases per period	Count orders, payments, or records that pass through the handoff	Observed data
M = re-entry minutes per case	Time a sample, including search and validation	Observed data
R = share of cases corrected	Cases requiring a correction ÷ observed cases	Observed data
C = minutes per correction	Time from detecting the error until it is resolved	Observed data
H = internal hourly cost	The cost the company chooses for the role	Internal data or documented assumption
D = cases delayed by the handoff	Cases whose delay can be attributed to this transition	Observed data
K = cost per delayed case	Demonstrable penalty, extra work, or financing cost	Internal data; use 0 if it cannot be supported

Estimate the period as follows:

re-entry hours = (V × M) ÷ 60
correction hours = (V × R × C) ÷ 60
operating cost = (re-entry hours + correction hours) × H
delay cost = D × K
estimated re-entry tax = operating cost + delay cost

Use a range when times vary widely. Keep three categories visible:

• Facts: counts, durations, and errors collected during the observed period.
• Assumptions: hourly cost, seasonality, or an attribution that has not been validated.
• Data to measure: delays without a recorded cause, corrections performed outside the system, or cases resolved in chat.

This separation stops an estimate from turning into a savings promise. An integration also has build, licensing, support, and exception-handling costs. Compare the current cost with the total cost of running the solution and the risk it reduces.

Match the solution to the cause

Approach	Use it when	What you must define	Main limitation
Synchronization	Two systems need the same stable field or reference	Owner system, direction, frequency, and conflict rule	Poorly defined two-way sync creates competing versions
Event-driven integration	A confirmed change must start work in another system	Event, schema, identifier, retries, and error queue	Consistency may be eventual and requires observability
Desktop automation	The legacy application has no viable API or connector	Machine, session, selectors, credentials, and recovery	Interface changes can break the flow
Downstream cleanup	Duplicates, incompatible formats, or incomplete data already exist	Matching rule, human review, and the source that keeps the result	It repairs existing errors but does not remove their cause

Microsoft’s documentation shows two useful layers for this decision. A custom connector wraps a REST or SOAP API and exposes consistent triggers and actions. Desktop flows can work with legacy applications through UI elements, images, or coordinates. Microsoft’s unattended flow troubleshooting guide documents that application updates and UI changes can affect selectors. The team still needs to assess permissions, licensing, and support in its own environment.

For workflows that react to an approved order, applied payment, or confirmed shipment, Azure’s event-driven architecture guidance describes event producers, consumers, and channels. The same guidance calls out eventual consistency, delivery, ordering, and error handling. An event removes the wait for a scheduled batch; it does not remove the need to reconcile states.

Desktop automation can be a reasonable bridge for an application without an API. Operate it like an integration: add alerts, use a controlled account, and test it after screen changes. If the interface can export data but someone converts the file every day, first check whether a connector, stable import, or API can remove that dependency.

Master data comes first

Suppose sales identifies a customer by email, the operating system uses an internal code, and accounting has two records with similar names. A fast automation can copy the order sooner and create the duplicate before anyone notices.

Before synchronizing customers, products, currencies, or addresses, define:

• the owner system for each attribute;
• the stable identifier that travels across systems;
• who resolves an uncertain match;
• which changes require approval;
• how the previous value and reason for change are retained.

Microsoft’s documentation on detecting and merging duplicate Dataverse records confirms that manual entry and bulk imports can introduce duplicates. Detection rules can help find them, but sensitive matches and merges need agreed criteria. Automating first can amplify an existing inconsistency.

When to add an agent

An integration moves defined data. An agent is useful when the step includes unstructured information or a decision that a person must review, such as reading a Teams note, extracting a reference from a payment document, explaining why a case entered the exception queue, or preparing the management summary.

The agent should not decide which balance is official or apply a payment from an inference. It can propose a match, collect evidence, and draft the next step. Deterministic rules validate amounts, IDs, allowed states, and permissions before a write occurs.

If the goal is to answer management questions from sales and collections data, the design for an ERP-connected executive assistant shows how to separate sources, recommendations, and actions. For a choice between connectors, desktop automation, and code, see Power Automate versus custom development.

An auditable pilot

Start with one approved order object moving from the sales system to the operating system. One direction prevents two applications from competing to update the same field.

1. The sales system publishes or exposes orders that meet a documented approval condition.
2. The integration validates customer ID, lines, quantities, currency, and address.
3. When every field is valid, it creates the order once and stores both identifiers.
4. Missing data or uncertain matches enter an exception queue with an owner and reason.
5. The log records correlation ID, source, destination, version, time, result, and technical actor.
6. A reconciliation compares approved orders with created orders to detect omissions or duplicates.

During the pilot, measure coverage, remaining manual time, corrections, queue age, and delayed cases. Test retries, repeated events, incomplete data, and destination outages. Only then compare the observed re-entry tax with the cost of operating the integration and decide whether to expand its scope.