E-Rechnung i Tyskland: strukturerte fakturaer fra egne systemer innen 1. januar 2027

Frankfurts skyline i skumringen, speilet i elven Main

Fra 1. januar 2027 kan en tysk virksomhet med omsetning over 800 000 euro i 2026 ikke lenger sende en papir- eller PDF-faktura til en annen tysk virksomhet. Fakturaen må være en strukturert e-faktura: en datafil bygget etter den europeiske standarden EN 16931. Fra 1. januar 2028 faller terskelen bort, og regelen gjelder alle virksomheter, bortsett fra noen få smale unntak.

For et lite firma kommer dette som en programvareoppdatering. For et selskap der fakturaene kommer fra eget faktureringssystem, en bransjepakke eller et ERP-system som er tilpasset gjennom femten år, er det et programvareprosjekt, og det gjenstår rundt tretten uker. Denne artikkelen er for den andre gruppen.

Hva loven sier

Definisjonen 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 som utstedes, overføres og mottas i et strukturert elektronisk format og kan behandles elektronisk. Formatet må være i samsvar med den europeiske standarden etter direktiv 2014/55/EU (i praksis EN 16931), eller være avtalt mellom partene, forutsatt at de påkrevde dataene kan hentes ut korrekt og fullstendig i en form som er forenlig med den standarden. En PDF holder ikke, uansett hvor ryddig den ser ut.

Plikten gjelder leveranser til en annen virksomhet der begge parter er etablert i Tyskland. Overgangsreglene står i § 27 Abs. 38 UStG:

Leveranser i 2025 og 2026 kan fortsatt faktureres på papir, eller i et annet elektronisk format hvis kunden samtykker, så lenge fakturaen sendes innen 31. desember 2026.
Leveranser i 2027 får samme lempelse frem til 31. desember 2027, men bare hvis utstederens samlede omsetning i foregående kalenderår ikke var over 800 000 euro.
EDI som ikke oppfyller standarden, kan fortsette for leveranser i 2027, med kundens samtykke, uansett størrelse.

Tre detaljer betyr mer enn de ser ut til.

Terskelen måles på fjorårets omsetning. Hvor du står i 2027, avhenger av tallet for 2026, som ingen vet nøyaktig før regnskapet er avsluttet. Ligger du i nærheten av 800 000 euro, bør du bygge som om du er over.

Lempelsen slutter på en sendedato. Leser man den første overgangsregelen bokstavelig, dekker den ikke lenger papir og PDF etter 31. desember 2026, selv for arbeid utført i 2026. Er du over terskelen og fakturerer etterskuddsvis, må fakturaen du sender første uke i januar for arbeidet i desember, allerede være strukturert. Bekreft dette med skatterådgiveren din, men ikke planlegg oppstart midt i januar.

Noen fakturaer er utenfor virkeområdet: fakturaer til forbrukere, grensekryssende fakturaer, småbeløpsfakturaer på opptil 250 euro brutto, billetter som regnes som faktura, fakturaer fra Kleinunternehmer og leveranser som er fritatt etter § 4 Nr. 8 til 29 UStG.

Vi kjenner ikke til noe lovforslag som flytter disse datoene. Planlegg som om de står seg.

Mottak har gjeldt siden 2025. Utstedelse er det nye.

Siden 1. januar 2025 har alle tyske virksomheter måttet kunne motta e-fakturaer. Det tyske finansdepartementets ofte stilte spørsmål om e-faktura er klare på hva som kreves: «Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.» En innboks er nok.

Legg merke til én linje i selve § 14: der plikten til e-faktura gjelder, kreves ikke mottakerens samtykke. En tysk bedriftskunde kan ikke avvise den strukturerte fakturaen din.

Utstedelse er et annet problem. Når du mottar, leser et verktøy en fil noen andre har laget. Når du utsteder, er systemet ditt forfatteren: er dataene feil ved kilden, kan ingen senere i kjeden reparere dem, og en faktura som feiler i kundens validering, blir liggende ubetalt.

Hvem som får dette i en oppdatering

Rett ut: er du et lite firma som fakturerer fra DATEV, lexoffice, sevDesk eller en lignende pakke, leverer programvareleverandøren formatet. Sjekk stamdataene (mva-nummer, kundeadresser, bankopplysninger), slå på funksjonen og send en testfaktura. Du trenger ikke et prosjekt, og du trenger ikke et programvareselskap.

Mye av det samme gjelder et utbredt ERP-system som fortsatt ligger nær standard: leverandøren eller partneren din leverer utdataene, og arbeidet består av konfigurasjon og testing.

Resten av denne artikkelen er for selskaper der fakturaene kommer fra kode de eier selv, eller kode ingen lenger vedlikeholder:

