EHF Faktura og Kreditnota

I Stortingsmelding nr. 36:2008-2009 Det gode innkjøp står det:

Fornyings- og administrasjonsdepartementet og Kirkedepartementet (FAD) anså bruk av åpne standarder som et grunnleggende element for å skape en velfungerende offentlig sektor, med god intern samhandling og et godt tjenestetilbud til innbyggere og næringsliv.

Målsetningen med dette dokumentet er å definere et felles format for fakturameldinger i det norske markedet, og å legge til rette for en effektiv innføring og utbredelse av elektronisk samhandling i fakturaprosessen basert på disse formatene.

Målgruppen for dokumentet (heretter omtalt som implementeringsveileder) er både faglig og teknisk personell hos brukere som ønsker å utføre hele eller deler av fakturaprosessen elektronisk. Det vil i praksis si å sende elektronisk faktura og kreditnota. Dokumentet kan også benyttes av systemleverandør, ERP leverandør og meldingsformidlere.

Dokumentet er inndelt i følgende deler:

Denne revisjonen gjøres tilgjengelig for bruk fra 10. desember 2019. Den vil være obligatorisk fra samme dato.

Versjon 2.0.17 er en revisjon av EHF Faktura og Kreditnota 2.0, og dette innebærer at endringene i denne revisjonen er bakoverkompatibel med EHF Faktura og Kreditnota 2.0, og dermed at instansdokumenter som er gyldige i henhold til EHF Faktura og Kreditnota 2.0 også vil være gyldige i versjon 2.0.17. Det presiseres her at gyldig i henhold til EHF Faktura og Kreditnota 2.0 innebærer at det er gyldig i henhold til veilederen til EHF Faktura og Kreditnota 2.0, da det er dette som er den normative kilden.

EHF er en forkortelse for Elektronisk handelsformat.

EHF er basert på arbeidet som er gjort i CEN BII. Dette er så videre tilpasset norske forskrifter (bokføringsforskriften) og gjeldene praksis for de ulike aktuelle forretningsprosesser slik disse praktiseres i det norske markedet. Difi arbeider for at hele handelsprosessen skal kunne gjennomføres med EHF dokumenter. Dette gjelder dokumenter både før og etter kontraktsinngåelse.

Dokumenter helt fra anbudskatataloger til kreditnota skal dekkes under EHF paraplyen. I løpet av 2013 vil Difi tilrettelegge for bruk av EHF formatene i det vi kaller post award prosessen, med andre ord prosessen etter at en selger og kjøper har inngått en kontrakt.

Ved å benytte EHF dokumentene skal samhandlingen mellom kjøper og selger være forutsigbar. Elementer fra Katalogen skal man kunne gjenbruke i en ordre, og elementene fra en ordre skal kunne gjenbrukes i en faktura. Dette medfører at man vil få en helhetlig bruk av alle dokumentene som er under EHF paraplyen.

Difi har valgt å basere EHF-formatene på CEN BII og en syntaks implementering basert på Universal Business Language (UBL). UBL er en fritt tilgjengelig standard som ikke innebærer lisenskostnader, og det samme gjelder for EHF.

EHF forvaltes og vedlikeholdes av Difi.

De ulike EHF-formatene nevnt over, inneholder en del felles informasjonselementer. (Leverandør, kunde, vare, etc). Det er viktig at felles informasjon er konsistent i de ulike formatene. Det vil si at elementer med identisk innhold er definert på samme måte og så langt det lar seg gjøre har samme navn. For eksempel vil EHF Fakturaformatene gjenbruke elementer fra katalog og ordre for å sikre konsistens på tvers av meldingene slik at innhold i disse transaksjonene reflekteres i fakturameldingene. På denne måten understøttes en effektiv og automatisert kontroll av faktura mot bakenforliggende transaksjoner.

Bruk av tomme elementer er ikke lov i UBL, som EHF er basert på. Dette skyldes at tomme elementer kan tolkes til å ha mening, f.eks. at et element ikke er tilgjengelig ved utsendelse. I tillegg vil numeriske felt og datofelt ha krav til innhold som vil feile i validering dersom de sendes som tomme elementer.

