Tysklands krav på E-Rechnung: strukturerade fakturor från dina egna system senast 1 januari 2027

Från 1 januari 2027 får ett tyskt företag vars omsättning 2026 översteg 800 000 € inte längre skicka en faktura på papper eller som PDF till ett annat tyskt företag. Fakturan måste vara en strukturerad e-faktura: en datafil uppbyggd enligt den europeiska standarden EN 16931. Från 1 januari 2028 försvinner gränsvärdet och regeln gäller alla företag, med några få snäva undantag.

För ett litet företag kommer det här som en programuppdatering. För ett företag vars fakturor kommer ur ett eget faktureringssystem, ett branschsystem eller ett ERP-system som anpassats under femton år är det ett mjukvaruprojekt, och det återstår ungefär tretton veckor. Den här artikeln är för den andra gruppen.

Vad lagen säger

Definitionen finns i § 14 UStG: en faktura ”die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”, alltså en faktura som utfärdas, överförs och tas emot i ett strukturerat elektroniskt format som möjliggör elektronisk behandling. Formatet måste överensstämma med den europeiska standarden enligt direktiv 2014/55/EU (i praktiken EN 16931), eller vara överenskommet mellan parterna, förutsatt att de obligatoriska uppgifterna kan extraheras korrekt och fullständigt till en form som är förenlig med standarden. En PDF uppfyller inte kraven, hur prydlig den än ser ut.

Skyldigheten gäller leveranser till ett annat företag där båda parter är etablerade i Tyskland. Övergångsreglerna finns i § 27 Abs. 38 UStG:

• Leveranser som görs 2025 och 2026 får fortfarande faktureras på papper, eller i ett annat elektroniskt format om kunden godkänner det, så länge fakturan skickas senast 31 december 2026.
• Leveranser som görs 2027 får samma lättnad fram till 31 december 2027, men bara om utfärdarens totala omsättning föregående kalenderår inte översteg 800 000 €.
• EDI som inte uppfyller standarden får fortsätta användas för leveranser som görs 2027, med kundens godkännande, oavsett din storlek.

Tre detaljer betyder mer än de ser ut att göra.

Gränsvärdet mäts på fjolårets omsättning. Din situation 2027 beror på siffran för 2026, som ingen känner till exakt förrän bokslutet är klart. Ligger du någonstans i närheten av 800 000 €, bygg som om du ligger över.

Lättnaden upphör vid ett sändningsdatum. Läst bokstavligt slutar den första övergångsregeln att omfatta papper och PDF den 31 december 2026, även för arbete som utförts 2026. Ligger du över gränsvärdet och fakturerar i efterskott måste fakturan som du skickar första veckan i januari för decembers arbete redan vara strukturerad. Stäm av detta med din skatterådgivare, men planera inte en driftstart i mitten av januari.

Vissa fakturor ligger utanför tillämpningsområdet: fakturor till konsumenter, gränsöverskridande fakturor, fakturor på småbelopp upp till 250 € inklusive moms, biljetter som räknas som fakturor, fakturor från Kleinunternehmer och leveranser som är undantagna enligt § 4 Nr. 8 till 29 UStG.

Vi känner inte till något lagförslag som flyttar dessa datum. Planera som om de gäller.

Mottagning har gällt sedan 2025. Utfärdandet är det nya.

Sedan 1 januari 2025 har varje tyskt företag varit skyldigt att kunna ta emot e-fakturor. Det tyska finansdepartementets FAQ om e-fakturering är rakt på sak om vad som krävs: ”Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” En e-postlåda räcker.

Notera en rad i själva § 14: där skyldigheten att använda e-faktura gäller krävs inte mottagarens samtycke. En tysk företagskund kan inte vägra ta emot din strukturerade faktura.

Att utfärda är ett annat problem. När du tar emot läser ett verktyg någon annans fil. När du utfärdar är ditt system upphovet: är uppgifterna fel vid källan kan ingen senare i kedjan rätta dem, och en faktura som inte klarar kundens validering blir liggande obetald.

Vem får det här via en uppdatering

Rakt ut: är du ett litet företag som fakturerar från DATEV, lexoffice, sevDesk eller ett liknande program levererar din leverantör formatet. Kontrollera dina grunddata (momsregistreringsnummer, kundadresser, bankuppgifter), slå på funktionen och skicka en testfaktura. Du behöver inget projekt, och du behöver inget mjukvaruföretag.

Ungefär detsamma gäller ett vanligt ERP-system som fortfarande ligger nära standard: leverantören eller din partner levererar utdata, och arbetet består av konfiguration och tester.

Resten av artikeln är för företag vars fakturor kommer från kod som de själva äger, eller kod som ingen underhåller längre:

