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

EN 16931 beskriver en semantisk datamodell. Den fastsetter hvilke opplysninger en faktura inneholder og hvordan de henger sammen, for eksempel fakturanummeret som BT-1 eller kjøperreferansen som BT-10. Standarden i seg selv er ikke et filformat.

For den tekniske representasjonen tillater den to syntakser: UBL og UN/CEFACT CII. Begge gjengir den samme semantiske modellen, men skiller seg i elementnavn og oppbygning. Programvare som bare leser UBL, kan ikke behandle en CII-faktura automatisk, selv om den følger standarden.

For implementeringen avgjør dette vedlikeholdsinnsatsen. To parallelle mappinger betyr at hver regelendring må følges opp to steder. Den som i stedet mapper én gang til standardens semantiske modell og lager begge syntaksene derfra, trenger bare endre ett sted per endring.

Ved mottak mappes den innkommende filen omvendt først til den semantiske modellen og overføres derfra til din datamodell.

Over standarden ligger de nasjonale og nettverksspesifikke variantene, som i standarden kalles Core Invoice Usage Specification, forkortet CIUS. En CIUS innsnevrer standarden. Den gjør valgfrie felt obligatoriske, utelukker andre og har med egne Schematron-regler. Varianter som går utover standardens omfang, kalles Extension.

Uavhengig av syntaks og variant foreligger en e-faktura enten som en ren XML-fil eller som en PDF/A-3 med en innebygd XML-fil. For det siste tilfellet har uttrykket hybridformat festet seg.

XRechnung er en CIUS av EN 16931 og forvaltes av det tyske koordineringskontoret for IT-standarder (Koordinierungsstelle für IT-Standards), forkortet KoSIT. Den finnes i begge syntaksene. Den har ingen visningskomponent, filen er ren XML.

XRechnung er påkrevd for fakturaer til den tyske føderale forvaltningen. Fakturaen adresseres via Leitweg-ID, som oppgis som kjøperreferanse i datasettet.

Innsendingskanalen avhenger av mottakeren. Aktuelt er portalene ZRE og OZG-RE eller et Peppol Access Point. I B2B spiller Leitweg-ID ingen rolle. Der er XRechnung bare én av flere tillatte profiler.

For tiden gjelder versjon 3.0.2. For XRechnung 4.0, implementeringen av EN 16931 i 2026-utgaven, finnes det allerede en forhåndsversjon. Den endelige versjonen av XRechnung 4.0 ventes å bli publisert våren 2027.

ZUGFeRD pakker en XML-fil i CII inn i en PDF/A-3. Mennesket ser PDF-en, mens programvaren leser XML-en.

Spesifikasjonen har flere profiler med ulikt dataomfang, fra MINIMUM til EXTENDED.

MINIMUM og BASIC WL inneholder ingen fullstendig faktura og oppfyller ikke standarden. Fra profilen EN 16931, i eldre utgaver kalt COMFORT, følger den strukturerte delen standarden. Programvaren din bør lese profilen ved import og behandle filer med MINIMUM eller BASIC WL separat, for eksempel via manuell kontroll.

Factur-X er teknisk sett i stor grad identisk med ZUGFeRD.

ZUGFeRD er særlig fornuftig der kundene dine fakturerer mottakere som fortsatt kontrollerer fakturaer visuelt. Det er likevel bare den innebygde XML-en som er rettslig avgjørende. Hvis PDF og XML avviker fra hverandre, har ifølge rundskrivet fra det tyske finansdepartementet (BMF-Schreiben) av 15. oktober 2025 dataene i den strukturerte delen forrang.

En godkjenningsprosess som bare kontrollerer PDF-en, kan derfor godkjenne en faktura der det rettslig avgjørende innholdet er et annet.

Ved sending bør programvaren din lage PDF og XML fra det samme datasettet, slik at de ikke glir fra hverandre. Ved mottak bør den bygge en egen visning fra XML-en for kontrollen i stedet for å vise den medfølgende PDF-en. Det tyske finansdepartementet anbefaler også å visualisere XML-delen selv.

Peppol BIS Billing 3.0 er også en CIUS av EN 16931, låst til UBL 2.1. OpenPeppol har spesifisert det som et eget format for utveksling av fakturaer og kreditnotaer via nettverket.

I tillegg til standardens regler har det egne Schematron-regler. En fil kan bestå kontrollen mot EN 16931 og likevel feile på en Peppol-regel. Ofte gjelder det kodelister eller felt som nettverket definerer strengere enn standarden.

