E-fakturaer: Validering og forståelse af ZUGFeRD, XRechnung, Peppol og EN 16931

Fredag, 15:40: Indkommende fakturabehandling er stået. Ikke fuldstændig – men præcis så meget, at det gør ondt. En del af de indkomne e‑fakturaer går problemfrit igennem, en anden del sidder fast i importstrømmen. Den faglige side siger: „I PDF’en ser alt korrekt ud.“ IT ser i loggen: „Profil ikke tilladt“ og „Business Rule overtrådt“. Derfra bliver det politisk: Indkøb vil kapacitet, regnskab vil sikkerhed, IT ønsker ingen særlogik pr. leverandør.

Den, der i denne situation skal tjekke e‑fakturaer, bemærker hurtigt: ZUGFeRD, XRechnung, Peppol og EN 16931 er ikke ordkløveri, men en afvejning. Afhængigt af hvor strengt I tjekker, flytter indsats og risiko sig – og dermed også arkitekturvalg (central tjekservice vs. plugin i ERP), driftsmæssige spørgsmål (overvågning, opdateringer, fallback) og udrulningsspørgsmål (pilotgrupper, leverandørkommunikation, fejlklasser).

To mål, der i det daglige trækker i hver sin retning

Mål 1: Automatisering med høj gennemstrømning. Mange virksomheder ønsker at indrette fakturamodtagelsen, så strukturerede fakturaer uden mediebrud lander i ERP, workflow og arkiv. Det reducerer manuel registrering og fremskynder godkendelser – men kun hvis dataene er pålidelige.

Mål 2: Kontrol­sikkerhed med efterviselig dokumentation. Samtidig skal det i tvivlstilfælde kunne dokumenteres, hvorfor en faktura blev accepteret eller afvist: hvilket profil, hvilken regel, hvilken version. Det bliver relevant senest, når leverandører reklamerer („I afviste, men hos andre gik det“) eller interne kontrolinstanser kræver en ubrydelig dokumentkæde.

Begge mål er legitime. Konflikten opstår, fordi hver ekstra kontrol reducerer risici, men samtidig kan skabe flere særtilfælde. Det gælder især, hvis leverandører sender forskellige profiler, eller et versionsskifte i specifikationen endnu ikke er nået ud alle steder.

EN 16931: Hvorfor I ved kontrol skal styre semantik i stedet for „filformat“

EN 16931 omtales i praksis ofte som „det XML‑format“. En mere brugbar tilgang er en anden: EN 16931 er det semantiske datamodel for kerneelementerne i en elektronisk faktura – altså betydningen af datafelterne og de tilhørende forretningsregler (Business Rules) for konformitet. Europa‑Kommissionen klassificerer EN 16931 netop sådan: som et semantisk datamodel for kerneelementer inklusive konformitetsregler.^[Quelle]

Den praktiske konsekvens for IT og drift: „XML er velstruktureret“ er kun indgangsdøren. Det afgørende er, om en faktura er semantisk konsistent (sumlogik, skatteangivelser, obligatoriske felter, koder). Og om den foreligger i det rigtige profil – fordi profiler fastlægger, hvilke dele af standarden gælder i hvilken udstrækning.

Det er også vigtigt, at standarder ikke står stille. I normfortegnelser er en opdateret udgave allerede opført som EN 16931‑1:2026.^[Quelle] Det betyder ikke, at I straks skal skifte. Det betyder dog, at jeres kontrol- og driftsmodel bør være opbygget sådan, at regelværk og validatorer kan versionsstyres og opdateres kontrolleret – uden at hele behandlingskæden ved hver opdatering kommer i en kritisk tilstand.

ZUGFeRD og XRechnung: To veje til at opfylde samme forpligtelse i praksis

I Tyskland mødes i mange virksomheder to almindelige udformninger:

• ZUGFeRD som et hybridformat: en PDF/A‑3‑fil, hvori strukturerede fakturadata (XML) er indlejret. FeRD beskriver ZUGFeRD 2.2 eksplicit som en hybridmodel: et synligt bevisdokument plus maskinlæselig XML indlejret i en PDF/A‑3.^[Quelle]
• XRechnung som et rent struktureret format: fokus ligger fuldstændig på maskinbehandlelige data, uden at et PDF som en del følger med.

Afvejningen er mindre ideologisk end operationel: ZUGFeRD er ofte nemmere for fagafdelinger at acceptere, fordi der foreligger et læsbart bevisdokument. Samtidig må PDF’en ikke få jer til at negligere XML‑kontrollen. XRechnung er klart dataorienteret og dermed velegnet til automatisering, men kræver i praksis næsten altid et godt visnings- og kontrolværktøj, som præsenterer indholdet forståeligt.

Retslig ramme: Hvad der fra 2025 tæller som „E‑Rechnung“

