Corporate financial statements: three locations, three figures
4 min read
Three plants, three ERP instances, three figures. When the board asks for the quarterly revenue, each site delivers a different total. Reconciling them takes days of manual work in controlling. This isn’t sloppiness-it’s an architectural decision nobody consciously made years ago. Companies running subsidiaries across borders know the tension between local autonomy and a unified view. The choice doesn’t have to be binary.
Key Takeaways
- The wrong choice. Forcing centralisation erodes local buy-in; leaving everything decentralised sacrifices the corporate perspective.
- A third path. One ERP instance per site, centrally managed master data. Federated data storage instead of a monolithic system.
- The decision. Three clear rules settle it: owner, direction, and conflict-resolution per data record.
Related:The ERP Maintenance Trap in Mid-Market Firms / When the Agent Books the Incoming Invoice Themselves
When every branch keeps its own version of the truth
The same scenario plays out in many expanding mid-market companies. A key account is created at headquarters. Three days later, the branch orders under a separate customer number; a third site invoices with different payment terms. Nobody booked incorrectly on purpose-the system simply allowed it.
Articles, suppliers and prices follow the same pattern. What one plant calls a single article is ten variants elsewhere. When consolidation time arrives, these worlds collide. The resulting discrepancies routinely cost controlling teams days of reconciliation every period. Ultimately, the question becomes: who actually owns a given data record?
Centralized or Decentralized: Both Come at a Cost
There are typically two responses. Forcing everything into a central system delivers clean reporting, but sites lose their local character and stall. Letting everyone do their own thing keeps local teams happy, yet at headquarters, no one can see the big picture. The third way is decided by criteria, not dogma.
| Criteria | Centralized | Decentralized | Federated |
|---|---|---|---|
| Local Autonomy | low | high | high |
| Corporate Oversight | high | low | high |
| Local Acceptance | low | high | medium to high |
| Integration After Acquisition | slow | barely | faster to integrate |
Federated Data Management in One Sentence
Each branch operates its own instance on an independent data schema. Local fields, custom document types, and site-specific extensions remain intact. The company centrally defines only the master data everyone shares-central customer IDs, core product data, or pricing logic-while local inventory logic stays local. Three rules underpin the model: who owns a data record, which direction it synchronizes, and which rule applies in case of conflict.
A Practical Example: Clients Instead of a One-Size-Fits-All Instance
A real-world case from the DACH region comes from Austrian software provider Multidata. It calls the approach the “client concept,” implemented on the MD-Premium platform. Companies set up separate instances for country organizations or branches, each with its own data schema and local flexibility. They centrally determine which data is shared and how it synchronizes.
Two key points keep the picture clear. The model is a programmable on-premises platform, not a cloud product that outsources the question to a hyperscaler. And the varying tax frameworks across multiple countries provide the context in which the system technically accommodates local requirements. The tax assessment itself remains the responsibility of local experts.
The Mistakes That Doom Federation
Federation rarely fails because of technology. It fails due to missing rules-always in the same places.
What Breaks
- No owner per master data record-no one decides in conflicts
- Local extensions erode the shared core schema
- Synchronization only runs at startup, then data drifts apart
What Works
- Clear separation between shared and local fields
- A named owner for each master data domain
- Fixed sync rules with frequency, direction, and conflict logic
Four Questions Before Deciding
These four questions separate clean architecture from data chaos. Answer them, and you’ve done half the work.
- Who owns customer, product, and supplier master data in case of conflict?
- Which fields must be consistent across the group, and which can vary locally?
- How often-and in which direction-are shared data synchronized?
- How quickly can an acquired site be integrated?
Local autonomy and central oversight aren’t opposites. They’re a decision your organization makes once-cleanly. If you don’t set the rules, someone else will. Then every site writes its own. And when the quarter closes, the board gets three different numbers.
Frequently Asked Questions
What does federated data management in ERP look like in practice?
Each unit operates its own instance with its own data schema. Shared master data-like customer IDs or core product records-is managed centrally and synchronized, while local fields remain under the site’s control.
Isn’t this just a centralized ERP with branches?
No. A centralized system enforces a single schema for all. In a federated model, each site keeps its own schema and local extensions, with only the shared core aligned.
What’s the biggest mistake when implementing federation?
Lack of ownership. If no one is designated to decide on master data conflicts, the data will drift apart-no matter how solid the technology.
Editor’s Picks
Read more on MyBusinessFuture
MyBusinessFutureWhen Every Order Email Has to be Manually Entered into the ERP SystemMyBusinessFutureInvestment backlog: How AI uncovers hidden budgetsMyBusinessFutureAI-Evaluation Before Succession: Preparing the Sales ValueMore from the MBF Media Network
cloudmagazinDeutschland Stack goes live: 250 million for the federal AI cloudDigital ChiefsVMware under Broadcom: Exit strategy as leverageSecurityToday72% of cyber defense comes from abroadImage source: AI-generated (June 2026)
