XRechnung, ZUGFeRD og BIS Billing 3.0: hvilke e-fakturaformater din software bør understøtte

EN 16931 beskriver en semantisk datamodel. Den fastlægger, hvilke oplysninger en faktura indeholder, og hvordan de hænger sammen, f.eks. fakturanummeret som BT-1 eller køberreferencen som BT-10. Standarden er ikke i sig selv et filformat.

Til den tekniske gengivelse tillader den to syntakser: UBL og UN/CEFACT CII. Begge gengiver den samme semantiske model, men adskiller sig i elementnavne og opbygning. Software, der kun indlæser UBL, kan ikke automatisk behandle en CII-faktura, selv om den overholder standarden.

For implementeringen er det afgørende for vedligeholdelsesindsatsen. To parallelle mappings betyder, at hver regelændring skal følges op to steder. Den, der i stedet mapper én gang til standardens semantiske model og genererer begge syntakser derfra, skal kun ændre ét sted pr. ændring.

Ved modtagelse mappes den indgående fil omvendt først til den semantiske model og overføres derfra til din datamodel.

Oven på standarden ligger de nationale og netværksspecifikke udformninger, i standarden kaldet Core Invoice Usage Specification, forkortet CIUS. En CIUS indsnævrer standarden. Den gør valgfrie felter obligatoriske, udelukker andre og medbringer egne Schematron-regler. Udformninger, der går ud over standardens omfang, kaldes extensions.

Uafhængigt af syntaks og udformning foreligger en e-faktura enten som en ren XML-fil eller som en PDF/A-3 med indlejret XML-fil. For det andet tilfælde er betegnelsen hybridt format blevet almindelig.

XRechnung er en CIUS af EN 16931 og vedligeholdes af det tyske koordineringskontor for IT-standarder (Koordinierungsstelle für IT-Standards), forkortet KoSIT. Den findes i begge syntakser. Den har ingen visuel komponent; filen er ren XML.

XRechnung er påkrævet for fakturaer til den tyske føderale forvaltning. Fakturaen adresseres via Leitweg-ID, som angives i datasættet som køberreference.

Indsendelsesvejen afhænger af modtageren. Mulighederne er portalerne ZRE og OZG-RE eller et Peppol access point. I B2B spiller Leitweg-ID ingen rolle. Her er XRechnung kun én af flere tilladte profiler.

I øjeblikket gælder version 3.0.2. Til XRechnung 4.0, implementeringen af EN 16931 i 2026-udgaven, findes der allerede en forhåndsversion. Den endelige version af XRechnung 4.0 forventes offentliggjort i foråret 2027.

ZUGFeRD pakker en XML-fil efter CII ind i en PDF/A-3. Mennesket ser PDF-filen, mens softwaren læser XML-filen.

Specifikationen har flere profiler med forskelligt dataomfang, fra MINIMUM til EXTENDED.

MINIMUM og BASIC WL indeholder ikke en fuldstændig faktura og opfylder ikke standarden. Fra profilen EN 16931, i ældre udgaver kaldet COMFORT, er den strukturerede del standardkonform. Din software bør læse profilen ved import og behandle filer med MINIMUM eller BASIC WL særskilt, f.eks. via en manuel kontrol.

Factur-X er teknisk stort set identisk med ZUGFeRD.

ZUGFeRD giver især mening, hvor dine kunder fakturerer til modtagere, der fortsat kontrollerer fakturaer visuelt. Her er det kun den indlejrede XML, der er juridisk afgørende. Afviger PDF og XML fra hinanden, har dataene i den strukturerede del forrang ifølge det tyske finansministeriums skrivelse af 15. oktober 2025 (BMF-Schreiben).

En godkendelsesproces, der kun kontrollerer PDF-filen, kan derfor godkende en faktura, hvis afgørende indhold lyder anderledes.

Ved afsendelse bør din software generere PDF og XML fra det samme datasæt, så de to ikke kommer ud af trit. Ved modtagelse bør den til kontrollen opbygge sin egen visning ud fra XML-filen i stedet for at vise den medsendte PDF. Det tyske finansministerium anbefaler ligeledes selv at visualisere XML-delen.

Peppol BIS Billing 3.0 er ligeledes en CIUS af EN 16931, fastlagt på UBL 2.1. OpenPeppol har specificeret det som et selvstændigt format til udveksling af fakturaer og kreditnotaer via netværket.

