Tysklands krav om E-Rechnung: strukturerede fakturaer fra jeres egne systemer senest 1. januar 2027

Fra 1. januar 2027 kan en tysk virksomhed, hvis omsætning i 2026 var over 800.000 euro, ikke længere sende en papir- eller PDF-faktura til en anden tysk virksomhed. Fakturaen skal være en struktureret e-faktura: en datafil bygget efter den europæiske standard EN 16931. Fra 1. januar 2028 forsvinder grænsen, og reglen gælder for alle virksomheder, bortset fra nogle få snævre undtagelser.

For en lille virksomhed kommer dette som en softwareopdatering. For en virksomhed, hvis fakturaer kommer ud af dens eget faktureringssystem, en branchepakke eller et ERP-system, der er tilpasset gennem femten år, er det et softwareprojekt, og der er omkring tretten uger tilbage. Denne artikel er til den anden gruppe.

Hvad loven siger

Definitionen står i § 14 UStG: en faktura, »die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht«, altså en faktura, der udstedes, overføres og modtages i et struktureret elektronisk format, som muliggør elektronisk behandling. Formatet skal overholde den europæiske standard efter direktiv 2014/55/EU (i praksis EN 16931) eller være aftalt mellem parterne, forudsat at de krævede data kan udtrækkes korrekt og fuldstændigt til en form, der er kompatibel med standarden. En PDF opfylder ikke kravet, uanset hvor pæn den ser ud.

Pligten omfatter leverancer til en anden virksomhed, hvor begge parter er etableret i Tyskland. Overgangsreglerne står i § 27 Abs. 38 UStG:

• Leverancer foretaget i 2025 og 2026 kan stadig faktureres på papir eller i et andet elektronisk format, hvis kunden er indforstået, så længe fakturaen sendes senest 31. december 2026.
• Leverancer foretaget i 2027 får samme lempelse frem til 31. december 2027, men kun hvis udstederens samlede omsætning i det foregående kalenderår ikke oversteg 800.000 euro.
• EDI, der ikke opfylder standarden, kan fortsætte for leverancer foretaget i 2027 med kundens accept, uanset virksomhedens størrelse.

Tre detaljer betyder mere, end de ser ud til.

Grænsen måles på sidste års omsætning. Jeres situation i 2027 afhænger af tallet for 2026, som ingen kender præcist, før regnskabet er lukket. Ligger I bare i nærheden af 800.000 euro, så byg, som om I ligger over.

Lempelsen slutter på en afsendelsesdato. Læst bogstaveligt holder den første overgangsregel op med at dække papir og PDF 31. december 2026, også for arbejde udført i 2026. Ligger I over grænsen og fakturerer bagudrettet, skal den faktura, I sender i første uge af januar for arbejdet i december, allerede være struktureret. Få det bekræftet af jeres skatterådgiver, men planlæg ikke en go live midt i januar.

Nogle fakturaer forbliver uden for kravet: fakturaer til forbrugere, grænseoverskridende fakturaer, fakturaer på små beløb op til 250 euro brutto, billetter der gælder som faktura, fakturaer fra Kleinunternehmer (små virksomheder under den tyske småvirksomhedsordning) og leverancer, der er fritaget efter § 4 Nr. 8 til 29 UStG.

Vi kender ikke til noget lovforslag, der flytter datoerne. Planlæg, som om de holder.

Modtagelse har gældt siden 2025. Udstedelse er det nye.

Siden 1. januar 2025 har alle tyske virksomheder skullet kunne modtage e-fakturaer. Det tyske finansministeriums FAQ om e-fakturering er ligefrem om, hvad det kræver: »Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.« En e-mailindbakke er nok.

Læg mærke til én linje i selve § 14: hvor kravet om e-faktura gælder, kræves modtagerens samtykke ikke. En tysk erhvervskunde kan ikke afvise jeres strukturerede faktura.

Udstedelse er et andet problem. Når I modtager, læser et værktøj en andens fil. Når I udsteder, er jeres system forfatteren: er data forkerte ved kilden, kan ingen senere i kæden rette dem, og en faktura, der fejler i kundens validering, bliver liggende ubetalt.

Hvem der får dette med en opdatering

Helt ærligt: er I en lille virksomhed, der fakturerer fra DATEV, lexoffice, sevDesk eller en lignende pakke, leverer leverandøren formatet. Tjek jeres stamdata (momsnummer, kundeadresser, bankoplysninger), slå funktionen til og send en testfaktura. I har ikke brug for et projekt, og I har ikke brug for et softwarefirma.

Stort set det samme gælder for et udbredt ERP-system, der stadig ligger tæt på standarden: leverandøren eller jeres partner leverer outputtet, og arbejdet består i konfiguration og test.

Resten af artiklen er til virksomheder, hvis fakturaer kommer fra kode, de selv ejer, eller kode, som ingen længere vedligeholder:

