Access control for multi-company ERPNext sites starts with one question: who may see which entity
Picture a group finance team running several legal entities on one ERPNext site, with shared suppliers, a central treasury and one consolidated close. The first design decision is not which reports to build but who may see which entity. Company user permissions, applied to link fields and DocTypes, are the control that keeps entities apart on a shared site. A user restricted to one company sees only the records linked to that company, and the same restriction can be applied to the Company field on transactions, so an accountant in one entity cannot post to another by accident. Whether a single multi-company site fits depends on how much those entities share. If they use one chart of accounts structure, shared items and common suppliers, a single site with company restrictions usually keeps administration simple. If entities need different hosting, separate data ownership, different upgrade windows or legal separation of their databases, separate sites may be the better fit. The researched facts do not cover multi-company guidance in depth, so confirm the exact behavior of each link field against your version before you commit.
ERPNext is licensed under GPL-3.0 and can be self-hosted, so the software itself carries no license cost for the group. The costs that matter are the implementation, the permission design, testing and ongoing administration. Frappe Cloud hosting is a separate choice with its own published plans, and the ERPNext pricing page lists the current figures. Before any build, write down the entity map: which companies exist, which users belong to which company, which items, customers and suppliers are shared and which are exclusive, and which users need consolidated views. Then test the design with a user from each entity and a group controller, and confirm that restrictions on one company do not hide data a user needs for legitimate work, such as shared master data or intercompany transactions. Ask any implementation partner to show this test, not just the configuration.
Which access model fits each entity structure
This model fits groups where several companies sell to the same customers or buy from the same suppliers, and where items, price lists and customer records should be maintained once. Access is shaped mainly by leaving the shared masters unrestricted by company while restricting transactional documents, such as sales invoices, purchase orders and payments, to the company that owns them. Users then see one customer record but only the transactions their company is allowed to create or view.
- Master records without company tags: Customers and suppliers that carry no company restriction are visible to every user who can open the DocType, so confirm which masters you intend to share.
- Company user permissions on transactions: Apply a Company user permission to each user so that sales and purchase documents default to and filter by their entity.
- Shared item catalog: Items can be centralized, but the item-level Company restrictions in the item settings must be checked before users outside the owning entity can post against them.
- Duplicate-looking balances: A shared customer can carry receivables in several companies, which makes the customer ledger harder to read without company filters.
- Accidental cross-posting: Users who hold permissions in two companies can select the wrong default, so test default company behavior per role.
Before committing, confirm in the ERPNext user manual how user permissions cascade from link fields and which DocTypes honor company restrictions on master data.
This model fits groups where entities operate independently, with their own staff, customers, suppliers and banking, and where a user in one company should have no visibility of another. Isolation is achieved by company user permissions on every relevant DocType, separate role assignments per entity, and company restrictions on masters so that duplicates are created per entity. The trade-off is more master data maintenance and a higher chance of inconsistent records across entities.
- Per-company masters: Duplicate customers and suppliers per entity keep balances and contacts isolated, but they multiply maintenance work and reconciliation of shared counterparties.
- Role separation by entity: Give each entity its own role profiles so that a user assigned to one company cannot widen access by accident.
- Restricted reports: Standard reports and list views respect user permissions, but custom reports and print formats must be tested for leakage.
- Shared administrators: Anyone with System Manager or broad roles can see every company, so limit those accounts and document who holds them.
- Integration scope: Bank feeds, payment gateways and email accounts are often configured globally, so confirm which settings are company-specific.
Ask the implementer to demonstrate, with test users in each entity, that no list, search or link field exposes another company's records.
This model fits group finance teams who need consolidated trial balances, group-level profit and loss, and intercompany visibility, while entity users stay restricted to their own books. Access is split between operational users, who are limited to one company, and a small group finance role that can read across companies. Consolidated reporting is a separate design problem from access, so the report scope and the user permissions should be decided together.
- Dedicated group finance role: Grant read access across companies to a limited set of accounts rather than extending broad permissions to all finance staff.
- Consolidation approach: Confirm in the ERPNext documentation whether multi-company reports are produced natively, through a consolidated report setup, or through exports, since each option has different access implications.
- Intercompany transactions: Intercompany invoices and payments create records in two companies, so define which group users can see both sides.
- Currency and period alignment: Consolidation needs matching currencies and closing calendars, which affects who can post into closed periods.
- Audit trail of cross-company access: Log and review which accounts can read multiple entities, because this is the most sensitive permission in the group.
Confirm with your finance team which reports leave the system and who may export them, since a consolidated export can expose every entity at once.
Setting up company restrictions step by step
This sequence turns a shared ERPNext site into one where each user sees only the companies they are entitled to, with checks at every stage so that restrictions are confirmed before live data is loaded. It produces a tested configuration that group finance and entity teams can rely on.
Create companies and chart of accounts
Create one Company record for each legal entity on the site, then set up each company's chart of accounts, default currency, cost centers and fiscal year. Confirm the company abbreviations and default accounts with your finance lead, because they are hard to change once transactions exist. You know this step is done when each company opens with its own accounts and the Company list shows every entity exactly once.
Define roles and role profiles
Create or review the roles each job function needs, such as accounts user, sales user or stock user, and bundle them into role profiles so that one profile can be assigned to many users. Keep System Manager limited to administrators. Check the result by opening a sample user and confirming the assigned roles match the job description before any company restriction is added.
Add company user permissions per user
For each user, add a User Permission for the Company DocType with the entities that user may access. Users who work across several entities receive several rows. Confirm with the business owner which companies each person needs, since this list is the foundation of every later restriction. Done when every user record shows the expected Company permissions and no user is left without one.
Apply restrictions on item, customer and supplier records
Decide which masters are shared across companies and which belong to one entity. For masters that are company-specific, apply the relevant user permissions so that the Company link on these DocTypes filters correctly. Review how Item, Customer and Supplier records are linked to companies in your version, and confirm the behavior in a test environment before relying on it. Done when a restricted user cannot select another entity's customer or supplier in a transaction.
Configure default company on documents
Set the default company in each user's defaults or in the relevant user profile, so that new sales invoices, purchase orders and journal entries open against the correct entity without manual selection. Review the defaults for users who belong to more than one company, because they are the most likely to post to the wrong entity. Check by creating a draft document as each user and confirming the Company field is correct.
Test each user role against link field dropdowns
Log in as a test user for each role profile and open a transaction form. Confirm that the Company dropdown and the customer, supplier and item dropdowns show only the entities that user is allowed to see. Repeat the check for reports and list views, since restrictions must hold there too. Record the results for each role, because any role that shows an unexpected company must be corrected before go-live.
Verify group reporting and sign-off
Confirm that users who need group visibility can run consolidated or cross-company reports, and that entity-level users cannot. Ask finance to reconcile a sample of totals against the individual company ledgers. Obtain written sign-off from the business owner that each role's access matches the agreed matrix. The sequence is complete when the test results, reconciliation and sign-off are stored with the configuration record.
Security risks that break entity separation
Entity separation on one ERPNext site fails in predictable places: broad roles, aggregate reports, shared files and scripts that run outside the rules. Each card names one risk and the control that closes it, so you can test the same paths before users find them.
Broad roles bypass company restrictions
Users with System Manager or wide read roles can often see records across every company, because role permissions and user permissions are separate checks. A user restricted to one company by a user permission still sees other companies if a broader role grants access to the DocType. Check every role assigned to entity staff, remove System Manager from anyone who does not administer the site, and test each role by logging in as a representative user from each entity.
Reports exposing group totals
Script reports, query reports and the sidebar totals on list views can reveal another company's revenue, payables or stock even when individual records are hidden. Aggregate figures often ignore the user permissions applied to the document list. Run each standard report that touches shared DocTypes as a restricted user and compare its totals with the records that user can open.
Shared links and attachments crossing entities
A document shared by link, an email notification or a file attached to a shared record can carry data into the wrong entity. Attachments inherit the visibility of their parent record in some setups but not others, so confirm it in your own site. Decide which DocTypes may be shared externally, restrict who can upload attachments to shared masters, and test a file link opened by a user from another entity.
Server scripts bypassing the rules
Server Scripts run Python on document events or as API endpoints, and code that queries with elevated privileges can return records a user should never see. From version 15 they are disabled by default and must be enabled with server_script_enabled. Frappe Cloud public shared benches do not allow them. Keep the setting off unless you need it, require review of every script, and list which scripts query shared DocTypes.
Stale access after staff move
When an accountant moves from one entity to another, the old company user permission often stays in place, and the new one is added on top. The result is a user who quietly sees two entities' books. Review user permissions at every transfer and on a fixed schedule, and compare each user's company list against their current job. Ask who owns the review and what evidence it leaves behind.
Group LDAP mappings granting access
If ERPNext maps directory groups to roles at each login, a group change in the directory can add roles that cross entity lines without anyone editing ERPNext. Map only the groups you intend, keep entity groups separate from role groups, and check the roles assigned after a test login. Confirm the mapping behavior in the LDAP documentation for your ERPNext version before relying on it.
What to confirm in your environment before relying on it
Company restrictions in ERPNext depend on which DocTypes, reports and integrations your version applies them to, and on how your identity source assigns roles. The cards below list the items to test on your own site before you rely on company separation for financial control or group reporting.
DocType and report behavior under company restrictions
Company user permissions do not necessarily filter every DocType and every report in the same way. Build a test matrix that lists each transactional DocType, master record and standard report your entities use, then log in as a restricted user for each company and record what appears. Check list views, link field dropdowns, search results and report filters separately, because a record can be hidden in one place and visible in another. Repeat the matrix on v15 and v16 if you run both during a migration.
Company restrictions on masters
Items, customers and suppliers can be shared across companies or tied to one company, and the answer changes how restrictions behave. Confirm which of your master records are shared, which carry a company field, and whether a restricted user can create or edit a master that another company then uses. Test a transaction that pulls a customer or item from a company the user cannot see, and confirm whether the system blocks it, warns, or allows it.
Cross-company reporting limits for group consolidation
A group finance role often needs consolidated balance sheet and profit figures across several companies, while entity users must not see each other's ledgers. Confirm whether the standard financial reports can be run for multiple companies by a single user, which currency and chart of accounts assumptions apply, and whether intercompany balances appear in the group view. Record any gap that needs a custom report or an export step, and who owns that step after go-live.
Intercompany transaction handling
Transactions between two companies on the same site, such as a sale from one entity to another, can require linked documents, matching accounts and a clear owner for each side. Confirm how your version creates or links these documents, which user roles can post on each side, and whether a restricted user can see the counterpart document. Agree the elimination process for group reporting before users begin posting, since fixing mismatched entries later is slower.
LDAP group mapping to roles at each login
If you authenticate users through LDAP, ERPNext maps directory groups to its roles at each login. A user who moves to another entity in the directory may keep old company access until the mapping is reviewed, or may gain access sooner than expected. Confirm which directory groups map to which roles, how the company user permissions are assigned, and what happens when a group is removed. Test a leaver and a mover account in a non-production site.
Support status for your version
Access rules that you test on one version may change after an upgrade, so the version you run sets the support and warranty position. Check your ERPNext and Frappe Framework version against Frappe's supported versions page, and confirm whether your support plan matches the version. Schedule re-testing of the company matrix after each minor and major upgrade, and keep the test evidence with your change records.
Questions buyers ask about multi-company access in ERPNext
Should we run one ERPNext site for all companies or separate sites?
For most group finance setups, one site with company restrictions is the better starting point, because shared masters such as items, suppliers and customers are maintained once and group reporting stays in one database. Separate sites make sense when entities must never share data, have different legal or regulatory boundaries, or run on different release schedules. The decision should be made before go-live, since moving companies between sites later is a migration project. Ask your partner to document the isolation requirement each entity imposes and to compare both options against it in writing.
How much effort does a multi-company permission design take in ERPNext?
Effort depends on four things: the number of legal entities, how many masters are shared versus company-specific, how many roles the business needs, and how many group reports must cross entities. A design with a few companies, shared item and supplier masters and a short role list is far simpler than one with many entities, intercompany transactions and branch-level restrictions. Ask for a quote that lists the entities, the DocTypes with company restrictions, the roles to be tested and the reports in scope, since each of these moves the price. Ask which parts are one-time design work and which recur when a new company is added.
What does the work need from our finance and IT teams?
Finance must confirm which entities exist, which masters are shared, how intercompany transactions are handled, and who may approve postings in each company. IT must provide the environment, identity source for users, and a named owner for role changes after go-live. Both teams should agree on who can grant company permissions, because user permission records control what each person sees. Plan time for finance reviewers to sign off on test cases, since they know which balances must stay separated. Your partner should list these inputs in the statement of work so that gaps are visible before the build starts.
Can our internal team set up multi-company access without a partner?
An experienced ERPNext administrator can configure user permissions and company restrictions, and the Frappe documentation describes the core steps. The harder part is the design: deciding which masters are shared, which reports must aggregate across companies, and where a missed restriction would expose another entity's data. Teams without prior Frappe Framework experience often underestimate testing and the way permissions interact across linked DocTypes. A reasonable approach is to have your own staff own the design decisions and use an outside reviewer for the permission matrix and test plan. Ask any partner to show how they would hand over the configuration and tests.
How do we test that one company cannot see another company's records?
Test with real users from each entity, not only with administrator accounts, because administrators bypass many restrictions. For each role, check list views, search results, link fields, reports, print formats and attachments for records from other companies. Include negative cases such as trying to open a record by its direct URL and creating documents under a company the user is not assigned to. Keep the test cases and results as evidence for your own audit file. Ask your partner whether the test plan covers reports and API access, since those paths are easy to overlook.
How is group reporting handled when access is restricted by company?
Group finance reporting needs a deliberate approach, because a user restricted to one company will not see other companies' data in standard reports. Typical options are a group-level role that is granted to a small finance team, consolidated reports built for that role, or a separate reporting copy with its own access rules. Each option has different controls, audit trails and maintenance costs. Ask for the reports that the group needs, who may run them, and how intercompany eliminations are produced, then confirm that the chosen approach has been tested with restricted users.
Does ERPNext support login controls like two-factor authentication alongside company access?
Yes, company restrictions work alongside login controls, but they solve different problems. Company permissions decide what a signed-in user can see, while two-factor authentication, login policies and LDAP or social login decide who can sign in. The ERPNext LDAP documentation describes automatic mapping of directory groups to roles at each login, which can speed up onboarding but must be designed carefully so that group membership does not grant unintended company access. Confirm with your partner how identity mapping and company permissions are reviewed together.
What DeployOpen delivers for multi-company ERPNext
The core deliverable is a permission matrix per entity that shows, for each company on the site, which roles can read, create, submit, cancel and export each DocType that matters for group finance, stock and sales. The matrix is agreed with your finance and audit leads before any configuration starts, so the company restrictions on items, customers and suppliers reflect the decisions your organization has actually made. DeployOpen then configures the User Permissions that tie each user to their permitted companies, applies them to the link fields that need them, and documents where a user should not be restricted, such as group-level reporting roles.
Each engagement also includes test accounts and recorded test results. We create one account per role and per company combination in the matrix, run the same transactions and report views as each account, and record what it can and cannot see or change. The results go back to you as evidence of how the configuration behaves, so your team can repeat the checks after a change or upgrade. Administrator documentation covers how the setup works, how to add a new company or user, and which checks to run first when a user reports missing data. Confirm with us in writing which DocTypes, reports and roles are in scope, how many test accounts you expect, and who signs off the matrix.
Engagements are fixed-scope: the scope, deliverables and timelines are written down and agreed before work starts, and any change to that scope is handled in writing. Ongoing support after go-live, including permission reviews when you add a company or a role, is available as a retainer. DeployOpen prepares the configuration, test evidence and documentation for your own compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask them early which evidence they will accept.
How DeployOpen scopes and supports multi-company access
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including ERPNext sites. For multi-company access control, we start from your entity structure and permission model, build and test it on your site, and hand over the configuration with the evidence your team needs to run it.
How we scope
- Map each legal entity, its users, and the records each role must see or change
- Agree in writing which DocTypes, reports and cross-company views are in scope
- Confirm whether the site needs company restrictions, group reporting or both
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
How we build
- Configure company user permissions, role profiles and per-DocType restrictions on your site
- Test that items, customers and suppliers stay limited to the right entities
- Verify group finance reports against intercompany and consolidation requirements
- Run permission tests with named test users for each role and entity combination
How we hand over
- Document the permission matrix, role definitions and the reasoning behind each rule
- Deliver test scripts so your administrators can repeat checks after future changes
- Train administrators on adding entities, users and roles without widening access
- Record configuration changes so reviewers can trace who changed what and when
How we support
- Review permission changes when you add a company, branch or user group
- Retest access after ERPNext minor releases and before major version upgrades
- Ongoing support and continuous testing are available as a retainer
- Confirm support terms and response expectations in the written scope before work starts
