How to Structure Authorization and Data Separation in Multi-Company Operations with Software Solutions?

How should shared and company-specific data be classified?

The first decision is to define whether each data object is shared across the group or belongs to a specific company. Records such as customers, products, suppliers, or users may share a common identity, while fields such as pricing, contracts, orders, costs, bank details, or operational notes can remain company-specific. Data ownership should be defined not only at the object level but, when necessary, at the field, transaction, and lifecycle level.

A data inventory is the starting point for the decision

Before designing screens, the technical team should create a data inventory and define the owner, source, sharing boundary, update authority, and retention rule for each record. This makes it possible to maintain one group-wide customer identity while isolating the commercial details of individual subsidiaries. A shared product catalog can coexist with company-specific pricing, while a centralized supplier record can remain separate from contract terms visible only to the relevant legal entity. This approach makes intercompany data management more predictable and simplifies onboarding additional companies.

• Which records will be maintained as shared master data across the group?
• Which fields can be viewed only by the company that owns the record?
• Which system or team owns updates to a shared record?
• Which event and permission can transfer data from one company to another?
• How will deletion, archiving, and anonymization rights differ by company?

Security is a process, not a product. - Bruce Schneier

Which architecture model fits multi-company software best?

There is no single correct data model for multi-company software development; the choice should depend on the required isolation level, reporting needs, scale, regulatory conditions, and operational independence between companies. Organizations may use one database separated by company identifiers, separate schemas, separate databases, or hybrid models. The architecture boundary affects not only technical performance but also the impact of authorization mistakes, maintenance effort, and the method for adding new companies later.

Isolation level should follow the operating model

A shared application layer can coexist with logically or physically separated company data. In growing group structures, understanding how a multi-tenant SaaS platform is built helps clarify decisions around tenant separation, configuration management, and scalability. However, a tenant does not have to be identical to a legal company; group, holding company, country, or business-unit scopes may need to be modeled as additional layers. Discovery should also evaluate how a growing company count will affect migration, backup, archiving, and reporting workloads.

• A shared-schema model offers centralized management but makes filtering discipline critical.
• A separate-schema model makes company boundaries clearer but may increase operational overhead.
• A separate-database model provides strong isolation but can complicate consolidation.
• A hybrid model can separate critical data while keeping common services centralized.
• Company onboarding, migration, and archiving processes should be designed from the start.

How should group and subsidiary access be constrained?

The group headquarters' broad reporting needs should not translate into unlimited operational privileges. An enterprise role and permission system should evaluate the user's role, assigned company, target data object, and requested action together. Under the least privilege principle, headquarters users should access only the companies, fields, and actions required for their responsibilities; a generic “group administrator” role should not automatically grant modification rights over every record.

The role matrix must go beyond job titles

Pure role-based access is often insufficient for headquarters teams, subsidiary managers, and operational users. Role rules can be reinforced with company or record context. When comparing providers, review how authorization, integration, and support models should be evaluated, and prefer a manageable policy layer instead of scattering permission logic throughout application code. Exceptions such as temporary assignments, delegation, approval limits, and sensitive-field access should also be documented as separate rows in the permission matrix.

• A group administrator may view all companies without being able to modify every transaction.
• A subsidiary manager may manage users and processes only within that company.
• An operational user may view and process records within an assigned task scope.
• Finance, human resources, or legal data may require an additional sensitivity layer.
• Temporary or delegated permissions should be time-limited and recorded.

How should intercompany transactions and approvals be tracked?

An intercompany transaction should not be modeled like an ordinary record owned by a single company. The source company, destination company, initiating user, counterparty approval, accounting result, and operational result should be tracked separately. A two-sided transaction trail prevents one company from silently changing another company's record and makes company-specific workflow auditable. Responsibility can therefore remain visible at every stage of the transaction.

Approval chains should expose each party's responsibility

Status transitions should be explicit in scenarios such as stock transfers, intercompany services, cost recharges, order transfers, or shared customer processes. When one company submits a transaction, a new approval task can be created for the counterparty; a rejection can store its reason; and revisions can preserve earlier versions. Thresholds or critical amounts can trigger additional approval layers. This allows the workflow to retain not only the final record but also a complete trail of decisions and changes.

• Source and destination company identifiers should be stored separately on the transaction.
• Submit, accept, reject, and cancel steps should be tracked as distinct states.
• Every approval step should record the user, time, and reason.
• Counterparty data should be updated through controlled workflows rather than direct editing.
• Corrections and reversals should not erase the previous audit trail.

How should ERP and CRM systems divide data responsibility?

If existing ERP and CRM systems will remain in place, the authoritative source for each data field must be defined. A customer may represent a financial account in ERP, a sales relationship in CRM, and an operational profile in the new platform. Building bidirectional synchronization without a defined system of record creates conflicting updates, duplicate records, and unclear ownership. Integration design should therefore answer “who owns this information” before it answers “which systems will connect.”

The integration contract should be defined field by field