Ud over standardens regler medbringer det egne Schematron-regler. En fil kan bestå kontrollen mod EN 16931 og fejle på en Peppol-regel. Ofte drejer det sig om kodelister eller felter, som netværket definerer snævrere end standarden.

Specifikationen videreudvikles i versioner. Den, der selv validerer, bør kontrollere, om regelsættene svarer til den aktuelle status.

På længere sigt bevæger Peppol sig i retning af PINT, et internationalt afstemt grundlag for fakturaprofiler uden for Europa. For implementeringen i Tyskland ændrer det foreløbig intet.

Til disse fakturaer skal din software kunne generere XRechnung. Modtagerens Leitweg-ID hører hjemme som obligatorisk felt i fakturadatasættet og angives i XRechnung som køberreference (BT-10). Mangler det, eller står det i det forkerte felt, afviser modtagerportalen fakturaen.

Loven kræver en faktura efter EN 16931 og lader formatet være åbent. XRechnung, ZUGFeRD fra profilen EN 16931 og også Peppol BIS Billing er tilladt. Den indlejrede XML er fortsat juridisk afgørende. Afviger PDF og XML fra hinanden, kontrollerer modtageren muligvis andre oplysninger end dem, der gælder juridisk.

Indenlandske virksomheder skal siden 1. januar 2025 kunne modtage e-fakturaer efter EN 16931. For en standardkonform e-faktura behøver afsenderen derfor ikke modtagerens samtykke, selv om denne foretrækker et bestemt format.

De to parter skal kun aftale overførselsvejen og formater uden for standarden. I praksis hører den aftalte vej derfor hjemme i stamdataene for den enkelte forretningspartner.

Ud over Peppol BIS Billing 3.0 kan der via Peppol-netværket også overføres XRechnung og siden marts 2025 ZUGFeRD som hybrid fil. De dokumenttyper, som en modtager har registreret i registertjenesten, viser, hvilke formater den accepterer. Før afsendelse skal din software slå denne registrering op og vælge det passende format. Til enkeltkontroller viser Peppol-ID-opslaget det uden login.

I den løbende drift bør din software foretage dette opslag automatisk før afsendelse, enten direkte via registertjenesterne SML og SMP eller via API’en fra dit Peppol access point. På det grundlag fastslås et format, som begge parter understøtter, og e-fakturaen genereres derefter i dette format.

Indgående fakturaer ankommer i det format, afsenderen har valgt. Din software bør derfor kunne læse begge syntakser, UBL og CII, og dermed også XRechnung i begge varianter. Dertil kommer ZUGFeRD og Factur-X som hybride filer og, så snart dine kunder modtager fakturaer fra udlandet, de profiler, der er almindelige dér.

Hver indgående fil indeholder et ID for, hvilken udformning den bruger. I UBL står det i elementet cbc:CustomizationID, i CII i retningslinjens kontekstparameter. Din software bør læse dette ID først, for det afgør, hvilke valideringsregler der gælder, og hvordan filen overføres til din datamodel.

Nogle Peppol access points tager dette trin fra dig. De kontrollerer den indgående fil, udlæser fakturadataene og overdrager dem sammen med den originale fil som et ensartet datasæt.

Din software bør dække modtagelsen fuldt ud før afsendelsen, altså begge syntakser og de hybride formater, for dine kunder skal allerede i dag kunne modtage e-fakturaer.

Afsendelsen bliver obligatorisk for dine kunder i to trin. Fra 1. januar 2027 ved en samlet omsætning på over 800.000 euro i det foregående år og fra 1. januar 2028 for al øvrig indenlandsk B2B-omsætning.

Den, der begynder med syntaksen CII, kan dermed generere XRechnung i CII-varianten og ZUGFeRD. UBL bliver nødvendig, så snart modtagere i Peppol-netværket forventer Peppol BIS Billing 3.0, for dette format forudsætter UBL.

Alle momsretlige obligatoriske oplysninger skal stå maskinlæsbart i den strukturerede del af e-fakturaen. Det gælder også ydelsesbeskrivelsen. En henvisning til et bilag, en følgeseddel eller et link erstatter ikke et obligatorisk felt. Grundlaget er det tyske finansministeriums FAQ om e-fakturering og det tyske finansministeriums skrivelse af 15. oktober 2025 (BMF-Schreiben).

Årsagen ligger i e-fakturaens opbygning. Ved hybride formater som ZUGFeRD er dataene i XML-filen styrende, og PDF-filen er kun en visning. En oplysning, der kun er synlig i PDF-filen, tæller derfor ikke.

