Kontrollere e‑fakturaer: forstå ZUGFeRD, XRechnung, Peppol og EN 16931

Fredag, 15:40: Mottaket av fakturaer har stoppet. Ikke fullstendig – men akkurat sånn at det gjør vondt. En del av de innkommende e‑fakturaene går gjennom uten problemer, en annen del sitter fast i importløpet. Fagavdelingen sier: „I PDF-en ser alt korrekt ut.“ IT ser i loggen: „Profil ikke tillatt“ og „Business Rule brutt“. Derfra blir det politisk: Innkjøp vil ha gjennomstrømning, regnskap vil ha sikkerhet, IT vil ikke ha spesiallogikk per leverandør.

Den som i en slik situasjon kontrollere e‑fakturaer skal, merker raskt: ZUGFeRD, XRechnung, Peppol og EN 16931 er ikke ordkløveri, men en avveining. Avhengig av hvor strengt du kontrollerer, endrer innsats og risiko seg – og dermed også arkitekturvalg (sentral sjekketjeneste vs. plugin i ERP), driftsmessige spørsmål (monitoring, oppdateringer, fallback) og utrullingsspørsmål (pilotgrupper, leverandørkommunikasjon, feiltyper).

To mål som i praksis trekker i hver sin retning

Mål 1: Automatisering med høy gjennomstrømning. Mange virksomheter ønsker å organisere fakturamottaket slik at strukturerte fakturaer uten mediebrudd havner i ERP, Workflow og arkiv. Det reduserer manuell registrering og akselererer godkjenninger – men bare dersom dataene er pålitelige.

Mål 2: Revisionssikkerhet med etterprøvbar dokumentasjon. Samtidig må det ved behov kunne dokumenteres hvorfor en faktura ble godkjent eller avvist: hvilket profil, hvilken regel, hvilken versjon. Dette blir relevant senest når leverandører klager («dere avviste, men hos andre gikk det») eller interne kontroller etterspør en ren dokumentkjede.

Begge mål er legitime. Konflikten oppstår fordi hver ekstra kontroll visserlig reduserer risiko, men samtidig kan skape flere særtilfeller. Dette gjelder særlig når leverandører sender forskjellige profiler eller et versjonsskifte i spesifikasjonen ennå ikke har nådd alle.

EN 16931: Hvorfor man bør håndtere semantikk i stedet for „Dateiformat“ ved validering

EN 16931 blir i prosjektlivet gjerne omtalt som «det XML-formatet». En mer praktisk nyttig tilnærming er en annen: EN 16931 er det semantiske datamodellen for kjerneelementene i en elektronisk faktura – altså betydningen av datafelt og tilhørende forretningsregler (Business Rules) for konformitet. EU-kommisjonen klassifiserer EN 16931 nettopp slik: som et semantisk datamodell for kjerneelementene inkludert konformitetsregler.^[Kilde]

Den praktiske konsekvensen for IT og drift: «XML er velformet» er kun inngangsdøren. Avgørende er om en faktura er semantisk konsistent (sumlogikk, avgiftsopplysninger, obligatoriske felt, koder). Og om den foreligger i riktig profil – for profiler fastsetter hvilke deler av standarden som gjelder i hvilken utgave.

Det er også viktig å være klar over at standarder ikke fryser. I normoversikter er allerede en oppdatert utgave listet som EN 16931‑1:2026.^[Kilde] Det betyr ikke at dere må bytte umiddelbart. Det betyr derimot at deres validerings- og driftsmodell bør være bygget slik at regelverk og validatorer kan versjoneres og oppdateres kontrollert – uten at hele behandlingen settes «på kanten» ved hver oppdatering.

ZUGFeRD og XRechnung: To veier for å gjøre samme forpliktelse praktisk

I Tyskland møtes i mange virksomheter to vanlige varianter:

• ZUGFeRD som hybridformat: en PDF/A‑3‑fil der strukturerte fakturadata (XML) er innebygd. FeRD beskriver ZUGFeRD 2.2 eksplisitt som en hybrid modell: lesbart bilag pluss maskinlesbart XML i en PDF/A‑3.^[Kilde]
• XRechnung som rent strukturert format: fokuset ligger fullstendig på maskinbehandlelige data, uten at en PDF følger med som komponent.

Vurderingen er mindre ideologisk enn operativ: ZUGFeRD er ofte lettere for fagavdelinger å akseptere fordi det finnes et lesbart bilag. Samtidig må ikke PDF-en friste til å forsømme XML-valideringen. XRechnung er klart dataorientert og dermed godt egnet for automatisering, men krever i praksis nesten alltid et godt visnings- og valideringsverktøy som gjør innholdet forståelig.

Rettslig ramme: Hva som fra 2025 regnes som „E‑Rechnung“

Für die Projektplanung ist eine Aussage besonders wirksam: Im umsatzsteuerlichen Kontext liegt ab 01.01.2025 nur dann eine E‑faktura vor, wenn sie in einem strukturierten elektronischen Format ausgestellt/übermittelt/empfangen wird und elektronische Verarbeitung ermöglicht.^[Kilde] Ein reines PDF ohne strukturierte Daten fällt damit nicht in die Definition, die hier relevant ist.

