Hoe ERP-systemen werken: modules, gegevensstroom en het grootboek onder de motorkap
Eén transactie gevolgd door elke module van een ERP, inclusief de daadwerkelijke journaalposten, en waarom het grootboek de bron is waar al het andere uit leest.
Een ERP-systeem werkt doordat het elke zakelijke gebeurtenis precies één keer opslaat, in één database, en elke module laat lezen en schrijven naar dat gedeelde overzicht. Een verzonden order is immers exact dezelfde registratie, ongeacht of het magazijn, het verkoopteam of de boekhouder ernaar kijkt. De module die het hele systeem integer houdt, is het grootboek: elke gebeurtenis met een geldwaarde mondt daar uit in een sluitende journaalpost, en elke rapportage wordt afgeleid van die posten.
Dit artikel volgt één verkooptransactie door de verschillende modules, toont de bijbehorende journaalposten en legt uit waarom integreren met een ERP draait om gebeurtenissen en het grootboek in plaats van om schermen.
De gedeelde database
Voor de komst van ERP beheerde elke afdeling haar eigen programma. Voorraad bevond zich in een magazijnsysteem, facturen zaten in een facturatiesysteem en de cijfers stonden in een boekhoudpakket. Het einde van de maand werd steevast besteed aan het afletteren van die drie systemen. Wat ERP-software is behandelt de categorie in brede zin; het mechanisme dat het daadwerkelijk laat werken is een enkel datamodel waarin:
- een relatie (partner) even goed wordt gebruikt door sales, inkoop als het grootboek,
- een artikel (item) de voorraadhoeveelheid, de FIFO-kostenlagen, de verkoopprijs en de omzetrekening met zich meedraagt,
- een document (order, factuur, creditnota, inkoop, productieorder) verwijst naar relaties en artikelen en precies één set journaalposten genereert,
- een journaalpost verwijst naar het document dat haar heeft aangemaakt, zodat elk cijfer in een rapportage is te herleiden tot de bron.
Wanneer de registraties gedeeld zijn, valt er tussen modules niets meer af te stemmen. Wat dan nog wel moet worden afgestemd, is de buitenwacht: bankafschriften en belastingaangiften.
De modulekaart
| Module | Schrijft | Leest |
|---|---|---|
| Verkoop | Orders, facturen, creditnota's | Relaties, artikelen, prijzen, btw-regels |
| Inkoop | Inkooporders, leveranciersfacturen | Relaties, artikelen, kostenrekeningen |
| Voorraad | Voorraadbewegingen, FIFO-kostenlagen, voorraadtellingen | Artikelen, magazijnen |
| Productie | Productieorders, componentverbruik, gereed product | Stuklijsten, voorraad |
| Bank | Geïmporteerde transacties, betalingskoppelingen | Openstaande facturen, bankrekeningen |
| Salarisadministratie | Loonruns, premies, aangiften | Werknemers, contracten, belastingtabellen |
| Vaste activa | Actiefregister, afschrijvingsruns | Activagroepen, economische levensduur |
| Fiscale zaken | Btw-aangiften, ICP-opgaven, Intrastat, e-facturen | Uitgereikte en geregistreerde documenten |
| Grootboek | Journaalposten, periodeblokkeringen | Alles hierboven |
| Rapportage | Niets | Het grootboek en de subadministraties |
Elke rij behalve de laatste twee eindigt met een schrijfactie naar het grootboek. Dat is de ontwerpregel die een ERP onderscheidt van een verzameling losse, gekoppelde tools.
Een doorgerekende gegevensstroom
Het onderstaande voorbeeld maakt gebruik van de endpoints van Nordlet en het standaardschema van het meegeleverde Litouwse rekeningschema. Elk ERP doorloopt dezelfde stappen; alleen de rekeningnummers en endpointnamen verschillen.
1. Order
Een webshop plaatst een order via POST /v1/ecommerce/orders/create: een relatie, regels met artikelen en hoeveelheden, en een land van bestemming. Er wordt nog niets geboekt in het grootboek. Een order is een intentieverklaring, geen transactie.
2. Voorraadreservering
orders/reserve zet de hoeveelheden apart zodat een tweede order dezelfde eenheden niet kan verkopen. Nog steeds geen journaalpost: gereserveerde voorraad is nog steeds eigendom.
3. Uitvoering
orders/fulfill registreert dat de goederen het magazijn verlaten. Twee dingen gebeuren in één databasetransactie:
- De voorraad wordt afgeboekt tegen FIFO-kosten: de oudste kostenlagen voor elk artikel worden als eerste gebruikt, wat de methode is die wordt beschreven in het begrippenkader over FIFO-voorraadwaardering.
- De kostprijs van die eenheden wordt geboekt als een journaalpost: debet kostprijs van de omzet, credit voorraad.
| Rekening | Debet | Credit |
|---|---|---|
| 6000 Kostprijs van de omzet | 600,00 | |
| 2040 Voorraad | 600,00 |
De uitvoeringsstap maakt tevens een kladfactuur (draft invoice) aan voor de order en bepaalt de btw-behandeling op basis van het land van bestemming met behulp van de EU-btw-engine.
4. Factuuruitgifte
Het uitreiken van de factuur is het moment waarop omzet wordt genomen voor een verkoop op een specifiek moment (point-in-time sale). Het document krijgt zijn hiatenloos nummer en er wordt één sluitende post geboekt: het brutosbedrag naar de debiteuren, de btw naar de verschuldigde-btw-rekening en het nettobedrag naar de omzet.
Voor een nettoverkoop van € 1.000 met 21% Litouwse btw:
| Rekening | Debet | Credit |
|---|---|---|
| 2410 Debiteuren | 1.210,00 | |
| 5000 Omzet goederen | 1.000,00 | |
| 4492 Verschuldigde btw | 210,00 |
Als een regel een andere erkenningsmethode dan direct resultaat kent, gaat het netto-bedrag in plaats daarvan naar de overlopende passiva (deferred income), en lost de omzetverantwoordingseengine dit volgens schema op. De boeking van debiteuren en btw verandert hierdoor niet.
De factuur kan nu worden verstuurd als pdf, als Peppol BIS 3.0 e-factuur of in het nationale e-facturatieformaat dat het land van de onderneming voorschrijft.
5. Bankkoppeling
Twee weken later komt er € 1.210 binnen. De mutatie komt binnen via een PSD2-bankfeed of een import van een camt.053-bankafschrift. De bankmodule scoort kandidaat-facturen op basis van bedrag, betalingskenmerk, naam van de tegenpartij en IBAN, waarna bank/transactions/match de vereffening boekt:
| Rekening | Debet | Credit |
|---|---|---|
| 2710 Bank | 1.210,00 | |
| 2410 Debiteuren | 1.210,00 |
De factuurstatus wijzigt naar betaald en er wordt een sale_invoice.paid-webhook verzonden. Het item over betalingsaflettering licht de koppelingslogica nader toe. Een betaling in een andere vreemde valuta boekt het gerealiseerde koersverschil in dezelfde stap naar de winst- of verliesrekening.
6. Btw-aangifte
Aan het einde van de maand hoeft er niets te worden overgetypt. De btw-aangifte wordt berekend op basis van de uitgereikte en geregistreerde documenten: declarations/eu/vat-return/compute voor de nationale aangifte (FR0600 in Litouwen), declarations/eu/oss/compute voor grensoverschrijdende consumentenverkopen onder het Unieregime. De bovenstaande verkoop belandt in het vak voor het algemene tarief van de binnenlandse aangifte omdat de btw-regeling domestic is.
7. Periodeblokkering
Zodra de aangifte is ingediend, sluit ledger/periods/lock de maand af. Vanaf dat moment wordt elke boeking met een datum in die periode, inclusief een late bankkoppeling of een opnieuw aangeboden API-aanroep, geweigerd met een HTTP 409-foutcode. Het vergrendelen triggert tevens de verantwoording van eventuele uitgestelde omzet die voor het einde van de periode is vrijgevallen, zodat een maand nooit kan sluiten met verdiende omzet die nog op de passivazijde staat.
Waarom het grootboek de basisadministratie is
Elke voornoemde module houdt een subadministratie (subledger) bij: debiteuren per klant, crediteuren per leverancier, voorraad per artikel, activa per activum. Het grootboek bevat de totalen waarmee die subadministraties moeten overeenstemmen. Subadministratie versus grootboek behandelt de onderlinge relatie; het praktische punt is dat een rapport op basis van het grootboek en een rapport op basis van een subadministratie exact dezelfde cijfers moeten opleveren, en een ERP garandeert dit door beide te produceren vanuit dezelfde journaalposten.
Drie eigenschappen maken het grootboek betrouwbaar als bronsysteem:
- Evenwicht wordt afgedwongen. In Nordlet weigert de database een post waarvan de debetzijden niet gelijk zijn aan de creditzijden. Een bug in een module kan dus nooit een scheve boeking veroorzaken.
- De historie is onveranderbaar (append-only). Een geboekte post wordt nooit gewijzigd. Een fout wordt gecorrigeerd met een tegenboeking en een nieuwe post, die beide gekoppeld blijven aan het origineel. Het lemma over het onveranderbare grootboek legt uit waarom accountants hier streng op toezien.
- Perioden sluiten af. Een vergrendelde maand kan niet meer veranderen, zodat de ingediende cijfers ook daadwerkelijk de cijfers blijven die in het systeem staan.
Integratie: gebeurtenissen en idempotentie, geen batchverwerking 's nachts
Oudere ERP-integraties werkten op basis van 's nachts uitgewisselde bestanden: orders exporteren, importeren en 's ochtends het foutenlogboek controleren. Moderne ERP's stellen een API ter beschikking, waardoor integratie neerkomt op twee uitgangspunten.
Gebeurtenissen naar buiten (Events out). Wanneer er iets verandert, laat het ERP dat weten. Nordlet schrijft elke webhookgebeurtenis naar een outbox in dezelfde databasetransactie als de wijziging zelf, zodat een document dat is teruggedraaid (rolled back) nooit een gebeurtenis uitstuurt en er geen enkele gebeurtenis verloren gaat. Leveringen worden ondertekend met HMAC-SHA256 en aangeboden met exponentiële uitsteltermijnen (exponential backoff). Uw systeem reageert op sale_invoice.paid in plaats van elke vijf minuten te vragen of er inmiddels al is betaald.
Veilig opnieuw aanbieden naar binnen (Safe retries in). Netwerken falen nu eenmaal, en een herhaald verzoek mag nooit leiden tot een tweede factuur. Nordlet accepteert een Idempotency-Key-header bij elke muterende aanroep: dezelfde sleutel met dezelfde payload retourneert de opgeslagen respons, dezelfde sleutel met een andere payload wordt afgewezen, en sleutels verlopen na 24 uur. Het begrippenkader over idempotentie en de API-conventies beschrijven dit exacte gedrag.
Omdat elke handeling een POST /v1/{module}/{resource}/{action}-aanroep is en de applicatie dezelfde endpoints gebruikt, kan een integratie de volledige voorgaande stroom doorlopen zonder dat ook maar iemand een scherm hoeft te openen. Hoe je een cloudboekhoud-API integreert in een SaaS-platform loopt stap voor stap door zo'n implementatie heen.
Wat rapportages inlezen
Rapportages slaan zelf geen cijfers op. Het zijn opvragingen (queries) op het grootboek en de subadministraties op een specifiek moment:
- Proef- en saldibalans, balans, winst- en verliesrekening en kasstroomoverzicht lezen journaalposten per rekening en periode.
- Ouderdomsanalyse (debt aging) leest openstaande debiteuren en crediteuren per vervaldatum.
- Voorraadsaldo en -beweging lezen de voorraadsubadministratie en diens FIFO-lagen.
- Btw-overzicht leest de btw-regels van uitgereikte en geregistreerde documenten.
- Kostenplaatsrapportages lezen de kostenplaatsdimensie op elke journaalregel.
In Nordlet wordt een rapportage op de achtergrond gegenereerd als XLSX, PDF of JSON, waarna er een webhook afgaat zodra het bestand klaar is. Groepscijfers zijn afkomstig van consolidatie, waarbij de grootboeken van meerdere entiteiten worden samengevoegd op basis van eigendomspercentages en valutaomrekening.
Waar dit in de praktijk misgaat
De meeste ERP-problemen zijn geen softwarestoringen, maar verstoringen van het principe van de gedeelde database. Veelvoorkomende scenario's:
- Een parallel spreadsheet voor zaken die het ERP "niet kan", dat vervolgens gaat afwijken van de boeken.
- Handmatige journaalposten om de uitvoer van een module te corrigeren in plaats van het brondocument aan te passen, waardoor de audit trail vanaf de rapportage naar de bron breekt.
- Integraties die saldi wegschrijven in plaats van documenten, waardoor het grootboek totalen bevat die niemand meer kan verklaren.
- Openstaande perioden die maandenlang niet worden afgesloten, waardoor de ingediende cijfers van het vorige kwartaal alsnog gaan schuiven.
Waarom ERP-implementaties mislukken behandelt hoe dit soort gewoonten tijdens een uitrol insluipen, en Realistische tijdlijnen voor ERP-implementaties laat zien in welke fase van het project ze doorgaans opduiken.
FAQ
Wat is de kern van een ERP-systeem?
Het grootboek en het daaromheen gegroepeerde, gedeelde datamodel. Elke module schrijft documenten die sluitende journaalposten genereren, en elke rapportage wordt afgeleid van die posten.
Hoe stromen gegevens door een ERP?
Een gebeurtenis wordt één keer geregistreerd als document (order, factuur, voorraadbeweging, loonrun). Het document produceert journaalposten in het grootboek en mutaties in de relevante subadministratie. Rapportages en belastingaangiften worden berekend op basis van die registraties. Er wordt niets gekopieerd tussen modules.
Wat is het verschil tussen een module en een integratie?
Een module schrijft naar dezelfde database en hetzelfde grootboek als de rest van het systeem. Een integratie is een extern programma dat de API van het ERP aanroept. Bij een API-first ERP is dat onderscheid klein, omdat de integratie simpelweg dezelfde endpoints gebruikt als de modules.
Boekt een ERP automatisch boekhoudkundige posten?
Ja. Het uitreiken van een factuur, het uitvoeren van een order, het afletteren van een betaling, het draaien van een loonrun of het afschrijven van een activum genereren elk afzonderlijk hun journaalpost zonder dat iemand handmatig debet- en creditregels hoeft op te stellen. De gebruikte rekeningen vloeien voort uit boekingsregels die per onderneming instelbaar zijn.
Waarom vergrendelen ERP's boekhoudperioden?
Zodat de cijfers die voor een periode zijn gerapporteerd of aangegeven achteraf niet meer kunnen veranderen. Een vergrendelde periode weigert nieuwe boekingen, wat de controleerbaarheid (audit trail) waarborgt en correcties afdwingt in de lopende periode waar ze zichtbaar zijn.