Ved å benytte PEPPOL Transport Infrastruktur vil man få en effektiv bruk og transport av EHF formatene. PEPPOL Transport Infrastruktur har som utgangspunkt å gjøre det enkelt med handel på tvers av landegrenser. Erfaringen viser også at det er enklere å etablere elektronisk meldingsutveksling internt i Norge, blant annet fordi alle tjenestetilbydere benytter standardprosesser.

Det er viktig å merke seg at alle dokumenter som skal sendes inn i transport infrastrukturen må være validert OK i henhold til Difis validator. Dette kan gjøres enten av dokumentutsteder eller av tjenesteyter på dokumentutsteders vegne.

Tidligere Fornyings- Administrasjons- og Kirkedepartementet (FAD) anbefaler i sitt Rundskriv P-10/2012, at alle statlige virksomheter skal benytte PEPPOL Transport Infrastruktur.

I tråd med den metodiske tilnærmingen som ligger til grunn for EHF formatene (se CEN BII) vil de elektroniske meldingene som inngår i et format bli utvekslet mellom de aktuelle aktørene som en del av en elektronisk samhandlingsprosess – en profil.

En profil er definert som den elektroniske samhandlingsprosess som en aktuell meldingsutveksling er en del av. En profil vil typisk omfatte flere relaterte meldinger som utveksles mellom to parter, men kan i sin enkleste form omfatte utveksling av kun en enkelt melding.

Så langt det har latt seg gjøre benytter EHF seg av profiler utarbeidet av BII eller PEPPOL. Eksempler på relevante profiler er:

De meldinger som utveksles innenfor en profil er tilpasset (engelsk: customized) for å tilfredsstille de krav til innformasjonsinnhold som gjelder for den spesifikke bruken av det aktuelle forretningsdokumentet.

En CustomizationID (tilpasningsidentifikator) benyttes for å identifisere de forretningsregler som gjelder for det aktuelle forretningsdokumentet, dvs. det sett av forretningsregler som ble lagt til grunn av utsteder når dokumentet ble etablert.

Nedenstående eksempel på CustomizationID indikerer at innholdet i den aktuelle meldingen er basert på forretningsregler fastsatt av BII (urn:www.cenbii.eu:transaction:biitrns010:ver2.0), utvidet (extended), tilpasset og presisert av PEPPOL (urn:www.peppol.eu:bis:peppol5a:ver2.0) og ytterligere utvidet, tilpasset og presisert for norske forhold i EHF Faktura veilederen (urn:www.difi.no:ehf:faktura:ver2.0).

Eksempel på CustomizationID dersom det sendes en PEPPOL BIS, ytterligere info om PEPPOL BIS kan finnes på PEPPOL.

Kombinasjonen av registreringer i ELMA og de veiledningene denne registreringen henviser til, gjør at det ikke er behov for å inngå en mer formell samhandlingsavtale mellom avsender og mottaker. Gjennom registreringen i ELMA har en aktør deklarert sin evne og vilje til å ta imot forretningsdokumenter som er satt opp i henhold til den aktuelle veilederen, og alle andre kan derfor fritt velge å sende det aktuelle forretningsdokumentet til denne aktøren.

Ved utveksling av katalog og ordre hvor registrering i ELMA ikke benyttes, anbefales det at bruken av elektroniske meldinger reguleres via kjøpskontrakten (rammeavtalen) eventuelt med en egen samhandlingsavtale som vedlegg. Dette for å knytte den elektroniske samhandlingen mot de merkantile bestemmelsene og dermed få en jevnlig revidering av den elektroniske prosessen.

Difi forbeholder seg retten til å endre nåværende format til et nytt format dersom behovet skulle oppstå. Difi vil publisere informasjon om dette på sine nettsider samt at de vil varsle sine registerte kontakter med e-Post.

Difi forvalter formatet på følgende måte:

De elektroniske meldingene som denne veilederen omfatter er faktura og kreditnota. Meldingene setter en leverandør i stand til å sende en faktura til kunde som på sin side får i oppdrag å betale denne.

Figuren under viser hvilke roller som inngår i fakturaprosessen. I EHF er henholdvis kunde og fakturamottaker, samt leverandør og fakturautsteder alltid den samme.

