Granska e‑fakturor: förstå ZUGFeRD, XRechnung, Peppol och EN 16931

Fredag, 15:40: Inkommande fakturor står stilla. Inte helt – men precis så att det gör ont. En del av de inkommande e‑fakturorna går igenom utan problem, en annan del fastnar i importkedjan. Fackavdelningen säger: „I PDF:en ser allt korrekt ut.“ IT ser i loggen: „Profil inte tillåten“ och „Business Rule överträdd“. Därifrån blir det politiskt: Inköp vill ha genomströmning, redovisning vill ha säkerhet, IT vill ingen speciallogik per leverantör.

Den som i denna situation ska granska e‑fakturor märker snabbt: ZUGFeRD, XRechnung, Peppol och EN 16931 är ingen ordlek utan en avvägning. Beroende på hur strikt ni kontrollerar förskjuts arbetsinsats och risk – och därmed också arkitekturval (central valideringstjänst vs. plugin i ERP), driftsfrågor (övervakning, uppdateringar, fallback) och rolloutfrågor (pilotgrupper, leverantörskommunikation, felklasser).

Två mål som drar åt olika håll i vardagen

Mål 1: Automatisering med hög genomströmning. Många företag vill utforma mottagandet av fakturor så att strukturerade fakturor utan medierbrytningar landar i ERP, arbetsflöde och arkiv. Det minskar manuell inmatning och påskyndar godkännanden – men endast om data är tillförlitliga.

Mål 2: Kontrollsäkerhet med eftervisbar dokumentation. Samtidigt måste det vid behov gå att redovisa varför en faktura accepterades eller avvisades: vilket profil, vilken regel, vilken version. Det blir särskilt relevant när leverantörer reklamerar („ni avslog, men hos andra gick det“) eller när intern revision kräver en spårbar dokumentkedja.

Båda målen är legitima. Konflikten uppstår eftersom varje ytterligare kontroll visserligen minskar risker, men också kan skapa fler undantagsfall. Detta gäller särskilt när leverantörer skickar olika profiler eller när en versionsändring i specifikationen ännu inte nått alla parter.

EN 16931: Varför ni vid granskning bör hantera semantik istället för „Dateiformat“

EN 16931 kallas i projektvardagen ofta för „XML-formatet“. En mer praktiskt användbar syn är en annan: EN 16931 är den semantiska datamodellen för kärnelementen i en elektronisk faktura – alltså betydelsen av datafält och de tillhörande affärsreglerna (Business Rules) för konformitet. Europeiska kommissionen klassificerar EN 16931 precis så: som en semantisk datamodell för kärnelementen inklusive konformitetsregler.^[Quelle]

Den praktiska slutsatsen för IT och drift: „XML är välformat“ är bara entrén. Avgörande är om en faktura är konsekvent i sin betydelse (sumlogik, skatteuppgifter, obligatoriska fält, koder). Och om den föreligger i rätt profil – eftersom profiler fastställer vilka delar av standarden i vilken utsträckning gäller.

Viktigt är också att standarder inte är statiska. I normförteckningar finns redan en uppdaterad utgåva listad som EN 16931‑1:2026.^[Quelle] Det betyder inte att ni måste byta omedelbart. Det innebär dock att er gransknings- och driftsmodell bör vara utformad så att regelverk och validatorer kan versioneras och uppdateras kontrollerat – utan att hela bearbetningen hamnar „på kanten“ vid varje uppdatering.

ZUGFeRD und XRechnung: Zwei Wege, dieselbe Pflicht praktisch zu machen

I Tyskland möter i många företag två vanliga varianter varandra:

• ZUGFeRD som ett hybridformat: en PDF/A‑3-fil där strukturerade fakturadata (XML) är inbäddade. FeRD beskriver ZUGFeRD 2.2 uttryckligen som en hybridmodell: ett läsbart kvitto plus maskinläsbart XML i en PDF/A‑3.^[Quelle]
• XRechnung som helt strukturerat format: fokus ligger helt på maskinläsbara data, utan att en PDF följer med som delkomponent.

Avvägningen är mindre ideologisk än operativ: ZUGFeRD är ofta lättare för verksamheten att acceptera eftersom ett läsbart kvitto finns. Samtidigt får inte PDF:en leda till att XML-granskningen försummas. XRechnung är tydligt dataorienterat och därmed bra för automatisering, men kräver i praktiken nästan alltid ett bra visnings- och kontrollverktyg som presenterar innehållet begripligt.

Rättslig ram: Vad som ab 2025 als „E‑Rechnung“ zählt

