What to Do When Two Systems Disagree

A client asks what they owe. Your job system says $18,400, your accounting package says $22,100, and the person answering has to work out which is right before they can reply.

Neither system is broken. They are answering slightly different questions and nobody ever wrote down which question the business actually asks.

Most disagreements are definitional

Before assuming anything is wrong, check whether the two systems mean the same thing by the same word. Usually they do not.

Timing. One records revenue when the job completes, the other when the invoice is raised. At any moment they will differ by whatever sits between those two events, permanently and correctly.

Scope. One includes tax, the other does not. One counts the parent company, the other counts the site. One includes work in progress, the other only completed jobs.

Status. A job marked complete by the crew, invoiced next Tuesday, paid in April. Three systems, three different truths about the same job, all accurate.

Chasing a reconciliation before settling the definitions is how people lose whole afternoons. The first question is never which number is wrong. It is what each number is counting.

Name one system as the master, per fact

The instinctive fix is to declare one system the source of truth for everything. It never survives, because no single system is authoritative about everything a business does.

Do it per fact instead. The accounting package owns what was invoiced and what was paid. The job system owns what work was done and when. The CRM owns who the client is and who owns the relationship. Write those down on one page.

Then the rule follows: for any question, there is exactly one system you go to, and the others are copies. When a copy disagrees with the master, the copy is wrong by definition and you stop arguing about it.

Two way sync is usually a mistake

The common technical response is to synchronise both directions so the systems always match. It creates a worse problem than it solves.

When both sides can write, you need a rule for what happens when both changed since the last sync. Most integrations resolve that by last write wins, which silently discards somebody’s edit. Nobody is told, and the discovery happens weeks later when a client mentions that the address they corrected has reverted.

One direction, from the master outward, is almost always the right design. It is less impressive and it does not lose data.

Where AI closes the seam

The genuinely hard part was never the syncing. It was deciding whether two records that look similar describe the same thing, and that is judgement.

Is Tremblay Construction in the CRM the same entity as Groupe Tremblay in the accounting package. Is the job called kitchen refit at 14 Rue Laurier the same as the one called Laurier renovation phase 2. Does this $4,200 payment correspond to that $4,200 invoice, or to a different one for the same amount. Rules cannot answer any of those and people answer them slowly.

An AI step can, at volume, with the reasoning shown so somebody can check the call rather than trust it. That turns reconciliation from a monthly ritual into something that runs continuously.

Two further uses matter more than the matching. It can explain a difference in plain language rather than only flagging one, which is the whole of what the person on Friday afternoon was trying to produce. And it can watch for the differences that should not exist, so a genuine error surfaces the day it happens instead of at month end.

Some differences should never be closed

An important distinction, because the instinct is to make everything agree.

A permanent, explained gap between two systems is fine and frequently correct. Revenue recognised on completion will always differ from revenue invoiced, and forcing them to match would misstate both.

What you want is not agreement. It is that every difference is either expected and explained, or flagged as an exception. A business where all the numbers match is usually a business where somebody has been adjusting one of them.

Who settles it when people disagree

The technical rule only holds if somebody enforces it, and this is where most attempts quietly fail.

Sales believes the CRM. Finance believes the accounting package. Operations believes the job system. Each is right about their own domain and each quotes their own number in meetings, so the business runs on three versions of reality and nobody is lying.

Name one person who settles definitional questions, and have them own the one page. Not a committee, and not whoever shouts loudest in the meeting. When a new question arises, they decide, they write it down, and it stops being reopened every quarter.

Beware the spreadsheet in the middle

Almost every business in this situation has one, and it is worth finding.

Somebody built a spreadsheet that pulls from both systems and reconciles them by hand, and the business now quietly runs on it. It is not backed up, it is not documented, it lives on one laptop, and the person who maintains it is the only one who understands the adjustments.

That spreadsheet is not the problem. It is the specification for what should have been built, and it is the best documentation you have of what the business actually needs. Find it before you build anything.

The half day that fixes most of it

• List the five questions your business asks most often. Revenue this month, what a client owes, jobs in progress, whatever they are.

• For each one, name the master system. One name, no exceptions, written down.

• Write the definition next to it. Revenue means invoiced, excluding tax, by invoice date. That sentence prevents more arguments than any integration.

• Identify the expected differences and record why they exist, so nobody investigates them again next quarter.

• Turn off the second entry point. Wherever two systems both let people create the same record, close one.

Half a day, one page, and it removes most of the recurring reconciliation work permanently. It is also the document any automation you build later has to be written against, so doing it first saves the build from inheriting the confusion.

AI Optimize matches records across systems that describe the same thing differently, shows the reasoning so you can check it, and explains each difference rather than only flagging it. That work sits under Custom AI Integrations.