Alle meldinger har ProfileID og CustomizationID. ProfileID identifiserer forretningsprosessen meldingen er en del av, CustomizationID identifiserer hvilken dokumenttype meldingen er og hvilke regler meldingen etterlever.

Profiler er knyttet til en forretningsprosess og en eller flere dokumenttyper. Gyldige instansdokumenter må ha både ProfileID og CustomizationID fra samme profil.

I oversikten under er hver dokumenttype knyttet til mottakers rolle når instansdokumenter sendes. Ved registrering i ELMA er det hvilke dokumenttyper mottaker kan motta som registreres.

Denne versjonen av EHF Faktura og Kreditnota gjør bruk av UBL XML schema versjon 2.1.

Dette i motsetning til tidligere versjoner av EHF Faktura og Kreditnota som benyttet UBL versjon 2.0.

Fakturaprosessen omfatter opprettelse og oversendelse av faktura og kreditnota fra leverandør til kunde, samt mottak og behandling hos kunde.

Fakturaprosessen kan beskrives ved følgende arbeidsflyt:

Figuren under viser fakturaprosessen ved bruk av EHF Fakturameldingene. Denne prosessen er basert på profil 5 i CENBII (BII05 – Billing) som forutsetter at både faktura og kreditnota blir sendt elektronisk. Profilen inneholder også meldingstypen «Corrective invoice». Denne benyttes ikke i Norge. Dersom kunden ikke aksepterer fakturaen, må leverandøren utstede kreditnota og eventuelt ny faktura.

Negativ faktura er når fakturaens totalsum er mindre en null. Denne versjonen av EHF Faktura tillater dette, men Difis validator vil gi en advarsel ved validering.

En kreditnota nullstiller hele eller deler av en tidligere sendt faktura, mens en negativ faktura er en faktura som i tillegg til salg av nye varer og/eller tjenester også inneholder andre poster (for eksempel retur av varer) som medfører at totalen blir mindre enn null.

Finansielle forskudd skal ikke være fakturert tidligere, jf. Skattdirektoratets uttalelse av 23.05.07 Finansielle forskudd eller forskuddsfakturering og GBS 13 Forskuddsfakturering. Dette betyr at når varen eller tjenesten er levert skal det utstedes et salgsdokument (faktura) etter reglene i bokføringsforskriften § 5-1 og § 5-2 selv om vederlaget allerede er innkrevd gjennom et finansielt forskudd. Salgsdokumentet avregnes mot det finansielle forskuddet. Dersom vederlaget overskrider det finansielle forskuddet, må kjøper innbetale restbeløpet. Dersom vederlaget er lavere enn det finansielle forskuddet oppstår det en ”negativ faktura”, altså hvor selger må tilbakebetale det overskytende beløpet.

I tilfeller med forskudds- eller akonto-fakturering må det utstedes en kreditnota etter reglene i bokføringsforskriften § 5-2-8 og GBS 1 Utstedelse av kreditnota for å korrigere det tidligere salgsdokumentet (som viste seg å angi et for høyt vederlag). Dette gjelder ikke hvis den negative fakturaen inneholder salg av nye varer og tjenester.

Følgende roller kan angis i formatet. Disse kan innehas av samme aktør eller ulike aktører avhengig av hvordan håndtering av meldingene er organisert.

Prisen på en varelinje er eksklusiv eventuelle rabatter og gebyrer på varelinjenivå, men inklusive rabatt/gebyr på prisnivå. Se også ytterligere spesifisering av rabatt/gebyr i kapitttel 6.2.

Deres referanse er obligatorisk kjøperreferanse. Skal inneholde referanse til bestiller, for eksempel bestillers navn, ansattnummer eller annen kode som identifiserer bestiller, eller en identifikator for avdeling/gruppe. Hos mange statlige mottakere vil identifikatoren være en kombinasjon av tall og bokstaver, f.eks. 3150okr som angir en bestemt person. Deres referanse vil styre behandlingen av fakturaen i et evt. arbeidsflytsystem hos mottaker, og det er derfor viktig at utsteder benytter korrekt verdi i henhold til krav fra kjøper. Dersom denne informasjonen ikke er relevant for fakturaen anbefales det at verdien «NA» (Not Applicable) benyttes i elementet, dette bør avklares med fakturamottaker. Deres ref angis i elementet AccountingCustomerParty/Party/Contact/ID.

