Multi-Company ERP: When One Database Helps and When It Hurts
By Apex Horizon Digital
One ERP database can give a group consistent master data, connected intercompany transactions, and consolidated visibility. It can also spread mistakes, blur legal boundaries, expose sensitive information, and force different companies into rules that do not fit. The decision should not begin with a preference for centralization. It should begin with an entity map: what each company owns, what they genuinely share, which transactions cross boundaries, who may see or act on data, and how reporting must reconcile.
Key takeaways
- Share data only where ownership, definition, and change authority are genuinely common.
- Keep legal transactions and permissions explicit even when companies use one platform.
- Choose the database boundary from operating interdependence, risk, and governance, not convenience alone.
1. Draw the entity and ownership model
List every legal entity, branch, operating unit, warehouse, brand, and shared service that the system must represent. For each, identify ownership of customers, suppliers, products, prices, inventory, employees, bank accounts, taxes, and documents. Some data may be global with local extensions. Other data must remain company-specific. A shared product catalog may help procurement, while selling price, tax treatment, or account mapping differs by entity. The model should say who creates, approves, changes, and retires each shared record.
2. Define intercompany transactions as complete workflows
Do not hide intercompany activity behind manual journals or unexplained transfers. Map the initiating document, supplying entity, receiving entity, pricing rule, tax treatment, shipment, receipt, invoice, settlement, mismatch handling, and reconciliation. Decide whether one action creates mirrored documents and which side may change them. If inventory moves between companies, legal ownership and operational location may change at different moments. The system needs explicit states so both entities can explain what they own, owe, expect, and have received.
3. Design permissions around company and function
A user may work for one entity, several entities, or a shared-service team. Permissions should combine company scope with function and action. A group buyer may view approved demand across companies but should not necessarily see payroll, margin, or bank data. Local finance may post for one entity while group finance consolidates several. Administration also needs separation: who can assign cross-company roles, change shared master data, or run exports. Test permissions with realistic personas and negative cases, not only administrator accounts.
4. Separate operational visibility from legal reporting
Management may need a group view of demand, stock, sales, cash exposure, and performance while each legal entity still requires its own books and controls. Define common dimensions and calculation rules before building consolidated reports. Record currency, exchange-rate source, elimination rules, reporting period, and ownership of adjustments. Operational dashboards can combine data without pretending every transaction belongs to one company. Reconciliation should trace a consolidated number back to entity transactions and explain intercompany differences.
5. Know when one database starts to hurt
One database becomes risky when companies have little operational connection, incompatible policies, different regulatory boundaries, weak shared governance, or a need for strong isolation. It can also become a bottleneck when every local change requires group agreement. Separate databases create integration and consolidation work, but they may contain risk and preserve autonomy. Use a decision matrix covering shared workflows, master-data overlap, intercompany volume, reporting needs, security isolation, regulatory constraints, change authority, outage impact, and exit requirements. The best architecture is the one the group can govern reliably.
- Shared layer: definitions, ownership, change authority, and local extensions.
- Company layer: legal documents, taxes, accounts, inventory ownership, and approvals.
- Intercompany layer: mirrored transactions, states, pricing, settlement, and reconciliation.
- Access layer: company scope, function, action, sensitive fields, and administration.
- Reporting layer: common dimensions, currency, eliminations, traceability, and sign-off.