An international rollout stays one system when you run a single group standard and tune it per country with Odoo's fiscal localizations, instead of letting each country build its own. Choose the deployment shape deliberately, write the standard down before the first go-live, and give it an owner.
You acquire a company in Germany, or you open a sales office in France, and the question lands on someone's desk: how do we run Odoo there too. The local team already has opinions. They have their own VAT rules, their own invoice layout, their own chart of accounts, their own way of doing things, and a local consultant who promises to set it all up quickly. So you let each country build its own Odoo. It feels respectful of local needs and it gets each office live fast.
Two years later you cannot get a single consolidated number without a spreadsheet and a week of work. Every country names the same product differently. A report that exists in one company does not exist in another. An upgrade has to be planned five times. You did not roll out one system across countries. You built five systems that happen to share a logo. The fix is not to override local needs. It is to run one Odoo standard and tune it locally, instead of letting each country start from scratch.
Why the per-country patchwork happens
It happens because the early decision looks like a choice between two good things, when it is actually a choice about who owns the standard.
Each country has real local requirements. VAT works differently in France than in Poland. Germany expects SAF-T style audit files and a specific data export. Italy has mandatory e-invoicing through a government exchange. Spain has its own digital VAT reporting. These are not preferences, they are law. So the local team argues, correctly, that their setup has to handle local rules. The mistake is the jump from "we have local rules" to "we need a local system". Those are different things. Odoo is built to handle local rules inside one shared structure. The patchwork is not caused by local law, it is caused by letting local law justify a local rebuild.
It also happens because nobody owns the group standard at the start. Each rollout is run as its own project, with its own consultant, its own timeline, its own decisions about how to name things and structure accounts. Without a single owner saying "this is how the group does it, here is where you adapt", every country reinvents the base. By the time anyone wants to consolidate, the bases no longer match, and aligning them after the fact is far more expensive than agreeing them up front.
The fix, in steps
The goal is one Odoo where the group shares a single standard and each country adapts only what local law and local operations actually require. Work in this order.
Decide the deployment shape first: one database with multi-company, or separate databases.
This is the decision everything else hangs on, so make it deliberately, not by accident.
One Odoo database with a company per country gives you the cleanest group view. Companies share the product catalogue, partners, and reporting structure, and you can consolidate across them natively and even post intercompany transactions automatically. The trade-off is that all companies live on the same database, the same version, and the same upgrade moment.
Separate databases per country give each entity full independence: its own upgrade timing, its own data residency, its own isolation. The trade-off is that consolidation and shared master data now need a deliberate process or a sync layer between them, because nothing is shared by default.
The honest rule is simple: if the countries are one group that wants to act as one group, lean toward one database with multi-company. If the entities are genuinely independent, with different ownership, very different sizes, or hard data-residency requirements, separate databases can be right, but you accept that you are managing several systems and must plan how they talk.
Define the group standard before any country goes live.
Before the first country configures anything, agree what is shared across the group and write it down. At minimum: the product naming and coding convention, the master chart of accounts structure, the analytic or reporting dimensions everyone uses, the core processes that should look the same everywhere, and the language and currency conventions. This is the standard. Everything below it is local adaptation, not local reinvention.
The reason to do this first is brutal arithmetic. Agreeing a naming convention before three countries go live costs a meeting. Re-coding three live catalogues to match afterward costs a project.
Apply the local fiscal localization per country, on top of the standard.
This is where the "local needs" worry dissolves. Odoo ships fiscal localization packages per country. Installing the localization for a company sets up that country's chart of accounts, its tax rules and VAT structure, its legal reports, and often its e-invoicing and statutory filings. France, Germany, Italy, Spain, the Netherlands, Belgium, and dozens more each have a maintained localization. You do not build local VAT by hand. You install the country's localization on that company, and the local rules sit on top of the shared standard rather than replacing it. One warning from our own rollouts: start from Odoo's official localization and be careful with replacement packages from local partners. A partner-built localization can override the standard one, and then the two fight, with broken tax reports and a blocked upgrade as the bill. Check what the official package already covers first, and let a local partner add on top of it, never swap it out.
Fiscal positions then handle the cross-border cases: they automatically swap the tax and the accounts on a transaction based on where the customer or supplier is, so an intra-EU sale, a domestic sale, and an export each get the right VAT treatment without anyone choosing it by hand.
Keep master data in one place, adapt presentation locally.
Products, partners and the account structure should have one definition for the group. What changes per country is presentation, not identity: the invoice layout and legal mentions, the language a customer sees, the local price, the local taxes. Odoo handles this with translations, per-company document layouts, and pricelists per currency and region, all reading from the same underlying records. One product, many local faces. That is what lets you consolidate later without a translation exercise.
Assign one owner of the standard, and a local champion per country.
A standard with no owner drifts back into a patchwork within a year. Name one person or team that owns the group standard and signs off on any change to the shared base. Give each country a local champion who owns the local adaptation and flags genuine local needs. Changes to the shared base go through the owner. Local-only changes stay local. This is the governance that keeps the single standard single after go-live, which is exactly where most rollouts quietly fall apart.
The part that trips people up
A few things catch almost everyone
Local law forces local adaptation, not a local system. This is the big one. Teams treat "we have different VAT and reporting" as proof they need their own build, when Odoo's localizations are designed to deliver exactly that inside one shared standard. Separate the legal requirement from the architecture decision, or you will rebuild what you could have configured.
One database means one upgrade for everyone. The multi-company single database is the cleanest for consolidation, but every company upgrades together. If one country has a hard reason to stay on an old version, that constraint now applies to the whole group. Decide whether that is acceptable before you pick the shape, not after.
Intercompany flows need setting up, they are not automatic by default. If you sell or move stock between your own entities, Odoo can automate the matching purchase and sale, but you configure it. Skip it and you get manual double entry and reconciliation between your own companies.
Letting each country choose its own product codes is the silent killer. It feels harmless during rollout and it is the single thing that makes group reporting impossible. The same item must mean the same thing everywhere, or no consolidated report can be trusted.
E-invoicing and statutory filing are country-specific and they move. Italy's exchange, France's upcoming mandate, Spain's digital VAT: these change, and they are not optional. The localization handles the mechanics, but someone has to track the rules per country and keep each company compliant as they shift.
Quick checklist
- You chose the deployment shape deliberately: one database with multi-company, or separate databases, with the trade-off understood.
- The group standard (product codes, chart of accounts, reporting dimensions, core processes) is agreed and written down before any country goes live.
- Each country runs the official Odoo fiscal localization for its VAT, accounts and legal reports.
- Fiscal positions handle domestic, intra-EU and export tax automatically.
- Master data has one group definition; only presentation (layout, language, price, tax) changes per country.
- One owner signs off changes to the shared standard; each country has a local champion.
- Intercompany flows are configured, not assumed.
- Someone tracks country-specific e-invoicing and statutory filing rules over time.
FAQ
Should I use one Odoo database for all countries or a separate database per country?
Use one database with a company per country when the entities are one group that wants to consolidate and share master data, because Odoo can then report across all companies natively and post intercompany transactions automatically. Use separate databases when the entities are genuinely independent or have hard data-residency or upgrade-timing requirements, but accept that you then need a deliberate process or a sync layer to consolidate and share data, because nothing is shared by default.
Can one Odoo handle different VAT and tax rules per country?
Yes. Odoo ships a fiscal localization package per country that sets up the local chart of accounts, VAT and tax rules, and legal reports. You install the localization on each company, and fiscal positions then apply the correct tax and accounts automatically depending on whether a transaction is domestic, intra-EU or an export. You do not have to build local VAT by hand.
Does each country really need its own Odoo system to meet local reporting law?
No. Different countries have different legal VAT and reporting requirements, but those are handled by Odoo's per-country localizations inside one shared system, not by building a separate system per country. Local law forces local adaptation, not a local rebuild. The patchwork comes from letting each country reinvent the shared base, not from the law itself.
How do I report across all countries in one view?
Run the countries on one database with multi-company so the financial consolidation and group reporting are native, and keep one shared definition for products, partners and the chart of accounts so the numbers line up. If you run separate databases instead, you consolidate through a deliberate process or a sync layer that brings the figures together, which is more work and a reason to choose one database when consolidation matters.