Dear members…
What is the best practise to manage companies in multiple countries (multi-currency accounting) in ERPNext?
-
Option-1: Create Separate Companies in ERPNext with default Currencies (Common USD and native country currency for each company). This setup will have Reports in one page.
-
Option-2: Create Separate Instance for each Company. Consolidated reports can achieved by add Frappe Insights. But there are certain limitations.
Here the accounts are managed from the Head Office in India and have branches in multiple Countries.
Awaiting any of your suggestion. Thank you.
I would counsel against option 2. Combining separate instances is significantly harder than splitting them apart if that becomes appropriate.
Some things you’ve already realized that I would like to add some flavor to:
- If your business is domiciled and/or legally registered in a country, that should correspond to a (1) Company doctype
- For each currency you do business in, it is appropriate to have a A/R and/or A/P account in that currency. Using multicurrency accounts is not considered a best practice.
- It is much more convenient to have a consolidation and/or eliminations company in the same instance as your others, or at least your primary company.
Consolidated reports can achieved by add Frappe Insights. But there are certain limitations.
The limitation is time and effort - you will have to rewrite all consolidating reports in Insights, which isn’t unsurmountable, but if a customer brought this to me, I’d probably decline the project. Insights can only combine queries across databases into a “OLAP” SQLite table and then query that. A more mature or enterprise-y solution would be to build a data lake using the write logs from your various instances - that’s “just” an ETL pipeline that pushes everything into the database of your choice. This is a similarly large and difficult project based on the scope of the businesses you are describing. Additionally, you loose all native intercompany ERPNext features if you do this, which would be a shame because they’re good features, and you’re introducing new exception reporting requirements to catch the intercompany activity that would otherwise just work.
We have implemented a solution for a customer who chose Option 2 that calls the report APIs between the ERPNext instances. It’s hard to test and hard to debug and things that should be common across instances don’t end up being that way - CoA, Cost Centers, etc. It is similarly limited, very much like the Insights approach.
I think it’s better to make this as a horizontal scaling infrastructure problem than it is to combine data from multiple instances in a performant way.
Hi @ameerbabu
Go with Option 1 unless:
- The companies are entirely unrelated (different legal ownership, processes, or compliance needs).
- Or You need strict data firewalls with zero shared infrastructure.
- Or, there’s a compelling technical/organizational reason for full isolation.
The consequences of opting Option 2 can be;
- No native consolidated reporting: Requires Frappe Insights or external BI tools — more setup, more complexity, and limitations on drill-down/report customization.
- Duplicated setup/maintenance: Upgrades, backups, user management all multiply.
- More expensive: Hosting and admin overhead is higher.
Dear @tmatteson and @ahsantareen,
Thank you both for your valuable insights on this topic. 
I wish to provide some additional context that might help clarify our specific situation. Here we are dealing with a group structure where the ownership and management remain consistent across all our companies in different countries. What makes this particularly interesting is that we share common inventory items and often work with the same customers and suppliers across multiple jurisdictions.
The real challenge we’re facing lies in the regulatory complexity.
Take India, for example: the tax compliance requirements here involve numerous additional fields and validations that simply don’t exist in other countries we operate in. While we can certainly use scripts to hide irrelevant fields for other locations, I’m curious about the long-term implications and whether there are more elegant solutions.
I hope to connect with others who’ve navigated similar multi-country implementations, particularly those dealing with varying regulatory requirements. Your experiences could really help us make informed decisions, and I believe this discussion could benefit others facing comparable challenges.
Has anyone here dealt with dramatically different tax structures across countries within a single ERP instance? I’d love to hear about your approach and any lessons learned.
Option 2
ERPNext v15 technically allows you to create multiple companies in a single instance, but the architecture is not designed for true data isolation. Here’s the breakdown:
-
Default Behavior
-
Item Master, Customer, Supplier, and other core doctypes are shared across all companies.
-
Role Permissions can restrict transactions (like invoices or journals), but masters remain visible.
-
Client/Server Scripts apply globally, so they affect all companies in the instance.
-
Limitations
-
Item visibility: Even if you restrict permissions, users from Company A can still see items belonging to Company B.
-
Scripts: Any customization applies system-wide, not company-specific.
-
Privacy risk: Without isolation, sensitive data can leak between companies.
-
Workarounds
-
Use Role Permission Manager to limit transaction access.
-
Add custom fields like “Company Ownership” to masters, then filter reports and forms.
-
Apply user permissions tied to company filters (though this is fragile).
-
For strict separation, spin up separate ERPNext instances per company — this avoids cross-company bleed.
-
Core Fix Needed
-
ERPNext’s authorization model must evolve to support company-level isolation at the DocType level.
-
If the Frappe team implements this, multi-company setups would become straightforward and secure.
Thanks for sharing this perspective and bringing up those limitations, especially regarding master data visibility and system-wide custom scripts.
However, for our specific use case, Option 1 still makes the most sense.
Since we operate as a group where ownership and management are centralized out of Pakistan/India, and more importantly, we share common inventory items, customers, and suppliers across borders, using a single instance is actually a massive advantage. If we went with Option 2 and created separate instances, our head office would constantly be duplicating data entry, syncing item masters, and struggling with manual cross-instance reconciliations.
Regarding the regulatory challenge—such as heavy country-specific tax compliance and fields that don’t apply elsewhere—we can handle this by keeping scripts conditional (checking frm.doc.company via client scripts) so that local validations only fire for the relevant country.
For anyone dealing with truly isolated local entities, separate instances make sense. But if your inventory and operations are tightly integrated and managed centrally, Option 1 with proper permission mapping is still the way to go.
For master sharing, we will have this starting from v17.
I totally get why we’d want to keep the companies within the same instance whenever we can. But let’s think about how much they really share in terms of operations, not just where they’re located.
If the head office needs things like consolidated reporting, intercompany transactions, shared users, or consistent processes across the different entities, having separate Company records in one instance seems way easier to handle over time. Sure, separate instances offer better isolation, but they also bring about ongoing integration and maintenance challenges that tend to get bigger as more entities join in.
Also, we should make sure the decision takes into account any country-specific requirements that might need customisations down the line. I’d ask whether those differences can be managed at the Company/localisation level without impacting the other entities. If they can, keeping everything together seems like the simpler setup.
Thanks for this. I think you’ve framed it exactly the right way: the decision should rest on how much the entities actually share operationally, not on where they sit. In our case the overlap is real: centralised management out of Pakistan/India, a common item master, shared customers and suppliers across borders, consolidated reporting and regular intercompany transactions.
On country-specific requirements, yes, I’m confident these can be managed at the Company/localisation level without affecting the other entities. In ERPNext, the Chart of Accounts, base currency, fiscal year, tax templates, default warehouses and letterheads are all set per Company, and the regional features key off each company’s country. For our own customisations, the rule would be that everything is scoped: custom fields shown or made mandatory only for the relevant company or country, and client/server scripts that check the company before running any local validation. User Permissions on Company keep each entity’s users within their own data, while head office keeps the group-wide view.
So I believe we’re aligned: one instance, separate Company records, proper permission mapping and scoped customisations. Happy to document this as the decision and draft a short customisation guideline if that helps. Thanks again for raising the right questions.