Hoe lang duurt een ERP-implementatie? Realistische tijdslijnen

Een fasegewijs antwoord op de vraag hoe lang een ERP-project duurt, de factoren die het verlengen en een contrasterende tijdslijn voor een boekhoudkern die u integreert via een API.

Een klein bedrijf dat overstapt op een cloud-ERP met standaardmodules heeft doorgaans drie tot zes maanden nodig vanaf de ondertekening tot de go-live. Een middelgroot bedrijf met meerdere entiteiten, aangepaste workflows (custom workflows) en koppelingen heeft meestal zes tot twaalf maanden nodig. Een grootschalige internationale uitrol duurt één tot drie jaar, vaak in golven per regio of bedrijfseenheid. Dit zijn marges die overeenkomen met wat implementatiepartners publiceren en wat financieteams rapporteren; het is geen uitkomst van een enquête, en een specifiek project kan hier in beide richtingen van afwijken.

Het ene getal waar iedereen om vraagt bestaat niet, omdat "implementatie" uit negen afzonderlijke onderdelen bestaat en de duur van elk onderdeel afhangt van beslissingen die de koper neemt voordat het project begint. Dit artikel deelt de tijdslijn op in die onderdelen, laat zien wat elk onderdeel verlokt of rekt, en beschrijft vervolgens een andere kalender: degene die u krijgt wanneer de boekhoudkern een API is waarnaar uw eigen software communiceert, in plaats van een systeem dat u configureert.

De negen fasen en wat elke fase bepaalt

Fase	Typische duur	Wat de lengte bepaalt
Selectie	1–3 maanden	Aantal geselecteerde leveranciers, demorondes, referentiegesprekken, inkoopregels
Ontwerp (Design)	2–8 weken	Hoeveel processen moeten worden in kaart gebracht, of het team het hierover eens is, in hoeverre de standaardflow van de leverancier ongewijzigd wordt geaccepteerd
Datamigratie	4–16 weken	Kwaliteit van de stamgegevens (master data), hoeveel jaren historie worden meegenomen, aantal bronssystemen
Configuratie	4–12 weken	Aantal entiteiten, grootboekrekeningschema's (charts of accounts), landen, belastingregimes, goedkeuringsstromen (approval flows)
Integratie	4–20 weken	Aantal te koppelen systemen (bank, salarisadministratie, e-commerce, CRM, magazijn), kwaliteit van de API aan beide kanten
Testen	3–8 weken	Aantal end-to-end scenario's, of de testgegevens realistisch zijn, hoeveel defecten de eerste ronde oplevert
Training	2–6 weken	Aantal medewerkers, diversiteit in rollen, hoe sterk het nieuwe proces afwijkt van het oude
Go-live	1–2 weken	Cutover-methode (big-bang of gefaseerd), timing ten opzichte van de periode-afsluiting
Hypercare	4–12 weken	Aantal openstaande defecten bij go-live, eerste periodeafsluiting van de maand, eerste btw-aangifte vanuit het nieuwe systeem

De fasen overlappen elkaar in de praktijk. De integratie begint terwijl de configuratie nog loopt; training overlapt vaak met testen. Een realistisch plan is niet zomaar de som van de kolom, maar het kritieke pad loopt meestal via datamigratie en integratie, en die twee zijn precies de plekken waar de meeste vertragingen ontstaan.

Wat het project langer laat duren

Maatwerk (Customisation). Elke wijziging ten opzichte van het standaardgedrag van de leverancier moet worden gespecificeerd, gebouwd, getest, gedocumenteerd en vervolgens opnieuw worden getest bij elke toekomstige upgrade. Een project dat het standaardproces voor 90% van de flows accepteert en de rest aanpast, heeft de neiging om te slagen; een project dat begint met het nabootsen van de schermen van het oude systeem, doet dat meestal niet.

Vervuilde stamgegevens. Dubbele klanten, leveranciers met drie verschillende spellingen, artikelen zonder maateenheid, een grootboekrekeningschema dat een decennium lang ongecontroleerd is gegroeid. Migratie kan nooit sneller gaan dan de opschoning, en die opschoning wordt gedaan door mensen die ook een dagtaak hebben. Dit is de meest voorkomende oorzaak van een uitgestelde go-live-datum en tegelijk de minst zichtbare in het oorspronkelijke plan.

Meerdere entiteiten. Elke juridische entiteit heeft haar eigen grootboek, nummering, btw-nummer, bankrekeningen en periodeafsluiting nodig. Intercompany-stromen hiertussen vragen om een eigen ontwerp. Vermenigvuldig de configuratiefase met het aantal entiteiten en tel daar het ontwerp voor de consolidatie bovenop.

