E-facturatiesoftware voor Europa: wat u controleert voordat u kiest

E-facturatiesoftware voor een Europese onderneming moet zeven dingen goed doen: het juiste gestructureerde formaat voor elk land genereren, het valideren voordat de factuur wordt uitgereikt, het over het kanaal vervoeren dat dat land gebruikt, inkomende gestructureerde facturen lezen, het gestructureerde origineel bewaren gedurende de bewaartermijn, de btw-behandeling afleiden uit de feiten van de transactie, en dat alles via een API voor andere systemen beschikbaar maken. Geen enkel product doet alle zeven in elk land zonder beperkingen; de nuttige vraag is welke beperkingen, en of de leverancier ze benoemt.

Formaatgeneratie: één factuur, vier nationale dialecten

De software moet precies het formaat produceren dat elke verplichting verwacht — XRechnung of ZUGFeRD voor Duitsland, Factur-X voor Frankrijk, Peppol BIS Billing 3.0 voor België, FA(3) voor Polen — op basis van dezelfde factuurgegevens, zonder dat de gebruiker XML bewerkt.

Drie van de vier zijn profielen van EN 16931, de Europese semantische norm waarvan de Commissie de delen 1 en 2 gratis beschikbaar stelt via de nationale normalisatie-instituten; de vierde, het Poolse FA(3), is een eigen nationaal schema. "Ondersteunt EN 16931" is dus noodzakelijk, maar niet voldoende. Vraag specifiek:

• Welke syntaxen voor Duitsland — XRechnung in UBL, in CII, of beide? ZUGFeRD in welke profielen (de FAQ van het BMF sluit MINIMUM en BASIC-WL uit van de definitie van e-factuur)?
• Bedt de Franse uitvoer de CII-XML in een PDF/A-3 in (Factur-X), zodat hetzelfde bestand mensen en machines bedient?
• Is de Belgische uitvoer de Peppol BIS Billing 3.0 UBL die het netwerk valideert, of een generieke UBL die een ontvangend toegangspunt kan weigeren?
• Welke FA-versie voor Polen — FA(3) is het huidige schema — en kan de software ook de visualisatie met het KSeF-nummer en de QR-code weergeven die het ministerie vereist wanneer een factuur buiten het systeem wordt gebruikt?
• Wordt het formaat automatisch gekozen op basis van het land van de uitreikende onderneming, of moet de gebruiker kiezen?

De formatengids koppelt elk formaat aan zijn land en verplichting.

Validatie vóór de uitreiking, niet na een weigering

Een gestructureerde factuur die niet voldoet aan de nationale bedrijfsregels is geen e-factuur onder die verplichting; de software moet die regels uitvoeren voordat het nummer wordt toegekend, en niet pas van een mislukking vernemen via een geweigerde verzending.

Validatie heeft lagen: XML-schema, Schematronregels van EN 16931, nationale CIUS-regels (die van KoSIT voor XRechnung, de Peppol BIS-regels voor België, het FA(3)-schema voor Polen), en kruiscontroles zoals de rekenkunde van totalen en btw-uitsplitsing. Vraag welke lagen worden uitgevoerd, of de regelsets de huidige versies zijn (de editie 2026 van de norm zet een migratie in gang, en KoSIT en OpenPeppol publiceren releases volgens hun eigen kalender), en of een mislukte validatie de uitreiking blokkeert of alleen waarschuwt. Een gratis onlinechecker die een bestand toetst aan de regels van een land is een faire manier om de beweringen van een leverancier te testen — zie de e-factuurchecker.

Transport: het onderdeel dat het meest per land verschilt

Duitsland schrijft geen kanaal voor, België schrijft Peppol voor, Frankrijk schrijft geregistreerde platformen voor, Polen schrijft zijn staatssysteem voor; software die alle vier de landen dekt, integreert elk kanaal of benoemt welk kanaal ze aan een aanbieder overlaat.

Wees precies met de woorden. "Peppol-ready" kan een geaccrediteerd toegangspunt betekenen, een verbinding via een toegangspunt, of alleen maar de mogelijkheid om een BIS-bestand te exporteren. "KSeF-ready" kan productiegebruik betekenen of een module die alleen tegen de sandbox is getest. De leverancier moet zeggen welke; de netwerkvergelijking legt uit waarom het onderscheid ertoe doet.

Ontvangen: inkomende XML omzetten in inkoopfacturen

Elke verplichting begint met ontvangen, dus de software moet XRechnung-, ZUGFeRD/Factur-X- en UBL-bestanden — uit e-mail, upload of een netwerk — in een inkooprecord kunnen inlezen zonder overtypen.

Vraag wat er gebeurt met een hybride pdf: wordt de ingebedde XML uitgepakt en gebruikt, of wordt de pdf als een afbeelding behandeld? Vraag of leverancier, bedragen, btw-uitsplitsing, vervaldatum en betalingsreferentie in de inkoopfactuur worden overgenomen, en of een bestand dat de validatie niet doorstaat, wordt geweigerd of gemarkeerd. Vraag hoe inkomende Peppol-documenten de inbox bereiken zodra de identificator van de onderneming is geregistreerd. Voor Duitsland, zie e-facturen ontvangen.

