Verplichte e-facturatie en je administratie

Wat er nu al verplicht is, en wat niet

Rond dit onderwerp circuleren veel koppen met "verplicht vanaf 2026". Die slaan bijna altijd op België. In Nederland is de stand op dit moment overzichtelijker dan de berichtgeving doet vermoeden.

• Aan de centrale rijksoverheid factureer je sinds 2017 verplicht elektronisch. Dat loopt via Peppol of via Digipoort, in de formaten Peppol BIS 3.0 of SI-UBL 2.0 (de Nederlandse invulling NLCIUS). Beide voldoen aan de Europese norm EN 16931.
• Decentrale overheden — gemeenten, provincies, waterschappen — moeten sinds april 2019 e-facturen kunnen ontvangen. Zelf versturen hoeven ze niet, tenzij het contractueel is afgesproken.
• Tussen bedrijven onderling geldt in Nederland op dit moment geen wettelijke plicht. Je mag nog gewoon een pdf mailen, of een papieren factuur sturen.

Dat laatste is precies wat verandert, en het is verstandig om nu al te weten hoe. Niet omdat de Nederlandse deadline dichtbij is, maar omdat de praktische deadline die van je klanten is, en die ligt vaak eerder.

De data die vaststaan, en de data die dat niet doen

Hieronder alleen wat op dit moment te onderbouwen is. Waar iets nog een voornemen is en geen wet, staat dat er expliciet bij — dat onderscheid verdwijnt in veel artikelen over dit onderwerp, en het scheelt nogal of je een verplichting hebt of een verwachting.

Over dat Nederlandse traject, zonder mooier te maken dan het is: op 10 maart 2026 ging een evaluatierapport naar de Tweede Kamer met als advies om Peppol als verplichte infrastructuur aan te wijzen en de verplichting te laten gelden voor álle binnenlandse B2B-transacties, niet alleen grensoverschrijdende. Een definitief kabinetsstandpunt was aangekondigd voor de zomer van 2026, gevolgd door een internetconsultatie van conceptwetgeving in het vierde kwartaal. Op het moment van schrijven, eind augustus 2026, hebben wij geen gepubliceerd definitief standpunt kunnen vinden; ook de voortgangspagina van de rijksoverheid noemt er geen. Behandel de jaartallen 2030 tot 2032 dus als richting, niet als datum in je agenda. Wat wél vaststaat is 1 juli 2030 voor grensoverschrijdend verkeer, want dat staat in de richtlijn zelf.

Een pdf mailen is geen e-factuur

Dit is het misverstand dat de meeste tijd kost. "Wij factureren al digitaal, we mailen pdf's." Dat is digitaal, maar het is geen e-facturatie in de zin van de wetgeving.

Een pdf is in feite een plaatje van een factuur. Een mens leest hem prima; software moet hem scannen, herkennen en gokken welk getal het totaalbedrag is. Dat gaat meestal goed en af en toe mis, en het gaat vaker mis naarmate de opmaak van je leveranciers varieert.

Een e-factuur is een bestand met een vaste datastructuur, in de praktijk UBL (Universal Business Language), een vorm van XML. Elk gegeven staat op een vaste plek: factuurnummer, factuurdatum, leverancier met KvK- en btw-nummer, per regel de omschrijving, het aantal, het tarief en het btw-percentage, en het totaal. De ontvangende administratie hoeft niets te herkennen; hij leest de velden. Om te zorgen dat elk land dezelfde velden op dezelfde manier invult, bestaat de Europese norm EN 16931. De Nederlandse invulling daarvan heet NLCIUS.

Peppol is iets anders dan het formaat: het is het netwerk waarover die bestanden reizen. Het werkt als e-mail. Jij bent aangesloten bij een toegangspunt, je klant bij een ander toegangspunt, en die twee wisselen het bericht uit volgens vaste afspraken. Je hebt een Peppol-adres nodig, meestal gebaseerd op je KvK-nummer of btw-nummer, zodat de andere kant je kan vinden. Anders dan bij e-mail krijg je bevestiging terug of het bericht technisch is aangekomen en geaccepteerd.