Belasting in meerdere landen. Een bedrijf dat verkoopt aan meerdere EU-lidstaten moet de regels voor de plaats van levering (place of supply), de verleggingsregeling (reverse charge VAT), de OSS-rapportage en de lokale aangifteformaten correct hebben ingericht in het nieuwe systeem voordat de eerste aangifte vervalt. Als de lokale wetgeving (localisation) van de leverancier voor een land door een partner is gebouwd in plaats van standaard aanwezig is, wordt de beschikbaarheid van die partner onderdeel van het kritieke pad.

Koppelingen met zwakke API's. Een ERP dat alleen op bestanden gebaseerde imports (file-based imports) ondersteunt, dwingt elk gekoppeld systeem in een batch-patroon, en elk batch-patroon vereist reconciliatielogica die iemand moet schrijven en testen.

Een go-live-datum die is vastgelegd vóór de scope. Wanneer de datum om politieke redenen wordt vastgesteld en de scope pas later helder wordt, moet het project óf snijden in het testen óf de datum verschuiven. Beide opties zijn kostbaar.

Wat het project korter maakt

Het accepteren van de standaardprocessen van de leverancier op gebieden waar het bedrijf zich niet daadwerkelijk onderscheidt.
Het opschonen van stamgegevens voordat het project begint, niet pas tijdens het project.
Het migreren van beginbalansen plus openstaande posten in plaats van de volledige historie, en het oude systeem toegankelijk houden voor raadpleging.
Het kiezen van een cutover-datum op een periode-grens met een vergrendelde, gereconcilieerde afsluitende proefbalans (trial balance).
Het aanwijzen van één proceseigenaar (process owner) per module met de bevoegdheid om knopen door te hakken.
Testen met echte documenten uit de afgelopen twaalf maanden in plaats van met verzonnen voorbeelden.
Het kiezen van een systeem waarvan de API het mogelijk maakt om integraties parallel aan de configuratie te bouwen en te testen, in plaats van pas achteraf.

Een andere kalender: de API-first boekhoudkern

De bovenstaande tijdslijnen beschrijven een systeem dat mensen via schermen configureren en vervolgens via schermen gebruiken. Er is echter een andere projectvorm met een heel andere dynamiek. Wanneer de boekhoudkern een boekhoud-API is, verschuift het integratiewerk naar voren en verdwijnt het grootste deel van de configuratiefase omdat er simpelweg minder in te stellen valt: het grootboek, de btw-regels en de aangifteformaten worden kant-en-klaar met het product meegeleverd.

Hoe dat eruitziet in de praktijk met Nordlet, omschreven op basis van wat het product vandaag de dag daadwerkelijk doet in plaats van als een belofte:

Dag één: een sandbox-bedrijf. Een sandbox-bedrijf wordt aangemaakt vanuit de app of via een enkele API-aanroep. Het gedraagt zich exact hetzelfde als een echt bedrijf, met dezelfde modules en dezelfde endpoints, en u kunt er zoveel aanmaken als u nodig heeft. De handleiding om te starten (getting-started guide) leidt u door de eerste API-aanroepen heen.

Dag één tot en met vijf: de eerste werkende flow. Maak een relatie aan, maak een factuur aan, boek deze, ontvang een betaling en lees de journaalpost (journal entry) uit die de boeking heeft gegenereerd. Elke bewerking is een POST /v1/{module}/{resource}/{action} aanroep met een JSON-body, en er zijn getypeerde SDK's beschikbaar voor negen talen, waardoor de eerste flow slechts enkele tientjes regels code beslaat. Het herhalen van verzoeken (retries) is veilig doordat een Idempotency-Key header het opgeslagen antwoord opnieuw afspeelt in plaats van een tweede factuur aan te maken.

Week twee: historie. De migratie-importeur (migration importer) leest het grootboekrekeningschema, relaties, artikelen, beginbalansen of de volledige journaalhistorie, openstaande klant- en leveranciersfacturen, vaste activa met afschrijvingen tot de datum van vandaag en de voorraad, en schrijft dit weg in één databasewransactie. Het endpoint dat enkel controles uitvoert (migration/books/validate) voert alle validaties uit zonder iets op te slaan, zodat u het pakket net zo lang kunt aanpassen totdat er geen fouten meer worden gemeld. Vervolgens draait u eenmalig migration/books/import. Als er ook maar één rij faalt, wordt er helemaal niets opgeslagen.

Week twee tot vier: de rest van de integratie. Bankfeeds via PSD2-koppelingen, camt.053 afschriftimport, Stripe-exports, webhooks zoals sale_invoice.paid zodat uw systeem reageert op gebeurtenissen in plaats van te pollen. Elk onderdeel is een afzonderlijk endpoint en kan door een andere ontwikkelaar parallel worden gebouwd.