An enterprise integration project should document which system creates, updates, and validates each field. Reviewing how SaaS architecture, API integrations, and cloud infrastructure are planned together highlights that data flow involves more than simply connecting systems. Error queues, retry behavior, mapping rules, synchronization latency, and remediation authority are also part of the responsibility model. In groups using multiple ERP platforms, common identity-matching rules should be governed centrally.

• Define which system creates the master customer identity.
• Specify whether financial fields can be changed outside the ERP.
• Limit which companies can receive CRM sales data.
• Assign an owner and remediation responsibility for integration errors.
• Separate bulk migration rules from daily synchronization rules.

How can centralized reporting preserve data separation?

Centralized reporting software does not need to remove operational access boundaries in order to show subsidiary data in one place. Consolidated metrics can be produced in a separate reporting layer and presented at company, regional, or group level according to the user's permissions. When reporting permission is separated from transaction permission, headquarters can gain visibility while change rights in the operational system remain limited. This prevents management reporting needs from becoming a reason to expand operational privileges.

Consolidation needs shared definitions and controlled access

Comparable metrics such as revenue, orders, customers, inventory, or service levels require a shared data dictionary. The reporting layer can normalize fields arriving from different ERP systems, while access to raw records remains restricted to authorized roles. Secondary access paths must also be controlled, including changing report filters to expose another company's data, exporting files, distributing scheduled reports by email, or providing downloadable extracts. The source and refresh time of consolidated transformations should remain traceable in the report.

• Create common calculation definitions for group KPIs.
• Apply company-level row access inside the reporting layer as well.
• Authorize raw-data access separately from summarized metrics.
• Separate export and sharing rights from viewing rights.
• Make data freshness and the source system visible in reports.

How is data separation protected beyond screen visibility?

Hiding a record in the user interface is not sufficient to create secure data separation. APIs, backend services, reporting queries, file exports, and integration accounts must follow the same access policy. Server-side authorization should prevent a user from accessing another company's data even when the request is sent directly instead of through the interface. The company context should be validated against the authenticated session and permission scope rather than trusted solely from a client-supplied parameter.

Audit trails and technical controls must work together

Software security design should combine object-level access control, company-context validation, restricted service accounts, and logging for critical actions. Company switching by administrators, bulk export, and temporary privilege elevation should produce additional records. Logs should answer not only who signed in, but also which action was performed on which record under which company context. This makes authorization violations not only preventable but also traceable for later investigation and operational review.

• Validate user and company scope on the server for every API request.
• Block cross-company access attempts made by changing record identifiers.
• Limit service accounts to only the companies and actions they require.
• Store critical administrator actions in protected audit trails.
• Authorize bulk downloads and report exports separately.

How is authorization and data separation acceptance tested?

Acceptance testing should prove not only that the correct user can see the correct screen but also that the wrong user cannot gain access. A test matrix should combine company, role, data object, and action, covering both positive and negative scenarios. Negative authorization testing is especially important in multi-company architecture because it can expose records that are hidden in the interface but still reachable through an API, report, or export channel. Test results should be retained as measurable evidence for project acceptance.

Acceptance criteria should be defined in the proposal

Test scenarios should not be postponed until the end of the project; technical scope and acceptance criteria should be included in the proposal. During provider selection, reviewing how code quality, testing, and source code delivery should be evaluated helps clarify the automation level and ownership of permission testing. Repeatable tests should be requested for cross-company access, role changes, active-session behavior, and integration users in particular. This makes it easier to revalidate the same security controls after future releases.

• Test both permitted and denied actions for every role.
• Attempt direct access using another company's record identifier.
• Check API, reporting, and file-export channels separately.
• Verify how permission changes affect active sessions.
• Confirm that audit records include user, time, company, and action details.

What should be prepared before technical discovery?

Technical discovery should begin with more than a feature list; it requires company structure and real transaction examples. An organization chart, current ERP and CRM systems, existing user roles, intercompany transaction samples, and consolidated reporting expectations directly influence architecture decisions. A concrete discovery package makes it easier to compare how solution providers define scope, risk, data responsibility, and integration ownership. This preparation also reduces the chance that major assumptions remain hidden inside the proposal.

Proposal comparison should expose architecture assumptions

Two proposals may include the same screens while taking different approaches to data isolation, integration ownership, logging, acceptance testing, and onboarding new companies. Compare not only module lists but also the data model, role matrix, system-of-record responsibilities, reporting layer, security controls, and post-delivery change management. This makes a high-budget investment more measurable before development begins and allows the technical discovery meeting to focus directly on decisions that affect scope and architecture.

• Prepare the group and subsidiary organization chart.
• Provide examples of headquarters, subsidiary-manager, and operational roles.
• List data ownership across ERP, CRM, and other source systems.
• Share at least three real intercompany transaction and approval scenarios.
• Define company-specific and consolidated reporting expectations with sample outputs.
• Document the access boundaries you want verified during acceptance testing.