Validere e-faktura og lese valideringsrapporten riktig

En validator kontrollerer en e-faktura etter tur mot tre regelverk og registrerer hvert avvik i en valideringsrapport.

Syntaksens XML-skjema

En e-faktura etter EN 16931 foreligger i en av to syntakser, UBL eller UN/CEFACT CII. Alle vanlige bruksspesifikasjoner bygger på disse to syntaksene, for eksempel XRechnung, ZUGFeRD og Peppol BIS Billing 3.0.

Syntaksens XML-skjema fastsetter hvilke elementer som er tillatt, i hvilken rekkefølge de står og hvilken datatype de har.

Skjemafeil har ingen regel-ID. XML-parseren melder dem med egne koder, for eksempel cvc-complex-type.2.4.a for et element på et sted der skjemaet ikke forventer det.

I ZUGFeRD er en CII-fil innebygd i en PDF. Validatoren kontrollerer XML-delen. Ved avvik fra bildedelen er det denne delen som gjelder, ifølge rundskrivet fra det tyske finansdepartementet (BMF-Schreiben) av 15. oktober 2025 om innføringen av obligatorisk e-faktura.

Forretningsreglene i EN 16931

Forretningsreglene kontrollerer opplysningene i en e-faktura for logiske feil, for eksempel om obligatoriske felt er fylt ut og om summene stemmer overens. Den europeiske standardiseringsorganisasjonen (CEN) publiserer disse reglene som Schematron-filer på GitHub, både for UBL og for CII.

Prefikset i regel-ID-en viser hva slags kontroll det er. Regler med BR og et tall kontrollerer obligatoriske felt og antallet av dem, BR-CO kontrollerer beregninger og avhengigheter mellom felt, BR-CL kontrollerer kodelister og BR-DEC antall desimaler i beløp. Regler som BR-S, BR-AE eller BR-IC kontrollerer opplysningene for de enkelte merverdiavgiftskategoriene.

CEN-filene inneholder i tillegg syntaksspesifikke regler. Regler med prefikset UBL-CR gir for eksempel en advarsel når en UBL-fil inneholder elementer som ikke hører til datamodellen i EN 16931.

Reglene i XRechnung og Peppol BIS Billing 3.0

XRechnung og Peppol BIS Billing 3.0 er bruksspesifikasjoner av EN 16931, faglig kalt CIUS (Core Invoice Usage Specification). De krever flere felt og supplerer EN 16931 med egne regler. Nye datafelt kan en CIUS ikke innføre.

