PDF per e-mail versus e-facturatie: wat is nu echt het verschil?

Een pdf-factuur per e-mail is digitaal en binnen enkele seconden bij de klant. Toch is dat iets anders dan e-facturatie. Het verschil zit niet in de snelheid waarmee de factuur wordt bezorgd, maar in wat er daarna nog moet gebeuren.

Pdf-facturatie heeft papier voor een groot deel uit het factuurproces verdrongen. Geen printer, envelop of postkamer meer: het financiële systeem genereert een pdf en verstuurt die automatisch per e-mail.

Dat klinkt al behoorlijk geautomatiseerd.

Toch is een pdf geen e-factuur. Bij een pdf ontvangt de klant een document met gegevens. Bij een e-factuur ontvangt de klant gestructureerde gegevens die rechtstreeks door software kunnen worden verwerkt.¹

Het verschil lijkt technisch, maar werkt door in kosten, automatisering, veiligheid en uiteindelijk zelfs betalingstermijnen.

Digitaal bezorgen is nog geen automatische invoer

Om het verschil goed te begrijpen, helpt het om drie stappen uit elkaar te houden:

bezorgen → invoeren → verwerken

Een pdf kan volledig automatisch worden bezorgd. Een paar seconden later staat hij in de inbox van de klant.

Maar daarmee staat de factuur nog niet in het financiële systeem.

De relevante gegevens — leverancier, factuurnummer, datum, ordernummer, bedragen, btw en factuurregels — moeten eerst uit het document worden gehaald.

Dat kan handmatig, maar steeds vaker gebeurt het met OCR, Intelligent Document Processing of AI. Ook een pdf-proces kan dus sterk worden geautomatiseerd.

Toch blijft er een extra stap bestaan:

document → gegevens herkennen → gegevens invoeren

Bij een gestructureerde e-factuur zijn die gegevens al afzonderlijk gedefinieerd:

gegevens ontvangen → gegevens invoeren

Het systeem hoeft niet eerst te bepalen welk nummer op de pagina het factuurnummer is of welk bedrag het btw-bedrag vertegenwoordigt.

Ontvangen is niet hetzelfde als in het systeem staan

Dat verschil wordt zichtbaar in de doorlooptijd.

Een pdf en een e-factuur kunnen allebei binnen enkele seconden bij de klant aankomen. De vraag is vooral: wanneer kan de financiële administratie ermee aan de slag?

APQC meet bij 2.461 organisaties de tijd tussen ontvangst van een factuur en het moment waarop de gegevens in het AP-systeem zijn ingevoerd. De mediane doorlooptijd bedraagt 12 uur.²

Dat betekent niet dat een pdf gemiddeld twaalf uur ongeopend in een mailbox ligt. In die periode zitten ook verwerking en wachttijd en het onderzoek maakt geen onderscheid naar ontvangstkanaal.

Maar het toont wel aan dat ontvangst en administratieve beschikbaarheid twee verschillende momenten zijn.

Voor de crediteurenadministratie betekent die tussenliggende tijd extra doorlooptijd. Voor de leverancier betekent het dat een factuur technisch wel bezorgd kan zijn, terwijl het betaalproces bij de klant nog niet is begonnen.

De grootste kosten zitten aan de ontvangende kant

Hetzelfde patroon zien we terug in onderzoek naar proceskosten.

Een door de Europese Commissie gebruikte benchmark becijfert de kosten van een B2B-factuur als volgt:³

Het verschil aan de verzendzijde is beperkt. Dat is logisch: een pdf automatisch genereren en mailen is al goedkoop.

Aan de ontvangende kant is het verschil veel groter.

De precieze bedragen verschillen uiteraard per organisatie. Volumes, salariskosten, software en automatiseringsgraad hebben veel invloed. Maar ook oudere onderzoeken van de Zwitserse e-invoicingonderzoeker Bruno Koch laten hetzelfde patroon zien: handmatige pdf-verwerking is relatief duur, OCR verlaagt de kosten sterk en volledig elektronische verwerking verlaagt ze verder.⁴

De kern is daarom niet één specifiek bedrag.

Digitaal bezorgen is goedkoop. Een document invoeren en verwerken kost geld.

Ook pdf-verwerking kan sterk worden geautomatiseerd

Daarbij moeten we pdf zeker niet gelijkstellen aan handmatig werk.