I momsavseende föreligger från och med 01.01.2025 en e‑faktura endast om den utfärdas/överförs/mottas i ett strukturerat elektroniskt format och möjliggör elektronisk bearbetning.^[Källa] En ren PDF utan strukturerade data omfattas därmed inte av den definition som är relevant här.

BMF nämner dessutom XRechnung samt ZUGFeRD från och med version 2.0.1 (med profilundantag) som format som i princip uppfyller momsrelaterade krav.^[Källa] Operativt leder detta inte till en „format-religionsfråga“, utan till en tydlig skyldighet: Ni måste identifiera, kontrollera och spårbart dokumentera profil och version. Annars är varken en pålitlig avvisningskontroll möjlig eller en tydlig dokumentation som visar varför en faktura hanterades på ett visst sätt.

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

Peppol behandlas i det dagliga arbetet ofta som ytterligare ett fakturaformat. Det ger upphov till felaktiga förväntningar. Peppol är i första hand en överförings- och interoperabilitetsram för strukturerade affärsdokument. För fakturor är Peppol BIS Billing 3.0 den relevanta komponenten.

I den officiella BIS-Billing-dokumentationen syns EN‑16931‑konformiteten via CustomizationID-Schemat (det vill säga via en identifierare som beskriver profil/“Customization“-kontexten). Det är viktigt eftersom det visar: I Peppol-miljön är profil- och konformitetsidentifieringar del av den maskinella bearbetningen och inte bara „nice to have“.^[Källa]

Vad detta innebär i drift är konkret: Utöver dokumentkontrollen tillkommer transportfrågor. Adressering, deltagar‑ID:n, tekniska avslag, leveransbevis – allt detta ger upphov till egna felmönster. Om ni inte klassificerar dessa fel separat hamnar i slutändan allt som „Rechnung kaputt“ hos Finance eller som „Peppol spinnt“ hos IT.

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

Vägledningen för användning av ingångskanalen Peppol för Bundesverwaltung beskriver till exempel bildandet av Peppol-ID från prefixet 0204 och Leitweg-ID för anslutna federala myndigheter och placerar Peppol Authority Deutschland hos KoSIT.^[Källa] Det är en specifik kontext (förbundsnivå). Den överförbara lärdomen för företag är ändå klar: Identifierare är inget sidospår. De hör hemma i Runbooks, testfall och konfiguration – eftersom „fel ID“ i drift blockerar på samma sätt som „fel profil“.

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

En praktisk strategi delar upp kontroller i nivåer. Ni beslutar medvetet vilken nivå som fungerar som ett hårt gate (avvisning) och vilken nivå som endast utlöser en varning (förklaring). Följande karta hjälper till att jämföra typiska alternativ.

Granskning av E‑fakturor: En kontrollväg som står sig i driften

Om ni formulerar granskningsprocessen så att den går att hitta i loggar, runbooks och ärendesystem minskar den senare friktionen. Följande väg är medvetet „driftsorienterad“ och oberoende av om mottagningen sker via e‑post, uppladdning, API eller Peppol.

1. Registrera mottagning: Kanal, tidsstämpel, avsändar-/mottagar‑ID:n, tekniska metadata. Det är ert revisionsspår.
2. Känna igen container: Rent XML? ZUGFeRD (PDF/A‑3 med inbäddat XML)? Annat? Vid hybridfall: extrahera XML och behandla det som separat kontrollobjekt.
3. Bestäm profil och version: Vilken variant föreligger (t.ex. EN‑16931‑profil, XRechnung‑version, Peppol BIS Billing med CustomizationID)? Utan denna information kontrollerar ni i blindo.
4. Strukturvalidering: Schema-/profilkontroll med protokollförd validatorversion och regelsets status. Resultatet måste vara reproducerbart.
5. Semantiska regler: Utvärdera EN‑16931‑affärsregler och konsistenskontroller (summor/moms/obligatorisk logik).
6. Interna affärsregler: Stamdataavstämning, beställningskoppling, dubblettkontroll, godkännanderegler, konteringskrav. Dessa regler är företagspecifika och ändras ofta oftare än standarder.
7. Styr resultatet: Automatiskt vidarebefordra/bokföra, sätta i klargöring eller avvisa – inklusive felklass, kort motivering och referens till kontrolloggen.

Gränsen för denna väg: Den avgör inte automatiskt vilken regel som måste vara ”hård” hos er. Det är ett ledningsbeslut mellan processtakt och risk – och bör dokumenteras så att förändringar kan följas i efterhand.

Arkitekturkonsekvenser: Central valideringstjänst eller validering i målsystemet?

I projekt uppstår ofta en till synes liten fråga: „Var validerar vi?“ I praktiken avgör den frågan underhållbarhet och driftkostnader.

Central validering (tjänst eller integrationsplattform)