Vår referanse er referansen for utsteder av EHF Fakturaen. Bør oppgis og være navn/referanse/identifikator til person hos leverandør som kan besvare evt. spørsmål om fakturaen. Angis i elementet AccountingSupplierParty/Party/Contact/ID.

MVA kategorier og satser pr. 1. juli 2013 for bruk i Norge er spesifisert i tabellen under. Bruk av andre MVA kategorier enn disse medfører at EHF instansdokumentet avvises ved validering.

MVA kategori må angis på linjenivå. På hodenivå angis MVA grunnlaget, MVA satsen samt MVA beløpet pr. MVA kategori samt totalt MVA beløp.

Ref kapittel 6.3.3.3 for eksempel ang. XML for MVA.

Dersom det er ønskelig å spesifisere særavgifter må dette gjøres ved å angi egne varelinjer for særavgiften. Den eneste lovlige avgiftskoden er VAT (MVA). Dersom ikke en egen varelinje for særavgift er angitt er eventuelle særavgifter å betrakte som inkludert i prisen.

For at behandling av elektronisk faktura skal bli mest mulig effektiv for kjøper, bør ordre-/bestillingsnummer tildelt av kjøper inkluderes i fakturaen. Dette vil gjøre det mulig for kjøper å gjøre automatisk match mot bestilling etablert i eget system.

Dersom ordrenummer er angitt på hodenivå forutsettes det at fakturaen kun er basert på en ordre. Ordrereferansene på linjenivå viser da kun de aktuelle ordrelinjene.

Dersom fakturaen omfatter flere ordre, oppgis ordrereferanse kun på linjenivå. Ordrereferansen på Iflinjenivå må da referere både til selve ordren og de aktuelle ordrelinjene. Syntaksen for hvordan dette angis bør avtales av partene, men det anbefales slik: ordrenummer##ordrelinjenummer.

Ved behov for andre typer av referanser enn ordre-/bestillingsnummer og kontraktsnummer (se punkt 6.8), skal andre dokumentreferanser benyttes, se punkt 6.11.

Når ordrenummer ikke er gitt skal Order Reference-elementet fjernes helt for å tydelig kommunisere at ingen ordrenummer var oppgitt. Når verdien "NA" brukes som ordrerefereanse er dette å anse som et reelt ordrenummer.

Kontraktsnummer kan benyttes i tillegg til ordre-/bestilingsnummer for å spore tilbake til inngått kontrakt (f.eks. rammeavtale) mellom partene.

Ved behov for andre typer av referanser enn ordre-/bestillingsnumer (se punkt 5.8) og kontraktsnummer, skal andre dokumentreferanser benyttes, se punkt 5.12.

Det er ofte et behov for å få angitt hvordan fakturainnholdet skal konteres i mottakers regnskap. Konteringsstrengen er anbefalt sendt på linjenivå forutsatt at leverandøren har mottatt konteringsstrengen fra kjøperen. Angivelse av konteringsstrengen muliggjør automatisk kontering for kjøper.

Siden konteringsstrengen kun er ett enkelt tekstfelt og en kontering i regnskapet gjerne benytter flere «dimensjoner» har en løsning for strukturert innhold i konteringsstrengen vært etterspurt av mange aktører. Nedenfor følger forslag til standardisert innhold i konteringsstreng ved bruk av følgende elementer i strengen:

Generelt innhold:

<Kontoplan>; Konto=<kontonr>;Avd=<avdeling>;Prod=<produkt>;Prosj=<prosjekt>;MVAkode=<MVA kode i mottakers regnskap>;Dim6=<Benyttes ved behov>;Dim7=<Benyttes ved behov>

Kontoplan må alltid komme først i strengen. Ingen krav ang. rekkefølge eller innhold i de andre feltene. Dersom norsk kontoplan benyttes av mottaker, skal NS4102 angis først i konteringsstrengen. For mottakere som benytter standard kontostreng for landbruk, versjon 1, skal Landbruk_kontostreng_v01 angis. Er det behov for andre felt i forbindelse med kontering enn konto, avdeling, produkt, prosjekt og MVA kode, kan feltene Dim6 og Dim7 benyttes. For eksempel er det i landbruksssammenheng behov for et felt for driftsgreinkode. Dim6 kan benyttes til dette.