Een AP-oplossing kan een factuurmail automatisch ophalen, de bijlage herkennen, gegevens met OCR of AI uitlezen en deze zonder menselijke invoer in het factuursysteem plaatsen.

Het verschil met e-facturatie zit dus niet simpelweg in handmatig versus automatisch.

Het verschil is dat documentherkenning eerst informatie uit een document moet interpreteren, terwijl die informatie bij een e-factuur al gestructureerd wordt aangeleverd.

Dat is een fundamenteel andere uitgangspositie.

Daarna kan ook de verwerking automatisch

Zodra de factuurgegevens in het systeem staan, begint de eigenlijke factuurverwerking.

Denk aan:

• validatie;
• factuurcodering;
• matching met de inkooporder;
• matching met goederenontvangst;
• goedkeuring;
• boeking.

Ook die stappen kunnen grotendeels automatisch verlopen.

Bij een orderfactuur kan het systeem bijvoorbeeld automatisch een two-way of three-way match uitvoeren. Kloppen factuur, bestelling en goederenontvangst binnen de ingestelde toleranties, dan kan de factuur zonder menselijke tussenkomst worden goedgekeurd en geboekt.

De ideale keten wordt dan:

ontvangen → invoeren → valideren → matchen → boeken

Alleen echte uitzonderingen komen nog bij een medewerker terecht.

Een verkeerde prijs verdwijnt door e-facturatie niet. Een ontbrekende goederenontvangst evenmin. Maar dat zijn inhoudelijke uitzonderingen.

Het doel is niet om iedere factuur sneller door een medewerker te laten controleren, maar om ervoor te zorgen dat een medewerker alleen nog nodig is wanneer er daadwerkelijk iets afwijkt.

OCR en AI lossen een ander probleem op

Daarmee wordt ook het verschil tussen documentherkenning en e-facturatie duidelijk.

OCR en AI kunnen steeds beter informatie uit een pdf halen, maar daarmee automatiseren ze de interpretatie van een document.

E-facturatie voorkomt dat die interpretatie nodig is.

De leverancier heeft de factuurgegevens immers al digitaal. Waarom zouden we die eerst omzetten naar een visueel document, versturen en bij de klant opnieuw uit dat document halen?

Dat maakt OCR en AI niet overbodig. Pdf-facturen en andere documenten zullen nog lange tijd blijven bestaan.

Maar waar gestructureerde gegevens kunnen worden uitgewisseld, is het logischer om de data zelf te versturen.

Ook het vertrouwensmodel is anders

Er is daarnaast een veiligheidsverschil.

E-mail is een algemeen communicatiekanaal. In principe kan iedereen proberen een factuur naar een openbaar factuuradres te sturen. Zakelijke e-mail kan technisch goed worden beveiligd, maar fraude via spoofing, gecompromitteerde mailboxen en gewijzigde betaalgegevens blijft een bekend risico.

Een netwerk als Peppol werkt anders.

Organisaties zijn als deelnemer geregistreerd, worden via participant identifiers geadresseerd en documenten lopen via geaccrediteerde Access Points. Beveiligd transport, certificaten en gestandaardiseerde protocollen zijn onderdeel van de infrastructuur.⁵

Dat maakt fraude niet onmogelijk. Ook een legitiem systeem kan worden gecompromitteerd.

Maar identiteit, adressering en transport worden wel sterker door het netwerk geborgd dan bij het versturen van een pdf naar een algemeen e-mailadres.

Bij facturen is dat relevant: de factuur vormt uiteindelijk de basis voor een betaling.

Voor debiteurenbeheer gaat het vooral om wat er bij de klant gebeurt

Aan de verzendende kant lijkt de businesscase voor e-facturatie misschien beperkt. Een pdf automatisch versturen kost immers al weinig. Maar voor Accounts Receivable is niet alleen van belang wanneer de factuur wordt verstuurd.

Belangrijker is: wanneer staat de factuur correct in het systeem van de klant?

Een pdf die om 09:00 uur wordt verstuurd, kan om 09:00:03 in een mailbox staan. Maar daarmee is hij nog niet noodzakelijk geregistreerd of klaar voor verwerking.

Een geïntegreerde e-factuur kan vrijwel direct als gestructureerde transactie in het financiële proces van de klant terechtkomen.