• faktureringsmotorer i abonnementsplatforme, markedspladser og forsyningsvirksomheder, som udsteder fakturaer programmatisk i store mængder;
• branchesoftware til engroshandel, byggeri, logistik eller udkørende service, hvor leverandøren er lille, langsom eller forsvundet;
• ERP-systemer, hvis fakturaoutput for år tilbage blev omskrevet til egne printprogrammer, rapportskabeloner eller en brevfletning ved månedsslut.

Formaterne: EN 16931, XRechnung og ZUGFeRD

EN 16931 er den europæiske standard. Den definerer den semantiske model for en faktura (felterne, hvad de betyder, hvilke der er obligatoriske, og forretningsreglerne mellem dem) og knytter den til to XML-syntakser, UBL 2.1 og UN/CEFACT CII.

XRechnung er den tyske specifikation oven på EN 16931, vedligeholdt af KoSIT: ren XML i en af de to syntakser, krævet af offentlige myndigheder og lige så gyldig mellem virksomheder. Ifølge KoSIT's side om XRechnung har version 3.0 været gældende siden 1. februar 2024 og er gældende mindst frem til 31. juli 2027. En foreløbig version af 4.0 blev offentliggjort i september 2026, og den endelige udgave ventes i foråret 2027. I går i drift på 3.0 og opgraderer inden for det første år.

ZUGFeRD er et hybridformat: en PDF/A-3-fil med CII-XML indlejret. Mennesker læser PDF'en, maskiner læser XML'en. I Frankrig hedder samme format Factur-X, og de to er teknisk identiske. FeRD udgav version 2.5.2 den 4. august 2026. ZUGFeRD findes i profiler (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), og ministeriets FAQ accepterer ZUGFeRD fra version 2.0.1 »mit Ausnahme der Profile MINIMUM und BASIC-WL«, altså undtagen profilerne MINIMUM og BASIC-WL.

I en hybridfaktura er det XML'en, der tæller. FAQ'en kalder den strukturerede del »führender Teil«, den førende del. Er PDF'en og XML'en uenige, er det PDF'en, der er forkert.

For de fleste tyske B2B-udstedere er det fornuftige udgangspunkt ZUGFeRD i profilen EN 16931, så kunder, der stadig læser fakturaer med øjnene, kan fortsætte som hidtil, plus XRechnung til offentlige myndigheder og alle, der beder om det. Begge bør komme fra ét internt fakturaobjekt, ikke fra to kodestier.

Hvad der skal ændres i jeres system

Fakturaen bliver til data, ikke et layout

Mange ældre systemer danner fakturaen i det øjeblik, den printes: tekst sat sammen i en skabelon, totaler summeret inde i rapporten og momsbemærkningen som et fast indkodet afsnit. Intet af det overlever EN 16931. I har brug for et gemt fakturaobjekt med hvert felt, hvorfra både XML og PDF dannes.

De felter, der som regel mangler eller er forkerte:

• Partsoplysninger. Strukturerede adresser med ISO-landekoder og et momsnummer eller skattenummer. Adresseblokke i fritekst skal deles op.
• Leveringsdato eller ydelsesperiode, gemt som data og ikke som en sætning i hovedet.
• Enheder. Hver mængde skal have en kode fra UN/ECE Recommendation 20 (H87 for stk., KGM for kilogram, DAY for dag). »Stk.« og »pauschal« skal mappes.
• Moms. Hver linje har en momskategori og en sats. Fakturaen har én momsopgørelse pr. kombination af kategori og sats, og totalerne skal stemme præcist på to decimaler. Systemer, der afrunder momsen pr. linje, fejler her.
• Tekst om fritagelse og omvendt betalingspligt. Sætningen nederst på PDF'en bliver til en kode for momskategori plus en fritagelsesårsag.
• Betaling. Betalingsmåde, IBAN og betingelser i struktureret form.
• Referencer. Ordrenummeret eller den købsreference, som kundens kreditorafdeling matcher mod. Har I aldrig gemt den, så begynd at registrere den nu.

Linjer med ren tekst (»levering efter aftale«) er en almindelig snublesten. I en struktureret faktura er en linje en faktureringslinje, så den tekst hører hjemme i en note.

Rettelser, kreditnotaer og selvfakturering

FAQ'en er udtrykkelig: hvor kravet om e-faktura gælder, skal en rettelse også være en e-faktura og bruge fakturatypen for rettelser. I EN 16931 henviser den til den foregående faktura med nummer og udstedelsesdato, så jeres system skal holde den kobling som data.

Hold øje med ordvalget. I tysk momsret er en »Gutschrift« en selvfaktura, udstedt af kunden efter forudgående aftale (§ 14 Abs. 2 UStG). Det, man på dansk kalder en kreditnota (et nedslag i prisen eller en annullering), er en rettelse. Mange systemer bruger én dokumenttype til begge dele. Skil dem ad, før I mapper dem, og selvfakturerer I leverandører, så behandl de dokumenter som fakturaer, jeres system udsteder.