Archivering: het gestructureerde bestand is het origineel

Waar de factuur een gestructureerd bestand is, is dat bestand — niet een pdf-weergave ervan — wat gedurende de nationale bewaartermijn ongewijzigd en opvraagbaar moet worden bewaard.

De Belgische overheid merkt op dat "de regels inzake archivering ongewijzigd blijven" door de verplichting, en dat geldt overal: bewaartermijnen en integriteitsvereisten zijn nationaal en dateren van vóór de e-facturatie. Wat verandert, is het object. Vraag of de software de uitgereikte XML (en de ontvangen XML) opslaat zoals verzonden, of ze het archief in bulk kan exporteren, en of een factuur opvraagbaar blijft na het einde van een abonnement. Bewaartermijnen en eventuele nationale vereisten inzake onveranderlijkheid of audittrails vereisen professionele bevestiging.

Btw-oordelen: afgeleid uit feiten, niet ingetypt

De btw-regel op een factuur volgt uit het land van de verkoper, het land van de koper, de hoedanigheid van de koper als onderneming en de aard van de prestatie; software moet ze uit die feiten afleiden en weigeren te gokken waar de feiten ontoereikend zijn.

Dat is in Europa belangrijker dan waar ook, omdat de gestructureerde formaten de btw-categoriecodes en vrijstellingsredenen expliciet vermelden en validators ze toetsen aan de bedragen. Vraag of de software onderscheid maakt tussen normaal tarief, nultarief, vrijgesteld, verlegging en buiten toepassingsgebied, of ze het btw-nummer van de koper bij de uitreiking in VIES controleert, of ze de beslissing bij de factuur opslaat voor latere controle, en — belangrijk — of ze een eerlijke toestand "invoer vereist" kent in plaats van een standaardtarief. Zie grensoverschrijdende e-facturatie voor de regels achter de oordelen en de gratis btw-nummerchecker.

API: de factuur ontstaat meestal ergens anders

Voor een SaaS, een marktplaats of een ERP-gestuurde onderneming ontstaat de factuur in een ander systeem; de e-facturatiesoftware heeft een gedocumenteerde API nodig met authenticatie, idempotent aanmaken, webhooks en een testmodus.

Vraag of de API concepten aanmaakt die vervolgens onder de validatie van het product worden uitgereikt, of rechtstreeks juridische facturen uitreikt (wat de bovenstaande controles omzeilt); of sleutels kunnen worden beperkt tot één onderneming en tot lezen of schrijven; of POST-verzoeken een idempotentiesleutel aanvaarden zodat een herhaalde aanroep geen twee facturen kan aanmaken; welke events via webhook worden gepusht en hoe ze worden ondertekend; en wat de rate limit is. Ontwikkelaars willen de referentie lezen voordat ze kopen — zie de e-facturatie-API en de API-referentie.

De checklist

Twaalf vragen die dekking van beweringen scheiden; een leverancier die elke vraag beantwoordt met een duidelijk ja, nee of "via aanbieder X" vertelt u wat u moet weten.

1. Welke nationale formaten worden automatisch gegenereerd op basis van het land van de onderneming, en in welke syntaxen en profielen?
2. Welke validatieregelsets worden vóór de uitreiking uitgevoerd, en welke versies?
3. Blokkeert een mislukte validatie de uitreiking?
4. Voor België: welk geaccrediteerd toegangspunt draagt het verkeer, en is de leverancier er zelf een?
5. Voor Frankrijk: is de leverancier een plateforme agréée, of via welke PA verzendt hij, en is die live?
6. Voor Polen: is de KSeF-integratie in productie gebruikt?
7. Worden inkomende XRechnung-, ZUGFeRD/Factur-X- en UBL-bestanden met de ingebedde XML in inkoopfacturen ingelezen?
8. Wordt het gestructureerde origineel opgeslagen zoals uitgereikt en is het in bulk exporteerbaar?
9. Wordt de btw-behandeling afgeleid uit de feiten van de transactie, met een VIES-controle en een opgeslagen oordeel?
10. Maakt de API concepten aan onder validatie, met beperkte sleutels, idempotentie en ondertekende webhooks?
11. Is er een testmodus die zich als productie gedraagt?
12. Welke van de bovenstaande punten beschrijft de leverancier als beperkingen, en zijn de beperkingen gedateerd?

Hoe KRONENWERK hiermee omgaat

KRONENWERK dekt formaten, validatie, ontvangst, btw-oordelen en de API volledig; bij het transport zitten de beperkingen, en die worden hieronder benoemd.

KRONENWERK dient geen enkele belasting in en draagt er geen af, geeft geen belasting- of juridisch advies en heeft geen beveiligingscertificering; het geeft geen garantie over nalevingsresultaten. Naast e-facturatie is het een boekhoudproduct — dubbel boekhouden, inkoopfacturen en uitgaven, bankkoppelingen via Enable Banking en Plaid, meerdere ondernemingen en meerdere valuta's, vijf interfacetalen. Zie e-facturatie in KRONENWERK, facturatie, plannen en, voor ontwikkelaars, het ontwikkelaarsoverzicht. Terug naar de Europa-hub.