Het verschil is dus: niet sneller bezorgd, maar sneller in het systeem.

Dat kan ook de DSO beïnvloeden

Dat werkt door in de betaalcyclus.

Een factuur die nog niet in het systeem staat, kan niet worden gematcht. Een factuur die niet is gematcht, kan niet worden goedgekeurd. En een niet-goedgekeurde factuur wordt doorgaans niet betaald.

De keten is eenvoudig:

eerder in het systeem → eerder verwerkt → eerder goedgekeurd → eerder betaalbaar

Ook fouten worden eerder zichtbaar. Een ontbrekend ordernummer of ander probleem hoeft niet pas dagen later te worden ontdekt.

Onderzoek van Sage rapporteerde bij organisaties die e-facturatie gebruiken 20% minder incidenten met late betaling en gemiddeld vier dagen kortere betalingstijden.⁶

Dat betekent niet dat e-facturatie automatisch vier dagen van de DSO afhaalt. DSO wordt door veel meer factoren bepaald, waaronder overeengekomen betalingstermijnen, klantgedrag en omzetontwikkeling.

Maar door vertraging aan het begin van de keten weg te nemen, ontstaat wel neerwaartse druk op de DSO.

Daarmee is e-facturatie niet alleen een Accounts Payable-vraagstuk, maar ook relevant voor order to cash en werkkapitaal.

Van digitaal document naar digitale transactie

Pdf per e-mail was een grote verbetering ten opzichte van papier.

Maar het onderliggende model bleef grotendeels hetzelfde:

de leverancier heeft data → maakt er een document van → verstuurt het document → de klant maakt er opnieuw data van.

E-facturatie doorbreekt die cirkel:

de leverancier heeft data → verstuurt data → de klant verwerkt data.

Daarna kunnen validatie, codering, matching, goedkeuring en boeking verder worden geautomatiseerd. Aan de verkoopkant kan de factuur eerder in het systeem van de klant staan en ontstaat een kortere route naar betaling. Via een netwerk als Peppol worden bovendien identiteit, adressering en beveiligd transport onderdeel van dezelfde infrastructuur.

Daarmee is de stap van pdf naar e-facturatie veel groter dan een verandering van bestandsformaat.

Een pdf digitaliseert vooral de bezorging van een factuur. Een e-factuur digitaliseert de gegevensuitwisseling — en vormt daarmee de basis voor automatisering van verzending tot betaling.

Bronnen en voetnoten

1. Europese Commissie, What is eInvoicing? Definitie van een e-factuur als factuur in een gestructureerd dataformaat dat automatische elektronische verwerking mogelijk maakt. Bron bekijken. ↩
2. APQC, Cycle time in hours from receipt of invoice until data entered into the system. Benchmark onder 2.461 organisaties; mediaan 12 uur tussen ontvangst van de factuur en invoer in het AP-systeem. Bron bekijken. ↩
3. Europese Commissie, Evaluation of Directive 2014/55/EU on electronic invoicing in public procurement, 2024. Bevat onder meer de benchmark van €2,02 verzendkosten en €7,68 ontvangstkosten voor een B2B-factuur per e-mail, tegenover €1,20 en €2,27 voor een gestructureerde e-factuur. Bron bekijken. ↩
4. Bruno Koch / Billentis, Nutzenpotenziale der E-Rechnung, Wirtschaftskammer Österreich, 2011. Het model vergelijkt onder meer handmatige pdf-verwerking, halfgeautomatiseerde OCR-verwerking en geautomatiseerde elektronische verwerking. De historische kostencijfers zijn vooral bruikbaar om de procesverschillen te illustreren en niet als actuele kostprijsbenchmark. Rapport bekijken. ↩
5. OpenPeppol, Peppol Interoperability Framework en Peppol eDelivery-documentatie. Het netwerk werkt onder meer met geregistreerde deelnemers, Access Points, participant identifiers, certificaten en beveiligde communicatie. Peppol Interoperability Framework en Peppol AS4-specificatie. ↩
6. Sage, E-Invoicing: Paving the way to a Connected, Real-time Economy, 2024. Het onderzoek rapporteert bij gebruikers van e-facturatie 20% minder incidenten met late betaling en gemiddeld vier dagen kortere betalingstijden. Het betreft onderzoek van een softwareleverancier en moet daarom als indicatief worden gelezen. Rapport bekijken. ↩