• faktureringsmotorer i prenumerationsplattformar, marknadsplatser och energi- och vattenbolag, som utfärdar fakturor programmatiskt i stora volymer;
• branschprogram för grossister, bygg, logistik eller fältservice, där leverantören är liten, långsam eller borta;
• ERP-system vars fakturautdata för länge sedan skrevs om till egna utskriftsprogram, rapportmallar eller en dokumentkoppling vid månadsskiftet.

Formaten: EN 16931, XRechnung och ZUGFeRD

EN 16931 är den europeiska standarden. Den definierar den semantiska modellen för en faktura (fälten, vad de betyder, vilka som är obligatoriska och affärsreglerna mellan dem) och knyter den till två XML-syntaxer, UBL 2.1 och UN/CEFACT CII.

XRechnung är den tyska specifikationen ovanpå EN 16931, som förvaltas av KoSIT: ren XML i någon av syntaxerna, krävd av offentliga myndigheter och lika giltig mellan företag. Enligt KoSIT:s sida om XRechnung har version 3.0 gällt sedan 1 februari 2024 och gäller till minst 31 juli 2027. En preliminär version av 4.0 publicerades i september 2026, och den slutliga versionen väntas våren 2027. Du går i drift med 3.0 och uppgraderar under ditt första år.

ZUGFeRD är en hybrid: en PDF/A-3-fil med inbäddad CII-XML. Människor läser PDF:en; maskiner läser XML:en. I Frankrike heter samma format Factur-X, och de två är tekniskt identiska. FeRD publicerade version 2.5.2 den 4 augusti 2026. ZUGFeRD finns i profiler (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), och departementets FAQ godtar ZUGFeRD från version 2.0.1 ”mit Ausnahme der Profile MINIMUM und BASIC-WL”, det vill säga med undantag för profilerna MINIMUM och BASIC-WL.

I en hybridfaktura är det XML:en som gäller. FAQ:n kallar den strukturerade delen för ”führender Teil”, den ledande delen. Säger din PDF och din XML olika saker är det PDF:en som är fel.

För de flesta tyska B2B-utfärdare är det förnuftiga standardvalet ZUGFeRD i profilen EN 16931, så att kunder som fortfarande läser fakturor med ögonen kan fortsätta med det, plus XRechnung för offentliga myndigheter och alla som ber om det. Båda bör komma från ett och samma interna fakturaobjekt, inte från två kodvägar.

Vad som måste ändras i ditt system

Fakturan blir data, inte en layout

Många äldre system bygger fakturan vid utskrift: text som fogas in i en mall, summor som räknas ihop inne i rapporten, momsupplysningen som ett hårdkodat stycke. Inget av det överlever EN 16931. Du behöver ett lagrat fakturaobjekt som innehåller varje fält, och både XML:en och PDF:en ska renderas från det.

Fälten som oftast saknas eller är fel:

• Partsuppgifter. Strukturerade adresser med ISO-landskoder, och ett momsregistreringsnummer eller skattenummer. Adressblock i fritext måste delas upp.
• Leveransdatum eller tjänsteperiod, lagrat som data i stället för som en mening i sidhuvudet.
• Enheter. Varje kvantitet behöver en kod från UN/ECE Recommendation 20 (H87 för styck, KGM för kilogram, DAY för dag). ”Stk.” och ”pauschal” måste mappas.
• Moms. Varje rad har en momskategori och en momssats. Fakturan har en momsspecifikation per kombination av kategori och sats, och summorna måste stämma exakt med två decimaler. System som avrundar momsen per rad faller här.
• Formuleringar om undantag och omvänd skattskyldighet. Meningen längst ned i PDF:en blir en kod för momskategori plus ett skäl till undantag.
• Betalning. Betalningssätt, IBAN och villkor i strukturerad form.
• Referenser. Ordernumret eller köparens referens som kundens leverantörsreskontra matchar mot. Har du aldrig lagrat det, börja samla in det nu.

Rader med enbart text (”leverans enligt överenskommelse”) är en vanlig stötesten. I en strukturerad faktura är en rad en debiterbar rad, så den texten hör hemma i en anteckning.

Rättelser, kreditnotor och självfakturering

FAQ:n är tydlig: där skyldigheten att använda e-faktura gäller måste även en rättelse vara en e-faktura, med fakturatypen för rättelse. I EN 16931 hänvisar den tillbaka till den föregående fakturan med nummer och utfärdandedatum, så ditt system måste behålla den kopplingen som data.

Se upp med terminologin. I tysk momslagstiftning är en ”Gutschrift” en självfaktura, som utfärdas av kunden efter förhandsöverenskommelse (§ 14 Abs. 2 UStG). Det som vi kallar en kreditnota (en prisnedsättning eller en annullering) är en rättelse. Många system använder samma dokumenttyp för båda. Separera dem innan du mappar dem, och om du tillämpar självfakturering mot leverantörer, behandla de dokumenten som fakturor som ditt system utfärdar.