Het praktische verschil zit in wat er daarna niet meer hoeft. Een binnenkomende e-factuur staat als concept-inkoopboeking in je administratie met de juiste btw-regels, in plaats van als bijlage in een mailbox die iemand moet openen. Dat is dezelfde winst die je met facturatie en administratie automatiseren nastreeft, alleen dan geregeld aan de bron in plaats van met slimme herkenning achteraf.

Wat je boekhoudpakket al kan

Voor de meeste bedrijven is dit het hele antwoord: je pakket kan het waarschijnlijk al, en het staat alleen uit. Onderstaande stand is die van de leveranciers zelf; wij hebben ze niet allemaal in elke abonnementsvorm getest, dus controleer in je eigen omgeving of zowel versturen als ontvangen aanstaat.

• Moneybird — versturen en ontvangen via Peppol, met automatische registratie van je Peppol-adres, en daarnaast losse UBL-bestanden versturen en inlezen. Wat je verder rond Moneybird kunt automatiseren staat op Moneybird koppelen.
• Exact Online — Peppol zit in het facturatiemenu; versturen en ontvangen gaat zonder het pakket te verlaten. Zie Exact Online koppelen.
• AFAS — is zelf een gecertificeerd Peppol-toegangspunt en ondersteunt zowel NLCIUS als Peppol BIS 3.0. Binnenkomende facturen worden direct in de administratie verwerkt. Zie AFAS koppelen.
• Simplicate — heeft een Peppol-integratie waarmee facturen rechtstreeks in de administratie van de klant belanden in plaats van als mailbijlage. Zie Simplicate koppelen.
• e-Boekhouden.nl — biedt Peppol-ondersteuning en publiceert zelf uitleg over de aankomende verplichting. Welke onderdelen in welk abonnement zitten wisselt; controleer dat in je eigen omgeving. Zie e-Boekhouden koppelen.

Zet je het aan, controleer dan drie dingen voordat je er vanuit gaat dat het werkt. Staan je KvK- en btw-nummer correct in je bedrijfsgegevens, want daar hangt je Peppol-adres aan. Staat het ontvangen ook aan, en niet alleen het versturen — de meeste bedrijven merken pas dat het uit stond als een leverancier belt waarom hij niets terughoort. En stuur één echte testfactuur naar een klant die al op Peppol zit, in plaats van te vertrouwen op de bevestiging in de instellingen.

Als je facturen uit een eigen systeem komen

Hier wordt het interessanter, en dit is de situatie die we in ons werk het vaakst tegenkomen: de facturen worden niet in het boekhoudpakket gemaakt maar in iets anders. Een eigen ordersysteem, een planningstool, een webshop, een branchepakket zonder Peppol-ondersteuning, of een ERP dat er nooit voor is ingericht. Het boekhoudpakket krijgt de factuur pas achteraf te zien, of ziet hem helemaal niet.

Dan heb je drie routes, in volgorde van oplopende kosten:

• Laat je bestaande pakket de verzending doen. Je eigen systeem maakt de factuur, een koppeling zet hem in Moneybird, Exact of AFAS, en dat pakket verstuurt hem via Peppol. Je hoeft dan zelf geen toegangspunt te regelen en geen UBL te valideren. In veruit de meeste gevallen is dit de goedkoopste en meest houdbare route.
• Rechtstreeks aansluiten op een Peppol-toegangspunt. Je koppelt je eigen systeem aan een dienstverlener die het netwerk voor je afhandelt. Nodig bij hoge volumes of als de tussenstap via een boekhoudpakket gegevens weggooit die je wél wilt meesturen, zoals ordernummers of projectcodes per regel.
• Zelf een toegangspunt worden. Vrijwel nooit de juiste keuze voor een mkb-bedrijf. Je neemt er certificering en beheer mee over voor iets dat als dienst wordt aangeboden.