En slutfaktura kan opliste tidligere delbetalinger i et bilag, forudsat at den strukturerede del henviser til det; FAQ'en bekræfter, at dette fortsætter efter 2027.

Validering, før noget forlader huset

KoSIT udgiver en open source-validator, der kontrollerer XML mod skemaer og Schematron-regler, med en offentlig konfiguration til XRechnung. Den kører fra kommandolinjen, som HTTP-dæmon eller som bibliotek. Sæt den ind i afsendelsesforløbet: hver faktura valideres, før den sendes, og en fejl lander i en kø, som en navngiven person ejer, med besked om, hvilket felt der brød hvilken regel.

For ZUGFeRD skal I validere den indlejrede XML mod jeres profils regler, kontrollere PDF/A-3-containeren for sig og bekræfte, at PDF'en viser de samme totaler som XML'en.

Overførsel

Loven, skriver FAQ'en, »sieht keinen bestimmten Weg vor«: den foreskriver ingen bestemt kanal. E-mail med filen vedhæftet er fint. Det samme er et API, en downloadportal, fælles lager inden for en koncern eller (ministeriets eget eksempel) en USB-nøgle. Peppol er ikke et krav for indenlandsk B2B i Tyskland.

Det tekniske arbejde ligger pr. kunde: en fakturaadresse, et foretrukket format og en registrering af, hvad der er sendt hvorhen. Et genforsøg efter en mislykket afsendelse indeholder det samme dokument med det samme fakturanummer. To numre for én leverance er et skatteproblem, ikke et softwareproblem.

Arkivering

Som minimum skal den strukturerede del opbevares »unversehrt in seiner ursprünglichen Form«, uændret i sin oprindelige form, og § 14b UStG fastsætter opbevaringen til otte år fra udgangen af udstedelsesåret. Gem præcis de bytes, I sendte, med en hashværdi. Planlæg ikke at gendanne fakturaer fra databasen senere: til den tid har både data og kode flyttet sig. Det samme gælder de e-fakturaer, I modtager.

En plan for oktober til december 2026

Tretten uger er nok til en fokuseret udvikling, hvis kildedata er i rimelig stand. Det er ikke nok til at udskifte faktureringssystemet.

Uge 1 og 2: overblik og beslutninger. List alle steder, hvor der dannes en faktura, inklusive manuelle kreditnotaer, slutfakturaer på projekter og regnearket til den ene store kunde. Sammenlign omsætningen for 2026 med grænsen. Vælg standardformatet, og beslut, om I bygger generatoren selv eller sender fakturadata til en e-faktureringsudbyders API.

Uge 2 til 4: analyse af datahuller. Map tre måneders rigtige fakturaer felt for felt til EN 16931. Markér, hvad der mangler, hvad der skal blive til en kode, og hvad der beregnes anderledes. Det er her, projektets reelle størrelse viser sig.

Uge 4 til 9: udvikling. Fakturaobjektet, mappingen, dannelse af XML og PDF/A-3, validatoren i afsendelsesforløbet, fejlkøen og arkivet. Samtidig renser nogen stamdata og indsamler fakturaadresser fra kunderne.

Uge 9 til 11: genkørsel og pilot. Kør de seneste tre måneders fakturaer gennem den nye generator og validér hver eneste. Lav derefter en pilot med nogle få villige kunder, og spørg, om deres systemer kan læse filerne.

Uge 11 til 13: frys og driftsvejledning. Frys ændringer i december. Skriv ned, hvem der ejer fejlkøen, hvordan en rettelse udstedes, og hvad der sker, når en kunde afviser en faktura. Januarfakturaer for arbejde i december er allerede omfattet.

Januar 2027. Gå i drift, og hold dagligt øje med køen gennem den første månedsafslutning og den første momsangivelse.

Gennem 2027. Planlæg opgraderingen til XRechnung 4.0, før 3.0 holder op med at være gyldig, og få eventuelle koncernselskaber under grænsen med inden 1. januar 2028.

Starter I sent, så skær ned på automatiseringen, ikke på outputtets gyldighed: automatisér de fakturatyper, der har størst volumen, først, og send sjældne dokumenter manuelt gennem et e-faktureringsværktøj i nogle uger.

Hvor I kan få hjælp

Vi bygger forbindelsen mellem det system, der danner jeres fakturaer, og det format, loven kræver: ændringer i datamodellen, mapping, validering, overførsel og arkiv, i jeres kodebase og sammen med jeres team. Vores service til integration af e-fakturering beskriver, hvordan de projekter forløber; lander kravet midt i et ERP-skifte, så se ERP-modernisering. Den bredere kalender findes i vores guide til EU digital compliance 2026.

Vi er ingeniører, ikke skatterådgivere: spørgsmål om afgrænsning hører hjemme hos jeres Steuerberater, og vi bygger efter deres svar. Fortæl os, hvad der danner jeres fakturaer i dag, og omtrent hvor mange der sendes om måneden: skriv til office@c9group.dev.