Peppol koppelen aan je eigen systeem: hoe het werkt

Je koppelt je eigen systeem aan Peppol niet rechtstreeks, maar via een gecertificeerde dienstverlener die als toegangspunt fungeert. Jouw systeem levert de factuurgegevens aan in een gestructureerd formaat, het toegangspunt zet dat om naar de Peppol-standaard en bezorgt het bij je klant. In de praktijk is dat een koppeling van een paar dagen werk, niet van maanden.

In het kort

• Je sluit niet rechtstreeks aan op Peppol maar via een toegangspunt dat je bericht controleert en bezorgt.
• De echte vraag is administratief: staan het btw-tarief per regel, de klantreferentie en het Peppol-adres van je klant al in je systeem.
• Drie routes: via je boekhoudpakket, rechtstreeks naar een toegangspunt, of zelf de XML opbouwen. Dat laatste raad ik meestal af.
• Vergeet de inkomende kant niet, want daar zit vaak de meeste tijdwinst.

Dit artikel gaat over de situatie die zelden beschreven wordt: je hebt een eigen offerte-, uren- of ordersysteem, en je wilt daar e-facturen uit krijgen. Alle uitleg die je online vindt komt van boekhoudpakketten die uitleggen hoe het in hun eigen product werkt. Dat helpt je niet als jouw facturen ergens anders ontstaan.

Hoe het netwerk in elkaar zit

Peppol werkt als een postnetwerk. Er zijn geen directe verbindingen tussen bedrijven, maar wel vaste adressen en een vast formaat. Iedereen levert af bij een toegangspunt, en dat toegangspunt regelt de bezorging bij het toegangspunt van de ontvanger.

Drie dingen zijn daarbij van belang.

Elke deelnemer heeft een uniek adres, meestal gebaseerd op het KvK-nummer of het btw-nummer. Dat adres staat in een centraal register, zodat een verzender kan opzoeken of jouw bedrijf bereikbaar is en welk soort documenten je aankunt.

Het bericht zelf heeft een vast formaat. Voor facturen is dat een XML-bestand volgens de Europese norm. Daarin staan velden voor de leverancier, de afnemer, de regels, de btw-tarieven en de betaalgegevens. Elk veld heeft een vaste plek en een vaste betekenis.

Het toegangspunt controleert of jouw bericht klopt voordat het verstuurd wordt. Ontbreekt er een verplicht veld of klopt een btw-berekening niet, dan krijg je het terug. Dat is streng, maar het is precies de reden dat de ontvangende kant het blind kan inlezen.

Wat dat betekent voor jouw eigen systeem

De belangrijkste vraag is niet technisch maar administratief: staan de gegevens die op een e-factuur moeten staan al gestructureerd in je systeem?

Loop dat lijstje eens langs. Je eigen bedrijfsgegevens en btw-nummer. De gegevens van je klant, inclusief hun Peppol-adres of de gegevens waarmee dat op te zoeken is. Per factuurregel een omschrijving, een aantal, een eenheidsprijs en een btw-tarief. Een factuurnummer, een factuurdatum en een vervaldatum. Vaak ook een ordernummer of een referentie die je klant meegeeft.

In veel eigen systemen staat het grootste deel hiervan er al. Wat er meestal ontbreekt is het btw-tarief per regel, omdat er in de praktijk gewoon één tarief voor de hele factuur wordt aangehouden, en de klantreferentie, omdat die nu in een mailtje of in het onderwerpveld staat. Dat zijn kleine aanpassingen, maar je moet ze wel doen voordat een koppeling zin heeft.

Drie manieren om het te bouwen

• Via je boekhoudpakket. Als je facturen uiteindelijk toch in je boekhoudpakket belanden, is dit meestal de goedkoopste weg. Je eigen systeem stuurt de factuurgegevens naar het boekhoudpakket via de API, en dat pakket regelt de Peppol-verzending. Je bouwt dan één koppeling in plaats van twee, en je hoeft zelf niets te weten van de Peppol-standaard. Nadeel: je bent afhankelijk van wat dat pakket ondersteunt.

• Rechtstreeks naar een toegangspunt. De meeste toegangspunten bieden een API waar je een factuur naartoe stuurt. Sommige accepteren je gegevens in een eenvoudiger formaat en doen de omzetting naar de Europese norm voor je. Dit is de nettere oplossing als je facturen niet via een boekhoudpakket lopen, of als je grote aantallen hebt.

• Zelf de XML opbouwen. Kan, maar ik zou het meestal afraden. De standaard is uitgebreid, de validatieregels zijn streng en ze veranderen af en toe. Je bouwt dan iets dat je moet onderhouden zonder dat het je iets extra's oplevert. Alleen zinnig bij heel specifieke eisen.

De inkomende kant vergeten mensen

Peppol is tweerichtingsverkeer. Zodra je een adres in het register hebt, kunnen leveranciers jou ook e-facturen sturen. Dat is vaak waar de meeste tijdwinst zit.

Een inkomende e-factuur bevat alle gegevens gestructureerd. Je kunt dus automatisch controleren of er een inkoopopdracht tegenover staat, of de prijzen kloppen met wat er is afgesproken, en of de factuur al eerder is binnengekomen. Dat scheelt niet alleen typewerk maar ook fouten die je anders pas bij de jaarafsluiting ontdekt.

Als je een eigen systeem hebt waarin je inkoop of projecten bijhoudt, is een inkomende e-factuur die zichzelf aan het juiste project koppelt een van de meest concrete verbeteringen die je kunt doorvoeren.

Waar het in de praktijk misgaat

Een paar dingen kom ik vaker tegen.

Het Peppol-adres van de klant ontbreekt of klopt niet. Dat moet je opzoeken in het register, en je moet het ergens vastleggen bij de klantgegevens. Doe je dat niet, dan valt elke factuur handmatig terug in de mail.

De factuurregels zijn te vrij opgebouwd. Als iemand in je systeem een regel kan typen zonder aantal of zonder tarief, komt die factuur niet door de validatie. Je moet dan bij de invoer al afdwingen wat er straks nodig is.

Creditfacturen en correcties zijn vergeten. Die hebben hun eigen documenttype en hun eigen verwijzing naar de oorspronkelijke factuur. Bouw je dat niet mee, dan doe je correcties alsnog met de hand.

Er is geen terugkoppeling ingebouwd. Een factuur kan worden afgekeurd door het toegangspunt of geweigerd door de ontvanger. Als niemand die meldingen ziet, denk je dat je verstuurd hebt terwijl er niets is aangekomen.

Wat ik hier in de praktijk mee doe

Bij bedrijven met een eigen offerte- of urensysteem is dit meestal een afgebakend project. Ik kijk eerst welke velden er al zijn en welke er ontbreken, ik pas de invoer aan zodat de ontbrekende gegevens vanzelf worden vastgelegd, en dan bouw ik de koppeling naar het toegangspunt of naar het boekhoudpakket.

Het mooie eraan is dat je het los kunt doen, zonder dat er iets anders op de schop hoeft. Wat je erna overhoudt is een systeem waarin een factuur ontstaat uit gegevens die er toch al stonden.

Wil je weten wat er in jouw geval nodig is? Plan een vrijblijvend gesprek, dan lopen we samen door je huidige factuurstroom.