Mangler en obligatorisk oplysning i den strukturerede del, anses fakturaen for ikke at være korrekt, og modtagerens momsfradrag kan være i fare. Dine kunder opdager det senest, når forretningspartnere afviser fakturaer af den grund.

Mange fakturaskabeloner overfører obligatoriske oplysninger som tekstblokke, der kun vises i PDF-filen. Ofte gælder det ydelsesbeskrivelsen, f.eks. “i henhold til tilbud 2026-114”, leveringsperioden i fakturaens sidefod og henvisningen til omvendt betalingspligt.

I datamodellen bør hver af disse oplysninger have sit eget felt, som XML-filen udfyldes fra. Leveringsperioden hører hjemme i felterne for faktureringsperioden (BG-14), henvisningen til omvendt betalingspligt i momskategorien med fritagelsesgrund (BT-120 og BT-121).

Den tekniske validering kontrollerer, om standardens obligatoriske felter findes og er formelt korrekt udfyldt. Den kan ikke se, om en ydelsesbeskrivelse er momsretligt tilstrækkelig. En faktura kan altså bestå kontrollen og alligevel kun indeholde en obligatorisk oplysning i utilstrækkelig form.

Følgesedler, timeopgørelser og andre dokumenter, der ledsager fakturaen, kan indlejres som bilag i e-fakturaen, i EN 16931 via gruppen for supplerende dokumenter (BG-24). Det erstatter separat afsendelse og samler faktura og dokumentation i én fil.

En XRechnung kontrolleres mod to regelsæt, reglerne i EN 16931 og KoSIT’s supplerende regler. For Peppol BIS Billing 3.0 gælder det samme med OpenPeppols regler. En kontrol alene mod standarden siger derfor kun begrænset noget om, hvorvidt modtageren accepterer filen. Din software bør kontrollere mod regelsættet for den udformning, modtageren forventer.

KoSIT og OpenPeppol offentliggør jævnligt nye versioner af deres regelsæt med tilpassede kodelister og Schematron-regler. Holder din software ikke regelsættene opdateret, kan fakturaer, der hidtil er blevet accepteret, blive afvist. Afvisningen kommer så fra modtageren, men årsagen ligger i dit eget forældede regelsæt.

Til tests under udviklingen kan enkelte filer kontrolleres mod EN 16931 og Peppol-reglerne med den gratis e-faktura-validator. Til den automatiske kontrol i drift tilbyder InvoiceRails også valideringen via en API, mod EN 16931 og profiler som XRechnung, ZUGFeRD og Peppol BIS Billing. Valideringsrapporten viser fejl, advarsler og hints hver for sig.

En mapping bygges én gang, men valideringsreglerne bag den kan ændre sig flere gange om året. Det næste større skifte står allerede for døren med XRechnung 4.0 og EN 16931 i 2026-udgaven.

2026-udgaven bygger på UBL 2.5. I konforme implementeringer kan UBL 2.5 først bruges, når CEN har offentliggjort en opdateret syntaksbinding. Indtil da gælder de eksisterende bindinger baseret på UBL 2.1. Udbydere kan altså forberede skiftet, men endnu ikke gennemføre det.

Den, der selv bygger tilslutningen, påtager sig denne vedligeholdelse permanent. Det indebærer at holde mappings for begge syntakser, kodelisterne og Schematron-reglerne opdateret og at følge versionsplanerne fra KoSIT, FeRD, OpenPeppol og CEN. Det kan lade sig gøre, men binder udviklingstid, som mangler i dit eget produkt.

Alternativt kan formatvedligeholdelsen outsources til et Peppol access point. InvoiceRails, det OpenPeppol-certificerede access point fra fino data services, dækker via en API mere end 60 formater, herunder XRechnung, ZUGFeRD og Factur-X, og vedligeholder løbende valideringsregler og formatopdateringer.

Udbydere tilslutter afsendelse og modtagelse én gang og stiller funktionen til rådighed for et vilkårligt antal af deres kunder, efter ønske under eget brand. Mappingen af egne fakturadata til grænsefladen forbliver hos udbyderen, ligesom de obligatoriske felter i egen datamodel.

Hvordan softwareudbydere grundlæggende bringer e-fakturering ind i deres eget produkt, kan du læse i artiklen om e-fakturering for softwareudbydere.