Valideringen körs som en central tjänst: enhetliga regler, enhetliga felklasser, en plats för uppdateringar. Det förenklar övervakning (t.ex. avvisningskvot per leverantör/profil) och underlättar revisioner eftersom granskningsresultat sparas konsekvent.

Priset: ni måste drifta en extra komponent. Hög tillgänglighet, underhållsfönster, versionering och rollback för regeluppdateringar blir obligatoriskt. I gengäld får ni kontroll.

Decentral validering (ERP/DMS-Plugins, Clients)

Här valideras i flera system. Det kan verka attraktivt på kort sikt („ERP kann das schon“), men leder ofta till drift: olika validator-versioner, olika felmeddelanden, olika undantag. Och just det är förödande för standardisering och support.

För IT-ledning är en tumregel användbar: Om flera ingångskanaler och flera målsystem är inblandade är en central granskningsservice ofta ett mer robust långsiktigt val. Om det bara finns en tydlig väg (ett ERP, en ingång) kan decentral validering vara försvarbar – men då bör versioneringen ändå vara ordentligt reglerad.

Vad som i projekt verkligen tar tid vid granskning

Tekniskt sett är inläsning av XML sällan problemet. Tid och risk uppstår i kanterna:

• Profil- und Versionsvielfalt: Utan transparens om vilka partner som skickar vilka profiler blir varje release en blindflygning. Telemetri (Profil/Version per Eingang) är därför inte en lyx, utan ett styrinstrument.
• Felöversättning: Validatorutdata är ofta för rå för fackavdelningar eller leverantörer. De behöver mappas till begripliga kategorier och åtgärdsalternativ.
• Stamdata och processer: Strukturerade fakturor gör stamdataproblem synliga (saknad leverantörstilldelning, inkonsekventa beställningsnummer). Det är bra, men initialt skapar det fler ärenden att reda ut.
• Verifikationskedja och arkiv: För spårbarhet räcker det inte att „filen lagrad”. Avgörande är: original (PDF/XML), granskningsresultat, regelsetversion, tidpunkt och koppling till affärsprocessen (frigivning, bokföring).

Rollout utan procesbrott: vågor, fallback och mätbara kriterier

Ett stabilt rollout uppnås om ni inte aktiverar allt samtidigt. En våglogik har visat sig fungera:

• Pilot: få leverantörer och verifikationstyper, mycket detaljerad loggning, daglig genomgång av de vanligaste felklasserna.
• Stabilisering: förfina reglerna, men med ändringsfönster och tydlig kommunikation. Återkommande mönsterfel löses målmedvetet tillsammans med inköp/leverantörer.
• Skalering: flytta över övervakningen till ordinarie drift (avvisningsgrad, utredningstid, vanligaste regelöverträdelserna, andel manuella).

Planera även för nöddrift. Om en regeluppdatering plötsligt blockerar många fakturor behöver ni en kontrollerad fallback (t.ex. temporärt varningsläge istället för hård avvisning) – med dokumenterat beslut och efterföljande granskning. Det är ingen „mjukgörare”, utan en driftbroms mot okontrollerade driftstopp.

Tre typiska missförstånd som ni bör reda ut tidigt

1) „ZUGFeRD är som tidigare en PDF.” I processen är den inbäddade XML det som räknas. PDF:en är användbar för människor men ersätter inte maskinell kontroll. Om PDF och XML skiljer sig åt måste det vara tydligt vilken källa som gäller i processen.

2) „Peppol gör automatiskt allt konform.” Peppol underlättar utbyte och interoperabilitet. Överensstämmelse uppstår först genom korrekt innehåll och lämpliga profiler. Leverans är inte detsamma som validering.

3) „Om validatorn visar grönt kan det bokföras.” Standardkonformitet är en bas, inte en fullständig processtillåtelse. Interna regler (krav på beställning, godsmottagning, attestgränser) kvarstår och bör hanteras som en separat nivå istället för att blandas in i validatorlogik.

Avslut: God granskning avlastar – när den är byggd som en driftprocess

Att granska E-fakturor är inte ett mål i sig. Vinsten uppstår när validering ses som ett driftssystem: versionshanterat, observerbart, med tydliga felklasser och en återkopplingskanal som inte fastnar i biljettköer. Då blir standarder som EN 16931, profiler som XRechnung/ZUGFeRD och transportvägar som Peppol inte ett ständigt byggprojekt utan hanterbara byggstenar i er processkedja.

För detta ämne är även „Zugferd Prüfen“ och „Xrechnung Validieren“ viktiga. Artikeln placerar dessa aspekter på ett lättförståeligt sätt och visar vad som är avgörande i vardagen.

Diskutera projekt eller moderniseringsinitiativ med Net-Base.