Factuurformaten en conversie: formaten, profielen en omzetting

Overzicht van de ondersteunde formaten

faktoora ondersteunt een breed scala aan elektronische factuurformaten. Welk formaat het juiste is, hangt af van het soort ontvanger en de wettelijke of contractuele eisen.

ZUGFeRD: profielen en versies

faktoora maakt ZUGFeRD-facturen aan met het Extended-profiel, dat de meeste functionaliteit biedt. Er zijn twee versies:

• ZUGFeRD 1.0 (zf:1:extended): de oorspronkelijke versie op basis van de CII-standaard. Deze wordt nog steeds ondersteund.
• ZUGFeRD 2.1 (zf:2:extended): de huidige versie volgens EN 16931 en de aanbeveling voor nieuwe facturen.

Het Extended-profiel is het meest volledige profiel en voldoet aan de norm EN 16931. De melding "U kunt alleen als pdf en als XRechnung downloaden" betekent dat het gekozen profiel alleen deze twee formaten als download aanbiedt; dat is bij bepaalde configuraties en factuurtypen zo voorzien.

XRechnung en CII/UBL

De XRechnung is de Duitse standaard-e-factuur voor publieke opdrachtgevers. faktoora maakt deze automatisch aan in de telkens geldende versie. Welke versie op dit moment verplicht is, bepaalt de Koordinierungsstelle für IT-Standards (KoSIT, de Duitse coördinatiedienst voor IT-standaarden); het bindende overzicht staat op xeinkauf.de.

XRechnung is technisch gebaseerd op CII (Cross Industry Invoice), niet op UBL (Universal Business Language). CII is het XML-formaat dat Duitsland en Oostenrijk de voorkeur geven, terwijl UBL vooral in het Peppol-netwerk (Noord-Europa, Nederland) domineert.

De twee schema's verschillen in hun structuur:

• CII: strikte, hiërarchische structuur; wordt gebruikt door Duitsland, Oostenrijk en de EN 16931-specificatie voor XRechnung.
• UBL: modulairder opgebouwd, opener; standaard in het Peppol-netwerk.

ZUGFeRD gebruikt altijd CII; daarom wordt bij het aanmaken van een ZUGFeRD-factuur de schemaoptie op CII gezet (deze is niet te kiezen).

Peppol (UBL) voor internationale B2B-facturen

Peppol (Pan-European Public Procurement Online) is een Europees netwerk voor gestructureerde facturen. faktoora maakt Peppol-facturen aan als op UBL gebaseerde EN 16931-facturen en kan deze, als Peppol-levering is geactiveerd, automatisch via het Peppol-netwerk versturen. Dit is ideaal voor B2B-facturen aan Europese bedrijven die een Peppol-toegangspunt hebben.

Pdf en de conversie van formaten

Van pdf naar elektronisch formaat: wat kan wel en wat niet

Pdf-facturen kunnen niet automatisch worden omgezet naar een elektronisch formaat (XRechnung, ZUGFeRD enz.). Dit komt doordat:

1. Structurele informatie ontbreekt: een pdf bevat alleen een visuele weergave, geen gestructureerde gegevens.
2. OCR is niet betrouwbaar: faktoora gebruikt OCR voor het uitlezen van teksten uit gescande facturen (inkomende facturen), maar OCR kan geen 100% betrouwbare herkenning van velden garanderen. Daarom dient de herkenning als hulpmiddel, niet als volledige automatisering.
3. Gegevensverlies: complexe informatie zoals belastingcategorieën, kortingen op regelniveau of betalingsvoorwaarden kan niet automatisch uit een pdf worden gereconstrueerd.

Uitzondering: als de pdf een XRechnung- of ZUGFeRD-formaat is (dus een PDF/A-3 met ingesloten XML), kan faktoora de XML extraheren en naar andere formaten converteren.

Van Excel/CSV naar elektronisch formaat