Das BMF nennt außerdem XRechnung sowie ZUGFeRD ab Version 2.0.1 (mit Profil-Ausnahmen) als Formate, die grundsätzlich die umsatzsteuerlichen Anforderungen erfüllen.^[Kilde] Operativ ergibt sich daraus keine „Format-Religionsfrage“, sondern eine klare Pflicht: Sie müssen Profil und Version erkennen, prüfen und nachvollziehbar dokumentieren. Sonst ist weder ein verlässliches Gate möglich noch ein sauberer Nachweis, warum eine Rechnung so behandelt wurde.

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

Peppol wird im Tagesgeschäft oft wie ein weiteres Rechnungsformat behandelt. Das führt zu falschen Erwartungen. Peppol ist in erster Linie ein Übertragungs- und Interoperabilitätsrahmen für strukturierte Geschäftsdokumente. Für Rechnungen ist Peppol BIS Billing 3.0 der relevante Baustein.

In der offiziellen BIS-Billing-Dokumentation ist die EN‑16931‑Konformität über das CustomizationID-Schema sichtbar (also über eine Kennung, die das Profil/den „Customization“-Kontext beschreibt). Das ist wichtig, weil es zeigt: Im Peppol-Umfeld sind Profil- und Konformitätskennungen Teil der maschinellen Auswertung und nicht nur „nice to have“.^[Kilde]

Was daraus im Betrieb folgt, ist sehr handfest: Neben der Dokumentprüfung kommen Transportthemen hinzu. Adressierung, Teilnehmer-IDs, technische Ablehnungen, Zustellnachweise – all das erzeugt eigene Fehlerbilder. Wenn Sie diese Fehler nicht getrennt klassifizieren, landet am Ende alles als „Rechnung kaputt“ bei Finance oder als „Peppol spinnt“ bei IT.

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

Der Leitfaden zur Nutzung des Eingangskanals Peppol für die Bundesverwaltung beschreibt beispielsweise die Bildung der Peppol-ID aus dem Präfix 0204 und der Leitweg-ID für angebundene Bundesstellen und verortet die Peppol Authority Deutschland bei KoSIT.^[Kilde] Das ist ein spezifischer Kontext (Bund). Die übertragbare Lehre für Unternehmen ist trotzdem klar: Identifikatoren sind kein Randthema. Sie gehören in Runbooks, Testfälle und Konfiguration – weil „falsche ID“ im Betrieb genauso blockiert wie „falsches Profil“.

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

Eine praxistaugliche Strategie trennt Prüfungen in Stufen. Sie entscheiden bewusst, welche Stufe als hartes Gate wirkt (Ablehnung) und welche Stufe nur eine Warnung auslöst (Klärung). Die folgende Karte hilft, typische Optionen zu vergleichen.

Kontroll av E‑fakturaer: Et kontrollløp som tåler drift

Hvis dere formulerer kontrollprosessen slik at den kan gjenfinnes i logger, runbooks og ticketsystemer, reduseres senere friksjonstap. Følgende løp er bevisst „driftsorientert“ og uavhengig av om inngangen skjer via e‑post, opplasting, API eller Peppol.

1. Registrere inngang: Kanal, tidsstempel, avsender-/mottaker-ID-er, tekniske metadata. Dette er deres revisjonsspor.
2. Gjenkjenne container: Rent XML? ZUGFeRD (PDF/A‑3 med innebygd XML)? Annet? Ved hybrid: ekstraher XML og behandl det som et eget kontrollobjekt.
3. Bestemme profil og versjon: Hvilken variant foreligger (f.eks. EN‑16931-profil, XRechnung-versjon, Peppol BIS Billing med CustomizationID)? Uten denne infoen sjekker dere i blinde.
4. Strukturvalidering: Skjema-/profilkontroll med protokollført validatorversjon og regelsett-stand. Resultatet må være reproduserbart.
5. Semantiske regler: Evaluere EN‑16931-forretningsregler og konsistenskontroller (summer/moms/påkrevd logikk).
6. Interne forretningsregler: Samsvar mot stamdata, bestillingsreferanse, duplikatsjekk, godkjenningsregler, kontoplankrav. Disse reglene er selskapsspesifikke og endres ofte hyppigere enn standardene.
7. Styre resultat: Automatisk videreformidle/bokføre, sette til avklaring eller avvise – inklusive feilklasse, kort begrunnelse og referanse til kontrollloggen.

Grensen for denne tilnærmingen: Den sier ikke automatisk hvilken regel som må være «streng» hos dere. Det er en ledelsesbeslutning mellom prosessgjennomstrømning og risiko – og bør dokumenteres slik at endringer kan spores senere.

Arkitekturkonsekvenser: Sentral valideringstjeneste eller validering i målsystemet?