Spesifikasjonen videreutvikles i versjoner. Den som validerer selv, bør kontrollere om regelsettene er oppdaterte.

På lengre sikt beveger Peppol seg mot PINT, et internasjonalt avstemt grunnlag for fakturaprofiler utenfor Europa. For implementeringen i Tyskland endrer dette foreløpig ingenting.

For disse fakturaene må programvaren din kunne lage XRechnung. Mottakerens Leitweg-ID hører hjemme som obligatorisk felt i fakturadatasettet og skrives i XRechnung som kjøperreferanse (BT-10). Mangler den eller står den i feil felt, avviser mottaksportalen fakturaen.

Loven krever en faktura etter EN 16931 og lar formatet være åpent. XRechnung, ZUGFeRD fra profilen EN 16931 og også Peppol BIS Billing er tillatt. Den innebygde XML-en er fortsatt rettslig avgjørende. Hvis PDF og XML avviker fra hverandre, kontrollerer mottakeren muligens andre opplysninger enn dem som gjelder rettslig.

Bedrifter i Tyskland har siden 1. januar 2025 måttet kunne motta e-fakturaer etter EN 16931. For en e-faktura som følger standarden, trenger avsenderen derfor ikke mottakerens samtykke, selv om mottakeren foretrekker et bestemt format.

Partene trenger bare å bli enige om overføringskanal og om formater utenfor standarden. I praksis hører den avtalte kanalen derfor hjemme i stamdataene til den enkelte forretningspartneren.

I tillegg til Peppol BIS Billing 3.0 kan også XRechnung og siden mars 2025 ZUGFeRD som hybridfil overføres via Peppol-nettverket. Dokumenttypene en mottaker har registrert i katalogtjenesten, viser hvilke formater den tar imot. Før sending må programvaren din slå opp denne registreringen og velge riktig format. For enkeltkontroller viser Peppol-ID-søket dette uten innlogging.

I løpende drift bør programvaren din gjøre dette oppslaget automatisk før sending, enten direkte via katalogtjenestene SML og SMP eller via API-et til Peppol Access Pointet ditt. Ut fra dette fastslås et format som begge støtter, og e-fakturaen lages deretter i dette formatet.

Innkommende fakturaer kommer i det formatet avsenderen har valgt. Programvaren din bør derfor kunne lese begge syntaksene, UBL og CII, og dermed også XRechnung i begge varianter. I tillegg kommer ZUGFeRD og Factur-X som hybridfiler og, så snart kundene dine mottar fakturaer fra utlandet, profilene som er vanlige der.

Hver innkommende fil inneholder en identifikator for hvilken variant den bruker. I UBL står den i elementet cbc:CustomizationID, i CII i retningslinjens kontekstparameter. Programvaren din bør lese denne identifikatoren først, for den avgjør hvilke valideringsregler som gjelder og hvordan filen overføres til datamodellen din.

Noen Peppol Access Points tar dette trinnet for deg. De kontrollerer den innkommende filen, trekker ut fakturadataene og overleverer dem sammen med originalfilen som et enhetlig datasett.

Programvaren din bør dekke mottak fullt ut før sending, altså begge syntaksene og hybridformatene, for kundene dine må allerede i dag kunne motta e-fakturaer.

Sending blir obligatorisk for kundene dine i to trinn. Fra 1. januar 2027 ved mer enn 800 000 euro i samlet omsetning året før, og fra 1. januar 2028 for all øvrig innenlandsk B2B-omsetning.

Den som begynner med syntaksen CII, kan lage XRechnung i CII-varianten og ZUGFeRD. UBL blir nødvendig så snart mottakere i Peppol-nettverket forventer Peppol BIS Billing 3.0, for dette formatet forutsetter UBL.

Alle obligatoriske merverdiavgiftsopplysninger må stå maskinlesbart i den strukturerte delen av e-fakturaen. Det gjelder også leveransebeskrivelsen. En henvisning til et vedlegg, en følgeseddel eller en lenke erstatter ikke et obligatorisk felt. Grunnlaget er spørsmål og svar fra det tyske finansdepartementet om e-faktura og rundskrivet fra det tyske finansdepartementet (BMF-Schreiben) av 15. oktober 2025.

Årsaken ligger i oppbygningen av e-fakturaen. I hybridformater som ZUGFeRD er dataene i XML-en styrende, PDF-en er bare en visning. En opplysning som bare er synlig i PDF-en, teller derfor ikke.

