ERP Architecture and Data Isolation for Multi-Company Structures

When planning Enterprise Software & ERP projects for businesses that incorporate multiple legal entities, subsidiaries, or brands, one of the most critical technical thresholds is how the infrastructure will be positioned. Maintaining the legal and operational independence of each legal entity while managing shared resources relies on establishing a proper ERP architecture. In this guide, we examine the technical steps centered on data security and regulatory compliance in multi-company structures.

1. Determining the Data Isolation Strategy

In multi-company structures, data isolation is mandatory to prevent the financial, personnel, and commercial data of different companies from mixing. Three core models stand out during the system design phase:

• Physical Database Separation: A completely independent database instance is created for each company. It provides the highest isolation, but hardware and maintenance costs are high.
• Schema-Based Isolation: Separate schemas are used for each company on a single database server. Table structures are managed jointly, but data is logically separated.
• Shared Table Architecture (Tenant ID): All data is kept in the same tables and row-level filtering is applied.

2. Schema Design and Shared Entity Management

Schema design directly impacts system performance and flexibility. When modeling databases for multi-company structures, the following rules must be observed:

• Ensure that each table includes primary keys as well as a company ID column specifying which company it belongs to.
• Common master data, such as inventory, current account, or material cards, is kept in common tables for centralized management and to facilitate inter-company trade.
• Transactional data (invoices, delivery notes, journal vouchers) is strictly isolated at the schema or row level.

3. Authorization and Access Control

In enterprise software solutions, users must only be able to access the data of companies they are authorized for. Company-based authorization matrices should be implemented along with Role-Based Access Control (RBAC). While a user has permission to access accounting records in company A, their access to financial data in company B must be completely blocked.

4. Consolidation and Reporting Layer

Even if data across different companies is isolated, generating consolidated reports for senior management is a requirement. At this stage, dedicated query and ETL processes running at the database level or within the Data Warehouse layer are structured. Centralized financial statements are generated with read-only permissions without violating isolation rules.

5. Hypothetical Case Study: A Three-Company Structure Under a Holding Umbrella

In this scenario, we examine how the enterprise ERP architecture is positioned for a holding company with three distinct legal entities operating in textiles, logistics, and retail. While the textile and retail companies are separated via schema-based isolation on the same database server, the logistics company is hosted on a completely physically independent database instance due to regulatory requirements and data sensitivity. Inventory and current account cards are synchronized by utilizing a central Enterprise Software & ERP layer for common master data management.

The primary trade-off between trade and performance in the system design is as follows: While schema-based isolation lowers hardware costs and accelerates joint reporting processes, a potential query optimization error can simultaneously impact the performance of both companies. Although physical separation ensures maximum security, it increases synchronization costs during inter-company goods movements. In the failure management scenario, during network outages or database response time timeouts, the central consolidation layer is automatically disabled to ensure local operations continue uninterrupted. This approach preserves regulatory compliance without risking operational continuity.

6. Detailed Implementation Checklist for Multi-Company ERP Architecture

To minimize technical risks and prevent data leaks when launching multi-company ERP projects, the following steps must be fully implemented:

• Architecture Selection: The physical, schema, or row-based isolation model must be finalized by analyzing the companies' legal obligations, data volumes, and budgets.
• Database and Schema Setup: Tenant ID and company keys must be added as mandatory fields to all transaction tables, and indexing should be optimized via these keys.
• Access and Permission Matrix: User access to data outside company boundaries must be blocked at the database and application layer using Role-Based Access Control (RBAC).
• Integration and ETL Processes: Secure, encrypted API and ETL pipelines must be designed for inter-company goods transfers and consolidated reporting.
• Error and Failure Management: Instant logging mechanisms and alarm systems must be established for database connection drops or unauthorized access attempts.
• Performance and Load Tests: Comprehensive stress tests must be conducted to observe system behavior under concurrent multi-company reporting.

References

• Enterprise Software & ERP — Cy Logic Software