For projektplanlægning er én udtalelse særligt virkningsfuld: I den momsmæssige kontekst foreligger der fra 01.01.2025 kun en e‑faktura, hvis den er udstedt/overført/modtaget i et struktureret elektronisk format og muliggør elektronisk behandling.^[Quelle] Et rent PDF uden strukturerede data falder dermed ikke ind under den relevante definition.

BMF nævner desuden XRechnung samt ZUGFeRD fra version 2.0.1 (med profil‑undtagelser) som formater, der grundlæggende opfylder de momsmæssige krav.^[Quelle] Operativt medfører det ikke et spørgsmål om „format‑religion“, men en klar forpligtelse: I skal kunne genkende, kontrollere og efterprøgbart dokumentere profil og version. Ellers er hverken en pålidelig gate mulig eller et solidt bevis for, hvorfor en faktura blev behandlet på en bestemt måde.

Peppol richtig einordnen: Transport und Interoperabilität statt „noch ein Format“

Peppol behandles i dagligdagen ofte som endnu et fakturafomat. Det skaber forkerte forventninger. Peppol er først og fremmest en overførsels‑ og interoperabilitetsramme for strukturerede forretningsdokumenter. For fakturaer er Peppol BIS Billing 3.0 den relevante komponent.

I den officielle BIS‑Billing‑dokumentation er EN‑16931‑konformitet synlig via CustomizationID‑Schemaet (altså via en identifikator, der beskriver profilen/“Customization“‑konteksten). Det er væsentligt, fordi det viser: I Peppol‑miljøet er profil‑ og konformitetsidentifikatorer en del af den maskinelle behandling og ikke blot „nice to have“.^[Quelle]

Konsekvenserne i driften er konkrete: Ud over dokumentkontrol kommer transportrelaterede emner til. Adressering, deltager‑ID’er, tekniske afvisninger, leveringskvitteringer – alt dette giver egne fejlscenarier. Hvis I ikke klassificerer disse fejl adskilt, ender det hele som enten „faktura ødelagt“ hos Finance eller som „Peppol driller“ hos IT.

Leitweg-ID & Peppol-ID: Warum Identifikatoren produktionskritisch sind

Vejledningen til brug af indgangskanalen Peppol for den føderale administration beskriver for eksempel dannelsen af Peppol‑ID ud fra præfikset 0204 og Leitweg‑ID for tilknyttede føderale enheder og placerer Peppol Authority Deutschland hos KoSIT.^[Quelle] Det er en specifik kontekst (Bund). Den overførbare lære for virksomheder er dog klar: Identifikatorer er ikke et periferispørgsmål. De hører hjemme i runbooks, testcases og konfiguration – fordi en „forkert ID“ i drift blokerer på samme måde som en „forkert profil“.

Abwägungskarte: Prüfstrategie nach Nutzen, Aufwand und Risiko

En praktisk anvendelig strategi opdeler kontroller i niveauer. I træffer et bevidst valg om, hvilket niveau der fungerer som en hård gate (afvisning), og hvilket niveau kun udløser en advarsel (afklaring). Følgende kort hjælper med at sammenligne typiske muligheder.

Kontrol af E‑fakturaer: Et kontrolforløb, der holder i driften

Hvis I formulerer kontrolprocessen, så den kan findes i logs, runbooks og ticketsystemer, reduceres senere friktionstab. Følgende forløb er bevidst „driftsorienteret“ og uafhængigt af, om indgangen sker via E‑Mail, upload, API eller Peppol.

1. Registrere indgang: Kanal, tidsstempel, afsender-/modtager-ID’er, tekniske metadata. Det er jeres auditspor.
2. Genkende container: Rent XML? ZUGFeRD (PDF/A‑3 med indlejret XML)? Andet? Ved hybrid: udtræk XML og behandl det som separat kontrolobjekt.
3. Bestemme profil og version: Hvilken variant foreligger (f.eks. EN‑16931-profil, XRechnung-version, Peppol BIS Billing med CustomizationID)? Uden denne info tester I i blinde.
4. Strukturvalidering: Skema-/profilkontrol med logget validator-version og regelsets status. Resultatet skal være reproducerbart.
5. Semantiske regler: Evaluér EN‑16931-forretningsregler og konsistenskontroller (summer/moms/obligatorisk logik).
6. Interne forretningsregler: Stamdata-sammenligning, bestillingshenvisning, duplikattjek, godkendelsesregler, konteringskrav. Disse regler er virksomhedsspecifikke og ændrer sig ofte hyppigere end standarder.
7. Styr resultatet: Automatisk videresende/bogføre, sætte til afklaring eller afvise – inklusive fejlklasse, kort begrundelse og reference til kontrollog.

Grænsen for denne sti: Den afgør ikke automatisk, hvilken regel der hos jer skal være „hård“. Det er en ledelsesbeslutning mellem procesgennemløb og risiko – og bør dokumenteres, så ændringer senere kan spores.

Arkitekturkonsekvenser: Central valideringstjeneste eller validering i målsystemet?

I projektet opstår ofte et tilsyneladende lille spørgsmål: „Hvor validerer vi?“ I praksis afgør det vedligeholdelighed og driftsomkostninger.

