Two Systems, Two Numbers, One Standing Meeting
When two systems disagree about the same fact, most companies add a meeting to decide which one to believe. The meeting is not the fix. It is the symptom of a decision nobody has made about which source is authoritative.
The ERP says there are four hundred units. The warehouse system says three hundred and sixty. Both were built by competent people, both are working as designed, and both have been wrong at different times.
So there is a meeting. Every week, the same people, reconciling the same two numbers, arriving at a third number that neither system holds. Then everyone goes back to work and the systems continue to disagree.
Nobody would design this. It arrived one reasonable decision at a time, and now it is load-bearing: decisions wait for the meeting, and if the meeting is cancelled, purchasing guesses.
This is broken work, and it is one of the most expensive versions of it, because the cost is disguised as diligence. It looks like careful people being careful. It is actually a permanent human process compensating for an architectural decision nobody has made.
The disagreement is not the problem
It is worth separating two things that get conflated.
Two systems holding different numbers is normal and often correct. They measure at different moments, with different definitions, for different purposes. An inventory count at the moment of receipt and an inventory count at the moment of putaway are genuinely different numbers, and both can be right.
The problem is not variance. The problem is that nobody has declared which one is authoritative for which decision.
Without that declaration, every downstream question becomes a negotiation. Can we promise this order? Depends who you ask. Do we need to reorder? Depends which screen you are looking at. What was our stock position on the thirty-first? Depends who is in the room.
If the answer to "which number is right?" is a person rather than a rule, you do not have a data problem. You have an undeclared system of record, and the reconciliation cost is being paid in salary every week.
Why the meeting is the wrong fix
The meeting is a rational local response. Something needed deciding, nothing decided it, so people stepped in. That is what good operators do.
But a recurring meeting has properties that make it a bad permanent answer.
It does not scale. Twice the volume means twice the reconciliation, and the meeting either gets longer or gets shallower. It usually gets shallower, which means the errors it was catching start getting through while everyone still believes they are being caught.
It produces a number that lives nowhere. The output of the meeting is a decision, and the decision is usually communicated verbally or in a message thread. It is not written back into either system. So both systems remain wrong, and the correct number exists only in the memory of the people who attended.
It hides the actual defect. Every week the reconciliation runs, the underlying cause is patched over rather than surfaced. If receipts are being entered late, the meeting absorbs the effect and nobody ever fixes the entry timing.
It becomes invisible in the numbers. The cost never appears as a line item. It appears as five people's calendars, and as delay in decisions that waited on it.
What is actually breaking
Underneath a recurring reconciliation there is almost always one of four things.
No declared system of record. Nobody has written down, for each fact, which system owns it. This is a governance decision, not a technical one, and it is usually cheap to make and expensive to keep avoiding.
Different definitions wearing the same word. One system counts a unit as available at receipt, the other at putaway. Neither is wrong. The word "available" is doing two jobs, and no glossary says so.
Latency nobody has stated. One system updates in real time, the other in a nightly batch. The systems are not in conflict; they are in different time zones. If nobody has said "this figure is accurate as of last night," people read it as current and make decisions on it.
A broken input at the source. The most common and least discussed. Something is entered inconsistently upstream, and every downstream system inherits the inconsistency differently. The reconciliation is not comparing two systems. It is repeatedly discovering the same data-entry problem.
Only one of those four is fixed by better software. The other three are fixed by decisions.
A standing reconciliation meeting is a decision deferred, running on a repeating charge. Somebody has to say which source is authoritative for which fact. Until they do, you are paying people to make that decision again every week, and to make it verbally.
The sequence that actually resolves it
Name the facts before naming the systems. Not "ERP versus WMS." List the actual questions the business asks: how much do we have, how much can we promise, what did we hold at period end. Each is a different fact, and they may legitimately have different owners.
Declare an owner for each fact, in writing. One system is authoritative. The others are copies, and they are allowed to differ. This is a five-line document and it eliminates most of the argument on its own, because the argument was never really about the numbers.
State the definition and the latency next to the number. "Available stock, at putaway, as of 02:00." Most perceived conflicts stop being conflicts once both figures carry their own definition. This is often a display change, not an integration project.
Trace the variance once, properly. Take a single instance where the two disagreed and follow it end to end. You are looking for whether this is definitional, timing, or a genuine data defect. One traced instance usually explains the majority of the pattern.
Fix upstream before integrating. If the root cause is inconsistent entry, integrating two systems will synchronise the error rather than resolve it. Fix the input, then connect.
Then retire the meeting deliberately. Not by cancelling it, which leaves people without an answer, but by replacing what it produced: a stated authoritative figure, visible to everyone who used to attend, with the exception path defined for when it looks wrong.
Keep the exception path
One caution, because the overcorrection is real.
The point is not to eliminate human review of the numbers. Somebody should still be able to say "that looks wrong" and have a defined route for it. What changes is that the review becomes an exception process rather than the primary mechanism, and it acts on a stated figure rather than producing one.
A weekly meeting that examines the handful of variances that breached a threshold is a control. A weekly meeting that exists because nobody knows which number to use is a workaround.
If your two systems disagree tomorrow morning, who decides which one the business acts on, and on what stated basis? If the answer is "we would get people together," that decision has not been made yet.
Why this one is worth doing early
Most broken work compounds slowly. This one compounds fast, because everything downstream inherits the ambiguity.
Reporting built on an undeclared source is unreliable in a way that is hard to detect. Automation built on it encodes the ambiguity and makes it faster. AI built on it produces confident answers from a source nobody agreed on, which is worse than no answer at all.
Declaring the system of record is unglamorous, costs almost nothing, and quietly determines whether anything you build on top of it can be trusted.