Mangler en obligatorisk opplysning i den strukturerte delen, regnes fakturaen som ikke forskriftsmessig, og mottakerens fradragsrett for inngående merverdiavgift kan være i fare. Kundene dine merker det senest når forretningspartnere avviser fakturaer av denne grunn.

Mange fakturamaler inneholder obligatoriske opplysninger som tekstblokker som bare vises i PDF-en. Ofte gjelder det leveransebeskrivelsen, for eksempel «i henhold til tilbud 2026-114», leveranseperioden i bunnteksten på fakturaen og merknaden om omvendt avgiftsplikt.

I datamodellen bør hver av disse opplysningene ha et eget felt som XML-en fylles ut fra. Leveranseperioden hører hjemme i feltene for faktureringsperioden (BG-14), merknaden om omvendt avgiftsplikt i avgiftskategorien med fritaksgrunn (BT-120 og BT-121).

Den tekniske valideringen kontrollerer om standardens obligatoriske felt finnes og er formelt korrekt utfylt. Den oppdager ikke om en leveransebeskrivelse er tilstrekkelig i merverdiavgiftsmessig forstand. En faktura kan altså bestå kontrollen og likevel bare inneholde en obligatorisk opplysning på en mangelfull måte.

Følgesedler, timelister og andre dokumenter som følger fakturaen, kan bygges inn som vedlegg i e-fakturaen, i EN 16931 via gruppen for tilleggsdokumenter (BG-24). Det erstatter separat utsending og holder faktura og dokumentasjon samlet i én fil.

En XRechnung kontrolleres mot to regelverk, reglene i EN 16931 og tilleggsreglene fra KoSIT. For Peppol BIS Billing 3.0 gjelder det samme med reglene fra OpenPeppol. En kontroll bare mot standarden sier derfor begrenset om mottakeren godtar filen. Programvaren din bør kontrollere mot regelverket for den varianten mottakeren forventer.

KoSIT og OpenPeppol publiserer jevnlig nye versjoner av regelverkene sine med oppdaterte kodelister og Schematron-regler. Hvis programvaren din ikke holder regelsettene oppdatert, kan fakturaer som tidligere ble godtatt, bli avvist. Avvisningen kommer da fra mottakeren, men årsaken ligger i ditt eget utdaterte regelsett.

For tester under utviklingen kan enkeltfiler kontrolleres mot EN 16931 og Peppol-reglene med den gratis e-fakturavalidatoren. For automatisk kontroll i drift tilbyr InvoiceRails valideringen også via et API, mot EN 16931 og profiler som XRechnung, ZUGFeRD og Peppol BIS Billing. Valideringsrapporten viser feil, advarsler og merknader hver for seg.

En mapping bygges én gang, men valideringsreglene bak den kan endres flere ganger i året. Den neste store overgangen, med XRechnung 4.0 og EN 16931 i 2026-utgaven, står allerede for døren.

2026-utgaven bygger på UBL 2.5. I samsvarende implementeringer kan UBL 2.5 først brukes når CEN har publisert en oppdatert syntaksbinding. Inntil da gjelder de eksisterende bindingene basert på UBL 2.1. Leverandører kan altså forberede overgangen, men ennå ikke gjennomføre den.

Den som bygger tilkoblingen selv, tar på seg dette vedlikeholdet permanent. Det omfatter å holde mappingene for begge syntaksene, kodelistene og Schematron-reglene oppdatert og å følge versjonsplanene til KoSIT, FeRD, OpenPeppol og CEN. Det er gjennomførbart, men binder utviklingstid som mangler i ditt eget produkt.

Alternativt kan formatvedlikeholdet settes ut til et Peppol Access Point. InvoiceRails, det OpenPeppol-sertifiserte Access Pointet fra fino data services, dekker mer enn 60 formater via ett API, blant annet XRechnung, ZUGFeRD og Factur-X, og vedlikeholder valideringsregler og formatoppdateringer løpende.

Leverandører kobler til sending og mottak én gang og gjør funksjonen tilgjengelig for så mange av kundene sine de vil, ved ønske under eget merkenavn. Mappingen av egne fakturadata til grensesnittet forblir hos leverandøren, det samme gjør de obligatoriske feltene i egen datamodell.

Hvordan programvareleverandører generelt kan få e-faktura inn i sitt eget produkt, kan du lese i artikkelen om e-faktura for programvareleverandører.