XRechnung, ZUGFeRD och BIS Billing 3.0, vilka e-fakturaformat din programvara bör stödja

EN 16931 beskriver en semantisk datamodell. Den fastställer vilka uppgifter en faktura innehåller och hur de förhåller sig till varandra, till exempel fakturanumret som BT-1 eller köparreferensen som BT-10. Standarden i sig är inget filformat.

För den tekniska representationen tillåter den två syntaxer: UBL och UN/CEFACT CII. Båda representerar samma semantiska modell men skiljer sig i elementnamn och uppbyggnad. Programvara som bara läser in UBL kan inte automatiskt bearbeta en CII-faktura, även om den följer standarden.

För implementeringen avgör det underhållsarbetet. Två parallella mappningar innebär att varje regeländring måste följas upp på två ställen. Den som i stället mappar en gång mot standardens semantiska modell och skapar båda syntaxerna därifrån behöver bara ändra på ett ställe per ändring.

Vid mottagning mappas den inkommande filen omvänt först mot den semantiska modellen och förs därifrån över till din datamodell.

Ovanför standarden ligger de nationella och nätverksspecifika varianterna, i standarden kallade Core Invoice Usage Specification, förkortat CIUS. En CIUS snävar in standarden. Den gör valfria fält obligatoriska, utesluter andra och har egna Schematron-regler. Varianter som går utöver standardens omfattning kallas extension.

Oberoende av syntax och variant finns en e-faktura antingen som ren XML-fil eller som PDF/A-3 med inbäddad XML-fil. För det andra fallet har uttrycket hybridformat etablerats.

XRechnung är en CIUS av EN 16931 och förvaltas av den tyska samordningsmyndigheten för IT-standarder (Koordinierungsstelle für IT-Standards), förkortat KoSIT. Den finns i båda syntaxerna. Någon visuell komponent har den inte, filen är ren XML.

XRechnung är föreskrivet för fakturor till den tyska federala förvaltningen. Fakturan adresseras via Leitweg-ID, som anges som köparreferens i dataposten.

Inlämningsvägen beror på mottagaren. Aktuella är portalerna ZRE och OZG-RE eller en Peppol-accesspunkt. Inom B2B spelar Leitweg-ID ingen roll. Där är XRechnung bara en av flera tillåtna profiler.

För närvarande gäller version 3.0.2. För XRechnung 4.0, implementeringen av EN 16931 i 2026 års version, finns redan en förhandsversion. Den slutliga versionen av XRechnung 4.0 väntas publiceras våren 2027.

ZUGFeRD paketerar en XML-fil enligt CII i en PDF/A-3. Människan ser PDF:en, medan programvaran läser XML-filen.

Specifikationen har flera profiler med olika dataomfång, från MINIMUM till EXTENDED.

MINIMUM och BASIC WL innehåller ingen fullständig faktura och uppfyller inte standarden. Från profilen EN 16931, i äldre versioner kallad COMFORT, följer den strukturerade delen standarden. Din programvara bör läsa ut profilen vid import och hantera filer med MINIMUM eller BASIC WL separat, till exempel genom en manuell kontroll.

Factur-X är tekniskt i stort sett identiskt med ZUGFeRD.

ZUGFeRD är framför allt meningsfullt där dina kunder fakturerar mottagare som fortfarande granskar fakturor visuellt. Det är dock bara den inbäddade XML-filen som är rättsligt avgörande. Om PDF och XML avviker från varandra har enligt det tyska finansdepartementets skrivelse (BMF-Schreiben) av den 15 oktober 2025 uppgifterna i den strukturerade delen företräde.

En godkännandeprocess som bara granskar PDF:en kan därför godkänna en faktura vars rättsligt avgörande innehåll är ett annat.

Vid sändning bör din programvara skapa PDF och XML från samma datapost, så att de inte glider isär. Vid mottagning bör den bygga upp en egen vy från XML-filen för granskningen, i stället för att visa den medföljande PDF:en. Det tyska finansdepartementet rekommenderar också att XML-delen visualiseras självständigt.

Peppol BIS Billing 3.0 är också en CIUS av EN 16931, fastställd på UBL 2.1. OpenPeppol har specificerat den som ett eget format för utbyte av fakturor och kreditnotor via nätverket.