Waar het bij eigen systemen misgaat is zelden het versturen. Het is de inkomende kant. Een e-factuur komt binnen als gestructureerde data, en dan moet iemand of iets bepalen bij welke inkooporder hij hoort, of het bedrag klopt met wat er is afgesproken, en op welke kostenplaats hij geboekt wordt. Dat matchen is het echte werk, en precies daar zit ook de winst: dezelfde velden die je anders overtypt, komen nu machineleesbaar binnen.

Bij dat soort koppelingen bouwen wij de verbinding met je administratie steeds vaker als MCP-server in plaats van als vaste flow. Het verschil: een vaste flow doet één ding — factuur binnen, boeking klaar — en stopt bij het eerste geval dat er niet in past. Een MCP-server stelt een afgebakende lijst handelingen beschikbaar (inkooporder opzoeken, leverancier matchen, boeking klaarzetten, afwijking melden), zodat een AI-agent de twijfelgevallen kan afhandelen die je vooraf niet kunt uitschrijven: een factuur zonder ordernummer, een levering die in twee delen is gefactureerd, een bedrag dat drie euro afwijkt door afrondingsverschil. De uitzonderingen zijn bij inkoopfacturen nu eenmaal de meerderheid van het handwerk. Wat zo'n server precies is, staat op wat is een MCP-server; welke Nederlandse pakketten onderling te koppelen zijn, staat in ons koppelingenoverzicht.

Waar het in de praktijk misgaat

• Alleen het versturen aanzetten. De helft van de winst zit aan de inkomende kant, en dat is ook de kant waar een toekomstige verplichting je als eerste raakt: je kunt niet weigeren wat een leverancier je stuurt.
• Denken dat de klant het merkt. Een correct verzonden e-factuur ziet je klant vaak helemaal niet als e-mail. Belt hij dat hij niets ontvangen heeft, controleer dan eerst zijn Peppol-registratie voordat je opnieuw een pdf stuurt en de administratie dubbel loopt.
• Een pdf én een e-factuur sturen. Begrijpelijke reflex, maar het levert dubbele boekingen op bij klanten die beide verwerken. Kies er één, en zet in de factuurmail waarom.
• Btw-nummers en KvK-nummers die niet kloppen. Bij een pdf leest een mens eroverheen; bij een e-factuur weigert de validatie het bericht. Reken erop dat je relatiebestand hier ooit op opgeschoond moet worden — dat is bijna altijd de echte kostenpost bij invoering.
• Wachten op de Nederlandse wet. Je Belgische en Duitse klanten hebben hun eigen deadlines, en die zijn er al of komen eerder.

Wat je nu zou doen

• Zoek uit waar je facturen echt vandaan komen. Uit het boekhoudpakket, of uit een systeem ervoor? Dat bepaalt of dit een instelling is of een koppeling.
• Zet in je pakket Peppol aan voor zowel versturen als ontvangen, en controleer je KvK- en btw-gegevens.
• Stuur één echte testfactuur naar een klant die al op Peppol zit, en vraag hem hoe hij binnenkwam.
• Kijk of je buitenlandse zakelijke klanten hebt in België of Duitsland. Zo ja, dan is dit geen project voor 2030 maar voor dit kwartaal.
• Schoon je relatiebestand op: btw-nummers, KvK-nummers en adresgegevens. Dit is het werk dat je toch moet doen en dat het langst duurt.
• Komen je facturen uit een eigen systeem, breng dan in kaart welke velden daar bestaan en welke EN 16931 verwacht. Dat gat is de scope van je koppeling.

Loop je vast op die laatste stap, of weet je niet zeker of je pakket de brug kan slaan naar je eigen systeem? Dat is het soort koppeling dat we vaker bouwen — bekijk de pakketten die we koppelen of plan een gesprek, dan lopen we het door voor jouw situatie.