faktoora biedt geen directe geautomatiseerde import van Excel of CSV voor het aanmaken van e-facturen via de webinterface. Via de API zijn er mogelijkheden om gestructureerde gegevens aan te leveren, maar daarvoor moet u de gegevens handmatig structureren of een integratiescript schrijven.

Alternatief: u kunt klantgegevens en producten via CSV importeren (zie Contacten importeren, Producten importeren) en daarna facturen handmatig of via de API aanmaken.

Van Word naar elektronisch formaat

Een Word-bestand (DOCX) kan niet automatisch worden omgezet naar XRechnung of een ander e-factuurformaat. Hiervoor gelden dezelfde beperkingen als voor pdf: het formaat bevat alleen visuele en vormelijke informatie, niet de gestructureerde gegevens die een e-factuurformaat nodig heeft.

Werkwijze: maak de factuur rechtstreeks in faktoora aan of voer de relevante gegevens (klant, regels, belastingen) handmatig in.

Buitenlandse facturen en fiscale nummers

Buitenlandse fiscale nummers en IBAN

faktoora ondersteunt facturen die niet van een Duits bedrijf afkomstig zijn. U kunt in uw profielinstellingen een buitenlands fiscaal nummer (bijv. een Oostenrijks UID-nummer of een Spaans NIF-nummer) en een buitenlandse IBAN invoeren; dit moet echter via een contactverzoek of door een beheerder worden geconfigureerd, omdat de webinterface vooraf is ingesteld op Duitse invoer.

Formaten voor het buitenland

• Internationaal: Peppol (UBL) is de standaard voor Europese B2B-e-facturen.
• Spanje: Verifactu-formaat voor overheidsinstanties en B2B.
• Frankrijk: Factur-X voor bedrijven; France-PA voor publieke opdrachtgevers (via een Plateforme Agréée, een erkend Frans facturatieplatform).
• Italië: FatturaPA voor overheidsinstanties en B2B-verzending via het SdI-netwerk.
• Polen: KSeF (FA(3)) voor overheidsinstanties en B2B.

Beperkingen bij elektronische facturen

Negatieve bedragen op regelniveau

Bij elektronische factuurformaten (XRechnung, ZUGFeRD, Peppol) kunnen geen negatieve bedragen op regelniveau worden ingevoerd. Dit is een eis van de norm EN 16931.

Reden: EN 16931 bepaalt dat correcties plaatsvinden via aparte creditnota's (factuurtypecode 381) of gecorrigeerde facturen (code 384), niet via negatieve regels in een gewone factuur.

Oplossing: maak in plaats daarvan een creditnota (factuurtype 381) of een gecorrigeerde factuur (384) aan als aparte factuur.

Leveringsdatum bij ZUGFeRD 2.x

De leveringsdatum (BT-72 in EN 16931) wordt bij ZUGFeRD 2.x in de XML-gegevens vastgelegd, maar is in de pdf-weergave standaard niet zichtbaar. U kunt deze in de factuurinterface activeren, zodat ze in de pdf-lay-out wordt weergegeven.

Prestatiedatum zonder eigen datum per regel

Voor afzonderlijke factuurregels (bijv. diensten zonder aparte leveringsdatum) kunt u daarnaast een leveringsdatum op productniveau instellen; dat is optioneel. Legt u voor de factuur geen eigen prestatiedatum of prestatieperiode vast, dan geldt automatisch: de prestatiedatum is gelijk aan de factuurdatum. Deze standaardwaarde wordt ook zo op de factuur vermeld en vereist geen extra invoer.

Validatie en foutafhandeling

Validatiefouten bij export/download

Als de export van een factuur als pdf of CSV mislukt met een validatiefout, zijn veelvoorkomende oorzaken:

• Fout in een BT-veld: een veld dat volgens EN 16931 verplicht is, is niet ingevuld of heeft een ongeldig formaat.
• Inconsistente belastinggegevens: negatieve belastingtarieven, niet-ondersteunde belastingcategorieën of ongeldige combinaties van categorieën.
• Veldformaat: een datum heeft niet het verwachte formaat, een telefoonnummer bevat ongeldige tekens enz.