Vedlegg kan benyttes i en EHF Faktura eller -Kreditnota for å gi tilleggsopplysninger som underbygger det kravet som er fremsatt i selve fakturaen. Aktuelle tilleggsopplysninger kan for eksempel være timelister, kvitteringer, flybilletter osv. Vedlegg skal i utgangspunktet ikke benyttes for å overføre en «pdf-versjon» av fakturaen. Er det gode grunner til å overføre en «PDF-versjon» SKAL feltet for dokumenttype ha verdien «Commercial invoice» for faktura og «Credit note» for kreditnota. Feltet for å sende vedlegg i formatet er valgfritt og kan gjentas mange ganger. Det er for eksempel grafikk, image eller andre tilleggsopplysninger som kan være et vedlegg til en faktura eller kreditnota. Vedlegget kan da sendes som et binært objekt knyttet til meldingen, eller at det overføres en referanse til stedet hvor vedlegget er lagret, for eksempel en URL.

Det er anbefalt å sende tilleggsinformasjon innebygd i dokumentet og ikke som eksternt vedlegg, da mange virksomheter ikke kan gå ut på eksterne lenker for å se tilleggsinformasjonen. Dersom eksterne vedlegg benyttes, er kjøper forpliktet til å laste ned innholdet bak lenken, og lagre dette selv med kontrollspor til fakturaen/kreditnotaen. En slik løsning krever, i henhold til Skattedirektoratet, en særskilt avtale mellom partene. Bruk av eksterne vedlegg anbefales derfor ikke.

Andre anbefalinger:

Det er ofte et behov å sende annen referanseinformasjon som ikke finnes direkte i EHF formatet. Til det formålet kan feltet AdditionalDocumentReference benyttes. Dette er et valgfritt felt som kan repeteres mange ganger. For eksempel kan det brukes til angivelse av pakkseddelnummer.

Fra og med versjon 2.0 er EHF Faktura tilrettelagt for å støtte faktura til forbruker. Dette innebærer at fakturautstedere kan benytte formatet overfor både bedriftskunder og forbrukere. Formidling av faktura til forbruker forventes å skje via nettbank eller tilsvarende tjenester som sikker digital post, under forutsetning av at det er inngått avtale om en slik tjeneste.

Referanse til en elektronisk B2C-faktura overføres som Additional DocumentReference hvor DocumentType skal settes til «elektroniskB2Cfaktura». Ved bruk av sikker digital post, skal fødselsnummer angis i ID elementet. Merk at det kun er offentlige organ som har tilgang til Kontakt- og reservasjonsregisteret.

Angivelse av organisasjonsnummer for kjøper kreves ikke oppgitt når elektroniskB2Cfaktura er oppgitt.

Overfor forbrukermarkedet er Avtalegiro utbredt som betalingsmåte.

Leveringsdato og -sted (Delivery) kan angis både på dokument og linjenivå.

Leveringsdato bør alltid spesifiseres, unntatt ved leveranse via speditør, post m.v, se nærmere spesifikasjon i bokføringsforskriften § 5-1-4.

Leveringssted anbefales fylt ut, men kan utelates dersom stedet for levering ikke har betydning for å kunne vurdere transaksjonen. Eksempler kan være ved fakturering av tjenester som utredninger og juridisk bistand. Se også NOU 2002:20 punkt 9.4.1.4

Elementet inneholder en identifikator (DeliveryLocation/ID) som kan benyttes dersom leveringsstedet er unikt definert gjennom en identifikator. Eksempler på dette er GLN (Global Location Number) eller GSRN (Global Sevice Relationship Number) begge utgitt av GS1. GSRN benyttes i det norske markedet til identifikasjon av Målepunkt ID i energibransjen. Ref. vedlegg 7 Veileder for energibransjen.

Leverandørens MVA nummer angis i elementet Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID og er opprinnelig et valgfritt felt, men i følge EU COUNCIL DIRECTIVE 2001/115/ må elementet sendes dersom faktura eller kreditnota har en MVA total. Det betyr i praksis at feltet nesten alltid må sendes. For virksomheter registrert i Norge er det organisasjonsnr. etterfulgt av bokstavene MVA (123456789MVA) som skal sendes. Det anbefales bruk av NO som prefiks ved fakturering til utlandet.

