ZUGFeRD-efterlevnad i Tyskland: profiler, krav och ERP-integration

24 augusti 2026

10 min läsning

Sammanfatta med AI

De tyska kraven på e-fakturering kan få en välbekant faktureringsprocess att plötsligt kännas som ett betydligt större IT-projekt. Om ditt ERP-system redan fungerar bra är det sista du vill göra att bygga om det bara för att stödja ett annat fakturaformat.

Därför skulle jag börja med det du redan har. Vissa ERP-system kan generera strukturerade e-fakturor via inbyggda moduler, API:er eller landsspecifika komponenter. Andra producerar fortfarande vanliga PDF-filer och kräver ett extra konverteringssteg. När du väl vet hur ditt system fungerar blir det mycket enklare att välja en ZUGFeRD-konfiguration som uppfyller kraven utan att behöva göra onödiga ändringar i själva faktureringsprocessen.

Dmitry Nazarevich

Teknikchef

Dmitry är en visionär arkitekt som överbryggar klyftan mellan rå innovation och kommersiell genomförbarhet. Han övervakar företagets tekniska färdplan och ser till att varje lösning byggs på en stack som löser omedelbar affärssmärta.

Visa profil

Vad är ZUGFeRD?

ZUGFeRD är ett hybridformat för elektroniska fakturor. En ZUGFeRD-faktura kombinerar ett läsbart PDF/A-3-dokument med inbäddad strukturerad XML-kod som bokföringsprogram kan bearbeta direkt.

XML-filen innehåller definierade fakturauppgifter, såsom information om säljare och köpare, fakturarader, taxe-koder, totalsummor, betalningsuppgifter och referenser. Vid elektronisk fakturering i Tyskland är den valda ZUGFeRD-versionen och -profilen lika viktig som själva filen.

Vilken ZUGFeRD-profil bör du använda?

ZUGFeRD har fem huvudprofiler samt referensprofilen XRECHNUNG, och dessa skiljer sig åt både vad gäller datainnehåll och tillämpning inom regelverket. För en typisk tysk B2B-implementering baserad på EN 16931 brukar jag vanligtvis börja med EN 16931-profilen och sedan övergå till EXTENDED när affärsprocessen kräver ytterligare strukturerade data.

Profil	Vad det omfattar	Situationen i Tyskland
MINIMUM	Grundläggande uppgifter om köpare, säljare, totalsummor och skatt	Erkänns inte som en fullständig faktura enligt UStG
BASIC WL	Redovisningsinformation på rubriknivå utan fakturarader	Erkänns inte som en fullständig faktura enligt UStG
GRUNDLÄGGANDE	Del av EN 16931 för enklare fakturor	Erkänd som en fullständig UStG-faktura
EN 16931, tidigare COMFORT	Fullständig fakturamall enligt EN 16931	Erkänd som en fullständig UStG-faktura och det främsta valet för standardiserad e-fakturering i enlighet med EU-reglerna
UTÖKAD	EN 16931 samt ytterligare data för mer komplexa affärsprocesser	Erkänd som en fullständig UStG-faktura
BERÄKNING	Referensprofil baserad på kraven för KoSIT XRechnung	Detta är främst relevant där kraven för XRechnung gäller, särskilt inom B2G

FeRD rekommenderar uttryckligen EN 16931 för elektroniska fakturor som uppfyller EU:s krav. Det tyska federala finansministeriet anger också att ZUGFeRD från version 2.0.1 uppfyller de tyska kraven för elektroniska fakturor, med undantag för MINIMUM och BASIC-WL.

Därför bör valet av profil göras i ett tidigt skede. Att till exempel välja ”MINIMUM” eftersom det innehåller de grundläggande beloppen innebär inte att dokumentet uppfyller kraven för en tysk e-faktura.

Vem måste följa reglerna i Tyskland?

Tyskland inför e-fakturering inom B2B-segmentet i etapper.

Från och med den 1 januari 2025 måste berörda tyska företag ha den tekniska kapaciteten att ta emot e-fakturor för transaktioner som omfattas av B2B-reglerna.
Fram till den 31 december 2026 tillåter övergångsbestämmelserna fortfarande pappersfakturor och, med mottagarens samtycke, andra elektroniska format såsom vanliga PDF-filer.
Under 2027 förlängs övergångsperioden för emittenter vars omsättning föregående år inte överstiger 800 000 euro. Vissa EDI-avtal omfattas också av en övergångsperiod som sträcker sig fram till och med 2027.
Den 1 januari 2028 löper den allmänna övergångsperioden ut för inhemsk B2B-fakturering som omfattas av bestämmelserna.

Jag skulle inte betrakta detta som en regel som innebär att varje tysk faktura måste följa ZUGFeRD. Tillämpningsområdet beror fortfarande på transaktionen. B2C-fakturor, vissa undantagna transaktioner, fakturor med lågt värde och andra specialfall kan omfattas av andra regler.

Varför vanliga PDF-fakturor inte längre räcker till

En vanlig PDF-fil innehåller främst information avsedd för mänsklig läsning. En strukturerad e-faktura innehåller dessutom maskinläsbara fält som är definierade för bokföringsprogram.

En person kan se:

En strukturerad faktura specificerar de underliggande beloppen så att programvaran kan avgöra vilket belopp som utgör beskattningsunderlaget, mervärdesskatten, bruttosumman och det belopp som ska betalas.

Denna skillnad gör det möjligt för ERP- och redovisningssystem att bearbeta fakturor utan att behöva rekonstruera deras innebörd utifrån PDF-texten eller sidlayouten.

Kontrollera först vad ditt ERP-system redan stöder