Utöver standardens regler har den egna Schematron-regler. En fil kan klara kontrollen mot EN 16931 och ändå fastna på en Peppol-regel. Ofta gäller det kodlistor eller fält som nätverket definierar snävare än standarden.

Specifikationen vidareutvecklas i versioner. Den som validerar själv bör kontrollera att regeluppsättningarna motsvarar den aktuella versionen.

På längre sikt rör sig Peppol mot PINT, en internationellt samordnad grund för fakturaprofiler utanför Europa. För implementeringen i Tyskland ändrar det för närvarande ingenting.

För dessa fakturor måste din programvara kunna skapa XRechnung. Mottagarens Leitweg-ID hör hemma som obligatoriskt fält i fakturaposten och anges i XRechnung som köparreferens (BT-10). Om det saknas eller står i fel fält avvisar mottagningsportalen fakturan.

Lagen kräver en faktura enligt EN 16931 och lämnar formatet öppet. XRechnung, ZUGFeRD från profilen EN 16931 och även Peppol BIS Billing är tillåtna. Den inbäddade XML-filen förblir rättsligt avgörande. Om PDF och XML avviker från varandra granskar mottagaren eventuellt andra uppgifter än de som gäller rättsligt.

Inhemska företag måste sedan den 1 januari 2025 kunna ta emot e-fakturor enligt EN 16931. För en standardenlig e-faktura behöver avsändaren därför inte mottagarens samtycke, även om mottagaren föredrar ett visst format.

Parterna behöver bara komma överens om överföringsvägen och om format utanför standarden. I praktiken hör den avtalade vägen därför hemma i grunddata för den enskilda affärspartnern.

Utöver Peppol BIS Billing 3.0 kan även XRechnung och sedan mars 2025 ZUGFeRD som hybridfil överföras via Peppol-nätverket. De dokumenttyper som en mottagare har registrerat i katalogtjänsten visar vilka format den tar emot. Före sändning måste din programvara slå upp denna registrering och välja rätt format. För enskilda kontroller visar Peppol-ID-sökningen detta utan inloggning.

I den löpande driften bör din programvara göra denna uppslagning automatiskt före sändning, antingen direkt via katalogtjänsterna SML och SMP eller via API:et hos din Peppol-accesspunkt. Utifrån detta fastställs ett format som båda parter stöder, och e-fakturan skapas sedan i det formatet.

Inkommande fakturor anländer i det format som avsändaren har valt. Din programvara bör därför kunna läsa båda syntaxerna, UBL och CII, och därmed även XRechnung i båda varianterna. Därtill kommer ZUGFeRD och Factur-X som hybridfiler och, så snart dina kunder tar emot fakturor från utlandet, de profiler som är vanliga där.

Varje inkommande fil innehåller en identifierare för vilken variant den använder. I UBL står den i elementet cbc:CustomizationID, i CII i riktlinjens kontextparameter. Din programvara bör läsa ut denna identifierare först, eftersom den avgör vilka valideringsregler som gäller och hur filen förs över till din datamodell.

Vissa Peppol-accesspunkter tar över detta steg åt dig. De kontrollerar den inkommande filen, läser ut fakturauppgifterna och lämnar över dem tillsammans med originalfilen som en enhetlig datapost.

Din programvara bör täcka mottagning fullt ut före sändning, alltså båda syntaxerna och hybridformaten, eftersom dina kunder redan i dag måste kunna ta emot e-fakturor.

Sändningen blir obligatorisk för dina kunder i två steg. Från den 1 januari 2027 vid en total omsättning på mer än 800 000 euro föregående år och från den 1 januari 2028 för all övrig inhemsk B2B-försäljning.

Den som börjar med syntaxen CII kan med den skapa XRechnung i CII-varianten och ZUGFeRD. UBL behövs så snart mottagare i Peppol-nätverket förväntar sig Peppol BIS Billing 3.0, eftersom det formatet förutsätter UBL.

Alla obligatoriska momsuppgifter måste finnas maskinellt läsbara i e-fakturans strukturerade del. Dit hör även beskrivningen av leveransen. En hänvisning till en bilaga, en följesedel eller en länk ersätter inte ett obligatoriskt fält. Grunden är det tyska finansdepartementets vanliga frågor om e-faktura och det tyska finansdepartementets skrivelse (BMF-Schreiben) av den 15 oktober 2025.

