When two systems disagree about the same fact, most companies add a meeting to decide which one to believe, and the meeting keeps happening because nobody has decided which source is authoritative.
The ERP says there are four hundred units, and the warehouse system says three hundred and sixty. Both were built by capable people, both are working as designed, and each has been wrong at different times.
So there's a meeting. Every week the same people reconcile the same two numbers and arrive at a third that neither system holds, and then everyone goes back to work while the systems carry on disagreeing.
Nobody would design it this way, it arrived one reasonable decision at a time, and by now a lot rests on it: decisions wait for the meeting, and when the meeting gets cancelled, purchasing guesses. Because it looks like careful people being careful, the cost hides in plain sight, and underneath the diligence is a permanent human process making up for a decision about the systems that nobody has made.
Different numbers can both be right
Two things tend to get tangled together here. Two systems holding different numbers is normal and often correct, since they measure at different moments, with different definitions, for different purposes. A count taken when stock is received and a count taken when it's put away on the shelf are genuinely different numbers, and both can be accurate.
What causes the trouble is that nobody has declared which system is authoritative for which decision. Without that, every downstream question becomes a negotiation. Can we promise this order? Do we need to reorder? What was our stock position on the thirty-first? Each answer depends on who you ask and which screen they happen to be looking at.
If the answer to "which number is right?" is a person instead of a rule, the data is fine and the organization hasn't named its system of record, and the reconciliation is being paid for in salaries every week.
Why a meeting makes a poor permanent answer
The meeting was a sensible local response. Something needed deciding, nothing in the systems decided it, so people stepped in, which is exactly what good operators do. As a permanent arrangement, though, a recurring meeting has some awkward properties.
It doesn't grow well. Double the volume and the reconciliation doubles, so the meeting gets longer or shallower, and it usually gets shallower, which means errors start slipping through while everyone still believes they're being caught.
Its answer lives nowhere. The meeting produces a decision, usually shared out loud or in a message thread, and it rarely gets written back into either system. Both systems stay wrong, and the correct number exists only in the memories of the people who attended.
It hides the real defect. Every week the reconciliation papers over the cause. If receipts are being entered late, the meeting absorbs the effect and nobody ever fixes the timing.
Its cost never shows up. There's no line item for it, just five people's calendars and every decision that waited on the result.
What's usually underneath
A recurring reconciliation almost always traces back to one of four things.
Nobody has named a system of record. No one has written down, for each fact, which system owns it. It's a governance decision more than a technical one, usually cheap to make and expensive to keep putting off.
One word, two meanings. One system counts a unit as available when it's received, the other when it's shelved. Neither is wrong, the word "available" is simply doing two jobs, and no glossary says so.
Timing nobody mentioned. One system updates instantly and the other overnight, so the two aren't in conflict so much as in different time zones. If nobody labels a figure "accurate as of last night," people read it as current and act on it.
A flawed input at the source. This is the most common and least discussed. Something gets entered inconsistently upstream, every downstream system inherits the inconsistency in its own way, and the weekly reconciliation keeps rediscovering the same data-entry problem.
Better software fixes only one of those four, and the other three get fixed by decisions.
A standing reconciliation meeting is a decision that keeps getting postponed, on a recurring charge. Until someone states which source is authoritative for which fact, you're paying people to make that decision again every week, out loud.
How to resolve it
Name the facts before the systems. Instead of framing it as "ERP versus warehouse system," list the questions the business actually asks: how much do we have, how much can we promise, what did we hold at period end. Each is a separate fact, and they may reasonably have different owners.
Write down an owner for each fact. One system is authoritative and the others are copies that are allowed to differ. It's a five-line document, and it settles most of the argument by itself, because the argument was never really about the numbers.
Put the definition and timing next to the number. "Available stock, when shelved, as of 2:00 a.m." Most apparent conflicts disappear once each figure carries its own definition, and that's often a change to how numbers are displayed rather than an integration project.
Trace one disagreement all the way through. Take a single case where the systems differed and follow it end to end, looking for whether it's a definition, a timing difference, or a genuine data error. One traced case usually explains most of the pattern.
Fix the source before connecting the systems. If the root cause is inconsistent entry, connecting the two systems will spread the error evenly instead of fixing it, so fix the input first and connect afterward.
Retire the meeting on purpose. Cancelling it outright leaves people without an answer, so replace what it produced: a stated authoritative figure, visible to everyone who used to attend, with a defined route for when it looks wrong.
Keep a way to say "that looks wrong"
It's easy to overcorrect here. People should still be able to flag a number that looks off and have a defined way to raise it. What changes is that the review becomes an exception process that acts on a stated figure, instead of the main mechanism for producing one.
A weekly meeting that examines the few variances that crossed a threshold is a control, while 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 written basis? If the answer is "we'd get people together," that decision hasn't been made yet.
Why it's worth doing early
Most broken work builds up slowly, and this kind builds up fast, because everything downstream inherits the ambiguity. Reports built on an undeclared source become unreliable in ways that are hard to spot, automation built on it bakes the ambiguity in and speeds it up, and AI built on it gives confident answers from a source nobody agreed on, which is worse than no answer at all.
Naming the system of record is unglamorous and costs almost nothing, and it quietly decides whether anything you build on top of it can be trusted.
Set up your own operating environment.
Starter is $299, bought online, with no sales call.