Validera e-fakturor och läs valideringsrapporten rätt

En validator kontrollerar en e-faktura i tur och ordning mot tre regelverk och registrerar varje avvikelse i en valideringsrapport.

Syntaxens XML-schema

En e-faktura enligt EN 16931 finns i en av två syntaxer, UBL eller UN/CEFACT CII. Alla vanliga tillämpningsspecifikationer bygger på dessa två syntaxer, till exempel XRechnung, ZUGFeRD och Peppol BIS Billing 3.0.

Syntaxens XML-schema fastställer vilka element som är tillåtna, i vilken ordning de står och vilken datatyp de har.

Schemafel har inget regel-ID. XML-parsern rapporterar dem med egna koder, till exempel cvc-complex-type.2.4.a för ett element på en plats där schemat inte förväntar sig det.

I ZUGFeRD är en CII-fil inbäddad i en PDF. Validatorn kontrollerar XML-delen. Vid avvikelser från bilddelen är det denna del som gäller, enligt det tyska finansdepartementets skrivelse (BMF-Schreiben) av den 15 oktober 2025 om införandet av obligatorisk e-faktura.

Affärsreglerna i EN 16931

Affärsreglerna kontrollerar uppgifterna i en e-faktura med avseende på logiska fel, till exempel om obligatoriska fält är ifyllda och om summorna stämmer med varandra. Europeiska standardiseringskommittén (CEN) publicerar dessa regler som Schematron-filer på GitHub, en för UBL och en för CII.

Av regel-ID:ts prefix framgår vilken typ av kontroll det gäller. Regler med BR och ett nummer kontrollerar obligatoriska fält och deras antal, BR-CO kontrollerar beräkningar och beroenden mellan fält, BR-CL kontrollerar kodlistor och BR-DEC antalet decimaler i belopp. Regler som BR-S, BR-AE eller BR-IC kontrollerar uppgifterna för enskilda momskategorier.

CEN-filerna innehåller dessutom syntaxspecifika regler. Regler med prefixet UBL-CR ger till exempel en varning när en UBL-fil innehåller element som inte ingår i datamodellen i EN 16931.

Regler för XRechnung och Peppol BIS Billing 3.0

XRechnung och Peppol BIS Billing 3.0 är tillämpningsspecifikationer av EN 16931, i fackspråket kallade CIUS (Core Invoice Usage Specification). De gör ytterligare fält obligatoriska och kompletterar EN 16931 med egna regler. Nya datafält får en CIUS inte införa.

