What to Do When Two Business Systems Disagree

When sales says an order is confirmed and accounting says it is unpaid, the immediate problem is not that two screens differ. The business needs to know which event actually occurred, which record should be corrected, and whether anyone has acted on the wrong information. Software connections can move data, but they cannot invent a business rule for conflicting facts.

Describe the disagreement precisely

Choose a real case and record the values, their sources, update times, and the people who entered or approved them. Are the systems describing the same thing? A sales status may mean that the customer accepted a quote; an accounting status may mean that money was received. Both can be correct. A conflict exists only after the business defines what each value claims. Clarify labels before assuming a transfer failed.

If the same customer address differs between tools, ask which process verified it most recently and for what purpose. A billing address and a delivery address may legitimately differ. A recently entered address is not necessarily the right one if it was copied from an old message. The resolution should use evidence, not simply choose the system with the newest timestamp.

Assign an authoritative source for each fact

Decide which system owns a fact at each stage of work. Sales may own the proposed order, operations the confirmed dispatch date, and finance the settled payment. Make these rules visible to staff and to anyone building a connection. Define what should happen when a source changes, when the destination rejects an update, and when a person manually corrects a destination value. Silent overwrites can undo careful corrections.

The GOV.UK guide to designing services from front to back encourages examining the internal processes and data behind the visible service. In a small business, a disagreement between systems is often a clue that the handoff rule was never made explicit. Fix the rule and the record rather than only changing the display.

Resolve the current case and its consequences

Name a person to investigate and record the decision. Correct the authoritative record, then update dependent systems through a controlled path. Check whether the discrepancy affected an invoice, delivery, customer message, or report. If it did, handle that consequence and communicate with the customer where needed. Preserve enough history to explain what changed without leaving a known wrong value as the current truth.

For frequent disagreements, count their types and look for a shared cause. Duplicated entry may call for a focused transfer. Missing validation may call for a form change. Different definitions may call for two separate fields. An occasional rare exception may be best handled by a clear manual review. The appropriate response depends on volume and the harm a mismatch could cause.

Give staff a safe way to flag a conflict without choosing a winner. They should be able to pause a consequential action, such as dispatch or a refund, and identify the person who can decide. If the case must proceed despite uncertainty, record the assumption and who authorized it. This prevents a guessed value from quietly becoming the accepted truth.

Test the rules before automating them

Use ordinary and awkward examples: a late payment, a cancelled order, a changed address, and two customers with similar names. Confirm that each update reaches the right record and that failures are visible. The GOV.UK guidance on regular quality testing recommends examining normal and unusual conditions. That matters especially when a transfer could make the same mistake across many records.

Holism can help the business owner define which facts each team owns and have a developer implement the checks and transfers using AI and reusable foundations. The owner resolves the business meaning; the developer makes the agreed rule dependable. Two systems can coexist successfully when people know which one to trust for each question and how to repair exceptions.