Central validering (Service oder Integrationsplattform)

Valideringen kører som en central tjeneste: ensartede regler, ensartede fejlklasser, ét sted for opdateringer. Det gør overvågning lettere (f.eks. afvisningsrate pr. leverandør/profil) og forenkler revision, fordi kontrolresultater gemmes konsistent.

Prisen: I driver en ekstra komponent. Høj tilgængelighed, vedligeholdelsesvinduer, versionsstyring og rollback for regelopdateringer bliver obligatorisk. Til gengæld får I kontrol.

Decentral validering (ERP/DMS-Plugins, Clients)

Her valideres i flere systemer. Det kan se attraktivt ud på kort sigt (»ERP kan det allerede«), men fører ofte til drift: forskellige validator-versioner, forskellige fejlkoder, forskellige undtagelser. Og netop dét er gift for standardisering og support.

For IT-ledelse er en tommelfingerregel nyttig: Hvis flere indgangskanaler og flere målsystemer er i spil, er en central valideringstjeneste ofte den mere robuste langsigtede beslutning. Hvis der kun er én klar vej (ét ERP, én indgang), kan decentral validering være acceptabel – men versionsstyring bør stadig være velordnet.

Hvad i projekter der virkelig koster tid ved validering

Teknisk er indlæsning af XML sjældent problemet. Tid og risiko opstår i kanterne:

• Profil- og versionsmangfoldighed: Uden gennemsigtighed i, hvilke partnere der sender hvilke profiler, bliver hver release et blindflug. Telemetri (Profil/Version pr. indgang) er derfor ikke luksus, men et styringsinstrument.
• Fejloversættelse: Validator-output er ofte for råt til fagafdelinger eller leverandører. De har brug for mapping til forståelige kategorier og handlingsmuligheder.
• Masterdata og processer: Strukturerede fakturaer synliggør masterdata-problemer (manglende kreditorallokering, inkonsistente ordrenumre). Det er godt, men skaber indledningsvis flere afklaringssager.
• Dokumentkæde og arkiv: Til efterprøvelighed er det ikke nok, at „filen er gemt“. Afgørende er: originalen (PDF/XML), kontrolresultat, regelsæt-version, tidspunkt og reference til forretningsprocessen (frigivelse, bogføring).

Rollout uden procesbrud: bølger, fallback og målbare kriterier

En stabil rollout opnås ved ikke at aktivere alt på én gang. En bølgemodel har vist sig værdifuld:

• Pilot: få leverandører og dokumenttyper, meget detaljeret logging, daglig gennemgang af de hyppigste fejlklasser.
• Stabilisering: Skærp reglerne, men med ændringsvinduer og klar kommunikation. Gentagne mønsterfejl afklares målrettet med indkøb/leverandører.
• Skalering: Overfør monitoring til drift (afvisningsrate, afklaringstid, top-regelovertrædelser, andel manuelt).

Planlæg desuden nødberedskab. Hvis en regelopdatering pludselig blokerer mange fakturaer, har I brug for en kontrolleret fallback (f.eks. midlertidig advarselsmodus i stedet for hård afvisning) – med dokumenteret beslutning og efterfølgende efterprøvning. Det er ikke en „blødgører“, men en driftmæssig bremse mod ukontrollerede standsninger.

Tre typiske misforståelser, som I bør afklare tidligt

1) „ZUGFeRD er som før et PDF.“ I processen er den indlejrede XML afgørende. PDF’et er nyttigt for mennesker, men erstatter ikke maskinel validering. Hvis PDF og XML divergerer, skal det være klart, hvilken kilde der gælder i processen.

2) „Peppol gør ikke automatisk alt konform.“ Peppol hjælper ved udveksling og interoperabilitet. Konformitet opstår først gennem korrekte oplysninger og relevante profiler. Levering er ikke lig med validering.

3) „Når validatoren er grøn, kan der bogføres.“ Standardkonformitet er en basis, ikke en fuld procesfrigivelse. Interne regler (bestillingspligt, varemodtagelse, frigivelsesgrænser) forbliver gældende og bør håndteres som en separat fase i stedet for at blive blandet ind i validatorlogikken.

Konklusion: God kontrol aflaster – når den er bygget som et driftssystem

At validere e-fakturaer er ikke et mål i sig selv. Gevinsten opstår, når validering tænkes som et driftssystem: versioneret, observerbart, med klare fejlklasser og en tilbagemeldingskanal, der ikke ender i sagskø. Så bliver standarder som EN 16931, profiler som XRechnung/ZUGFeRD og transportveje som Peppol ikke til et evigt byggeprojekt, men til håndterbare byggesten i jeres proceskæde.

Til dette emne er kontrol af ZUGFeRD og validering af XRechnung også vigtige. Artiklen sætter disse aspekter i en forståelig kontekst og viser, hvad der er vigtigt i den daglige drift.

Drøft projekt eller moderniseringsprojekt med Net-Base.