Een multi-entity Business Central rollout in twee landen tegelijkertijd is geen software-traject —
het is finance-leiderschap met software erbij. Vijf lessen uit de afgelopen twaalf maanden.
Business Central is een uitstekend ERP-platform voor middelgrote organisaties — modulair,
breed gedragen, en met een actief partnerlandschap. Maar een re-implementatie, zeker in twee
landen tegelijkertijd, faalt vrijwel altijd om dezelfde redenen. Niet vanwege de software, maar
vanwege keuzes die te vroeg of te laat worden gemaakt. Hieronder vijf lessen uit recente
projecten in Nederland en Duitsland.
Les 01 — Het rekeningschema is geen IT-onderwerp
De grootste fout: het rekeningschema laten ontwerpen door de implementatiepartner of de
IT-afdeling. Het rekeningschema is een finance-instrument. Het bepaalt hoe het bedrijf naar
zijn cijfers kijkt, hoe consolidatie werkt, hoe rapportage werkt, hoe analyse werkt.
We adviseren altijd: start met de rapportagestructuur waar de CFO op stuurt,
leid daaruit het rekeningschema af, pas het pas aan voor entity-specifieke eisen waar
absoluut noodzakelijk. In multi-entity setups streven we naar 90%+ overlap tussen entiteiten.
Les 02 — Lokalisatie is geen detail
Duitsland en Nederland lijken op elkaar — handelspartners, vergelijkbare boekhoudstandaarden.
Maar BC-lokalisaties verschillen substantieel. Datev-export voor Duitse belastingadviseurs
werkt anders dan Nederlandse SBR. Btw-codes, factuurnummering, payroll-integratie, e-facturen
(XRechnung in Duitsland, UBL in Nederland) — allemaal afwijkend.
De fout: aannemen dat NL-instellingen "wel zullen werken" voor de DE-entiteit. De praktijk: ja,
ze werken — totdat de Duitse belastingdienst om Datev vraagt en het bestand er niet uitkomt.
Plan localisatie als apart workpackage, met een lokale stakeholder die er ownership op neemt.
Multi-country BC werkt niet als "NL met Duitse stickers erop". Elk land verdient een
volwaardige inrichting met zijn eigen review-cyclus.
Les 03 — Master data migratie is 60% van het werk
Niemand schat dit goed in. Klanten, leveranciers, artikelen, vaste activa, openstaande posten,
WIP-saldi — de migratie van masterdata is meestal de zwaarste fase, en gebeurt op het moment
dat het oude systeem nog operationeel is en het nieuwe nog niet getest.
Wat helpt: een dataschoning vóór de migratie. Klanten die al jaren niets bestellen, oude
artikelen, dubbele leveranciers — eerst opruimen in het oude systeem. Dat verkort de migratie
en verbetert de datakwaliteit in BC vanaf dag één.
Plan ook expliciet de WIP-waardering rondom go-live. WIP-saldi op datum X
moeten consistent zijn tussen oud en nieuw, en de waarderingsmethode moet op detailniveau
gedocumenteerd zijn.
Les 04 — Lucanet niet vergeten
BC is operationeel transactionsysteem. Voor consolidatie, planning en management-rapportage
gebruiken we typisch Lucanet (of vergelijkbaar). De integratie BC → Lucanet wordt vaak laat in
het traject opgepakt, terwijl de mapping van BC-rekeningen naar Lucanet-categorieën tijdens
de rekeningschema-keuze gemaakt zou moeten worden.
Als de mapping pas later wordt bedacht, zit je vast aan een rekeningschema dat niet
consolidatie-vriendelijk is. Dat is repareerbaar, maar het kost een tweede iteratie.
Les 05 — Change management onderschat
Een ERP-implementatie is voor 30% software, voor 70% mensen. Het finance-team moet anders gaan
werken. Inkopers moeten leren hoe een purchase order in BC wordt aangemaakt. Magazijnmedewerkers
moeten de juiste schermen vinden. Als die training pas na go-live komt, verliest het project
binnen weken aan vertrouwen.
We plannen training als een aparte stroom met eigen owner, eigen budget, eigen mijlpalen. Niet
één afsluitende workshop, maar gefaseerde sessies in de weken voor go-live, en in de eerste
maand actieve floorwalking. Het verschil tussen een succesvolle en een moeizame go-live zit
niet in de software — het zit in hoe goed het team is voorbereid.
Tot slot
BC-re-implementaties slagen of falen op finance-leiderschap, niet op technische
configuratie. De CFO of group controller moet het project bezitten — niet als sponsor op
afstand, maar als degene die rekeningschema, rapportagestructuur, en data-eigenaarschap
actief stuurt. De rest is uitvoering.
Business Central is an excellent ERP platform for mid-sized organisations — modular, widely
adopted, with an active partner ecosystem. But a re-implementation, especially across two
countries simultaneously, almost always fails for the same reasons. Not because of the
software, but because of choices made too early or too late. Five lessons from recent projects
in the Netherlands and Germany.
Lesson 01 — The chart of accounts is not an IT topic
The biggest mistake: letting the implementation partner or IT department design the chart of
accounts. The chart of accounts is a finance instrument. It determines how the business sees
its numbers, how consolidation works, how reporting works, how analysis works.
We always advise: start with the reporting structure the CFO actually steers on,
derive the chart of accounts from it, and only adjust for entity-specific requirements where
truly necessary. In multi-entity setups we aim for 90%+ overlap across entities.
Lesson 02 — Localisation is not a detail
Germany and the Netherlands resemble each other — trading partners, comparable accounting
standards. But BC localisations differ substantially. Datev export for German tax
advisors works differently from Dutch SBR. VAT codes, invoice numbering, payroll integration,
e-invoicing (XRechnung in Germany, UBL in the Netherlands) — all different.
The mistake: assuming NL settings "will work" for the DE entity. The reality: yes, they work —
until the German tax authority asks for Datev and the file won't generate. Plan localisation
as a separate work package, with a local stakeholder taking ownership.
Multi-country BC doesn't work as "NL with German stickers on top." Each country deserves a
proper setup with its own review cycle.
Lesson 03 — Master data migration is 60% of the work
Nobody estimates this correctly. Customers, vendors, items, fixed assets, open AR/AP, WIP
balances — the master data migration is usually the heaviest phase, and it happens while the
old system is still operational and the new one isn't yet tested.
What helps: data cleansing before the migration. Customers who haven't ordered in
years, obsolete items, duplicate vendors — clean them in the old system first. That shortens
the migration and improves data quality in BC from day one.
Also plan WIP valuation explicitly around go-live. WIP balances on date X
must be consistent between old and new, and the valuation method must be documented at
line-item level.
Lesson 04 — Don't forget Lucanet
BC is an operational transaction system. For consolidation, planning and management reporting
we typically use Lucanet (or equivalent). The BC → Lucanet integration is often picked up
late in the project, when the mapping from BC accounts to Lucanet categories should have been
defined during the chart-of-accounts design.
If mapping is figured out afterwards, you end up with a chart of accounts that isn't
consolidation-friendly. That's fixable, but it costs a second iteration.
Lesson 05 — Change management underestimated
An ERP implementation is 30% software, 70% people. The finance team has to work differently.
Buyers have to learn how a purchase order is created in BC. Warehouse staff have to find the
right screens. If training only happens after go-live, the project loses trust within weeks.
We plan training as a separate stream with its own owner, its own budget, its own milestones.
Not one closing workshop, but phased sessions in the weeks before go-live, and active floor-
walking in the first month. The difference between a successful and a painful go-live isn't
in the software — it's in how well the team is prepared.
Closing
BC re-implementations succeed or fail on finance leadership, not technical configuration. The
CFO or group controller must own the project — not as a distant sponsor, but as the person
actively steering chart of accounts, reporting structure, and data ownership. The rest is
execution.
HAAI 