En slutfaktura får lista tidigare delbetalningar i en bilaga, förutsatt att den strukturerade delen hänvisar till den; FAQ:n bekräftar att detta fortsätter att gälla efter 2027.

Validering innan något lämnar huset

KoSIT publicerar en validator med öppen källkod som kontrollerar XML mot scheman och Schematron-regler, med en publik konfiguration för XRechnung. Den körs från kommandoraden, som HTTP-daemon eller som bibliotek. Lägg den i sändningsvägen: varje faktura valideras innan den skickas, och ett fel hamnar i en kö som en namngiven person äger, med uppgift om vilket fält som bröt mot vilken regel.

För ZUGFeRD: validera den inbäddade XML:en mot reglerna för din profil, kontrollera PDF/A-3-behållaren separat och bekräfta att PDF:en visar samma summor som XML:en.

Överföring

Lagen, säger FAQ:n, ”sieht keinen bestimmten Weg vor”: den föreskriver ingen viss kanal. E-post med filen bifogad fungerar. Det gör också ett API, en nedladdningsportal, delad lagring inom en koncern eller (departementets eget exempel) ett USB-minne. Peppol krävs inte för inhemsk B2B i Tyskland.

Ingenjörsarbetet sker per kund: en fakturaadress, ett föredraget format och en logg över vad som skickades vart. Ett nytt försök efter ett misslyckat utskick skickar samma dokument med samma fakturanummer. Två nummer för en och samma leverans är ett skatteproblem, inte ett mjukvaruproblem.

Arkivering

Åtminstone den strukturerade delen måste bevaras ”unversehrt in seiner ursprünglichen Form”, oförändrad i sin ursprungliga form, och § 14b UStG anger en bevarandetid på åtta år från utgången av det år fakturan utfärdades. Spara exakt de byte du skickade, med en hash. Planera inte att återskapa fakturor från databasen senare: då har både data och kod hunnit ändras. Detsamma gäller e-fakturor som du tar emot.

En plan för oktober till december 2026

Tretton veckor räcker för ett fokuserat bygge om källdata är i rimligt skick. Det räcker inte för att byta ut faktureringssystemet.

Vecka 1 och 2: inventering och beslut. Lista varje ställe där en faktura skapas, inklusive manuella kreditnotor, slutfakturor i projekt och kalkylbladet för en stor kund. Jämför omsättningen 2026 med gränsvärdet. Välj standardformat och bestäm om du bygger generatorn själv eller skickar fakturadata till en e-fakturaleverantörs API.

Vecka 2 till 4: gapanalys av data. Mappa tre månaders verkliga fakturor fält för fält mot EN 16931. Markera vad som saknas, vad som måste bli en kod och vad som räknas ut på annat sätt. Det är här projektets verkliga storlek visar sig.

Vecka 4 till 9: bygg. Fakturaobjektet, mappningen, renderingen av XML och PDF/A-3, validatorn i sändningsvägen, felkön och arkivet. Parallellt rensar någon grunddata och samlar in fakturaadresser från kunderna.

Vecka 9 till 11: omkörning och pilot. Kör de senaste tre månadernas fakturor genom den nya generatorn och validera varenda en. Kör sedan en pilot med några villiga kunder och fråga om deras system kan läsa filerna.

Vecka 11 till 13: frys och driftrutiner. Frys ändringar i december. Skriv ned vem som äger felkön, hur en rättelse utfärdas och vad som händer när en kund avvisar en faktura. Januarifakturor för decembers arbete omfattas redan.

Januari 2027. Gå i drift och bevaka kön dagligen genom det första månadsskiftet och den första momsdeklarationen.

Under 2027. Planera uppgraderingen till XRechnung 4.0 innan 3.0 slutar gälla, och för över eventuella koncernbolag under gränsvärdet före 1 januari 2028.

Börjar du sent, skär i automatiseringen, inte i utdatans giltighet: automatisera de fakturatyper som har störst volym först och skicka sällsynta dokument manuellt via ett e-fakturaverktyg under några veckor.

Var du får hjälp

Vi bygger kopplingen mellan systemet som skapar dina fakturor och formatet som lagen kräver: ändringar i datamodellen, mappning, validering, överföring och arkiv, i din kodbas och tillsammans med ditt team. Vår tjänst för integration av e-fakturering beskriver hur sådana projekt går till; om kravet slår till mitt i ett ERP-byte, se modernisering av ERP-system. Den bredare kalendern finns i vår guide till EU:s digitala regelefterlevnad 2026.

Vi är ingenjörer, inte skatterådgivare: frågor om tillämpningsområdet hör hemma hos din Steuerberater, och vi bygger utifrån deras svar. Berätta vad som skapar dina fakturor i dag och ungefär hur många som skickas varje månad: skriv till office@c9group.dev.