faktureringsmotorer i abonnementsplattformer, markedsplasser og forsyningsselskaper, som utsteder fakturaer programmatisk i store volum;
bransjeprogramvare for engroshandel, bygg og anlegg, logistikk eller feltservice, der leverandøren er liten, treg eller borte;
ERP-systemer der fakturautskriften for mange år siden ble skrevet om til egne utskriftsprogrammer, rapportmaler eller en fletting ved månedsslutt.

Formatene: EN 16931, XRechnung og ZUGFeRD

EN 16931 er den europeiske standarden. Den definerer den semantiske modellen for en faktura (feltene, hva de betyr, hvilke som er obligatoriske og forretningsreglene mellom dem) og knytter den til to XML-syntakser, UBL 2.1 og UN/CEFACT CII.

XRechnung er den tyske spesifikasjonen oppå EN 16931, forvaltet av KoSIT: ren XML i én av de to syntaksene, påkrevd av offentlige myndigheter og like gyldig mellom virksomheter. Ifølge KoSITs side om XRechnung har versjon 3.0 vært gjeldende siden 1. februar 2024 og gjelder minst til 31. juli 2027. En foreløpig versjon av 4.0 ble publisert i september 2026, og den endelige utgaven ventes våren 2027. Du går i drift på 3.0 og oppgraderer i løpet av det første året.

ZUGFeRD er en hybrid: en PDF/A-3-fil med CII-XML innebygd. Mennesker leser PDF-en; maskiner leser XML-en. I Frankrike heter det samme formatet Factur-X, og de to er teknisk identiske. FeRD publiserte versjon 2.5.2 den 4. august 2026. ZUGFeRD finnes i profiler (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), og departementets spørsmål og svar godtar ZUGFeRD fra versjon 2.0.1 «mit Ausnahme der Profile MINIMUM und BASIC-WL», altså med unntak av profilene MINIMUM og BASIC-WL.

I en hybridfaktura er det XML-en som teller. Departementet kaller den strukturerte delen «führender Teil», den ledende delen. Er PDF-en og XML-en uenige, er det PDF-en som er feil.

For de fleste tyske B2B-utstedere er det fornuftige utgangspunktet ZUGFeRD i profilen EN 16931, slik at kunder som fortsatt leser fakturaer med øynene, kan fortsette med det, pluss XRechnung for offentlige myndigheter og alle som ber om det. Begge bør komme fra ett internt fakturaobjekt, ikke to kodeløyper.

Hva som må endres i systemet ditt

Fakturaen blir data, ikke et oppsett

Mange eldre systemer bygger fakturaen i utskriftsøyeblikket: tekst satt sammen i en mal, totaler summert inne i rapporten, mva-merknaden et hardkodet avsnitt. Ingenting av det overlever EN 16931. Du trenger et lagret fakturaobjekt som inneholder hvert felt, og både XML-en og PDF-en genereres fra det.

Feltene som som regel mangler eller er feil:

Partsdata. Strukturerte adresser med ISO-landkoder, og et mva-nummer eller skattenummer. Adresseblokker i fritekst må deles opp.
Leveringsdato eller tjenesteperiode, lagret som data og ikke som en setning i toppteksten.
Enheter. Hver mengde trenger en kode fra UN/ECE Recommendation 20 (H87 for stykk, KGM for kilogram, DAY for dag). «Stk.» og «pauschal» må mappes.
Merverdiavgift. Hver linje har en mva-kategori og en sats. Fakturaen har én mva-oppstilling per kombinasjon av kategori og sats, og totalene må gå nøyaktig opp med to desimaler. Systemer som avrunder mva per linje, feiler her.
Tekst om fritak og omvendt avgiftsplikt. Setningen nederst på PDF-en blir en kode for mva-kategori pluss en fritaksgrunn.
Betaling. Betalingsmåte, IBAN og betingelser i strukturert form.
Referanser. Ordrenummeret eller kjøperreferansen som kundens fakturamottak matcher mot. Har du aldri lagret den, begynn å registrere den nå.

Linjer med bare tekst («levering som avtalt») er en vanlig snublestein. I en strukturert faktura er en linje en fakturerbar linje, så slik tekst hører hjemme i en merknad.

Korrigeringer, kreditnotaer og selvfakturering

Departementet er tydelig: der plikten til e-faktura gjelder, må også en korrigering være en e-faktura, med fakturatypen for korrigering. I EN 16931 viser den tilbake til den foregående fakturaen med nummer og utstedelsesdato, så systemet ditt må ta vare på den koblingen som data.

Vær obs på begrepene. I tysk merverdiavgiftsrett er en «Gutschrift» en selvfaktura, utstedt av kunden etter forhåndsavtale (§ 14 Abs. 2 UStG). Det en engelskspråklig kaller en credit note (en prisreduksjon eller en kansellering), er en korrigering. Mange systemer bruker én dokumenttype for begge. Skill dem fra hverandre før du mapper dem, og selvfakturerer du leverandører, behandle de dokumentene som fakturaer systemet ditt utsteder.

