Een internationale uitrol blijft één systeem wanneer je één groepsstandaard draait en die per land afstemt met de fiscale localisaties van Odoo, in plaats van elk land zijn eigen systeem te laten bouwen. Kies de vorm van de uitrol bewust, leg de standaard vast voor de eerste go-live, en geef die een eigenaar.
Je neemt een bedrijf in Duitsland over, of je opent een verkoopkantoor in Frankrijk, en de vraag belandt op iemands bureau: hoe draaien we daar ook Odoo. Het lokale team heeft al meningen. Ze hebben hun eigen btw-regels, hun eigen factuurlay-out, hun eigen rekeningschema, hun eigen manier van werken, en een lokale consultant die belooft het allemaal snel op te zetten. Dus je laat elk land zijn eigen Odoo bouwen. Het voelt respectvol naar lokale behoeften en het krijgt elk kantoor snel live.
Twee jaar later krijg je geen enkel geconsolideerd getal zonder een spreadsheet en een week werk. Elk land noemt hetzelfde product anders. Een rapport dat in één bedrijf bestaat, bestaat niet in een ander. Een upgrade moet vijf keer worden gepland. Je hebt geen één systeem over landen uitgerold. Je hebt vijf systemen gebouwd die toevallig een logo delen. De oplossing is niet om lokale behoeften te overschrijven. Het is om één Odoo-standaard te draaien en die lokaal af te stemmen, in plaats van elk land vanaf nul te laten beginnen.
Waarom de lappendeken per land ontstaat
Het gebeurt omdat de vroege beslissing eruitziet als een keuze tussen twee goede dingen, terwijl het eigenlijk een keuze is over wie eigenaar is van de standaard.
Elk land heeft echte lokale eisen. Btw werkt anders in Frankrijk dan in Polen. Duitsland verwacht SAF-T-achtige auditbestanden en een specifieke data-export. Italië heeft verplichte e-facturatie via een overheidsuitwisseling. Spanje heeft zijn eigen digitale btw-rapportage. Dit zijn geen voorkeuren, het is wet. Dus het lokale team beargumenteert, terecht, dat hun opzet lokale regels moet kunnen verwerken. De fout is de sprong van "we hebben lokale regels" naar "we hebben een lokaal systeem nodig". Dat zijn verschillende dingen. Odoo is gebouwd om lokale regels binnen één gedeelde structuur te verwerken. De lappendeken wordt niet veroorzaakt door lokale wetgeving, maar doordat je lokale wetgeving een lokale herbouw laat rechtvaardigen.
Het gebeurt ook omdat niemand aan het begin eigenaar is van de groepsstandaard. Elke uitrol wordt als een eigen project gerund, met een eigen consultant, een eigen tijdlijn, eigen beslissingen over hoe dingen genoemd en rekeningen gestructureerd worden. Zonder één eigenaar die zegt "zo doet de groep het, hier pas je aan", vindt elk land de basis opnieuw uit. Tegen de tijd dat iemand wil consolideren, komen de bases niet meer overeen, en ze achteraf op elkaar afstemmen is veel duurder dan ze vooraf afspreken.
De oplossing, in stappen
Het doel is één Odoo waar de groep één gedeelde standaard deelt en elk land alleen aanpast wat lokale wetgeving en lokale operatie echt vereisen. Werk in deze volgorde.
Bepaal eerst de vorm van de uitrol: één database met multi-company, of aparte databases.
Dit is de beslissing waar al het andere aan hangt, dus maak die bewust, niet per ongeluk.
Eén Odoo-database met een bedrijf per land geeft je het schoonste groepsoverzicht. Bedrijven delen de productcatalogus, partners en rapportagestructuur, en je kunt er native overheen consolideren en zelfs automatisch intercompany-transacties boeken. De afweging is dat alle bedrijven op dezelfde database leven, dezelfde versie, en hetzelfde upgrademoment.
Aparte databases per land geven elke entiteit volledige onafhankelijkheid: een eigen upgrade-timing, een eigen dataresidentie, een eigen isolatie. De afweging is dat consolidatie en gedeelde stamdata nu een bewust proces of een sync-laag tussen hen nodig hebben, omdat er standaard niets gedeeld wordt.
De eerlijke regel is simpel: als de landen één groep zijn die als één groep wil opereren, neig naar één database met multi-company. Als de entiteiten echt onafhankelijk zijn, met verschillende eigendom, sterk verschillende omvang, of harde dataresidentie-eisen, kunnen aparte databases juist zijn, maar je accepteert dat je meerdere systemen beheert en moet plannen hoe ze met elkaar praten.
Definieer de groepsstandaard voordat één land live gaat.
Voordat het eerste land iets configureert, spreek af wat er over de groep wordt gedeeld en leg het vast. Minimaal: de afspraken voor productnamen en -codering, de structuur van het master-rekeningschema, de analytische of rapportagedimensies die iedereen gebruikt, de kernprocessen die er overal hetzelfde uit moeten zien, en de afspraken voor taal en valuta. Dit is de standaard. Alles daaronder is lokale aanpassing, geen lokale heruitvinding.
De reden om dit eerst te doen is botte rekenkunde. Een naamgevingsafspraak overeenkomen voordat drie landen live gaan kost een vergadering. Drie live catalogi achteraf hercoderen om ze te laten matchen kost een project.
Pas de lokale fiscale localisatie per land toe, bovenop de standaard.
Dit is waar de zorg over "lokale behoeften" oplost. Odoo levert fiscale localisatiepakketten per land. Het installeren van de localisatie voor een bedrijf zet het rekeningschema van dat land op, de belastingregels en btw-structuur, de wettelijke rapporten, en vaak de e-facturatie en wettelijke aangiftes. Frankrijk, Duitsland, Italië, Spanje, Nederland, België, en tientallen meer hebben elk een onderhouden localisatie. Je bouwt lokale btw niet met de hand. Je installeert de localisatie van het land op dat bedrijf, en de lokale regels zitten bovenop de gedeelde standaard in plaats van die te vervangen. Eén waarschuwing uit onze eigen uitrollen: begin bij de officiële localisatie van Odoo en wees voorzichtig met vervangingspakketten van lokale partners. Een door een partner gebouwde localisatie kan de standaard overschrijven, en dan vechten de twee, met kapotte belastingrapporten en een geblokkeerde upgrade als de rekening. Controleer eerst wat het officiële pakket al dekt, en laat een lokale partner er bovenop toevoegen, ruil het nooit om.
Fiscale posities verwerken vervolgens de grensoverschrijdende gevallen: ze wisselen automatisch de belasting en de rekeningen op een transactie om op basis van waar de klant of leverancier zich bevindt, zodat een intra-EU-verkoop, een binnenlandse verkoop en een export elk de juiste btw-behandeling krijgen zonder dat iemand die met de hand kiest.
Houd stamdata op één plek, pas de presentatie lokaal aan.
Producten, partners en de rekeningstructuur zouden één definitie voor de groep moeten hebben. Wat per land verandert is presentatie, geen identiteit: de factuurlay-out en wettelijke vermeldingen, de taal die een klant ziet, de lokale prijs, de lokale belastingen. Odoo regelt dit met vertalingen, document-lay-outs per bedrijf en prijslijsten per valuta en regio, allemaal lezend uit dezelfde onderliggende records. Eén product, vele lokale gezichten. Dat is wat je later laat consolideren zonder een vertaaloefening.
Wijs één eigenaar van de standaard aan, en een lokale champion per land.
Een standaard zonder eigenaar zakt binnen een jaar terug naar een lappendeken. Wijs één persoon of team aan dat eigenaar is van de groepsstandaard en elke wijziging aan de gedeelde basis goedkeurt. Geef elk land een lokale champion die eigenaar is van de lokale aanpassing en echte lokale behoeften signaleert. Wijzigingen aan de gedeelde basis lopen via de eigenaar. Lokale wijzigingen blijven lokaal. Dit is de governance die de één standaard één houdt na go-live, precies daar waar de meeste uitrollen stilletjes uit elkaar vallen.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Lokale wetgeving dwingt lokale aanpassing af, geen lokaal systeem. Dit is de grote. Teams behandelen "we hebben andere btw en rapportage" als bewijs dat ze hun eigen build nodig hebben, terwijl de localisaties van Odoo precies dat binnen één gedeelde standaard leveren. Scheid de wettelijke eis van de architectuurbeslissing, of je bouwt opnieuw wat je had kunnen configureren.
Eén database betekent één upgrade voor iedereen. De multi-company op één database is het schoonst voor consolidatie, maar elk bedrijf upgradet samen. Als één land een harde reden heeft om op een oude versie te blijven, geldt die beperking nu voor de hele groep. Beslis of dat acceptabel is voordat je de vorm kiest, niet erna.
Intercompany-stromen moeten worden ingesteld, ze zijn standaard niet automatisch. Als je voorraad verkoopt of verplaatst tussen je eigen entiteiten, kan Odoo de bijbehorende inkoop en verkoop automatiseren, maar je configureert het. Sla het over en je krijgt handmatige dubbele boekingen en reconciliatie tussen je eigen bedrijven.
Elk land zijn eigen productcodes laten kiezen is de stille moordenaar. Het voelt onschuldig tijdens de uitrol en is het enige dat groepsrapportage onmogelijk maakt. Hetzelfde item moet overal hetzelfde betekenen, anders is geen enkel geconsolideerd rapport te vertrouwen.
E-facturatie en wettelijke aangiftes zijn landspecifiek en ze veranderen. De uitwisseling in Italië, de aankomende verplichting in Frankrijk, de digitale btw in Spanje: deze veranderen, en ze zijn niet optioneel. De localisatie regelt de techniek, maar iemand moet de regels per land bijhouden en elk bedrijf compliant houden naarmate ze verschuiven.
Snelle checklist
- Je hebt de vorm van de uitrol bewust gekozen: één database met multi-company, of aparte databases, met begrip van de afweging.
- De groepsstandaard (productcodes, rekeningschema, rapportagedimensies, kernprocessen) is afgesproken en vastgelegd voordat één land live gaat.
- Elk land draait de officiële fiscale Odoo-localisatie voor de btw, rekeningen en wettelijke rapporten.
- Fiscale posities verwerken binnenlandse, intra-EU- en exportbelasting automatisch.
- Stamdata heeft één groepsdefinitie; alleen de presentatie (lay-out, taal, prijs, belasting) verschilt per land.
- Eén eigenaar keurt wijzigingen aan de gedeelde standaard goed; elk land heeft een lokale champion.
- Intercompany-stromen worden geconfigureerd, niet verondersteld.
- Iemand houdt landspecifieke regels voor e-facturatie en wettelijke aangiftes in de gaten in de loop van de tijd.
FAQ
Moet ik één Odoo-database voor alle landen gebruiken of een aparte database per land?
Gebruik één database met een bedrijf per land wanneer de entiteiten één groep zijn die wil consolideren en stamdata delen, omdat Odoo dan native over alle bedrijven kan rapporteren en automatisch intercompany-transacties kan boeken. Gebruik aparte databases wanneer de entiteiten echt onafhankelijk zijn of harde eisen aan dataresidentie of upgrade-timing hebben, maar accepteer dat je dan een bewust proces of een sync-laag nodig hebt om te consolideren en data te delen, omdat er standaard niets gedeeld wordt.
Kan één Odoo verschillende btw- en belastingregels per land aan?
Ja. Odoo levert een fiscaal localisatiepakket per land dat het lokale rekeningschema, de btw- en belastingregels en wettelijke rapporten opzet. Je installeert de localisatie op elk bedrijf, en fiscale posities passen vervolgens automatisch de juiste belasting en rekeningen toe afhankelijk van of een transactie binnenlands, intra-EU of een export is. Je hoeft lokale btw niet met de hand te bouwen.
Heeft elk land echt zijn eigen Odoo-systeem nodig om aan de lokale rapportagewet te voldoen?
Nee. Verschillende landen hebben verschillende wettelijke btw- en rapportage-eisen, maar die worden afgehandeld door de landspecifieke localisaties van Odoo binnen één gedeeld systeem, niet door per land een apart systeem te bouwen. Lokale wetgeving dwingt lokale aanpassing af, geen lokale herbouw. De lappendeken komt doordat je elk land de gedeelde basis opnieuw laat uitvinden, niet door de wet zelf.
Hoe rapporteer ik over alle landen in één overzicht?
Draai de landen op één database met multi-company zodat de financiële consolidatie en groepsrapportage native zijn, en houd één gedeelde definitie voor producten, partners en het rekeningschema zodat de cijfers op elkaar aansluiten. Als je in plaats daarvan aparte databases draait, consolideer je via een bewust proces of een sync-laag die de cijfers samenbrengt, wat meer werk is en een reden om voor één database te kiezen wanneer consolidatie belangrijk is.