Det anbefales at både BBAN (Basic Bank Account Number) og IBAN (International Bank Account Number) angis når begge er tilgjengelige. BBAN bør angis først i XML instansdokumentet. Dersom det er et norsk kontonummer anbefales det alltid å oppgi BBAN.

Endepunkt ID benyttes for å angi den elektroniske adresse en sender/mottaker benytter for sin meldingsutveksling. Elektroniske adresser for norske aktører i PEPPOL transportinfrastruktur er organisasjonsnummeret og skal være registrert i ELMA.

Organisasjonsnummer (Company ID) benyttes for å identifisere den juridiske enhet fakturaen tilhører, dvs. den enhet som eier eller er ansvarlig for kravet.

Siden mindre virksomheter normalt kun vil ha et organisasjonsnummer vil det være samsvar mellom Endepunkt ID og organisasjonsnummer.

Enkelte større virksomheter vil kunne ha ulike organisasjonsnummer for eksempel basert på geografisk beliggenhet. Dersom disse virksomhetene samtidig ønsker en sentralisert behandling av sine fakturaer oppstår spørsmålet om hvilken enhet som skal identifiseres i de ulike feltene. I denne sammenheng anbefales det at alle enheter etableres som fakturamottakere i ELMA og at formidlingen til et sentralt fakturamottak realiseres som en del av registreringen hos det aktuelle Aksesspunkt. Dette innebærer blant annet at ELMA vil inneholde organisasjonsnummeret til alle enheter som kan faktureres ved hjelp av EHF og at registeret således kan benyttes for å vaske leverandørens kunderegister.

Alternativet er å sammenligne Endepunkt ID med «fakturamottaksadresse». Dette innebærer at fakturamottakeren manuelt må informere om hvilket Endepunkt ID som skal benyttes i meldingsutveklslingen.

Selgers MVA-representant er aktuelt for selgere som leverer varer og tjenester i Norge, men som ikke har fast driftssted i Norge. I slike tilfeller må MVA-representantens navn og adresse oppgis i fakturaen.

Mottakers system må kunne forholde seg til alle felt på en faktura (inkludert alle valgfrie) og minimum kunne vise alle utfylte element for kontroll og attestering.

Dynamisk visning av faktura og kreditnota vil utvikles av Difi.

Fra og med versjon 2.0.8 støtter EHF Faktura forsendelse av utbetalingsanmodning for å støtte oppunder prosesser i offentlig sektor. Denne varianten er ikke å anse som en faktura.

Nivåer i valideringsprosessen:

Kombinasjonen av ProfileID og CustomizationID i et XML instansdokument definerer hvilke valideringsregler som gjelder for meldingen.

CustomizationID kan utvides med flere element for bransjespesikke og firmaspesifikke valideringsregler.

Difis Validator er et program som brukes til å validere EHF XML-filer.

Informasjon om tjenesten her: https://vefa.difi.no/ehf/knowledge-base/validation/

Vedlagt er strukturtabell som gir en skjematisk oversikt for aktuelle meldinger.

Vedlagt er komplett meldingstabell for aktuelle meldinger.

Gjeldende kodelister for EHF:

UBL 2.1 Schema som denne implementasjonsguiden baserer seg på er tilgjengelig fra OASIS.

Ved validering vil syntaksvalidering gjøres mot aktuelle schema.

For mer informasjon om UBL 2.1 henviser vi til standarden. Ytterligere ressurser er også tilgjengelig.

Valideringsfiler basert på Schematron er tilgjengelig i vårt Github-repoistory. Release "2021-02-15" inneholder gjeldende versjon og branch "master" inneholder utvikling og høring.

Fra og med release 2016-11-15 distribueres valideringsfiler som Schematron i stedet for XSLT.

Eksempelfiler er gjort tilgjengelig for å hjelpe utviklere. Eksempelfiler for denne implementasjonsguiden er inkludert i eksempelfil-pakken.

Det er utarbeidet følgende bransjeveiledere: