Viden · E-faktura
Valider e-fakturaer og læs valideringsrapporten korrekt
Når en e-faktura fra din software bliver afvist, skal dit team ud fra valideringsrapporten finde ud af, hvilket felt der udløste meldingen, og hvem der kan rette det.
Vi viser, hvordan du læser en valideringsrapport, og hvor valideringen hører hjemme i din software.
Hvad der kontrolleres ved validering af en e-faktura
En validator kontrollerer en e-faktura efter hinanden mod tre regelsæt og registrerer enhver afvigelse i en valideringsrapport.
Syntaksens XML-skema
En e-faktura efter EN 16931 foreligger i en af to syntakser, UBL eller UN/CEFACT CII. Alle gængse applikationsspecifikationer bygger på disse to syntakser, f.eks. XRechnung, ZUGFeRD og Peppol BIS Billing 3.0.
Syntaksens XML-skema fastlægger, hvilke elementer der er tilladt, i hvilken rækkefølge de står, og hvilken datatype de har.
Skemafejl har intet regel-ID. XML-parseren melder dem med sine egne koder, f.eks. cvc-complex-type.2.4.a for et element et sted, hvor skemaet ikke forventer det.
Ved ZUGFeRD er en CII-fil indlejret i en PDF. Validatoren kontrollerer XML-delen. Ved afvigelser fra billeddelen er det denne del, der er afgørende, ifølge det tyske finansministeriums skrivelse af 15. oktober 2025 (BMF-Schreiben) om indførelsen af den obligatoriske e-faktura.
Forretningsreglerne i EN 16931
Forretningsreglerne kontrollerer oplysningerne i en e-faktura for logiske fejl, f.eks. om obligatoriske felter er udfyldt, og om summerne stemmer overens. Den Europæiske Standardiseringsorganisation (CEN) offentliggør disse regler som Schematron-filer på GitHub, både for UBL og for CII.
Ud fra præfikset i regel-ID’et kan du se, hvilken slags kontrol der er tale om. Regler med BR og et tal kontrollerer obligatoriske felter og deres antal, BR-CO kontrollerer beregninger og afhængigheder mellem felter, BR-CL kontrollerer kodelister og BR-DEC decimalerne i beløb. Regler som BR-S, BR-AE eller BR-IC kontrollerer oplysningerne om de enkelte momskategorier.
CEN-filerne indeholder desuden syntaksspecifikke regler. Regler med præfikset UBL-CR melder f.eks. en advarsel, hvis en UBL-fil indeholder elementer, der ikke hører til datamodellen i EN 16931.
Regler i XRechnung og Peppol BIS Billing 3.0
XRechnung og Peppol BIS Billing 3.0 er applikationsspecifikationer af EN 16931, i fagsproget kaldet CIUS (Core Invoice Usage Specification). De foreskriver yderligere felter og supplerer EN 16931 med egne regler. Nye datafelter må en CIUS ikke indføre.
Reglerne i XRechnung begynder med BR-DE og stammer fra det tyske koordineringskontor for IT-standarder (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 tilføjer regler med præfikserne PEPPOL-EN16931 og PEPPOL-COMMON samt landespecifikke regler.
Specifikations-ID’et i BT-24 fastlægger, hvilken applikationsspecifikation der gælder for filen. KoSIT’s validator vælger ud fra dette ID det passende valideringsscenarie. Et forkert eller forældet ID kan derfor føre til, at filen kontrolleres mod andre regler eller afvises.
Hvad en validering ikke kontrollerer
En validator kan ikke se, om momssatsen passer til ydelsen, eller om ydelsesbeskrivelsen er tilstrækkelig.
Ifølge det tyske finansministerium skal alle momsretlige obligatoriske oplysninger stå i den strukturerede del af e-fakturaen. En blot henvisning til et bilag med ydelsesbeskrivelsen er ikke nok. Et varenavn som „se bilag“ i BT-153 består alligevel valideringen, fordi ingen regel vurderer indholdet i dette felt.
KoSIT og Forum elektronische Rechnung Deutschland (FeRD) har offentliggjort en tabel, der knytter de obligatoriske oplysninger efter den tyske momslov til de tilsvarende BT-felter. Ud fra denne tabel kan du fastlægge, hvilke obligatoriske oplysninger din software bør sikre med egne plausibilitetskontroller.
Opbygningen af en valideringsrapport
Hver post i valideringsrapporten indeholder som regel fire oplysninger.
Regel-ID
Regel-ID’et, f.eks. BR-CO-15 eller BR-DE-2, henviser til reglen i dokumentationen for det pågældende regelsæt.
Alvorlighedsgrad
En validator markerer hver melding som fejl eller advarsel. I Peppol-reglerne kaldes fejl fatal. En advarsel alene fører som regel ikke til afvisning. Nogle validatorer giver desuden hints, altså anbefalinger til en ren implementering uden indflydelse på resultatet. KoSIT-validatoren anbefaler i slutningen af sin rapport at acceptere eller afvise dokumentet.
Peppol indfører ofte nye regler først som advarsel og opgraderer dem til fejl i en senere release. Med version 3.0.21 blev f.eks. reglerne PEPPOL-COMMON-R052 og PEPPOL-COMMON-R053 ændret fra advarsler til fejl, som det fremgår af release notes for Peppol BIS Billing 3.0.
Placering
Placeringen er et XPath-udtryk, der peger på det berørte element i XML-filen. Det samme BT-nummer ligger forskellige steder i UBL og CII. Fakturabeløbet inklusive moms (BT-112) står i UBL i elementet cbc:TaxInclusiveAmount under cac:LegalMonetaryTotal og i CII i elementet ram:GrandTotalAmount under ram:SpecifiedTradeSettlementHeaderMonetarySummation.
Ved regler, der sammenligner flere felter, peger placeringen ofte på et overordnet element. Den værdi, der udløser meldingen, finder du så via meldingsteksten.
Meldingstekst
Meldingsteksten beskriver reglen og nævner som regel de involverede BT-numre. Meldingen til BR-CO-15 siger f.eks., at fakturabeløbet inklusive moms (BT-112) skal svare til summen af fakturabeløbet eksklusive moms (BT-109) og momsbeløbet (BT-110).
Siden version 3.0.21 begynder teksterne i Peppol-reglerne med regel-ID’et.
Gennemgå valideringsrapporter i den rigtige rækkefølge
En lang valideringsrapport skyldes ofte få årsager.
-
Ret skemafejl
Så længe filen ikke opfylder skemaet, er resultaterne af forretningsreglerne ikke særlig sigende eller mangler helt. Ret derfor først skemafejlene i eksporten, og valider derefter filen igen.
-
Gruppér poster efter regel-ID
En fejl i mappingen kan optræde i hver fakturalinje. En faktura med 40 linjer giver så 40 poster til den samme regel, som alle skyldes én enkelt årsag. Gennemgå derfor rapporten efter regel-ID.
-
Genkend følgefejl
Et manglende element kan overtræde flere regler på én gang. Hvis momsspecifikationen (BG-23) mangler, melder validatoren f.eks. BR-CO-18 og desuden regler for den berørte momskategori som BR-S-01. Ret først årsagen, og valider igen, før du behandler de øvrige meldinger enkeltvis.
-
Via BT-nummeret ind i din egen datamodel
BT-nummeret forbinder valideringsrapporten med din software. Vedligehold en kobling fra hvert BT-nummer til databasefeltet, til formularfeltet i din brugerflade og til ansvaret. Ansvaret fastlægger, om dit team retter en fejl eller din kunde, f.eks. hvis der mangler stamdata.
-
Vurder og registrér advarsler
Beslut for hver advarsel, om du retter den eller bevidst accepterer den, og registrér beslutningen. Kontrollér ved hver ny release, om en accepteret advarsel bliver opgraderet til fejl.
Typiske fejlårsager efter regelgruppe
Regelgruppen viser ofte allerede, hvor i din software rettelsen skal ske.
Skemafejl uden regel-ID
Årsagen ligger i elementrækkefølgen, namespace eller en forkert datatype i eksporten. Rettelsen sker i eksportfunktionen, én gang for alle kunder.
BR med tal
Årsagen er et obligatorisk felt, der ikke er mappet eller er tomt i stamdataene. Rettelsen sker i mappingen eller ved det obligatoriske felt i brugerfladen.
BR-CO og BR-DEC
Årsagen ligger i summer, afrunding, rabatter og tillæg på dokumentniveau. Rettelsen sker i beregningslogikken i fakturaoprettelsen.
BR-CL
Årsagen er en forældet eller egen kode, f.eks. for måleenheder eller lande. Rettelsen sker i kodelisterne i din software.
BR-S, BR-AE, BR-IC og andre kategorier
Momskategori, momssats og fritagelsesgrund passer ikke sammen. Rettelsen sker i momslogikken og i varestamdataene.
UBL-CR
Eksporten indeholder UBL-elementer uden for datamodellen i EN 16931. Rettelsen sker i eksportfunktionen.
BR-DE
Sælgerens kontaktoplysninger, betalingsoplysninger eller køberreferencen mangler. Rettelsen sker som regel i dine kunders stamdata.
PEPPOL-EN16931 og PEPPOL-COMMON
Den elektroniske adresse mangler, eller et ID har det forkerte format. Rettelsen sker i stamdataene og i administrationen af Peppol-ID’er.
Manglende køberreference ved XRechnung (BR-DE-15)
Reglen BR-DE-15 melder en manglende køberreference i BT-10. Ved fakturaer til den offentlige forvaltning står myndighedens Leitweg-ID her. For B2B-fakturaer er det ifølge det tyske finansministerium momsretligt tilstrækkeligt med en pladsholder som „-“, hvis fakturamodtageren ikke angiver sin egen identifikator. Din software kan derfor forudfylde feltet for B2B-fakturaer med en pladsholder, som dine kunder kan overskrive.
Afrundingsdifferencer i momsen (BR-S-09)
Reglen BR-S-09 sammenligner momsbeløbet i kategorien standardsats med produktet af beregningsgrundlag og momssats. Hvis din software afrunder momsen pr. linje og lægger beløbene sammen, kan summen afvige herfra. Ved mange linjer kan afvigelsen blive større end den tolerance, reglen tillader. Beregn derfor momsbeløbet pr. kategori ud fra beregningsgrundlag og momssats, som reglen foreskriver.
Byg validering ind i din software
Valideringen hører hjemme fem steder i din software og din udviklingsproces.
Før afsendelse
Din software bør validere hver e-faktura direkte efter oprettelsen og stoppe afsendelsen ved fejl. Dine kunder kan ikke bruge et regel-ID eller et XPath-udtryk til ret meget. Oversæt derfor de regler, som dine kunder selv kan rette, til en besked ved det berørte formularfelt. Beskeden til BR-DE-6, telefonnummeret på sælgerens kontaktperson i BT-42, kan f.eks. lyde „Angiv venligst et telefonnummer til spørgsmål“.
Fejl, der skyldes din mapping eller din beregningslogik, kan din kunde ikke rette. Sådanne fejl bør gå som intern besked til dit team.
Ved modtagelse
Din software bør også validere indgående e-fakturaer og vise resultatet ved bilaget. Gem den originale fil uændret og valideringsrapporten som et separat dokument ved siden af. Det tyske finansministerium kræver, at i det mindste den strukturerede del af en e-faktura opbevares uændret i sin oprindelige form.
Hvis en indgående faktura indeholder fejl, kan din kunde anmode afsenderen om en berigtiget faktura. Din software kan understøtte dette trin, f.eks. med en forberedt henvendelse til afsenderen, der indeholder valideringsrapporten.
I automatiserede tests
Opret en samling af testfakturaer, der dækker dine fakturatyper med deres koder, f.eks. 380 for en faktura og 384 for en berigtiget faktura. Dæk desuden hver momskategori, som dine kunder bruger. Dertil kommer rabatter og tillæg samt hver syntaks, som din software genererer. Medtag også bevidst fejlbehæftede filer, og kontrollér, at validatoren afviser dem.
KoSIT-validatoren er et open source-program til kommandolinjen og kan integreres i en build-pipeline. KoSIT stiller desuden en testsuite med eksempelfakturaer til rådighed, som egner sig som udgangspunkt for din egen samling.
Efter hver opdatering af regelsættene
Regelsættene ændrer sig også uden nyt versionsnummer. KoSIT offentliggør jævnligt bundles med fejlrettelser til XRechnung 3.0.2, senest i udgaven af 31. august 2026. XRechnung 3.0 forbliver gældende mindst indtil 31. juli 2027.
Forhåndsversionen af specifikationen XRechnung 4.0 udkom den 15. september 2026. Den er udtrykkeligt ikke beregnet til produktiv brug, men giver dig et tidligt overblik over de nye og ændrede funktionaliteter. Den endelige version forventes at udkomme i foråret 2027 sammen med de tekniske komponenter.
OpenPeppol offentliggør jævnligt nye releases af Peppol BIS Billing 3.0, de seneste år hver maj og november. Version 3.0.21 blev offentliggjort den 20. maj 2026 og har været bindende siden 17. august 2026.
Planlæg for hver release en fast dato, hvor du validerer din testsamling mod de nye regler. Registrér i hver valideringsrapport, med hvilken version af validator og regelsæt den er lavet. Så kan du også eftervise et resultat, når reglerne er ændret i mellemtiden. Til skiftet til XRechnung 4.0 bør dit testmiljø kunne kontrollere begge versioner parallelt.
Analysér valideringsrapporter på tværs af alle kunder
Hvis din software genererer e-fakturaer for mange kunder, kan det betale sig at analysere valideringsrapporterne på tværs af alle kunder. Dukker det samme regel-ID pludselig op hos mange kunder, ligger årsagen sandsynligvis i mappingen eller i et nyt regelsæt. Optræder det kun hos én kunde, ligger årsagen snarere i dennes stamdata.
Validering med InvoiceRails
Trinene i denne artikel kan du implementere fuldt ud selv. Den engangsindsats, det kræver, er overskuelig, men det er den løbende ikke: Regelsæt, kodelister og valideringskonfigurationer ændrer sig flere gange om året, og hver ændring skal ind i dine tests, din afsendelse og din releaseplanlægning.
Validering, afsendelse og vedligeholdelse af regelsættene kan derfor også overlades til et certificeret Peppol access point som InvoiceRails.
E-faktura-validator til enkeltkontroller
Den gratis e-faktura-validator fra InvoiceRails kontrollerer XML-filer i UBL og CII samt hybride PDF-fakturaer uden login. Den genkender automatisk syntaks, version og profil, herunder XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X og andre profiler af EN 16931. Den validerer derefter filen mod XML-skemaet samt mod Schematron- og forretningsreglerne i den genkendte profil. Valideringsrapporten kan du downloade som PDF eller dele via et link, f.eks. når din support gennemgår en afvist faktura med en kunde.
InvoiceRails-API i din software
InvoiceRails er det OpenPeppol-certificerede Peppol access point fra fino data services. Din software tilslutter InvoiceRails via en REST-API og sender og modtager e-fakturaer gennem den for et vilkårligt antal kunder, efter ønske som white label.
API’en tilbyder valideringen som et selvstændigt endpoint, ligeledes med automatisk profilgenkendelse. Din software kan dermed kontrollere e-fakturaer direkte efter oprettelsen. Hver melding i svaret indeholder regel-ID, alvorlighedsgrad, meldingstekst og placering som XPath. Din software kan gemme validerings-ID’et ved fakturaen og hente resultatet igen i mindst 90 dage.
InvoiceRails validerer hver fil, som din software sender via Peppol, også uden dette kald. Din software skal på forhånd kontrollere, hvilke formater en modtager understøtter.
InvoiceRails kontrollerer også indgående e-fakturaer og overdrager den originale fil sammen med de udlæste fakturadata til din software. En webhook melder enhver ændring i leveringsstatus til din software.
Din software står fortsat for koblingen af felterne fra din datamodel, de letforståelige beskeder i din brugerflade og plausibilitetskontrollerne for obligatoriske oplysninger, som ingen regel dækker.