Skälet ligger i e-fakturans uppbyggnad. I hybridformat som ZUGFeRD är data i XML-filen styrande, och PDF:en är bara en vy. En uppgift som bara syns i PDF:en räknas därför inte.

Om en obligatorisk uppgift saknas i den strukturerade delen anses fakturan inte vara korrekt, och mottagarens avdragsrätt för ingående moms kan äventyras. Dina kunder märker det senast när affärspartner avvisar fakturor av detta skäl.

I många fakturamallar finns obligatoriska uppgifter som textblock som bara syns i PDF:en. Ofta gäller det beskrivningen av leveransen, till exempel “enligt offert 2026-114”, leveransperioden i fakturans sidfot och hänvisningen till omvänd skattskyldighet.

I datamodellen bör var och en av dessa uppgifter ha ett eget fält som XML-filen fylls från. Leveransperioden hör hemma i fälten för faktureringsperioden (BG-14), hänvisningen till omvänd skattskyldighet i skattekategorin med undantagsskäl (BT-120 och BT-121).

Den tekniska valideringen kontrollerar om standardens obligatoriska fält finns och är formellt korrekt ifyllda. Den upptäcker inte om en beskrivning av leveransen räcker ur momssynpunkt. En faktura kan alltså klara kontrollen och ändå innehålla en obligatorisk uppgift på ett otillräckligt sätt.

Följesedlar, tidrapporter och andra underlag som hör till fakturan kan bäddas in som bilaga i e-fakturan, i EN 16931 via gruppen för kompletterande dokument (BG-24). Det ersätter separat sändning och håller samman faktura och underlag i en fil.

En XRechnung kontrolleras mot två regelverk, reglerna i EN 16931 och KoSIT:s kompletterande regler. För Peppol BIS Billing 3.0 gäller detsamma med OpenPeppols regler. En kontroll enbart mot standarden säger därför bara i begränsad omfattning något om huruvida mottagaren godtar filen. Din programvara bör kontrollera mot regelverket för den variant som mottagaren förväntar sig.

KoSIT och OpenPeppol publicerar regelbundet nya versioner av sina regelverk med anpassade kodlistor och Schematron-regler. Om din programvara inte håller regeluppsättningarna aktuella kan fakturor avvisas som tidigare godtogs. Avvisningen kommer då från mottagaren, men orsaken ligger i den egna, föråldrade regeluppsättningen.

För tester under utvecklingen kan enskilda filer kontrolleras mot EN 16931 och Peppol-reglerna med den kostnadsfria validatorn för e-fakturor. För automatisk kontroll i drift erbjuder InvoiceRails valideringen även via API, mot EN 16931 och profiler som XRechnung, ZUGFeRD och Peppol BIS Billing. Valideringsrapporten redovisar fel, varningar och upplysningar separat.

En mappning byggs en gång, men valideringsreglerna bakom den kan ändras flera gånger om året. Nästa större byte står redan för dörren med XRechnung 4.0 och EN 16931 i 2026 års version.

2026 års version bygger på UBL 2.5. I standardenliga implementeringar kan UBL 2.5 användas först när CEN har publicerat en uppdaterad syntaxbindning. Till dess gäller de befintliga bindningarna baserade på UBL 2.1. Leverantörer kan alltså förbereda bytet men ännu inte genomföra det.

Den som bygger anslutningen själv tar på sig detta underhåll permanent. Det innebär att hålla mappningarna för båda syntaxerna, kodlistorna och Schematron-reglerna aktuella och att följa versionsplanerna från KoSIT, FeRD, OpenPeppol och CEN. Det är genomförbart, men binder utvecklingstid som saknas i den egna produkten.

Alternativt kan formatunderhållet läggas ut på en Peppol-accesspunkt. InvoiceRails, den OpenPeppol-certifierade accesspunkten från fino data services, täcker via ett API mer än 60 format, bland annat XRechnung, ZUGFeRD och Factur-X, och underhåller valideringsregler och formatuppdateringar löpande.

Leverantörer ansluter sändning och mottagning en gång och gör funktionen tillgänglig för valfritt antal av sina kunder, om så önskas under eget varumärke. Mappningen av de egna fakturauppgifterna mot gränssnittet ligger kvar hos leverantören, liksom de obligatoriska fälten i den egna datamodellen.

Hur programvaruleverantörer i grunden för in e-faktura i sin egen produkt kan du läsa i artikeln om e-faktura för programvaruleverantörer.