Werkwijze: lees de foutmelding goed; deze noemt doorgaans het betreffende BT-veld of de validatieregel. Pas de gegevens aan en probeer het opnieuw.

Fouten bij het genereren van de pdf bij ZUGFeRD

Als een als pdf gedownloade ZUGFeRD-factuur mislukt of bij het openen niet wordt weergegeven, kunnen dit de oorzaken zijn:

• PDF/A-3-conformiteit: de pdf is niet PDF/A-3-conform, wat in sommige leesprogramma's tot problemen leidt. Probeer de pdf te openen met Acrobat Reader of een andere pdf-lezer.
• Probleem met de ingesloten XML: de ingesloten XML is beschadigd. Dit komt zelden voor en wordt door de validatie herkend.

Oplossing: gebruik de validatiefunctie (validate: true bij het aanmaken via de API) om fouten vóór het downloaden op te sporen.

Contactpersoon in ZUGFeRD-facturen

Als u een contactpersoon in de XML definieert (bijv. via de API), wordt deze niet automatisch in de pdf-lay-out weergegeven. De pdf toont doorgaans een standaardcontact of het bedrijf zelf. De contactpersoon is wel aanwezig in de gestructureerde gegevens (XML) en wordt meegenomen door systemen die de XML uitlezen.

Automatisch genereren van pdf's bij API-integraties

Als een factuur via een externe API-integratie wordt aangemaakt (bijv. door een worker of een batchproces), wordt de pdf-weergave mogelijk gegenereerd met een standaardlay-out in plaats van met uw eigen factuursjabloon. Dit is het geval als:

• De API-aanroep geen sjabloon-ID meegeeft.
• Het systeem terugvalt op een standaardsjabloon (bijv. bij door het systeem gegenereerde facturen).

Oplossing: zorg ervoor dat uw API-payload de juiste sjabloon-ID of configuratiereferenties bevat.

Veld BT-18: documentreferentie

Het veld BT-18 (verwijzing naar een zakelijk document) wordt in faktoora bijgehouden via het veld buyerReference of vergelijkbare contexten. In de API kunt u invoiceReferencedDocument.IssuerAssignedID gebruiken om een verwijzing naar een andere factuur in te stellen (bijv. bij correcties). Hoe BT-18 precies wordt toegewezen, hangt af van het factuurtype en de context.

Testmogelijkheden

Om ZUGFeRD-facturen te testen, kunt u:

1. Een factuur in de webinterface aanmaken, deze als concept opslaan en vervolgens aan een klant laten zien.
2. De factuur met de gegevens van de klant aanmaken in het testaccount van de klant (met diens API-sleutel).
3. Een testfactuur via de API aanmaken met draftOnly: true.

Met al deze opties kunt u een werkend voorbeeld laten zien zonder de factuur daadwerkelijk te versturen.

ZUGFeRD en XRechnung combineren

Een factuur die als ZUGFeRD 2.1 (Extended) is aangemaakt, kan niet automatisch als XRechnung worden gedownload. Dat komt doordat ZUGFeRD 2.1 met het CII-schema wordt opgebouwd (pdf + CII-XML), terwijl de XRechnung weliswaar ook CII gebruikt, maar eigen validatieregels en een ander uitvoerformaat heeft.

Juiste werkwijze:

• Voor private opdrachtgevers: ZUGFeRD 2.1 (Extended) aanmaken.
• Voor publieke opdrachtgevers: XRechnung expliciet selecteren.
• ZUGFeRD met het profiel zf:2:xrechnung biedt een hybride profiel tussen ZUGFeRD en XRechnung, maar maakt geen vrije keuze achteraf mogelijk.

Wilt u een echte XRechnung aanmaken, kies dan bij het aanmaken formaat: xrechnung. Wilt u een ZUGFeRD-hybride die compatibel is met XRechnung, gebruik dan zf:2:xrechnung. Achteraf converteren tussen beide is niet mogelijk: het formaat wordt bij het aanmaken vastgelegd.