Innan du inför en konverterare bör du kontrollera om ERP-systemet redan erbjuder landsspecifika funktioner för e-fakturering, API:er eller dokumentmoduler.

Det finns vanligtvis tre vägar:

I SAP-miljöer kan man till exempel utnyttja landspecifika funktioner via SAP Document and Reporting Compliance. Andra ERP-system eller anpassade system kan kräva mellanprogramvara eller en separat konverteringstjänst.

En fristående konverterare är därför det mest lämpliga alternativet när lämpligt inbyggt stöd saknas eller när en ändring av kärnprogrammet för fakturering skulle medföra onödiga projektrisker.

Hur en fristående PDF-till-ZUGFeRD-konverterare kan vara till hjälp

För en PDF-baserad process kan konverteringsflödet se ut så här:

I den mån det är möjligt är strukturerade ERP-data en bättre källa än värden som rekonstruerats utifrån PDF-filen. JSON, XML, CSV, databasposter eller API-data bevarar betydelsen av fakturafälten och minskar risken för tolkningsfel.

Anpassa fakturauppgifterna till EN 16931-modellen

För att skapa XML-filen krävs en korrekt semantisk mappning. Konverteraren måste identifiera vad varje fakturavärde står för och placera det i motsvarande strukturerat fält.

Ett pris är enkelt. Andra fält kräver mer sammanhang: säljar- och köparidentifierare, fakturatyp, skattekategorier, enhetskoder, avdrag, avgifter, referenser, betalningsvillkor, leveransinformation och momsspecifikationer kan alla påverka XML-koden.

Fakturabelopp	Begrepp enligt EN 16931
Fakturanummer	BT-1
Utgivningsdatum	BT-2
Valuta	BT-5
Säljarens namn	BT-27
Kundens namn	BT-44
Nettobelopp per rad	BT-131
Totalt exklusive moms	BT-109
Moms totalt	BT-110
Totalt inklusive moms	BT-112
Belopp som ska betalas	BT-115

Det mesta av implementeringsarbetet handlar om denna datamodell och valideringen kring den. Systemet måste korrekt mappa källdata, skapa giltig XML, paketera den i PDF/A-3 och se till att båda representationerna är konsekventa.

Validera i lager

Jag skulle gå igenom fakturan i flera steg:

Till exempel:

Konverteraren bör beräkna och jämföra dessa värden istället för att kopiera formaterade strängar från PDF-filen.

Jag skulle också kontrollera den färdiga PDF/A-3-filen efter att XML-koden har bäddats in. Paketeringen förändrar dokumentet, så att det inte räcker att endast kontrollera käll-PDF:en för att säkerställa att det slutliga resultatet är korrekt.

Innan jag skickar iväg skulle jag jämföra fakturanummer, datum, parter, valuta, radbelopp, skatteuppgifter, totalsummor, betalningsuppgifter och referenser mellan PDF- och XML-filerna.

Behöver du lägga till e-fakturering i ditt ERP-system?

Vi kan hjälpa er att utvärdera er nuvarande ERP-lösning, fastställa ett lämpligt flöde för fakturauppgifter och införa e-fakturering i de system ni redan använder.

Checklista för efterlevnad av ZUGFeRD

Använd en ZUGFeRD-version som stöds och rätt profil.
Följ kraven i EN 16931 för den valda fakturatypen.
Ange alla nödvändiga fakturauppgifter i den strukturerade XML-filen.
Skapa ett giltigt PDF/A-3-dokument.
Bädda in XML-koden korrekt i PDF-filen.
Se till att värdena i PDF- och XML-fakturor är enhetliga.
Validera XSD-scheman och Schematron-affärsregler.
Kontrollera värdena i kodlistan för valuta, enheter, momsgrupper och betalningssätt.
Beräkna om moms, summor, datum och betalningsbelopp.
Avvisa fakturor som inte klarar de obligatoriska valideringskontrollerna.
Spara den elektroniska fakturan i enlighet med de tyska kraven på arkivering.
Testa filerna med kundernas redovisningssystem innan de tas i drift.

Mer om detta ämne

Tjänster

KSeF:s integrationstjänster – efterlevnad av reglerna för e-fakturering

Blogg

Automatiserad fakturahantering

Blogg

SAP e-fakturering: efterlevnad av dokument och rapportering

Blogg

Migrering av ERP-data: bästa praxis, strategi och verktyg

Kontakta oss

Boka ett samtal eller fyll i formuläret nedan så återkommer vi till dig när vi har behandlat din förfrågan.

Namn

Företag

E-post

Telefon

Meddelande

Skicka ett röstmeddelande till oss

Bifoga dokument

Ladda upp filen

Du kan bifoga 1 fil på upp till 2 MB. Giltiga filformat: pdf, jpg, jpeg, png.

Genom att klicka på Skicka samtycker du till att Innowise behandlar dina personuppgifter enligt våra Integritetspolicy för att förse dig med relevant information. Genom att lämna ditt telefonnummer samtycker du till att vi kan kontakta dig via röstsamtal, SMS och meddelandeappar. Samtals-, meddelande- och datataxor kan gälla.

Du kan också skicka oss din förfrågan

till contact@innowise.com

Vad händer härnäst?

När vi har tagit emot och behandlat din förfrågan återkommer vi till dig för att beskriva dina projektbehov och undertecknar en NDA för att säkerställa sekretess.

Efter att ha undersökt dina önskemål, behov och förväntningar kommer vårt team att ta fram ett projektförslag förslag med arbetsomfattning, teamstorlek, tids- och kostnadsberäkningar.

Vi ordnar ett möte med dig för att diskutera erbjudandet och fastställa detaljerna.

Slutligen undertecknar vi ett kontrakt och börjar arbeta med ditt projekt direkt.