Reglerna för XRechnung börjar med BR-DE och kommer från den tyska samordningsmyndigheten för IT-standarder (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 lägger till regler med prefixen PEPPOL-EN16931 och PEPPOL-COMMON samt landsspecifika regler.

Specifikationsidentifieraren i BT-24 anger vilken tillämpningsspecifikation som gäller för filen. KoSIT:s validator väljer utifrån denna identifierare rätt valideringsscenario. En felaktig eller föråldrad identifierare kan därför leda till att filen kontrolleras mot andra regler eller avvisas.

Vad en validering inte kontrollerar

En validator upptäcker inte om skattesatsen passar leveransen eller om beskrivningen av leveransen är tillräcklig.

Enligt det tyska finansdepartementet måste alla obligatoriska momsuppgifter finnas i e-fakturans strukturerade del. En hänvisning till en bilaga med beskrivningen av leveransen räcker inte. Ett artikelnamn som ”se bilaga” i BT-153 klarar ändå valideringen, eftersom ingen regel bedömer innehållet i detta fält.

KoSIT och Forum elektronische Rechnung Deutschland (FeRD) har publicerat en tabell som kopplar de obligatoriska uppgifterna enligt den tyska momslagen till motsvarande BT-fält. Med hjälp av tabellen kan du bestämma vilka obligatoriska uppgifter din programvara bör säkra med egna rimlighetskontroller.

Varje post i valideringsrapporten innehåller i regel fyra uppgifter.

Regel-ID

Regel-ID:t, till exempel BR-CO-15 eller BR-DE-2, hänvisar till regeln i dokumentationen för respektive regelverk.

Allvarlighetsgrad

En validator markerar varje meddelande som fel eller som varning. I Peppol-reglerna kallas fel fatal. En varning leder i regel inte ensam till avvisning. Vissa validatorer ger dessutom upplysningar, alltså rekommendationer för en korrekt implementering utan påverkan på resultatet. KoSIT-validatorn rekommenderar i slutet av sin rapport att dokumentet antingen godtas eller avvisas.

Peppol inför ofta nya regler först som varning och uppgraderar dem till fel i en senare release. Med version 3.0.21 blev till exempel reglerna PEPPOL-COMMON-R052 och PEPPOL-COMMON-R053 fel i stället för varningar, enligt releaseanteckningarna för Peppol BIS Billing 3.0.

Position

Positionen är ett XPath-uttryck som pekar på det berörda elementet i XML-filen. Samma BT-nummer ligger på olika ställen i UBL och CII. Fakturabeloppet inklusive moms (BT-112) står i UBL i elementet cbc:TaxInclusiveAmount under cac:LegalMonetaryTotal, i CII i elementet ram:GrandTotalAmount under ram:SpecifiedTradeSettlementHeaderMonetarySummation.

För regler som jämför flera fält pekar positionen ofta på ett överordnat element. Värdet som utlöser meddelandet hittar du då via meddelandetexten.

Meddelandetext

Meddelandetexten beskriver regeln och nämner oftast de berörda BT-numren. Meddelandet för BR-CO-15 säger till exempel att fakturabeloppet inklusive moms (BT-112) måste motsvara summan av fakturabeloppet exklusive moms (BT-109) och momsbeloppet (BT-110).

Sedan version 3.0.21 börjar texterna i Peppol-reglerna med regel-ID:t.

En lång valideringsrapport går ofta tillbaka på ett fåtal orsaker.

Regelgruppen visar ofta redan var i din programvara rättelsen ska göras.

Schemafel utan regel-ID

Orsaken ligger i elementordningen, namnrymden eller en felaktig datatyp i exporten. Rättelsen görs i exportfunktionen, en gång för alla kunder.

BR med nummer

Orsaken är ett obligatoriskt fält som inte är mappat eller som är tomt i grunddata. Rättelsen görs i mappningen eller vid det obligatoriska fältet i gränssnittet.

BR-CO och BR-DEC

Orsaken ligger i summor, avrundning, rabatter och tillägg på dokumentnivå. Rättelsen görs i beräkningslogiken för fakturaskapandet.

BR-CL

Orsaken är en föråldrad eller egen kod, till exempel för måttenheter eller länder. Rättelsen görs i kodlistorna i din programvara.

BR-S, BR-AE, BR-IC och fler kategorier

Momskategori, skattesats och undantagsskäl stämmer inte överens. Rättelsen görs i skattelogiken och i artikelgrunddata.

UBL-CR

Exporten innehåller UBL-element utanför datamodellen i EN 16931. Rättelsen görs i exportfunktionen.

BR-DE

Säljarens kontaktuppgifter, betalningsuppgifter eller köparreferensen saknas. Rättelsen görs oftast i dina kunders grunddata.

PEPPOL-EN16931 och PEPPOL-COMMON

Den elektroniska adressen saknas eller en identifierare har fel format. Rättelsen görs i grunddata och i hanteringen av Peppol-ID:n.

Saknad köparreferens i XRechnung (BR-DE-15)

Regeln BR-DE-15 rapporterar en saknad köparreferens i BT-10. För fakturor till den offentliga förvaltningen står myndighetens Leitweg-ID där. För B2B-fakturor räcker enligt det tyska finansdepartementet ur momssynpunkt en platshållare som ”-”, om fakturamottagaren inte anger någon egen identifierare. Din programvara kan därför förifylla fältet för B2B-fakturor med en platshållare som dina kunder kan skriva över.

Avrundningsdifferenser i momsen (BR-S-09)

Regeln BR-S-09 jämför momsbeloppet för kategorin normalskattesats med produkten av beskattningsunderlag och skattesats. Om din programvara avrundar momsen per rad och adderar beloppen kan summan avvika. Med många rader kan avvikelsen bli större än den tolerans som regeln tillåter. Beräkna därför skattebeloppet per kategori utifrån beskattningsunderlag och skattesats, så som regeln föreskriver.

Valideringen hör hemma på fem ställen i din programvara och din utvecklingsprocess.

Före sändning

Din programvara bör validera varje e-faktura direkt efter att den skapats och stoppa sändningen vid fel. Dina kunder har svårt att tolka ett regel-ID eller ett XPath-uttryck. Översätt därför de regler som dina kunder själva kan åtgärda till en anvisning vid det berörda formulärfältet. Anvisningen för BR-DE-6, telefonnumret till säljarens kontaktperson i BT-42, kan till exempel lyda ”Ange ett telefonnummer för frågor”.

Fel som beror på din mappning eller din beräkningslogik kan din kund inte åtgärda. Sådana fel bör gå som ett internt meddelande till ditt team.

Vid mottagning

Din programvara bör även validera inkommande e-fakturor och visa resultatet vid verifikationen. Spara originalfilen oförändrad och valideringsrapporten som ett separat dokument bredvid. Det tyska finansdepartementet kräver att åtminstone den strukturerade delen av en e-faktura arkiveras oförändrad i sin ursprungliga form.

Om en inkommande faktura innehåller fel kan din kund begära en korrigerad faktura från avsändaren. Din programvara kan stödja detta steg, till exempel med en förberedd förfrågan till avsändaren som innehåller valideringsrapporten.

I automatiserade tester

Skapa en samling testfakturor som täcker dina fakturatyper med deras koder, till exempel 380 för en faktura och 384 för en korrigerad faktura. Täck dessutom in varje momskategori som dina kunder använder. Därtill kommer rabatter och tillägg samt varje syntax som din programvara skapar. Ta också med medvetet felaktiga filer och kontrollera att validatorn avvisar dem.

KoSIT-validatorn är ett program med öppen källkod för kommandoraden och kan byggas in i en byggpipeline. KoSIT tillhandahåller dessutom en testsvit med exempelfakturor som lämpar sig som utgångspunkt för din egen samling.

Efter varje uppdatering av regelverken

Regelverken ändras även utan nytt versionsnummer. KoSIT publicerar regelbundet paket med felrättningar för XRechnung 3.0.2, senast i versionen av den 31 augusti 2026. XRechnung 3.0 gäller till minst den 31 juli 2027.

Förhandsversionen av specifikationen XRechnung 4.0 publicerades den 15 september 2026. Den är uttryckligen inte avsedd för produktiv användning, utan ger dig en tidig överblick över nya och ändrade funktioner. Den slutliga versionen väntas publiceras våren 2027 tillsammans med de tekniska komponenterna.

OpenPeppol publicerar regelbundet nya releaser av Peppol BIS Billing 3.0, under de senaste åren i maj och i november. Version 3.0.21 publicerades den 20 maj 2026 och är bindande sedan den 17 augusti 2026.

Planera för varje release ett fast datum då du validerar din testsamling mot de nya reglerna. Ange i varje valideringsrapport med vilken version av validator och regelverk den togs fram. Då kan du förstå ett resultat även om reglerna har ändrats sedan dess. Inför bytet till XRechnung 4.0 bör din testmiljö kunna kontrollera båda versionerna parallellt.

Utvärdera valideringsrapporter för alla kunder

Om din programvara skapar e-fakturor för många kunder lönar det sig att utvärdera valideringsrapporterna för alla kunder sammantaget. Om samma regel-ID plötsligt dyker upp hos många kunder ligger orsaken troligen i mappningen eller i ett nytt regelverk. Om det bara förekommer hos en kund ligger orsaken snarare i den kundens grunddata.

Stegen i denna artikel kan du genomföra helt på egen hand. Engångsinsatsen för det är överskådlig, den löpande insatsen däremot inte: regelverk, kodlistor och valideringskonfigurationer ändras flera gånger om året, och varje ändring måste in i dina tester, din sändning och din releaseplanering.

Validering, sändning och underhåll av regelverken kan därför också lämnas över till en certifierad Peppol-accesspunkt som InvoiceRails.

Validator för e-fakturor för enskilda kontroller

Den kostnadsfria validatorn för e-fakturor från InvoiceRails kontrollerar XML-filer i UBL och CII samt hybrida PDF-fakturor, utan inloggning. Den känner automatiskt igen syntax, version och profil, bland annat XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X och andra profiler av EN 16931. Därefter validerar den filen mot XML-schemat samt mot Schematron- och affärsreglerna för den identifierade profilen. Valideringsrapporten kan du ladda ner som PDF eller dela via länk, till exempel när din support går igenom en avvisad faktura med en kund.

InvoiceRails-API:et i din programvara

InvoiceRails är den OpenPeppol-certifierade Peppol-accesspunkten från fino data services. Din programvara ansluter till InvoiceRails via ett REST-API och skickar och tar emot e-fakturor för valfritt antal kunder, om så önskas som white label.

API:et erbjuder valideringen som en egen endpoint, även den med automatisk profilidentifiering. Din programvara kan därmed kontrollera e-fakturor direkt efter att de skapats. Varje meddelande i svaret innehåller regel-ID, allvarlighetsgrad, meddelandetext och position som XPath. Din programvara kan spara validerings-ID:t vid fakturan och hämta resultatet igen i minst 90 dagar.

InvoiceRails validerar varje fil som din programvara skickar via Peppol, även utan detta anrop. Din programvara måste i förväg kontrollera vilka format en mottagare stöder.

InvoiceRails kontrollerar även inkommande e-fakturor och lämnar över originalfilen tillsammans med de utlästa fakturauppgifterna till din programvara. En webhook meddelar din programvara varje ändring av leveransstatusen.

Din programvara ansvarar fortfarande för mappningen av fälten från din datamodell, de begripliga anvisningarna i ditt gränssnitt och rimlighetskontrollerna för obligatoriska uppgifter som ingen regel täcker.