The most time-consuming task for the group’s CFO at month-end is often preparing the consolidated financial statements.Follow-up on Excel for each subsidiary: The accounting standards vary, customer codes are inconsistent, and internal transactions have not been fully eliminated. The root cause is not that the finance team lacks effort, but ratherIn a multi-entity environment, there is a lack of a unified organizational, permission, and master data foundation.——Each subsidiary operates as an information silo, leaving the group with only the option of “piecing together the puzzle” afterward.
Typical pain points of multi-entity management
- Organizational boundaries are blurred.: Legal entities, management units, profit centers, and cost centers are used interchangeably, resulting in mismatched reporting dimensions.
- Permissions are either strictly restricted or completely unrestricted.: Either the subsidiary cannot see the group view, or the group can modify the subsidiary’s details, leading to disputes.
- Master data split: The same customer has different codes across different subsidiaries; the same material name and specifications are inconsistently written, making consolidated procurement and inventory analysis impossible.
- Internal transactions are difficult to offset.: There are no system records for related sales, fund transfers, or service settlements; reconciliation during consolidation is done manually.
- System chimney: A subsidiary uses a certain ERP, while B uses another; the group’s BI can only connect to the ODS layer for hard data cleansing.
How to break down the business: three layers—organization, permissions, and master data.
Organizational model
Suggested hierarchy:Group → Legal Entity (Company) → Business Unit/Division → Department → Position. The legal entity is used forStatutory Reports and Taxation; Business units are used forManagement Reports and Performance Evaluation; Department used forPermissions and Approval Workflow. One person may belong to multiple organizations (e.g., concurrently serving as an executive in two subsidiaries), butData OwnershipIt must be clarified: which legal entity and which BU does this order and this expense belong to?
Permission system
Adopting RBAC + Data Scope: Role-based definition of functional permissions (whether to approve, whether to modify master data); definition of data scope boundaries for visibility and write access (within the same legal entity, within the same BU, read-only across the entire group, or requiring authorization for cross-legal-entity access). Key principles:
- Default minimum visibility: Subsidiary users can only see their own company by default; group users can view the summary, and drilling down requires an audit trail.
- Master Data Hierarchical Maintenance: Group-level master data (customer group accounts, group materials) can only be modified by the group’s master data administrator; subsidiary-level extended fields can be maintained by the subsidiaries.
- Explicit authorization across entities in business operations: Company A sells inventory from Company B, requiring internal transaction rules and visibility configurations for both parties; shared accounts are not permitted.
Master Data Governance
Core master data domain:Customers, suppliers, materials, accounts, organizations, employees. Each domain defines: coding rules, required attributes, uniqueness constraints, change approval, and effective version. For group customers, “one customer, one code”: when a subsidiary enters data,First, search the group library., if the match is successful, it will be referenced; otherwise, a new approval process will be initiated. The same applies to materials, to avoid “multiple names for the same item” that could distort the integration of MRP and procurement.
How to design: tenant, accounting set, and consolidation architecture
Single database with multi-tenancy vs. multi-database federation
Single database, multi-tenant: A single system,org_idData isolation, suitable for groups with strong governance and high standardization.Multi-warehouse federation: Each subsidiary has its own independent instance, with the group level synchronizing via an integration platform or MDM, suitable for scenarios where subsidiaries have high autonomy and legacy systems are difficult to migrate. The selection depends on: the real-time requirements for consolidated reporting, the IT capabilities of the subsidiaries, and regulatory isolation requirements.
Internal Transactions and Mergers
The system should support:Internal sales orders, internal procurement, internal settlement prices, and intercompany reconciliation. The consolidated reporting engine automatically identifies internal revenue/costs/intercompany transactions according to predefined rules and generates eliminating entries (or exports them to the consolidation system). Without transaction-level records, consolidation always relies on manual Excel spreadsheets.
Approval and workflows across entities
The group-level approval chain for policies (such as capital expenditures and major contracts) may span multiple legal entities: from the initiating subsidiary → business unit → group functions → senior group executives. The process engine must supportRoute by organization, and approvers can only view the document details within their data scope.
How to implement: phased rollout and acceptance testing
Suggestion for installment plans
- Organization and Permissions Foundation: The legal entity/BU/department tree has been launched, and RBAC plus data scope have been successfully implemented.
- Group Master Data: Customers and materials each have a unique code—one customer, one code; one item, one code—while subsidiaries can access and reference them.
- Internal transactions: Integrated procurement and sales, as well as accounts reconciliation, have gone live.
- Consolidated financial statements: From exporting offset templates to semi-automatic and then fully automatic systems.
Acceptance criteria
- When a new customer is created at any subsidiary,Plagiarism checkEffective; group accounts can be associated for query purposes.
- Subsidiary userUnable to exceed authorityView other legal entity details (security test passed).
- Internal Transaction List and Consolidation Elimination Working PapersCan be exported with one click, with a discrepancy from the manual financial spreadsheet < the agreed threshold.
Typical scenarios of cross-entity collaboration
When Company A within the group handles production and Company B handles sales, the system must support:Internal transfer price(Avoid tax risks arising from the unreasonable transfer of profits among entities),Shared inventory visibility(B can see A’s finished goods available quantity when making a sales commitment),Unified Customer View(Group accounts place orders at any subsidiary, and historical orders can be queried with associated links.) If these scenarios relied on email coordination, responses would take days; with a unified organization and master data foundation, response times can be reduced to hours.
Another common requirement isGroup procurement centralization: Centralized procurement contracts, decentralized receipt of goods, and settlement by legal entity. During design, it must be clearly defined who issues the PO, who confirms receipt, who matches the invoice, and who initiates payment—these four steps may involve three legal entities. The workflow routing must automatically assign tasks according to the organizational tree, rather than relying on manual @-ing the corresponding accountant.
Common pitfalls
Only the organizational tree, no data scope.: With functional permissions in place, data is still exposed across the entire group.Massive master data cleansing: Before going live, there was a rushed standardization; after launch, there was no maintenance position, and chaos ensued within three months.Ignoring the resistance to change in subsidiaries: The mandatory adoption of the group coding has met with resistance, necessitating supporting incentives and a transitional mapping table.Mergers only handle finance and do not involve business operations.: If the business master data is incorrect, no matter how accurate the consolidated figures are, they still cannot support business decision-making.
The group’s goal of multi‑entity digital intelligence is to enable “flexible operations at the subsidiary level” and “group‑wide visibility and management” to coexist under a unified set of rules, rather than an endless battle of report‑driven collection.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) delivers digital and intelligent systems related to multi-organization ERP, master data management, and consolidated reporting for group enterprises. See details at…xynadmin.com。