One Source of Truth: Ending the Which-Number-Is-Right Meeting
If your weekly operations meeting includes five minutes where people compare the numbers from different systems and debate which one is correct, you do not have a reporting problem. You have an integration problem.
A single source of truth means that when you ask "how many units of SKU-1234 do we have?", there is exactly one place to look, and it is always right.
Why Multiple Systems Produce Different Answers
Each system updates on its own schedule and through its own processes. A warehouse management system records a goods receipt when the items are physically confirmed. The accounting system records it when the invoice is posted. The sales system allocates the stock when the order is confirmed. These three events happen at different times, processed by different people.
Between those events, the three systems genuinely have different answers — and each one is correct according to its own logic. The problem is not the systems. It is that there is no rule defining which system's answer is authoritative for a given question.
Common conflicts:
| Question | System A Says | System B Says | Why They Differ |
|---|---|---|---|
| Stock on hand | 450 units | 480 units | 30 units allocated but not shipped |
| Revenue this month | RM 180,000 | RM 165,000 | 3 invoices not yet posted |
| Outstanding payables | RM 42,000 | RM 38,000 | 2 POs received but not invoiced |
| Customers this year | 84 | 91 | Duplicate records in one system |
Each of these conflicts has a resolution. Defining the resolution rule — and enforcing it through integration — is what produces a single source of truth.
The Two Ways to Solve It
Option 1: Integration with defined authority rules. Each system remains the authority for its own domain. The warehouse system owns physical stock counts. The accounting system owns financial balances. An integration layer reads from each authoritative source and presents a unified view. Conflicts are resolved by rule, not by debate.
Option 2: A single system that covers all domains. A custom ERP where one system is the only place data is entered — orders, stock, accounting, procurement — eliminates the problem at the source. This is the right answer for some businesses and too large a change for others.
Most Singapore SMEs start with Option 1 and move toward Option 2 over time as they outgrow their current stack.
The Integration Layer in Practice
Our system API integration work defines the authoritative source for each data type and builds the connections that keep every system updated from that source. The key rules that must be documented:
- Which system is the master for customer records?
- Which system's stock figure is used for available-to-promise calculations?
- Which system's invoice total is the one reported in management accounts?
- What is the sequence of events that triggers an update across systems?
Once these are defined and integrated, the which-number-is-right meeting becomes unnecessary because the answer is always the same in every system.
When a Custom ERP Makes Sense
For businesses where the number of integration rules becomes too large to maintain — typically when five or more systems need to stay synchronised across dozens of data types — a custom ERP is the more sustainable path. One system, one entry point, one source of truth by design.
The decision between deep integration and a custom ERP depends on transaction volume, the number of systems involved, and the cost of ongoing integration maintenance versus a rebuild.
FAQ
How long does it take to establish a single source of truth?
For a business with two to three systems, the integration and rule-definition work typically takes eight to twelve weeks. For businesses with more systems or more complex data relationships, longer. The cleanup of existing conflicting data adds time that varies by how long the conflict has been building.
Our systems do not have APIs. Can we still integrate?
Some systems offer file export as the only integration option. File-based integration is less real-time but still workable for many use cases. We assess each system's integration options during the scoping phase.
What happens when a new system is added in future?
A well-documented integration architecture means adding a new system involves connecting it to the defined authority rules, not rebuilding everything. The key is documenting which system owns which data type before the first integration is built.
Book a System Audit