When one ERPNext site should run several legal entities
ERPNext can hold several Company records on one site, and each Company keeps its own chart of accounts, books and reporting. That makes one site a practical choice for a group of related legal entities that share users, suppliers or services. Inter-company work does not run itself, though: it needs deliberate design of who transacts with whom, how the paired entries are posted, and which masters each company is allowed to see and change.
The feature set covers four things you will configure. Each company gets its own chart of accounts. Inter-company work is handled through an Inter Company Journal Entry, which records two linked Journal Entries, one in each Company with opposite totals, for shared costs, fund transfers and adjustments between related entities. A represents company setting on a customer or supplier lets one company's record stand for another company in the group. Company restrictions on masters such as customers, suppliers, items and warehouses decide which entity can use which record. Permissions for these restrictions belong to the roles and access design covered elsewhere on this page, so plan them before data is loaded.
Use one site when the entities report into the same group, share a currency policy and staff, and need consolidated visibility. Ask whether separate legal entities must be isolated for data access, audit or regulatory reasons, because a shared site means every administrator, scheduler and backup covers all companies. Use separate sites when entities have different owners, jurisdictions or data-residency rules, or when a sale or divestment is likely. Confirm with your auditors and tax advisers how inter-company invoices and tax treatment must be documented in each jurisdiction before you commit to one site.
Choosing between one site and separate sites per entity
When several entities share finance services, a single ERPNext site with multiple companies is the model that fits most directly. One site keeps one set of users, roles, items, customers that trade across entities and shared masters, so a group finance team can work across entities without logging into separate systems. Each legal entity still keeps its own company record, chart of accounts and books, and inter-company transactions are recorded through linked entries rather than copied data.
- Shared masters: Items, suppliers and customers that several entities use can be maintained once, with company restrictions controlling which entity can see or post against them.
- Group reporting: Consolidated views are simpler when every entity's ledger lives in the same database.
- Single upgrade path: One site means one upgrade cycle and one set of backups to test.
- Shared administration: A single set of administrators controls access for the whole group, which also concentrates risk.
- Shared performance load: Heavy reporting or batch jobs from one entity affect the others on the same site.
Confirm with your finance and IT leads which masters must be shared and which must be restricted, because that decision drives the company restriction design more than the hosting choice does.",
When entities operate independently and trade with each other only occasionally, the cost of a shared site may outweigh its benefits. Separate sites give each entity its own upgrade schedule, backup window, administrators and change control, and remove any chance that one entity's configuration changes reach another. The trade-off is that inter-company activity then crosses two systems, so invoices, shared costs and reconciliations need a documented process to move between them.
- Independent change control: Each entity can test and release configuration changes on its own timetable.
- Separate administration: Administrators for one entity have no access to another entity's data by design.
- Duplicated masters: Shared suppliers, items and chart structures must be maintained in each site, which adds ongoing effort.
- Manual inter-company flow: Matching documents across two sites is usually a documented manual or integration task rather than a linked entry.
- Separate hosting and backups: Each site adds its own infrastructure, backup and monitoring footprint.
Ask for a count of the transactions that would cross between entities each month, since a low volume of trades often makes separate sites reasonable.",
Entities subject to different regulators, or to data residency rules that require personal or financial records to stay in a specific country or region, may need separate hosting regardless of how closely they trade. A single site places all companies' data in one database, and whether that is acceptable depends on the rules that apply to each entity, not on ERPNext's capabilities. ERPNext's company restrictions control what users see inside a site, but they are not a substitute for physical or jurisdictional separation where a regulator requires it.
- Data location: Confirm where each entity's data must be stored, backed up and administered, including by the hosting provider's staff.
- Access separation: Determine whether administrators with access to one entity's data may also access another's.
- Audit scope: A shared site brings all entities into one control environment, which can widen the scope of an audit for each.
- Retention differences: Different retention periods for records in each jurisdiction can complicate purges and backups on one site.
- Cross-border inter-company flow: Documents that move between sites in different countries may need their own legal basis.
Confirm regulatory separation with your own legal, tax and compliance advisers before deciding, since DeployOpen does not provide legal or regulatory opinions on whether a model is compliant.
Configuration options for companies, parties and masters
This table compares the main ways to separate or link legal entities on one ERPNext site, from company records and charts of accounts to represents-company parties and user permissions. Read each row as a choice between keeping books apart, linking shared trading, and limiting who sees which entity's masters. The main takeaway is that most multi-company problems come from master data design, so decide the entity structure and party model before transactions start.
| Option | What it does | Trade-off | When it fits |
|---|---|---|---|
| Separate company records | Each legal entity has its own Company, chart of accounts, default accounts and ledgers on the same site | Clean statutory books per entity, but every company needs its own setup, masters and period close | Each legal entity must file its own accounts and close its own books |
| Shared chart of accounts design | Companies are configured with account structures that mirror group reporting needs | Consolidated reporting is easier to map, but account naming and numbering must be agreed across entities up front | Group reporting needs comparable line items across entities |
| Represents-company on Customer and Supplier | Links a party record to another Company in the same site so a sale in one entity can appear as a purchase in the other | Removes duplicate master data for intercompany trade, but the linked party's terms and accounts must be checked carefully | Entities trade goods or services with each other and both sides should be recorded in ERPNext |
| Company restrictions through user permissions | Limits which users see or post against masters and documents for specific companies | Protects entity data from staff in other entities, but permissions must be tested for every role and linked document | Staff work for one entity or a subset of entities and must not see the others' records |
| Inter Company Journal Entry | Creates two linked Journal Entries, one in each Company with opposite totals, for shared costs, fund transfers and adjustments | Documents cross-entity movements explicitly, but each side is still posted separately and needs reconciliation | Shared costs, fund transfers or adjustments between related entities need a visible audit trail |
| Shared masters without restriction | Items, suppliers or customers are available to all companies without company-level limits | Less maintenance, but users may post against records that belong to another entity | Entities share the same catalog and counterparties with no confidentiality concern |
| Separate sites per entity | Each legal entity runs its own ERPNext site with no shared data | Strongest data separation, but intercompany flows must be integrated outside ERPNext | Regulators or group policy require physical or administrative separation |
How an inter-company journal entry posts in two companies
An ERPNext Inter Company Journal Entry records two linked Journal Entries, one in each Company, with opposite totals. It is the tool for shared costs, fund transfers and adjustments between related legal entities. Each side posts to that company's own ledger, so the books of both entities balance on their own, and the link between the two entries is what lets finance match them during close. Before anyone creates one, the team should agree which entity bears the cost or holds the cash, and which entity records the matching side, because the posting direction determines both sets of accounts. The alignment work happens before the first entry. Confirm that each company has a chart of accounts with the receivable, payable, bank or expense accounts the transaction needs, and that the intercompany accounts on both sides are named and mapped consistently. Agree the currency of each company and of the transaction, and decide how an exchange difference will be treated if the two companies use different base currencies. Confirm the cost centers each side will charge, and whether those cost centers belong to the correct company. A mismatch here usually shows up as a rejected or unbalanced pair at submission, not as a clean error at the start.
Approval is the control most often left undefined. Name who prepares the entry, who reviews the company receiving it, and who can submit it in each company, and make sure those users hold the right roles and company access on the site. Write down the supporting document for each side, such as the recharge invoice or the transfer confirmation, so both entities can trace the amount to evidence. Then run a test pair on a non-production copy of the site with an illustrative amount, and check that both journal entries post, that the totals are opposite, and that the intercompany accounts net to zero across the group. The ERPNext documentation on Inter Company Journal Entry sets out the linked-entry behavior and should be read against your own chart of accounts before the design is signed off. Confirm with your implementation team which version of ERPNext your site runs, since the screens and field names should be checked against that release.
How to set up companies, masters and inter-company records
This sequence builds the legal entities, their accounts and their access rules in the right order, then proves that one inter-company transaction posts correctly in both companies before any live volume is loaded.
Define each company and its chart of accounts
Create one Company record for each legal entity, with its registered name, abbreviation, default currency and fiscal year. Load or build the chart of accounts for each company separately, since ERPNext keeps account trees per company. Confirm with your finance lead which entities need their own books and which costs will be shared. The step is done when every company appears in the company list with its own account tree, and no account is shared between companies by accident.
Set default accounts and currencies per company
On each Company record, set the default receivable, payable, income, expense, bank and cash accounts, along with the cost center used for postings. Decide which intercompany receivable and payable accounts each entity will use, because inter-company postings depend on them. Record each company's currency and confirm with accounting whether any entity transacts in a second currency, which affects later multi-currency setup. The step is done when a test document in each company picks up the correct default accounts without manual changes.
Configure represents-company parties
For each company that trades with a sister entity, create a Customer and a Supplier record that represent the other company, and link them to that company through the represents company field. This lets an invoice raised in one company generate the matching document in the other. Ask your accountants to confirm the party names, tax treatment and default payment terms for each pair. The step is done when each represented party shows the correct linked company and no duplicate party exists for the same entity.
Restrict masters with user permissions by company
Create roles for each company team and assign user permissions that limit users to their own company on company-linked masters such as customers, suppliers, items with company-specific data and cost centers. Test with a user who holds only one company's permission, and confirm they cannot open or post against another company's records. Review which users can change the Company record and the chart of accounts, since those changes affect every posting. The step is done when a restricted test user sees only their own company's records in list views and link fields.
Run one inter-company transaction end to end
Choose a small, clearly labeled test transaction, such as a sales invoice from one company to its represented customer or a journal entry for a shared cost. Submit it and let ERPNext create the linked document in the counterpart company. Then open the Inter Company Journal Entry or the linked invoice in both companies and confirm the amounts are equal and opposite, the intercompany accounts carry the balances, and each document references the other. The step is done when both sides reconcile to zero on the intercompany accounts.
Reconcile the test and document the setup
Review the general ledger and trial balance for each company after the test, then cancel or reverse the test documents according to your audit policy so they do not reach live reporting. Record the account mapping, represented parties, permission roles and the test evidence in your configuration log. Ask your auditors or finance controller to confirm how they want the test records retained. The step is done when the trial balance for each company matches the expected state and the configuration record is signed off by the finance owner.
Access control and audit trail across companies
Several legal entities on one ERPNext site share a database, so company restrictions, roles and approval rules decide who can see or post to each ledger. The cards below cover the controls to design before go-live and the records to review afterward, with the points to confirm with whoever manages roles in your organization.
Company restrictions through user permissions
A User Permission on Company limits a user to the entities they are assigned to, and linked masters such as customers, suppliers, warehouses and cost centers can be restricted by company as well. Without these restrictions, a user with a broad role may see every entity's ledger, parties and stock. Confirm with the role owner which users need one company, which need several, and whether restrictions apply to reports as well as documents.
The cross-entity ledger visibility risk
A user who can read one entity's Journal Entries can see that entity's balances, counterparties and payment history, even when they only work in another company. Shared parties, represents-company customers and inter-company documents make this more likely because they link records across entities. Test the restriction by logging in as a representative user from each entity and checking the General Ledger, Accounts Receivable and Stock Balance reports.
Segregating approval for inter-company entries
An Inter Company Journal Entry creates two linked entries, one in each Company, so a single user who can draft and submit both sides can move value between entities without a second check. Decide which role drafts, which role submits in each company, and whether the same person may act on both sides. Confirm the approval design with your finance controller and record it before the first live transaction.
Role profiles for accounting and stock
Role Profiles bundle the roles a job function needs, which keeps permissions consistent when entities are added or staff move. Separate roles for creating invoices, submitting payments, managing master data such as Chart of Accounts and Company records, and running period-closing steps reduce the number of people who can change the books. Ask the team that manages roles to map each role to a named duty and to review the mapping at each new entity.
Reviewing the version and activity trail
ERPNext keeps a version history for many documents and a Activity Log for logins and document changes, which lets reviewers see who amended or cancelled an entry and when. Review these records for each company on a fixed cadence, focusing on amendments to submitted entries, changes to company-level settings and logins from unexpected users. Confirm with your security team how long logs are retained and whether they are forwarded to a central log platform.
Protecting company settings and masters
Company defaults, default accounts and the Chart of Accounts control how every posting lands, so changes to them affect all later transactions in that entity. Restrict who can edit Company records and account masters, and use permission rules to keep ordinary accounting users from changing default receivable or payable accounts. Confirm the change process with the team that owns the chart of accounts before any new entity is added to the site.
Questions teams ask before setting up multi-company ERPNext
How much effort does a multi-company ERPNext setup take?
Effort depends mostly on how many legal entities you run, how different their charts of accounts are, and how much of your intercompany activity needs to be automated rather than booked by hand. Each company needs its own chart of accounts, fiscal year, currency and default accounts, and every shared master such as customers, suppliers, items and cost centers needs a decision about which company owns it. Intercompany invoices and journal entries add more design work than the company setup itself, because pairing accounts and tax treatment must be agreed before the first transaction. A small group of entities with aligned charts is a contained exercise. Many entities with different reporting rules, currencies or tax regimes take considerably longer and need more testing before go-live.
Can an internal finance team set up multi-company ERPNext alone?
An internal team with ERPNext experience and a clear accounting design can do it alone, and many do. The harder part is usually agreement rather than configuration: finance, tax, and the entity controllers have to sign off on the structure before anyone builds it. Teams without recent ERPNext build experience tend to underestimate how company restrictions on masters, represents-company parties and intercompany pairing interact, and how hard they are to change once transactions exist. A common pattern is to keep decisions and sign-off in-house and bring in outside help for the configuration, testing and documentation. Whichever route you choose, confirm who will maintain the setup after go-live, since new entities and new intercompany flows will need the same design work.
What does the work need from our finance and governance teams?
The setup depends on decisions that only your organization can make. Before work starts, you will need:
- A chart of accounts for each legal entity, or a agreed common structure with entity-specific accounts
- A written intercompany policy covering which costs are recharged, on what basis, and which accounts each side uses
- Named approvers for intercompany entries, master data changes and period close
- Confirmation of tax treatment for cross-entity invoices in each jurisdiction
- A list of shared masters, such as customers, suppliers and items, and which company owns each one
If these inputs are missing, the build stalls at the point where a configuration choice needs a business answer. Ask any partner to list these inputs in the written scope so the dependency is visible from the start.
Is ERPNext free to self-host for multiple companies?
ERPNext is free and open source, licensed under GPL-3.0, and self-hosting it carries no license fee. The ERPNext pricing page states that self-hosting is free. Your costs then sit elsewhere: the infrastructure you run it on, backups, monitoring, upgrades, staff time, and any external implementation or support. Hosting on Frappe Cloud is a separate choice with its own published plans, which you should compare against your own infrastructure costs. Check the pricing page for current figures before budgeting, because hosting prices are listed there and may change.
How does a partner quote follow from the scope?
A partner quote follows from a written scope that lists the entities, the chart of accounts work, intercompany flows, master data rules, data migration, testing, training and documentation. DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. To compare quotes, ask each provider to state what is included, what is excluded, which inputs they expect from your team, how testing is handled, and what happens if the scope changes. Ask whether ongoing support is priced separately, since upgrades and new entities after go-live are a recurring cost.
What breaks most often in intercompany transactions?
The most common failures come from mismatched design rather than software faults. Typical problems include:
- Intercompany journal entries posted to accounts that do not pair correctly between the two companies
- Parties shared across companies without the right company restrictions, so one entity sees another's data
- Tax treatment on cross-entity invoices that differs from what the local ledger expects
- Period close run in one company before the matching entries in the other are booked
The ERPNext Inter Company Journal Entry creates two linked journal entries with opposite totals, one in each company, for shared costs, fund transfers and adjustments. Test each intercompany flow with a sample set of transactions before go-live, and confirm the close sequence with every entity controller.
Who controls access to data across legal entities?
Access is controlled through roles, user permissions and company restrictions in ERPNext, so you should design these alongside the chart of accounts rather than after go-live. Decide which users may see which company, which masters are shared, and who can post intercompany entries. Review these rules with your security and compliance leads, because segregation between entities is often a control requirement. Confirm the exact permission behaviour for your ERPNext version with the official documentation and test it with real user accounts before relying on it.
Running multi-company books after go-live
The main operational risk after go-live is that inter-company balances drift apart between the entities, so reconciliation has to be a scheduled close step rather than a one-off check. Each Inter Company Journal Entry creates two linked Journal Entries, one in each Company with opposite totals, which gives you a pair to match. Before each period closes, run a report of inter-company receivables and payables for every entity pair and confirm that both sides agree. Any difference should be traced to a specific document, such as a shared cost posted in one company without its counterpart, a fund transfer booked on different dates, or a foreign-currency amount converted at different rates. Agree with your controllers in advance who clears these items, who approves an adjustment, and the cut-off date after which unmatched items roll into the next period. Confirm with your implementation partner exactly which reports your ERPNext version provides for this check.
Unmatched entries need a review queue, not an email thread. Assign an owner to each entity pair and require that every open item carries a reason code and a target close date. Where a mismatch is caused by a posting error, correct the original document in the company where it was entered and avoid manual journal entries that plug the gap, because plugs hide the cause and make the next reconciliation harder. Keep the audit trail intact by recording who reviewed each item and what evidence supports it. Document the review steps in the close checklist so that a new controller can follow them without help from the person who designed the setup. Changes to the entity structure happen after go-live too. Adding a legal entity means creating a new Company with its own chart of accounts, then setting up its inter-company parties, accounts and any company restrictions on masters before users can transact with it. Retiring an entity is harder: confirm with your finance and tax advisers that all inter-company balances are settled, the final period is closed, and the historical records must remain accessible for statutory retention. Plan the retirement as a project with a sign-off list, and test each step on a copy of the site first. Ask your partner to document the exact sequence for your version, since the steps depend on which company-level settings you have already configured.
User training is the control that prevents most posting errors. Users need to know which Company they are working in when they create an invoice, payment or journal entry, and they need to see that company clearly on every form. Define role-based access so that each user can post only to the entities they support, and use company restrictions on customers, suppliers and other masters so that a party belonging to one entity cannot be selected in another. Train staff with examples drawn from your own entity names and accounts, and include the inter-company workflow, so that users know when to raise a linked entry instead of posting a one-sided transaction. Refresh the training whenever an entity is added or retired, and test the permission matrix after each change, because a permission that works for one role can leak into another if roles are reused.
How DeployOpen scopes multi-company ERPNext work
DeployOpen plans and implements ERPNext inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network, so the company codes, ledgers and inter-company records stay under your control. Most engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before any build work starts. Scoping for a multi-company site starts with an entity map: every legal entity, its functional currency, its fiscal year, its tax registrations and which entities trade with which. That map determines how many companies the site needs and which transactions must cross between them.
The next steps are a review of each company's chart of accounts, an inter-company policy and a permission design. The chart of accounts review checks whether entities can share a structure or need their own, and where the Default Receivable and Payable accounts should point for each company. The inter-company policy sets which transactions create linked documents, such as an inter-company journal entry for shared costs or fund transfers, who approves them and how the two sides are reconciled. The permission design decides which users may see or post for which company, and how Company restrictions on customers, suppliers and items are applied. Confirm these decisions with your finance and audit leads before the design is written.
The test plan closes the scope. It covers sample inter-company invoices and journal entries in a non-production site, restriction tests with users from each company, and period close rehearsals across all entities. Ongoing support, upgrades and continuous testing are available as a retainer after go-live, which matters because the chart of accounts and inter-company rules usually change as the group grows. Ask for the scope document, the list of deliverables, the acceptance criteria and the retainer terms in writing, and check that each item matches the entity map you approved.