Compliance: reeds geregistreerd. De btw-behandeling van een grensoverschrijdende verkoop wordt afgehandeld door de EU-btw-engine (EU VAT engine), en de aangiftekalender voor het land van de onderneming wordt automatisch gevuld op basis van ingebouwde regels. De tabel voor aangifteondersteuning (filing support table) vermeldt voor alle 30 landen welke deadlines Nordlet zelf indient, voor welke landen het een bestand genereert en welke handmatig moeten worden ingevoerd. Niets hiervan is projectwerk.

De periodeafsluiting als de ultieme test. De eerste periodeafsluiting van de maand is het moment waarop een ERP-project erachter komt of het ook echt werkt. Met een onveranderbaar grootboek en periodevergrendeling (period locking) wordt een boeking met een datum in een vergrendelde maand afgewezen met een 409-foutcode. Hierdoor wordt de afsluiting afgedwongen door het systeem in plaats van door discipline, en komen integratiefouten die anders pas tijdens de hypercare-fase waren opgedoken, nu al naar boven in de sandbox.

Eerlijke grenzen van deze kalender: dit bestrijkt de kern voor boekhouding, belasting en aangiften. Als uw project daarnaast ook magazijnbeheer, productieplanning of een CRM vereist, zijn dat ofwel Nordlet-modules die u op dezelfde manier integreert (voorraad, productie, e-commercebestellingen, leads) of het zijn systemen die ernaast draaien, waarbij het integratiewerk voor die laatste categorie nog steeds bij u ligt. Nordlet is bovendien een jong product, in 2026 in early access en bezig met het onboarden van launching partners, wat een overweging is bij elke leverancierskeuze.

Hoe u uw eigen project begroot

Tel het aantal entiteiten, landen en btw-registraties. Elk van deze elementen vraagt om configuratiewerk in een traditioneel ERP, maar is niet meer dan een bedrijfsrecord in een API-first systeem.
Tel het aantal koppelingen en controleer de API van elk systeem voordat u tekent. Een interface die uitsluitend op bestanden is gebaseerd, verdubbelt grofschatting de integratietijd.
Bepaal hoeveel historische data u wilt migreren. Beginbalansen plus openstaande posten kost weken; een volledige multi-year historie kost maanden.
Bepaal de cutover-datum op basis van de periodekalender en niet andersom. Een einde van het jaar of kwartaal met een gereconcilieerde afsluitende balans is de goedkoopste cutover die er bestaat.
Houd er rekening mee dat de eerste periodeafsluiting twee keer zo lang duurt als een normale afsluiting, en reserveer budget voor hypercare tijdens de eerste btw-aangifte en de eerste salarisrun vanuit het nieuwe systeem.
Schrijf de acceptatietest voordat het project begint: de lijst met documenten, rapporten en aangiften die correct uit het nieuwe systeem moeten rollen voor de eerste afgesloten maand. Het pre-production testplan dient als sjabloon voor het boekhoudkundige gedeelte.

FAQ

Kan een ERP-implementatie minder dan drie maanden duren?

Ja, voor een bedrijf met een enkele entiteit dat standaardprocessen accepteert, alleen beginbalansen migreert en één of twee koppelingen heeft. Bij een API-first boekhoudkern is de eerste werkende flow te meten in dagen, en het langstlopende overgebleven onderdeel is doorgaans het datamigratiepakket.

Welke fase loopt het vaakst vertraging op?

Datamigratie, op de voet gevolgd door integratie. Beide zijn afhankelijk van de staat van systemen die buiten de invloedssfeer van de leverancier liggen: de kwaliteit van uw bestaande data en de API's van de systemen die u aansluit.

Moeten we de volledige historie migreren of volstaan beginbalansen?

Beginbalansen en openstaande posten zijn voldoende om het nieuwe systeem vanaf de cutover-datum compleet te laten functioneren, en ze kosten slechts een fractie van de tijd. Een volledige historie is alleen nodig wanneer u vergelijkende cijfers binnen het nieuwe systeem wilt inzien of wanneer het oude systeem volledig wordt uitgefaseerd. De importeur van Nordlet ondersteunt beide opties.

Is een gefaseerde uitrol sneller dan een big-bang-cutover?

Gefaseerde uitrollen duren in totaal langer, maar brengen minder risico per stap met zich mee en stellen het team in staat om te leren van de eerste entiteit voordat de volgende aan de beurt is. Een big-bang-aanpak is korter wanneer de organisatie klein genoeg is om alles in één cutover-weekend af te ronden.

Waarin verschilt "implementatie" voor een API-first product?

Er is geen configuratietraject waarbij schermen handmatig worden ingericht. Het werk bestaat uit integratie en migratie, uitgevoerd door ontwikkelaars tegen een sandbox, en de compliancelaag (btw-regels, aangifteformaten, kalenders) wordt kant-en-klaar meegeleverd met het product. De keerzijde is dat iemand aan uw kant daadwerkelijk code moet schrijven.