I prosjektet oppstår ofte et tilsynelatende lite spørsmål: «Hvor validerer vi?» I praksis avgjør dette vedlikeholdbarhet og driftskostnader.

Sentral validering (tjeneste eller integrasjonsplattform)

Valideringen kjøres som en sentral tjeneste: enhetlige regler, enhetlige feilkategorier, ett sted for oppdateringer. Det gjør overvåking enklere (f.eks. avvisningsrate per leverandør/profil) og forenkler revisjoner, fordi kontrollresultatene lagres konsistent.

Prisen: Dere må drifte en ekstra komponent. Høy tilgjengelighet, vedlikeholdsvinduer, versjonshåndtering og rollback ved regeloppdateringer blir obligatorisk. Til gjengjeld får dere kontroll.

Desentralisert validering (ERP/DMS-Plugins, klienter)

Her valideres det i flere systemer. Dette kan virke fristende kortsiktig («ERP kan det allerede»), men fører ofte til drift: ulike validator-versjoner, ulike feilmeldinger, ulike unntak. Og nettopp dette er gift for standardisering og support.

For IT-ledelsen er en tommelfingerregel nyttig: Hvis flere inngangskanaler og flere målsystemer er involvert, er en sentral valideringstjeneste ofte et mer robust langtidsvalg. Hvis det bare finnes én klar vei (ett ERP, en inngang), kan desentralisert validering være akseptabel – men da bør versjonshåndtering likevel være tydelig regulert.

Hva som i prosjekter virkelig koster tid ved validering

Teknisk sett er innlesing av XML sjelden problemet. Tid og risiko oppstår i grenseflatene:

• Profil- og versjonsmangfold: Uten transparens om hvilke partnere som sender hvilke profiler blir hver release en blindflyvning. Telemetri (profil/versjon per inngang) er derfor ikke luksus, men et styringsinstrument.
• Feiloversettelse: Validatorutdata er ofte for rå for fagavdelinger eller leverandører. De trenger mapping til forståelige kategorier og handlingsalternativer.
• Stamdata og prosesser: Strukturerte fakturaer gjør stamdataproblemer synlige (manglende kreditor-tilordning, inkonsistente bestillingsnumre). Det er bra, men skaper i starten flere avklaringssaker.
• Bilagskjede og arkiv: For etterprøvbarhet holder det ikke med «Datei abgelegt». Avgørende er: originalen (PDF/XML), kontrollresultat, regelset-versjon, tidspunkt og kobling til forretningsprosessen (godkjenning, bokføring).

Rollout uten prosessbrudd: bølger, fallback og målbare kriterier

En stabil utrulling oppstår når dere ikke aktiverer alt i produksjon samtidig. En bølgevis tilnærming har vist seg å fungere:

• Pilot: få leverandører og bilagstyper, svært detaljert logging, daglig gjennomgang av de hyppigste feilkategoriene.
• Stabilisering: skjerpe reglene, men med endringsvinduer og klar kommunikasjon. Gjentakende mønsterfeil bør avklares målrettet med innkjøp/leverandører.
• Skalering: overføre overvåking til løpende drift (avvisningsrate, avklaringsvarighet, topp regelbrudd, andel manuelt).

Planlegg også for beredskapsdrift. Hvis en regeloppdatering plutselig blokkerer mange fakturaer, trenger dere en kontrollert fallback (f.eks. midlertidig advarselsmodus i stedet for streng avvisning) – med dokumentert beslutning og senere etterkontroll. Dette er ikke en „mykgjører“, men en driftbrems mot ukontrollerte stopp.

Tre typiske misforståelser dere bør avklare tidlig

1) „ZUGFeRD ist wie früher ein PDF.“ I prosessen er den innebygde XML det som teller. PDF‑et er nyttig for mennesker, men erstatter ikke maskinell kontroll. Når PDF og XML avviker, må det være klart hvilken kilde som gjelder i prosessen.

2) „Peppol macht automatisch alles konform.“ Peppol hjelper ved utveksling og interoperabilitet. Konformitet oppnås først gjennom korrekte innhold og passende profiler. Levering er ikke det samme som validering.

3) „Wenn der Validator grün ist, kann gebucht werden.“ Standardkonformitet er et grunnlag, ikke en fullstendig prosessfrigivelse. Interne regler (bestillingsplikt, varemottak, godkjenningsgrenser) består og bør håndteres som egen nivå i stedet for å blandes inn i validatorlogikken.

Avslutning: God kontroll avlaster – når den er bygget som et driftsprosess

E‑fakturaer skal ikke kontrolleres som et mål i seg selv. Nytten oppstår når validering tenkes som et driftsmessig system: versjonert, observerbart, med klare feilkategorier og en tilbakemeldingskanal som ikke ender i en sakskø. Da blir standarder som EN 16931, profiler som XRechnung/ZUGFeRD og transportveier som Peppol ikke en permanent byggeplass, men håndterbare byggeklosser i prosesskjeden deres.

Für dieses Thema sind auch Zugferd Prüfen und Xrechnung Validieren wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.