Peppol factureren lijkt simpel. Totdat je de hele keten gaat testen.
Wat uitgebreide praktijktests ons leerden over e-factureren via Peppol
Eén druk op de knop?
Voor een ondernemer moet elektronisch factureren vooral eenvoudig zijn. Je maakt een factuur, controleert de gegevens en klikt op verzenden. Daarna verwacht je dat de factuur veilig en correct bij de administratie van je klant terechtkomt.
Achter die ene handeling gebeurt echter veel meer. De boekhoudkundige gegevens moeten kloppen, de elektronische factuur moet volgens de juiste standaard worden opgebouwd, de ontvanger moet via Peppol bereikbaar zijn én het aangeboden documenttype kunnen verwerken. Vervolgens wil je ook weten of het bericht daadwerkelijk is afgeleverd — of waarom het onderweg is geweigerd.
De afgelopen periode hebben we binnen Yoursminc daarom niet alleen de ‘happy flow’ getest. Juist de uitzonderingen kregen veel aandacht: creditfacturen, nulfacturen, orderreferenties, verschillende factuurstatussen, ontvangende partijen met specifieke mogelijkheden en situaties waarin een factuur bewust wordt afgewezen.
Want pas als ook die situaties goed worden afgehandeld, wordt e-factureren voor de gebruiker werkelijk eenvoudig.
Peppol factureren is meer dan een digitaal postvak
Peppol is een internationaal afsprakenstelsel voor het uitwisselen van elektronische berichten, waaronder facturen, orders en timecards. Organisaties sluiten via gecertificeerde serviceproviders aan op het netwerk. Het uitgangspunt is aantrekkelijk: één keer aansluiten en vervolgens elektronisch kunnen communiceren met andere aangesloten organisaties.
Maar bereikbaarheid alleen is niet voldoende. De betrokken systemen moeten dezelfde berichten kunnen begrijpen en verwerken. Daarvoor gebruikt Peppol onder meer de Peppol BIS-standaarden. Die bepalen veel preciezer dan een traditionele PDF welke gegevens in een elektronisch bericht staan en hoe die gegevens worden geïnterpreteerd.
Dat is precies de kracht van een echte e-factuur. Een PDF is in de eerste plaats een document dat een mens kan bekijken. Een gestructureerde e-factuur is bedoeld om rechtstreeks van systeem naar systeem te worden verwerkt. Daardoor kan veel handmatig overtypen verdwijnen, maar alleen wanneer de gegevens en afspraken aan beide kanten kloppen.
De rol van Logius en de Nederlandse Peppolautoriteit
In Nederland speelt de Nederlandse Peppolautoriteit (NPa) een belangrijke rol. Logius voert de werkzaamheden van de NPa uit. De NPa waarborgt namens het ministerie van Binnenlandse Zaken en Koninkrijksrelaties de kwaliteit en betrouwbaarheid van het Nederlandse Peppol-afsprakenstelsel en beheert de Nederlandse, landspecifieke eisen die aan Peppol BIS-berichttypen kunnen worden toegevoegd.
Voor softwareleveranciers betekent dit dat een Peppol-implementatie niet ophoudt bij het technisch kunnen verzenden van XML. Een betrouwbare implementatie moet rekening houden met het afsprakenstelsel, de berichtstandaarden, de eisen aan gegevens en de manier waarop ontvangende systemen daarop reageren.
De essentie: Peppol testen betekent niet alleen controleren of een bericht wordt verzonden, maar of de volledige keten — van boekhouding tot ontvanger en terugkoppeling — zich voorspelbaar gedraagt. |
Daarom hebben we de volledige keten getest
Bij onze tests hebben we zowel de verzendende als de ontvangende kant bekeken. In het facturenoverzicht van Yoursminc is bijvoorbeeld zichtbaar welke verkoopfacturen nog in behandeling zijn en welke door Peppol zijn afgeleverd. Dat maakt de technische status onderdeel van de dagelijkse boekhoudworkflow, in plaats van informatie die ergens in een apart technisch logbestand verborgen blijft.
Op het niveau van één factuur tonen we vervolgens de terugmelding van Peppol. In onderstaande test is de factuur afgeleverd en wordt naast de status ook het moment van aflevering vastgelegd. Voor de gebruiker is dat veel relevanter dan alleen de wetenschap dat er ooit een XML-bestand is aangemaakt.
De uitzonderingen zijn waar het interessant wordt
Een gewone verkoopfactuur die zonder problemen wordt afgeleverd is belangrijk, maar vertelt maar een deel van het verhaal. In de praktijk ontstaan juist vragen bij afwijkende situaties. Wat gebeurt er met een creditfactuur? Hoe behandelen we een factuur met een totaalbedrag van nul? Welke administratieve status is leidend bij het genereren van het elektronische document? En wat gebeurt er wanneer een ontvanger wel op Peppol staat, maar het betreffende documenttype niet ondersteunt?
Tijdens het testen kwamen precies dit soort scenario’s aan bod. Dat leidde ook tot aanpassingen in de logica. Een creditfactuur kan bijvoorbeeld een andere statusgeschiedenis hebben dan een reguliere factuur. Als de generatie van het elektronische document alleen naar één specifieke status kijkt, kan een boekhoudkundig correcte transactie toch verkeerd worden geïnterpreteerd. Zulke situaties ontdek je alleen door de volledige bedrijfsflow te testen en niet uitsluitend de technische koppeling.
Ook een weigering is een geslaagde test
Een goede e-facturatieketen moet niet alleen succesvolle berichten correct verwerken. Een afwijzing moet net zo goed gecontroleerd en begrijpelijk terugkomen. Bij de functionaliteitstests met de Nederlandse Peppolautoriteit zijn daarom ook inkomende testfacturen verwerkt die bewust tot verschillende resultaten leiden.
Wanneer een bericht wordt geweigerd, hoort daar een bruikbare reden bij. In Yoursminc blijft die informatie gekoppeld aan de uitgave. In onderstaande test is bijvoorbeeld zichtbaar dat de uitgave is geweigerd en wordt de toelichting op de afwijzing vastgelegd.
Een ontvanger op Peppol is niet automatisch genoeg
Een van de nuttigste lessen uit het testen is dat ‘de klant zit op Peppol’ niet hetzelfde betekent als ‘ieder elektronisch document kan naar deze klant worden gestuurd’. Binnen Peppol maakt een organisatie kenbaar welke berichttypen zij kan ontvangen. Daardoor kan een verzendpoging terecht worden afgewezen wanneer het aangeboden documenttype niet door de ontvanger wordt ondersteund.
Voor een gebruiker kan zo’n melding in eerste instantie technisch klinken. Voor ons is het daarom belangrijk dat de onderliggende foutinformatie niet verloren gaat. Een duidelijke terugmelding maakt het mogelijk om vast te stellen of de oorzaak in de factuur, de adressering, de ondersteuning bij de ontvanger of elders in de keten ligt.
Een orderreferentie is niet zomaar een extra veld
Een ander concreet voorbeeld uit onze tests is de Buyer Order Reference. Op het eerste gezicht lijkt dit misschien een extra referentieveld op een factuur. In geautomatiseerde verwerking kan zo’n referentie echter bepalend zijn voor de vraag of de ontvanger de factuur direct aan de juiste inkoopopdracht kan koppelen.
Dat belang zien we ook terug in de Handreiking Basisfactuur Rijk van Logius. Voor de Basisfactuur Rijk is een ordernummer of referentie verplicht. Logius wijst er bovendien op dat een onjuiste referentie tot een langere verwerkingstijd kan leiden. De handreiking is compliant met onder andere Peppol BIS.
Daarom hebben we deze referentie niet alleen aan de gebruikersinterface toegevoegd, maar ook meegenomen in de generatie van de elektronische factuur. Dat illustreert mooi waarom functionele en technische ontwikkeling bij e-factureren niet los van elkaar kunnen worden gezien.
Wat hebben we in de praktijk getest?
reguliere verkoopfacturen en succesvolle aflevering via Peppol;
creditfacturen en de bijbehorende statuslogica;
nulfacturen en afwijkende boekhoudkundige situaties;
order- en klantreferenties, waaronder de Buyer Order Reference;
verschillende factuur- en uitgavestatussen;
de mogelijkheden van Peppol-ontvangers en ondersteunde documenttypen;
inkomende berichten binnen de NPa-functionaliteitstest;
bewuste afwijzingen en het vastleggen van de reden daarvoor;
status-terugkoppeling, waaronder PENDING en DELIVERED;
de samenhang tussen de elektronische factuur en de verwerking in de boekhouding.
De techniek moet uiteindelijk uit beeld verdwijnen
Het klinkt misschien tegenstrijdig, maar juist door veel aandacht aan de techniek te besteden, willen we ervoor zorgen dat de gebruiker er zo weinig mogelijk van merkt. Een ondernemer hoeft niet te weten welk XML-element een orderreferentie bevat, welke Peppol BIS-regel wordt gevalideerd of welke statuscode een serviceprovider terugstuurt.
Wat de gebruiker wél moet kunnen zien, is of een factuur klaarstaat, wordt verwerkt, is afgeleverd of is geweigerd — en in dat laatste geval waarom. De boekhoudsoftware moet de technische keten vertalen naar informatie waarmee iemand daadwerkelijk verder kan.
Daarom testen we niet alleen of Yoursminc een elektronische factuur kan versturen. We testen of de hele keten zich gedraagt zoals een ondernemer mag verwachten: van de oorspronkelijke boeking en de inhoud van de factuur tot de aflevering via Peppol en de terugmelding in de administratie.
Pas dan wordt ‘Versturen’ weer zo eenvoudig als het eruitziet.
Meer weten?
Werk je met Yoursminc en wil je weten hoe Peppol binnen jouw administratie wordt gebruikt, of loop je tegen een melding aan bij het verzenden of ontvangen van een e-factuur? Neem dan contact op met Yoursminc Support. We kijken graag mee naar de factuur én naar de terugmelding uit de keten.
Bronvermelding
Logius – Peppol — https://www.logius.nl/onze-dienstverlening/gegevensuitwisseling/peppol
Logius – Wie doet wat voor Peppol? — https://www.logius.nl/onze-dienstverlening/gegevensuitwisseling/peppol/wie-doet-wat-voor
Logius – Handreiking Basisfactuur Rijk — https://www.logius.nl/onze-dienstverlening/gegevensuitwisseling/e-factureren/handreiking-basisfactuur-rijk