En sluttfaktura kan liste opp tidligere delbetalinger i et vedlegg, forutsatt at den strukturerte delen viser til det; departementet bekrefter at dette fortsetter etter 2027.

Validering før noe sendes

KoSIT publiserer en validator med åpen kildekode som kontrollerer XML mot skjemaer og Schematron-regler, med en offentlig konfigurasjon for XRechnung. Den kjører fra kommandolinjen, som HTTP-tjeneste eller som bibliotek. Legg den inn i sendeløpet: hver faktura valideres før den går ut, og en feil havner i en kø som en navngitt person eier, med beskjed om hvilket felt som brøt hvilken regel.

For ZUGFeRD validerer du den innebygde XML-en mot reglene for profilen din, kontrollerer PDF/A-3-beholderen separat og bekrefter at PDF-en viser de samme totalene som XML-en.

Overføring

Loven «sieht keinen bestimmten Weg vor», skriver departementet: den foreskriver ingen bestemt kanal. E-post med filen vedlagt er greit. Det samme er et API, en nedlastingsportal, delt lagring innad i et konsern eller (departementets eget eksempel) en minnepinne. Peppol er ikke påkrevd for innenlands B2B i Tyskland.

Utviklingsarbeidet skjer per kunde: en fakturaadresse, et foretrukket format og en logg over hva som ble sendt hvor. Et nytt forsøk etter en mislykket sending inneholder det samme dokumentet med det samme fakturanummeret. To numre for én leveranse er et skatteproblem, ikke et programvareproblem.

Arkivering

Minst den strukturerte delen må oppbevares «unversehrt in seiner ursprünglichen Form», uendret i sin opprinnelige form, og § 14b UStG setter oppbevaringstiden til åtte år fra utgangen av utstedelsesåret. Lagre nøyaktig de bytene du sendte, med en hash. Ikke planlegg å generere fakturaer på nytt fra databasen senere: da har både dataene og koden endret seg. Det samme gjelder e-fakturaer du mottar.

En plan for oktober til desember 2026

Tretten uker holder for en fokusert utvikling hvis kildedataene er i rimelig stand. Det holder ikke for å bytte ut faktureringssystemet.

Uke 1 og 2: kartlegging og beslutninger. List opp hvert sted en faktura lages, inkludert manuelle kreditnotaer, sluttfakturaer i prosjekter og regnearket for den ene store kunden. Sjekk omsetningen for 2026 mot terskelen. Velg standardformat, og avgjør om dere bygger generatoren selv eller sender fakturadata til API-et hos en e-fakturaleverandør.

Uke 2 til 4: gapanalyse av dataene. Map tre måneder med ekte fakturaer felt for felt mot EN 16931. Marker hva som mangler, hva som må bli en kode og hva som beregnes annerledes. Det er her prosjektets reelle størrelse viser seg.

Uke 4 til 9: utvikling. Fakturaobjektet, mappingen, generering av XML og PDF/A-3, validatoren i sendeløpet, feilkøen og arkivet. Parallelt rydder noen i stamdataene og samler inn fakturaadresser fra kundene.

Uke 9 til 11: kjøring av historikk og pilot. Kjør de siste tre månedenes fakturaer gjennom den nye generatoren og valider hver eneste en. Kjør deretter en pilot med noen villige kunder, og spør om systemene deres leser filene.

Uke 11 til 13: frys og driftsrutiner. Frys endringer i desember. Skriv ned hvem som eier feilkøen, hvordan en korrigering utstedes og hva som skjer når en kunde avviser en faktura. Januarfakturaer for arbeid i desember er allerede omfattet.

Januar 2027. Gå i drift, og følg med på køen daglig gjennom den første månedsavslutningen og den første mva-meldingen.

Gjennom 2027. Planlegg oppgraderingen til XRechnung 4.0 før 3.0 slutter å gjelde, og få eventuelle konsernselskaper under terskelen over før 1. januar 2028.

Starter du sent, kutt i automatiseringen, ikke i gyldigheten til det som sendes ut: automatiser fakturatypene med størst volum først, og send sjeldne dokumenter manuelt gjennom et e-fakturaverktøy i noen uker.

Hvor du får hjelp

Vi bygger koblingen mellom systemet som lager fakturaene dine og formatet loven krever: endringer i datamodellen, mapping, validering, overføring og arkiv, i deres kodebase og sammen med teamet deres. Vår tjeneste for e-fakturaintegrasjon beskriver hvordan slike prosjekter foregår; kommer kravet midt i et ERP-bytte, se ERP-modernisering. Den bredere kalenderen finner du i vår guide til EU digital etterlevelse 2026.

Vi er ingeniører, ikke skatterådgivere: spørsmål om virkeområde hører hjemme hos deres Steuerberater, og vi bygger etter svaret de gir. Fortell oss hva som lager fakturaene deres i dag, og omtrent hvor mange som sendes ut hver måned: skriv til office@c9group.dev.