The moment mid-market leaders realise the CRM, the ERP, the finance system, the HR system and the operational tool no longer agree — and a working diagnosis of what to do next.
The board pack has three revenue numbers. The one the CFO trusts. The one from the CRM the CRO uses. The one from the operational reporting the COO relies on. On any given month, they will not agree — usually by a small amount, occasionally by a large one. The finance team spends the last week of every month reconciling. The CRO's team spends the first week of every month re-explaining. The board learns that the numbers are *directional*, which is a polite way of saying *nobody knows for sure*. Meanwhile, the head of HR is reporting a different headcount than the payroll system. The head of operations is quoting a different service level than the ticketing system. And when the CEO asks a simple question — *how many customers do we have?* — the answer arrives after a conversation between three heads of department about which definition of customer to use.
The five systems were bought at five different times, by five different sponsors, to solve five different problems. Each was implemented on its own terms. Each was configured against its vendor's default assumptions. None of them was configured against a definition of the business's core entities that had been agreed across the leadership team — because that definition had never been written down. The CRM has a customer. The ERP has a customer. The finance system has a debtor. The HR system has an employee. The operational tool has an account. These are not the same thing. Each system knows its own version. None of them knows the master version. There is no master version.
The obvious cost is the reconciliation work — measured in headcount hours per month across finance, operations and IT. The larger costs are subtler. Every management report comes with a footnote nobody reads. Every strategic conversation loses its first fifteen minutes to *whose numbers are we using?* Every attempt to add analytics or AI hits the same wall: the models cannot be trusted because the data underneath them cannot be trusted. Working capital is worse than it should be because inventory data across systems disagrees. Sales incentives get argued because the CRM's booking definition differs from the finance system's revenue-recognition definition. Talent leaves because senior operators cannot get a straight answer to a straight question.
The software vendors each did their job. The individual systems each work well within their own boundary. The failure is not inside any system. The failure is between them — in a layer nobody was accountable for. Master data management (MDM) platforms exist and can solve this at large enterprises with dedicated teams to run them. For a mid-market business, an MDM platform is heavier than the problem requires. What is missing is not another platform. What is missing is a definition of the master entities and a small integration layer that keeps the systems in agreement.
None of the five systems, in most cases. Each is individually adequate; each was chosen for good reasons at the time. Replacing any of them is expensive, disruptive, and does not solve the between-system problem. Also do not build a data warehouse and hope that it will produce agreement — a warehouse that pulls from five disagreeing sources produces a sixth version of the truth, not a canonical one. The redesign starts with agreement on definitions, not with technology.
The definitions of the business's core entities. What is a customer? What counts as a booking? What counts as revenue? What is an active employee versus a contractor? What is an open case versus a closed one? These sound like trivial questions. In most mid-market businesses they have never been answered explicitly. When they are answered — through a short, sharp process the leadership team owns — the definitions become the specification the systems must serve. That specification is the beginning of a canonical version.
The systems, against the canonical definitions. Once the leadership team has agreed what a customer is, every system either records the customer that way or has a mapping that translates it. The integration layer is not a heroic architecture. It is a small, disciplined middleware that keeps the systems in agreement — and, critically, that surfaces the exceptions where a system's data cannot be reconciled without a human decision. Those exceptions become the operational discipline that keeps the data clean going forward.
The reconciliation the finance team does at month-end. The employee-headcount check the HR head does before the board. The service-level report the operations team assembles for the exec pack. All of these are repeatable, rule-based tasks the human is currently doing because the systems disagreed. Once the definitions are agreed and the integration layer is running, the reconciliation becomes automatic — and the humans revert to handling only the exceptions the automation flagged.
AI helps at the reconciliation exception layer. The rule-based integration handles the standard cases. AI is useful for the harder ones — matching a customer record that was entered differently in two systems, flagging a booking that looks like it might be duplicated across two revenue streams, categorising a case that could belong in either the CRM or the ticketing system. Used at this layer, AI accelerates the reconciliation and produces the audit trail that finance and audit will require. Used above this layer — on data that has not been reconciled — AI produces the sixth version of the truth described earlier.
This class of work does not need a large programme. Start with the entity that produces the most disagreement — usually the customer or the booking. Agree the definition. Wire the integration for that entity. Automate the reconciliation. Expose the resulting single version of the truth to the leadership team. When the leadership team stops arguing about the customer number, fund the next entity. A typical twelve-month arc: months 1–2 agree definitions for two entities; months 3–6 integrate and automate the first entity; months 7–10 integrate and automate the second; months 11–12 consolidate the reporting layer. The change is progressive; the credibility compounds.
This is not a large-team programme. It requires senior digital leadership to hold the leadership team through the definitional decisions — which is more organisational than technical — and specialists to build the integration layer against the specific systems in the stack. The delivery load is finite. Once the definitions are in place and the integration is running, the operating discipline that keeps the data clean is a lightweight standing capability, not a full internal-IT function.
A Jettifi engagement of this class begins with a definition workshop — one day per entity — that the leadership team runs and Jettifi facilitates. The output is a canonical definition of each core entity, signed off by the executive owner. Senior Jettifi core then designs the integration layer; specialists build it against the specific systems in the stack. The engagement ends when the leadership team can look at a single number for each core entity and not have to argue about it — and when the discipline that keeps the number clean is owned by the client.
Discuss the single version of the truth your board needs
Talk to Jettifi →For the underlying working paper, read the Digital Reengineering pillar or the executive edition of The Guide.