When a second company is established, the team re-licenses and re-trains the same program. At the third company, this burden becomes unsustainable.
The correct model is to work with company scopes under a single account. Records remain separate, while management can view them consolidated when necessary.
In this article, we explained the multi-company structure, user access, record separation, and consolidated view.
Table of Contents
Why a single account?
Separate programs mean separate definitions, separate users, and a separate support burden; retraining is repeated for each company. As the holding grows, this model collapses and costs become uncontrollable.
EQLEM is a solution platform; it aims to manage multiple companies under a single account with scoping. The goal is not to install separate software for each legal entity, but to separate records while unifying management.
Common definitions can be kept central; company-specific fields remain separate and do not mix. This balance ensures both consistency and independence, making the financial advisor's job easier.
Management works by switching companies in a single session; the context selection remains visible. Constant logging out and in slows down daily speed and increases the risk of errors.
We discussed the single-session approach in the single session all modules article.
Company scope
Scope determines which companies' data the user will see and filters the list accordingly. An incorrect scope leads to writing documents to the wrong company and generates financial disorder.
An operations user is generally tied to a single company; their daily work runs within this boundary. A holding manager can select multiple companies, but a single context must remain mandatory at the time of writing.
The default company must be clear; the context must not get mixed when opening a record, and it should be clearly displayed to the user. An ambiguous default produces the most expensive operational errors.
Scope changes must be audited like permission changes; it must be known who expanded it and when. Silent expansion opens the door to data mixing and destroys auditing.
We covered the branch layer in the branch and warehouse scope article.
Record segregation
Each company's current accounts, inventory, and document records must be kept separate. Mixed records ruin the accountant's work.
Even if a common product card is used, stock balances must be read on a company basis. A single balance produces false stock promises.
Document numbers must be unique within the company. The same number across different companies creates clashes in reports.
If there is an intercompany transfer, a special document type must be defined. Writing it like a normal sale misleads the accounting.
We explained the structure setup in the company branch warehouse structure article.
User access
The user account is singular; access is limited by the company scope. Creating a separate user for each company is unnecessary.
Role and scope work together; the role says what to do, and the scope says where to do it. If one is missing, security is breached.
Common service teams can be assigned to multiple companies. In this case, the default context and warnings must be strengthened.
Sensitive finance permissions must be narrowed on a company basis. Holding finance and branch collections are not the same package.
We established the role setup in the role-based authorization article.
Consolidated view
Management must be able to view companies separately and combined. A consolidated view increases decision speed.
Consolidation is an operational total; it does not replace the statutory financial statement. Clearly explain this distinction to the team.
Intercompany transactions must not be double-counted. Filters should be able to weed out internal transfers.
Reporting permissions must also restrict the consolidated view. Not every manager should see the financials of every company.
We covered consolidation details in the multi-company consolidation article.
Integration with the existing ERP
In many holdings, each company keeps financial records in its own existing ERP system. The platform gathers operations on a common surface.
Synchronization must be planned on a company basis; make it clear which company will communicate with which system. One size does not fit all.
Record ownership must be written at the company and system level. Ambiguity creates duplicate records.
EQLEM does not have to replace your existing ERP systems; it works alongside them. This keeps the multi-company transition low-risk.
We explained working together in the platform alongside existing ERP article.
Branch and warehouse layer
Below the company scope lies the branch and warehouse layer. The user should often see only a single branch.
Warehouse balances must be read in the context of the company and branch. The wrong context produces the wrong shipment.
Intercompany warehouse sharing is an exception; it should not become a rule. The exception must be defined in writing.
List filters must reflect the default scope. Users should not have to manually set filters every morning.
We discussed warehouse groups in the warehouse groups article.
License impact
The single-account model makes it unnecessary to purchase a separate full package for each company. Module and channel licenses are managed centrally.
Only certain modules may be open in some companies. This flexibility ties the budget to company needs.
e-Document credits must be tracked on a company basis. One company's quota should not consume another's.
Read invoice lines by company and module. A mixed single line disrupts cost control.
We explained the licensing logic in the modular licensing article.
Common mistakes
Leaving the default company undefined is the most common mistake. Users enter documents into the wrong company.
Opening all companies to everyone is the second mistake. Control is lost for the sake of convenience.
Mistaking a consolidated report for a legal balance sheet is the third mistake. The operation total is not a financial statement.
Processing intercompany transfers like regular sales is the fourth mistake. The accounting side gets corrupted.
Strengthen report confidentiality with the report permissions article.
Installation steps
First, define the company list and legal entity information. Then, set up the branch and warehouse tree for each company.
Map users to scopes and clarify the default company. Test the wrong context with a test record.
Plan existing ERP synchronization on a company basis. Do not connect all companies at once.
Open consolidated report permissions by keeping them restricted. Grant them only to the management team in the first month.
We outlined the sync plan in the how to plan ERP synchronization article.
Frequently asked questions
Is separate software required for each company?
No, you can manage them under a single account with company scopes.
Do records get mixed up?
With the correct scope and default company definition, they do not; verify with a test record.
Is the consolidated view a financial statement?
No; it is an operational total. The statutory financial statement remains in the existing ERP or financial advisor setup.
Should the current ERP be shut down?
It does not have to be shut down; the platform can run alongside your existing ERP systems.
Installing separate software for multi-company increases cost and complexity. The single-account scope model is more sustainable.
Clarify the default company and keep user scopes narrow. The wrong context produces the most expensive operational errors.
Separate records on a company basis; keep the consolidated view limited to management.
Maintaining the existing ERP setup on a company basis while unifying operations on the platform is a low-risk path.
Monitor license and e-document credits according to company needs.
By consulting with the EQLEM team, you can set up your multi-company scope together.