Reglene i XRechnung begynner med BR-DE og kommer fra det tyske koordineringskontoret for IT-standarder (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 legger til regler med prefiksene PEPPOL-EN16931 og PEPPOL-COMMON samt landspesifikke regler.

Spesifikasjonsidentifikatoren i BT-24 fastsetter hvilken bruksspesifikasjon som gjelder for filen. KoSIT-validatoren velger det riktige kontrollscenariet ut fra denne identifikatoren. En feil eller utdatert identifikator kan derfor føre til at filen kontrolleres mot andre regler eller avvises.

Hva en validering ikke kontrollerer

En validator oppdager ikke om avgiftssatsen passer til leveransen, eller om leveransebeskrivelsen er tilstrekkelig.

Ifølge det tyske finansdepartementet må alle obligatoriske merverdiavgiftsopplysninger stå i den strukturerte delen av e-fakturaen. En ren henvisning til et vedlegg med leveransebeskrivelsen er ikke nok. Et varenavn som «se vedlegg» i BT-153 består likevel valideringen, fordi ingen regel vurderer innholdet i dette feltet.

KoSIT og Forum elektronische Rechnung Deutschland (FeRD) har publisert en tabell som kobler de obligatoriske opplysningene etter den tyske merverdiavgiftsloven til de tilsvarende BT-feltene. Ved hjelp av denne tabellen kan du fastsette hvilke obligatoriske opplysninger programvaren din bør sikre med egne plausibilitetskontroller.

Hver oppføring i valideringsrapporten inneholder som regel fire opplysninger.

Regel-ID

Regel-ID-en, som BR-CO-15 eller BR-DE-2, viser til regelen i dokumentasjonen for det aktuelle regelverket.

Alvorlighetsnivå

En validator merker hver melding som feil eller advarsel. I Peppol-reglene kalles feil fatal. En advarsel alene fører som regel ikke til avvisning. Noen validatorer gir i tillegg merknader, altså anbefalinger for en ryddig implementering uten innvirkning på resultatet. KoSIT-validatoren anbefaler til slutt i rapporten sin å godta eller avvise dokumentet.

Peppol innfører ofte nye regler først som advarsel og oppgraderer dem til feil i en senere release. Med versjon 3.0.21 ble for eksempel reglene PEPPOL-COMMON-R052 og PEPPOL-COMMON-R053 endret fra advarsler til feil, slik det står i release notes for Peppol BIS Billing 3.0.

Plassering

Plasseringen er et XPath-uttrykk som peker på det berørte elementet i XML-en. Det samme BT-nummeret ligger på ulike steder i UBL og CII. Fakturabeløpet inklusive merverdiavgift (BT-112) står i UBL i elementet cbc:TaxInclusiveAmount under cac:LegalMonetaryTotal, i CII i elementet ram:GrandTotalAmount under ram:SpecifiedTradeSettlementHeaderMonetarySummation.

For regler som sammenligner flere felt, peker plasseringen ofte på et overordnet element. Verdien som utløser meldingen, finner du da via meldingsteksten.

Meldingstekst

Meldingsteksten beskriver regelen og nevner som regel de involverte BT-numrene. Meldingen for BR-CO-15 sier for eksempel at fakturabeløpet inklusive merverdiavgift (BT-112) må tilsvare summen av fakturabeløpet eksklusive merverdiavgift (BT-109) og merverdiavgiftsbeløpet (BT-110).

Siden versjon 3.0.21 begynner tekstene i Peppol-reglene med regel-ID-en.

En lang valideringsrapport skyldes ofte noen få årsaker.

Regelgruppen viser ofte allerede hvor i programvaren din rettelsen må gjøres.

Skjemafeil uten regel-ID

Årsaken ligger i elementrekkefølgen, navnerommet eller en feil datatype i eksporten. Rettelsen gjøres i eksportfunksjonen, én gang for alle kunder.

BR med tall

Årsaken er et obligatorisk felt som ikke er mappet, eller som er tomt i stamdataene. Rettelsen gjøres i mappingen eller ved det obligatoriske feltet i grensesnittet.

BR-CO og BR-DEC

Årsaken ligger i summer, avrunding, rabatter og tillegg på dokumentnivå. Rettelsen gjøres i beregningslogikken for fakturaopprettingen.

BR-CL

Årsaken er en utdatert eller egendefinert kode, for eksempel for måleenheter eller land. Rettelsen gjøres i kodelistene i programvaren din.

BR-S, BR-AE, BR-IC og andre kategorier

Merverdiavgiftskategori, avgiftssats og fritaksgrunn passer ikke sammen. Rettelsen gjøres i avgiftslogikken og i varestamdataene.

UBL-CR

Eksporten inneholder UBL-elementer utenfor datamodellen i EN 16931. Rettelsen gjøres i eksportfunksjonen.

BR-DE

Selgerens kontaktopplysninger, betalingsopplysninger eller kjøperreferansen mangler. Rettelsen gjøres som regel i stamdataene til kundene dine.

PEPPOL-EN16931 og PEPPOL-COMMON

Den elektroniske adressen mangler, eller en identifikator har feil format. Rettelsen gjøres i stamdataene og i administrasjonen av Peppol-ID-ene.

Manglende kjøperreferanse i XRechnung (BR-DE-15)

Regelen BR-DE-15 melder en manglende kjøperreferanse i BT-10. For fakturaer til offentlig forvaltning står myndighetens Leitweg-ID der. For B2B-fakturaer er det ifølge det tyske finansdepartementet avgiftsmessig nok med en plassholder som «-» hvis fakturamottakeren ikke angir en egen identifikator. Programvaren din kan derfor forhåndsutfylle feltet for B2B-fakturaer med en plassholder som kundene dine kan overskrive.

Avrundingsdifferanser i merverdiavgiften (BR-S-09)

Regelen BR-S-09 sammenligner merverdiavgiftsbeløpet for kategorien standardsats med produktet av beregningsgrunnlag og avgiftssats. Hvis programvaren din avrunder merverdiavgiften per linje og legger sammen beløpene, kan summen avvike fra dette. Ved mange linjer kan avviket bli større enn toleransen regelen tillater. Beregn derfor avgiftsbeløpet per kategori ut fra beregningsgrunnlag og avgiftssats, slik regelen krever.

Valideringen hører hjemme på fem steder i programvaren din og utviklingsprosessen din.

Før sending

Programvaren din bør validere hver e-faktura rett etter at den er opprettet, og stanse sendingen ved feil. Kundene dine har lite nytte av en regel-ID eller et XPath-uttrykk. Oversett derfor reglene som kundene dine kan rette selv, til en melding ved det berørte skjemafeltet. Meldingen for BR-DE-6, telefonnummeret til selgerens kontaktperson i BT-42, kan for eksempel lyde «Legg inn et telefonnummer for henvendelser».

Feil som skyldes mappingen eller beregningslogikken din, kan ikke kunden rette. Slike feil bør gå som en intern melding til teamet ditt.

Ved mottak

Programvaren din bør også validere innkommende e-fakturaer og vise resultatet ved bilaget. Lagre originalfilen uendret og valideringsrapporten som et eget dokument ved siden av. Det tyske finansdepartementet krever at minst den strukturerte delen av en e-faktura oppbevares uendret i sin opprinnelige form.

Hvis en inngående faktura inneholder feil, kan kunden din be avsenderen om en korrigert faktura. Programvaren din kan støtte dette trinnet, for eksempel med en forberedt henvendelse til avsenderen som inneholder valideringsrapporten.

I automatiserte tester

Lag en samling testfakturaer som dekker fakturatypene dine med kodene deres, for eksempel 380 for en faktura og 384 for en korrigert faktura. Dekk i tillegg hver merverdiavgiftskategori kundene dine bruker. I tillegg kommer rabatter og tillegg samt hver syntaks programvaren din lager. Ta også med bevisst feilaktige filer, og kontroller at validatoren avviser dem.

KoSIT-validatoren er et åpen kildekode-program for kommandolinjen og kan bygges inn i en build-pipeline. KoSIT tilbyr også en testsuite med eksempelfakturaer som egner seg som utgangspunkt for din egen samling.

Etter hver oppdatering av regelverkene

Regelverkene endres også uten nytt versjonsnummer. KoSIT publiserer jevnlig pakker (bundles) med feilrettinger for XRechnung 3.0.2, sist i utgaven av 31. august 2026. XRechnung 3.0 gjelder minst til 31. juli 2027.

Forhåndsversjonen av spesifikasjonen XRechnung 4.0 ble publisert 15. september 2026. Den er uttrykkelig ikke ment for produktiv bruk, men gir deg en tidlig oversikt over nye og endrede funksjoner. Den endelige versjonen ventes å komme våren 2027 sammen med de tekniske komponentene.

OpenPeppol publiserer jevnlig nye releaser av Peppol BIS Billing 3.0, de siste årene i mai og november. Versjon 3.0.21 ble publisert 20. mai 2026 og har vært bindende siden 17. august 2026.

Sett av en fast dato for hver release der du validerer testsamlingen din mot de nye reglene. Noter i hver valideringsrapport hvilken versjon av validator og regelverk den ble laget med. Da kan du forstå et resultat også når reglene har endret seg i mellomtiden. Ved overgangen til XRechnung 4.0 bør testmiljøet ditt kunne kontrollere begge versjonene parallelt.

Analyser valideringsrapporter på tvers av alle kunder

Hvis programvaren din lager e-fakturaer for mange kunder, lønner det seg å analysere valideringsrapportene på tvers av alle kunder. Dukker den samme regel-ID-en plutselig opp hos mange kunder, ligger årsaken sannsynligvis i mappingen eller i et nytt regelverk. Oppstår den bare hos én kunde, ligger årsaken heller i kundens stamdata.

Trinnene i denne artikkelen kan du gjennomføre helt selv. Engangsinnsatsen er overkommelig, den løpende er det ikke: Regelverk, kodelister og valideringskonfigurasjoner endres flere ganger i året, og hver endring må inn i testene, sendingen og releaseplanleggingen din.

Validering, sending og vedlikehold av regelverkene kan derfor også overlates til et sertifisert Peppol Access Point som InvoiceRails.

E-fakturavalidator for enkeltkontroller

Den gratis e-fakturavalidatoren fra InvoiceRails kontrollerer XML-filer i UBL og CII samt hybride PDF-fakturaer, uten innlogging. Den gjenkjenner syntaks, versjon og profil automatisk, blant annet XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X og andre profiler av EN 16931. Deretter validerer den filen mot XML-skjemaet og mot Schematron- og forretningsreglene for den gjenkjente profilen. Valideringsrapporten kan du laste ned som PDF eller dele via lenke, for eksempel når kundestøtten din går gjennom en avvist faktura med en kunde.

InvoiceRails-API-et i programvaren din

InvoiceRails er det OpenPeppol-sertifiserte Peppol Access Pointet fra fino data services. Programvaren din kobler seg til InvoiceRails via et REST-API og sender og mottar e-fakturaer gjennom det for så mange kunder du vil, ved ønske som white label.

API-et tilbyr validering som et eget endepunkt, også med automatisk profilgjenkjenning. Programvaren din kan dermed kontrollere e-fakturaer rett etter at de er opprettet. Hver melding i svaret inneholder regel-ID, alvorlighetsnivå, meldingstekst og plassering som XPath. Programvaren din kan lagre validerings-ID-en sammen med fakturaen og hente resultatet på nytt i minst 90 dager.

InvoiceRails validerer hver fil som programvaren din sender via Peppol, også uten dette kallet. Programvaren din må på forhånd kontrollere hvilke formater en mottaker støtter.

InvoiceRails kontrollerer også innkommende e-fakturaer og overleverer originalfilen sammen med de uttrukne fakturadataene til programvaren din. En webhook varsler programvaren din om hver endring i leveringsstatusen.

Programvaren din står fortsatt for koblingen av feltene fra datamodellen din, de forståelige meldingene i grensesnittet ditt og plausibilitetskontrollene for obligatoriske opplysninger som ingen regel dekker.