Dette dokumentet beskriver Elektronisk Handelsformat (EHF) for utveksling av fakturainformasjon elektronisk mellom handelspartnere. Dokumentet er utarbeidet som en del av satsingen til Direktoratet for forvaltning og IKT (Difi) innen standardisering av elektroniske handelsprosesser.

Innmelding av feil og mangler
Dersom du finner feil eller mangler i dokumentet ber vi om at det det meldes inn på Github Issues. Dersom man ikke allerede har bruker på Github kan man opprette bruker gratis.

Innledning

Bakgrunn og målsetning

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

Regjeringa meiner auka bruk av elektroniske løysingar er viktig for å forbetre og effektivisere offentleg innkjøp. Bruk av elektroniske løysingar kan redusere tidsbruken ved offentlege innkjøp, auke konkurransen og leggje til rette for innkjøp som er meir gjennomsiktige og lettare kan etterprøvast. Ved å bruke mindre tid og pengar på innkjøp frigjer ein ressursar som kan brukast til både fornying av offentleg sektor og meir velferd. Målet med å innføre elektroniske løysingar er å medverke til betre, enklare og sikrare innkjøp.

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.

Definisjon av åpen standard:
En åpen standard kjennetegnes ved at den er anerkjent og vil bli vedlikeholdt av en ikke-kommersiell organisasjon, og det løpende utviklingsarbeidet foregår på basis av beslutningsprosesser som er åpne for alle interesserte parter. Standarden er publisert og dokumentasjonen er tilgjengelig, enten gratis eller til en ubetydelig avgift. Det må være tillatt for alle å kopiere, distribuere og bruke standarden gratis eller for en ubetydelig avgift. Den intellektuelle rettighet knyttet til standarden (eks. patenter) er gjort ugjenkallelig tilgjengelig, uten royalty. Det er ingen forbehold om gjenbruk av standarden.

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ålgruppe

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.

  • Kapittel 1 til 5 er rettet mot faglig personell.

  • Kapittel 5 til 6 er rettet både mot faglig og teknisk personell.

  • Kapittel 7 til 8 (vedlegg) er rettet mot teknisk personell.

Dokumentstruktur

Dokumentet er inndelt i følgende deler:

  • Kapittel 1 gir en kort introduksjon som beskriver bakgrunn og målsetting med implementeringsveileder.

  • Kapittel 2 beskriver de endringer som er gjort mellom forskjellige versjoner av implementeringsveilederen.

  • Kapittel 3 beskriver EHF formatene generelt.

  • Kapittel 4 inneholder definisjoner som er relevant for fakturaformatene.

  • Kapittel 5 beskriver generelle prinsipper og forutsetninger for fakturaformatene.

  • Kapittel 6 gir detaljerte beskriver av sentrale informasjonselementer i fakturaformatene.

  • Kapittel 7 omhandler validering, det vil si kontroll av informasjonsinnhold.

  • Kapittel 8 inneholder vedlegg.

Ikrafttredelse

Denne revisjonen gjøres tilgjengelig for bruk fra 15. november 2018. Den vil være obligatorisk fra samme dato.

1. Endringslogg

1.1. Konsekvenser av implementinger av denne versjonen

Versjon 2.0.15 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.15. 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.

1.1.1. Registrering i ELMA

Alle som er registrert i ELMA for mottak av EHF Faktura og Kreditnota 2.0, vil kunne motta 2.0.15 uten endringer i ELMA.

1.2. Versjon 2.x

Versjon 2.0.15 (15.11.2018)

Sak Beskrivelse Type

-

Flyttet eksempelfilene inn i en eksempelfil-pakke. Vedlegget er oppdatert med ny lenke.

Guide

-

Bytte ut utlisting av valideringsregler med lenker til alle relevante valideringsregler.

Guide

-

Kombinere 'NOGOV-UBL-T10.sch' og 'NONAT-UBL-T10.sch' som 'EHF-UBL-T10.sch'.

Validator

-

Kombinere 'NOGOV-UBL-T14.sch' og 'NONAT-UBL-T14.sch' som 'EHF-UBL-T14.sch'.

Validator

-

Legge til "grunnleggende" valideringsregler som er automatisk generert basert på syntaks. Reglene er identifisert med 'EHF-T10-BXXXXX' for faktura og 'EHF-T14-BXXXXX' for kreditnota hvor 'XXXXX' er et løpenummer.

Validator

Valideringsregler som er ventet å trigge feil i neste release: Alle grunnleggende valideringsregler (EHF-TXX-BXXXXX).

Versjon 2.0.14 (12.09.2018)

Sak Beskrivelse Type

#267

Legge til et manglende ord i "Profiler og meldinger"-seksjonen.

Guide

Versjon 2.0.13 (20.02.2018)

Sak Beskrivelse Type

#244

Endre reglene NONAT-T10-R033 (E) og NONAT-T14-R033 (E) så de trigger error.

Validator

Versjon 2.0.12 (15.11.2017)

Sak Beskrivelse Type

#230

Oppdatere reglene NONAT-T10-R031 (F), NONAT-T10-R032 (F), NONAT-T14-R030 (F) og NONAT-T14-R031 (F) til å trigge feil.

Validator

#229

Benytte PEPPOL BIS sin Schematron som kilde i prosjetet for å forenkle vedlikehold og økt transparens.

Validator

#238

Bytte ut en del regler med regler i EHF Common.

Validator

#244

Legge til reglene NONAT-T10-R033 (W) og NONAT-T14-R033 (W).

Validator

#233

Oppdatert kapittel om validering så det reflerterer bruk av EHF Common.

Guide

#239

Tydeliggjøre bruk av "NA" på ordrenummer og "Deres referanse."

Guide

#245

Legge til informasjon om nye MVA-kategorier tilgjengelig i neste release.

Guide

Valideringsregler som er ventet å trigge feil i neste release: NONAT-T10-R033, NONAT-T14-R033
Mapping of rules for EHF Common in EHF Invoice
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NONAT-T10-R025 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NONAT-T10-R025 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NONAT-T10-R019 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T10-R026 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T10-R036 (F)

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

NOGOV-T10-R030 (F)

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T10-R031 (F)

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T10-R027 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NONAT-T10-R030 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T10-R028 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

NOGOV-T10-R044 (W)

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

NOGOV-T10-R010 (W)

Mapping of rules for EHF Common in EHF Credit Note
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NONAT-T14-R023 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NONAT-T14-R023 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NONAT-T14-R015 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T14-R009 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T14-R023 (F)

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

NOGOV-T14-R013 (F)

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T14-R014 (F)

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T14-R010 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NONAT-T14-R017 (F), NONAT-T14-R028 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T14-R011 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

NOGOV-T14-R044 (W)

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

NOGOV-T14-R020 (W)

Versjon 2.0.11 (14.09.2017)

Sak Beskrivelse Type

#200

Legge til reglene NONAT-T10-R031 (W), NONAT-T10-R032 (W), NONAT-T14-R030 (W) and NONAT-T14-R031 (W) for validering av mva-kategorier.

Validator

#215

Fikse implementasjonen for en del regler for å oppnå høyere kvalitet.

Validator

#184

Endre NONAT-T14-R028 (F) fra W, bytte ut NONAT-T10-R028 (W) med NONAT-T10-R030 (F).

Validator

#210

Endre NONAT-T10-R029 (F) og NONAT-T14-R029 (F) fra W.

Validator

#217

Legge til reglene NOGOV-T10-R044 (W) og NOGOV-T14-R044 (W) for validering av GLN-nummer.

Validator

Valideringsregler som er ventet å trigge feil i neste release: NONAT-T10-R031, NONAT-T10-R032, NONAT-T14-R030, NONAT-T14-R031

Versjon 2.0.10 (15.05.2017)

Sak Beskrivelse Type

#207

Oppdaterte validatorfiler for PEPPOL BIS fra OpenPEPPOL.

Validator

#209

Oppdatere NONAT-T10-R026 (F) og NONAT-T14-R024 (F) til å akseptere slakk på 0.02. Fjerner NONAT-T10-R027 og NONAT-T14-R025.

Validator

#210

Nye regler NONAT-T10-R029 (W) og NONAT-T14-R029 (W) for validering av TaxableAmount i TaxSubtotal.

Validator

#208

Legge til informasjon om hvordan man skal håndtere vedlegg som ikke er iht. listen over anbefalte formater.

Guide

#206

Oppdatere lenker i 3.6, 5.7 og kodelister.

Guide

Valideringsregler som er ventet å trigge feil i neste release: NONAT-T10-R029, NONAT-T14-R029.

Versjon 2.0.9 (15.02.2017)

Sak Beskrivelse Type

#173

Endre NOGOV-T10-R041 (F) og NOGOV-T14-R041 (F) fra advarsel til feil.

Validator

#187

Legge til NOGOV-T10-R043 (W) for å validere at PayableRoundingAmount er lik eller mindre enn 10% av PayableAmount.

Validator

#195

Legge til informasjon de nye guidene for energi og finans.

Guide

Versjon 2.0.8 Feilretting (13.12.2016)

Sak Beskrivelse Type

#193

Fjerne regelen som tilsier at cac:PaymentMeans/cac:PayeeFinancialAccount/cac:FinancialInstitutionBranch/cbc:ID er obligatorisk i EHF Core.

Validator

#192

Fjerne EHF Core for faktura og kreditnota.

Validator

Versjon 2.0.8 (15.11.2016)

Sak Beskrivelse Type

#156

Legge til 6.13.1 som beskriver utvidet bruk av faktura til forbruler (B2C).

Guide

#170

Legge til 6.20 som beskriver utbetalingsanmodning.

Guide

#169

Rette mindre feil i eksempelfiler for faktura og kreditnota.

Vedlegg

#157

Oppdatere NONAT-T10-R026 (F) og legge til 0,01 i slakk. Introduserer NONAT-T10-R027 (W) uten slakk.

Validator

#157

Oppdatere NONAT-T14-R024 (F) og legge til 0,01 i slakk. Introduserer NONAT-T14-R025 (W) uten slakk.

Validator

#157

Retting av NONAT-T10-R014 (F) og NONAT-T10-R021 (F).

Validator

#157

Retting av NONAT-T14-R017 (F).

Validator

#168

Retting av NONAT-T14-R004 (F).

Validator

#161

Endre NOGOV-T10-R034 (F) og NOGOV-T10-R035 (F) fra advarsel til feil.

Validator

#161

Endre NOGOV-T14-R021 (F) og NOGOV-T14-R022 (F) fra advarsel til feil.

Validator

#173

Endre NOGOV-T10-R041 (F) og NOGOV-T14-R041 (F) fra advarsel til feil.

Validator

#169

Oppdatere NOGOV-T10-R026 (F), NOGOV-T10-R030 (F), NOGOV-T10-R031 (F) og NOGOV-T10-R036 (F) til også å kontrollere kontrollsiffer på organisasjonsnummer.

Validator

#169

Oppdatere NOGOV-T14-R004 (F), NOGOV-T14-R009 (F), NOGOV-T14-R013 (F) og NOGOV-T14-R014 (F) til også å kontrollere kontrollsiffer på organisasjonsnummer.

Validator

#115

Regelen CI-T10-R001 (F) er undertrykt til fordel for NOGOV-T10-R042 (F).

Validator

#170

Oppdatere reglene NOGOV-T10-R001 (W), NOGOV-T10-R002 (W), NOGOV-T10-R004 (W), NOGOV-T10-R005 (W), NOGOV-T10-R042 (F), NONAT-T10-R001 (F), NONAT-T10-R003 (W), NONAT-T10-R004 (W) og NONAT-T10-R008 (F) for å tillate dokumenttype for internt bruk i det offentlige.

Validator

#184

Legge til NONAT-T10-R028 (W) og NONAT-T14-R028 (W), forventes å bli F i neste release.

Validator

#179

Oppdaterte validatorfiler for PEPPOL BIS fra OpenPEPPOL.

Validator

#172

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NOGOV-T10.

Validator

#157

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NONAT-T10.

Validator

#176

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NOGOV-T14.

Validator

#157

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NONAT-T14.

Validator

Versjon 2.0.7 (15.09.2016)

Sak Beskrivelse Type

#145

Konvertere guiden til Asciidoctor-format.

  • Justere kapittel 1 så det er mer likt andre guider.

  • Justere kapittel 3 så det er mer likt andre guider.

  • Fjerne kapittel 7 til fordel for GEFEG-visning tilgjengelig på VEFA.

  • Flytte kapittel 8 til kapittel 7.

  • Presentasjoner og illustrasjoner er endret grunnet nytt format.

  • Flytte kapittel 9 til kapittel 8.

Guide

#151

Endre regelen BII2-T10-R034 til å være WARNING for å tillate negativ faktura.

Validator

Tidligere annonsert endring av NOGOV-T10-R034 og NOGOV-T10-R035 fra advarsel (warning) til feil (error) er utsatt til versjon 2.0.8.

Versjon 2.0.6 (23.05.2016)

Sak Beskrivelse Type

#125

Sjekker at alle beløp på dokumentnivå kun har to desimaler.

Validator

#114

Sjekker at et organisasjonsnummer er 9 siffer, dersom schemeID = NO:ORGNR.

Validator

#116

Sjekker at dersom det er oppgitt rabatt/gebyr på dokumentnivå, så finnes elementer for totale gebyrer/rabatter.

Validator

#133

Sjekker at det det er en TaxSubtotal per TaxCategory i TaxTotal. Implementert som advarsel og er identifisert som NOGOV-T10-R041 og NOGOV-T14-R041.

Validator

#99

Tydeliggjøring av bruk av deres ref.

Guide

#71

Tydeliggjøring av anbefaling om at PEPPOL BIS kun brukes dersom en av aktørene er utenlandske.

Guide

#135

Lav mva sats (kategori AA) endret fra 8 til 10% i kapittel 6.6.

Guide

Versjon 2.0.5 (01.05.2015)

Validator endringer:
  • Nye valideringsartefakter fra PEPPOL og BII, oppgradering til XSLT/xPath 2.0

  • Tomme elementer vil medføre feilmelding, ikke advarsel som tidligere, gjelder regel NONAT-T10-R025 og NONAT-T14-R023.

Editorielle endringer:
  • Tydeliggjøring av bruk av verdien «NA» dersom kontakt ID ikke er relevant

  • Korrigere elementhenvisning for betalingsmottaker under kapittel 6.1

Andre endringer:
  • Vedlegg til veileder ”pakkes ut” på Github for å lette tilgang til filene

  • Manglende eksempelfiler på github legges tilbake

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Hotfix (15.04.2015)

Fjernet validering av schemeID for ClassifiedTaxCategory på faktura og kreditnota, da denne brøt mot bakoverkompatibilitet

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 2.0.4 (01.03.2015)

Validator endringer:
  • Validering av at schemeID = «UNCL5305» for ClassifiedTaxCategory på faktura og kreditnota

  • Advarsel dersom vedlegg er utenfor anbefalte dokumenttyper, både for faktura og kreditnota

Editiorielle endringer i veilederen:
  • Korrigering av eksempel i kapittel 6.15

  • Fakturering av forbrukere via sikker digital post

  • Tydeliggjøring av bruk av BBAN ved norske kontonnumer

  • Editorielle endringer i kap. 7 og 6.2.2

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 2.0.3 (01.12.2014)

Validator-endringer:
  • Validering av alle påkrevde og anbefalte felt.

  • Validering av elementer som ikke finnes i EHF og kardinalitet i hht. EHF. Validering av ulike datatyper (organisasjons-nummer, dato, bankkontonummer o.l)

  • Validering av at beløpet i //cac:TaxTotal/ cac:TaxSubtotal/cbc:TaxableAmount.

  • Validering av at EndpointID kun kan være organisasjonsnummer.

  • Validering av at valutakode-attributtet er lik DocumentCurrencyCode.

  • Korrigere feil i validator for validering av TaxInclusiveAmount, Credit note line amount

  • NONAT-T14-R020 gjøres om fra feil til advarsel.

Editorielle endringer i veilederen:
  • Tydeliggjøring av avhengige felt (D)

  • Spesifisering av pris-elementet

  • Endret forklaring til leveringsadresse og – dato.

  • Diverse feilrettinger/små tekstlige endringer

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

  • Yngve Pettersen, Edisys Consulting AS

Versjon 2.0.2 (29.09.2014)

Endret regel for leverandørs MVA nummer, for å tillate fakturaer fra bedrifter som ikke er registrert i MVA-registeret. Editoriske endringer i vedlegg 3

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 2.0.1 (19.08.2014)

Tillat med fakturadato frem i tid, for bade faktura og kreditnota. NONAT-T10-R009 og NONAT-T14-R005 endret fra feil til advarsel. Lagt inn ny regel for å kontrollere at verdiene i Profil ID er korrekte.

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 2.0 (07.05.2014)

Endringer, både faktura og kreditnota:
  • Faktura/Kreditnota i annen valuta enn NOK. Spesifikasjon av MVA i NOK. Følgende elementer må fylles ut:

    • TaxCurrency Code

    • TaxExchangeRate,

      • From currency

      • To currency

      • Exchange rate

    • TaxTotal/TaxSubtotal/TransactionCurrencyTaxAmount.

  • Lagt til navn og adresse for finansinstitusjon

  • Endringer i krav om og innhold av attributt listID for henvisning til ulike kodelister

  • Fjernet attributt schemeAgencyID i CompanyID

  • Fjernet moms representantens post adresse for å harmonisere med PEPPOL BIS

Endringer for kreditnota:
  • OrderReference på dokumentnivå

Editorielle endringer i regel ID’er og regeltekster.

Forfatter:
  • Olav Kristiansen, Difi

  • Siw Meckelborg, Edisys Consulting AS

  • Jostein Frømyr, Edisys Consulting AS

  • Are Berg, Edisys

  • Trond Bertil Barstad, Edisys

Versjon 2.0 (30.05.2013)

Utvidelser, både faktura og kreditnota:
  • Fakturering i annen valuta enn NOK (Moms i NOK)

  • Selgers momsrepresentant

  • Kontrakstype

  • Type rabatt/gebyr

  • Navn i kontakt for selger og kjøper

  • Periode, produsent samt varens opprinnelsesland på linjenivå

Utvidelser, kreditnota:
  • Navn på juridisk enhet selger og kjøper

  • Levering på dokument og linje

  • Betalingsmåte på dokument

  • Rabatt/gebyr på linje

  • Antall prisen gjelder for på linje

  • Referanse til faktura/fakturalinje på kreditnotalinje (BillingReference)

Følgene elementer er fjernet, faktura og kreditnota:
  • Adresseindentifikator, postboks, gatenummer og avdeling under adresse for leverandør og kunde samt levering

  • Region, provins, fylke under juridisk adresse

  • Avdeling under selger og kjøper

  • Betalingskanal under betalingsmåte

  • Kontaktperson under selger og kjøper

  • MVA spesifikasjon for rabatter/gebyrer på linje og pris

Følgene elementer er fjernet, kreditnota:
  • Referanse til kreditnota som kreditnotaen gjelder på dokumentnivå (BillingReference)

Endringer, faktura & kreditnota:
  • Fakturatype, obligatorisk

  • Navn på juridisk enhet selger og kjøper, obligatorisk

  • MVA % på linje, valgfritt

  • Betalingsbetingelse kan oppgis flere ganger

  • Feil MVA kode medfører avvisning

  • Utfylling av endepunktID er endret

  • Utfylling av UBL versjon endret fra 2.0 til 2.1

  • Utfylling av tilpasningidentifikator er endret

  • Versjonsnr. i Profil ID endret fra 1.0 til 2.0

Funksjonell utvidelse:
  • Fakturering av forbrukere (B2C)

Diverse tekstlige utvidelser / endringer ang:
  • Konteringsstreng

  • Leveringssted

  • Vedlegg

  • Bruk av valgfrie felt

  • Endepunkt ID

  • Bankkontonummer

Bruk av UBL versjon 2.1 XML schema.

Forfatter:
  • Olav A. Kristiansen, Difi

  • Camilla Bø, Hafslund

  • Morten Gjestad, Nets

  • Dan Andre Nylænder, Unit4 Agresso

  • Jan Terje Kaaby, NARF

  • Morten Krøgenes, Bankenes Standariseringskontor

  • Per Martin Jøraholmen, DFØ

  • Jostein Frømyr, Edisys Consulting AS

  • Erik Gustavsen, Edisys Consulting AS

2. Elektronisk HandelsFormat (EHF)

2.1. Om EHF

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.

2.2. Konsistent informasjonsinnhold

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.

2.3. Tomme elementer

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.

Bruk av tomme elementer er, som forklart over, ikke tillatt i EHF.

2.4. Meldingstransport

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.

2.5. Profiler og meldinger

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:

Profil Dokumenttyper

Kun faktura (bii04)

Faktura

Kun kreditnota (biixx)

Kreditnota

Faktura og kreditnota (bii05)

Faktura, Kreditnota

Faktura, kreditnota og purring (biixy)

Faktura, Kreditnota, Purring

Ordre og faktura (bii06)

Ordre, Ordrebekreftelse, Faktura, Kreditnota

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).

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0</cbc:CustomizationID>

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

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0</cbc:CustomizationID>
Det presiseres at dersom begge aktørene er hjemmehørende i Norge, skal EHF customizationID benyttes. PEPPOL BIS bør kun benyttes dersom en av partene er utenlandske.

2.6. Bruk av samhandlingsavtaler

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.

2.7. Versjonshåndtering

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:

Hovedversjon

En ny hovedversjon vil bli varslet minimum fem måneder før denne publiseres. Etter at den nye hovedversjonen er publisert vil det være en implementasjonstid på minimum tolv måneder før denne vil bli obligatorisk.

Difi ønsker å forankre alle hovedversjoner i forskrift om IT standarder i offentlig sektor.

Underversjon

En ny underversjon vil varsles minimum tre måneder før publiseringsdato og skal være obligatorisk i bruk etter 5 måneder.

Alle underversjoner skal være bakoverkompatible. To måneder etter at den nye underversjonen er obligatorisk vil all støtte for den tidligere versjonen (validator og veiledere) bli fjernet.

Revisjon

En revisjon er i prinsippet en feilretting av siste underversjon. Denne vil kun bli varslet ved publisering og anbefales implementert så raskt som mulig.

3. Definisjoner

Nedenfor følger definisjoner av sentrale begrep i forbindelse med faktureringsprosessen.

Faktura

Faktura er et dokument som regnskapsmessig stadfester et salg mellom en selger og en kjøper. Fakturaen utstedes av selgeren og kjøperen får i oppdrag å betale denne.

Kreditnota

En kreditnota er et dokument som opphever hele eller deler av en faktura som allerede er utstedt. Kreditnota skal ha en tydelig henvisning til hvilken faktura den gjelder for.

Elektronisk faktura

Elektronisk faktura er en faktura som overføres elektronisk fra fakturautsteder til fakturamottaker og som kan importeres i fakturamottakers økonomisystem og behandles maskinelt.

Leverandør

En person eller et firma som leverer en vare eller en tjeneste på egne eller andres vegne.

Kunde

Person eller organisasjon som overtar råderett over en vare eller tjeneste mot betaling, for en bestemt pris.

Selger

Person eller organisasjon som har til oppgave på egne eller andres vegne å slutte en avtale eller kontrakt om overdragelse av et produkt, en vare eller tjeneste mot et avtalt vederlag til en kjøper.

Kjøper

Person eller organisasjon som overtar råderett over en vare eller en tjeneste mot betaling, for en bestemt pris.

Fakturautsteder

En fakturautsteder er en person eller organisasjon som utsteder faktura for varer eller tjeneste som ble solgt på egne eller på andres vegne. Fakturamottaker En fakturamottaker er en person eller organisasjon som, på egne eller andres vegne, som vil motta faktura for varer eller tjenester som ble kjøpt.

Betalingsmottaker

En betalingsmottaker er en person eller organisasjon som får betaling.

4. Prinsipper og forutsetninger

Dette kapitlet beskriver de prinsipper og forutsetninger som ligger til grunn for bruk av EHF Fakturaprosess. Dette er i hovedsak basert på tilsvarende beskrivelser i profil CEN BII 05 Billing og PEPPOL BIS 5a.

4.1. Generelt om fakturameldingene

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.

4.2. Funksjoner og roller

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.

Funksjoner og roller

4.3. Profiler og meldinger

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.

CustomizationID er en streng uten mellomrom. Under er det lagt til mellomrom i CustomizationID for å lette lesbarheten. Husk å fjerne mellomrom før bruk.

4.3.1. Profil 04 - Kun faktura

ProfileID

urn:www.cenbii.eu:profile:bii04:ver2.0

Type CustomizationID Rolle

Faktura

urn:www.cenbii.eu:transaction:biitrns010:ver2.0 :extended:urn:www.peppol.eu:bis:peppol4a:ver2.0 :extended:urn:www.difi.no:ehf:faktura:ver2.0

Oppdragsgiver

4.3.2. Profil 05 - Faktura og kreditnota

ProfileID

urn:www.cenbii.eu:profile:bii05:ver2.0

Type CustomizationID Rolle

Faktura

urn:www.cenbii.eu:transaction:biitrns010:ver2.0 :extended:urn:www.peppol.eu:bis:peppol5a:ver2.0 :extended:urn:www.difi.no:ehf:faktura:ver2.0

Oppdragsgiver

Kreditnota

urn:www.cenbii.eu:transaction:biitrns014:ver2.0 :extended:urn:www.peppol.eu:bis:peppol5a:ver2.0 :extended:urn:www.difi.no:ehf:kreditnota:ver2.0

Oppdragsgiver

4.3.3. Profil XX - Kun kreditnota

ProfileID

urn:www.cenbii.eu:profile:biixx:ver2.0

Type CustomizationID Rolle

Kreditnota

urn:www.cenbii.eu:transaction:biitrns014:ver2.0 :extended:urn:www.cenbii.eu:profile:biixx:ver2.0 :extended:urn:www.difi.no:ehf:kreditnota:ver2.0

Oppdragsgiver

4.3.4. Profil XY - Faktura, kreditnota og purring

ProfileID

urn:www.cenbii.eu:profile:biixy:ver2.0

Type CustomizationID Rolle

Faktura

urn:www.cenbii.eu:transaction:biitrns010:ver2.0 :extended:urn:www.cenbii.eu:profile.eu:biixy:ver2.0 :extended:urn:www.difi.no:ehf:faktura:ver2.0

Oppdragsgiver

Kreditnota

urn:www.cenbii.eu:transaction:biitrns014:ver2.0 :extended:urn:www.cenbii.eu:profile:biixy:ver2.0 :extended:urn:www.difi.no:ehf:kreditnota:ver2.0

Oppdragsgiver

Purring

NA

Oppdragsgiver

4.4. Bruk av UBL 2.1

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.

4.5. Fakturaprosessen

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:

  1. En leverandør utsteder og sender en EHF Faktura til en kunde. Fakturaen refererer til en eller flere ordre samt en spesifikasjon av leverte varer og tjenester. En faktura kan også referere til en kontrakt eller rammeavtale. Fakturaen kan inneholde artikler (varer eller tjenester) med artikkelnummer eller artikler med fritekstbeskrivelse.

  2. Kunden mottar fakturaen og behandler denne i sitt fakturakontrollsystem. Resultatet av fakturakontrollen vil være en av følgende:

    1. Kunden aksepterer fakturaen i sin helhet, bokfører den i regnskapet og sender den videre til betaling.

    2. Kunden avviser fakturaen i sin helhet, tar kontakt med leverandøren og anmoder om at kreditnota utstedes.

    3. Kunden bestrider deler av fakturaen, tar kontakt med leverandøren og anmoder om at kreditnota samt ny faktura ustedes.

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.

Fakturaprosess

4.5.1. Avvikshåndtering, validering hos avsender

En EHF Faktura eller EHF Kreditnota skal valideres hos avsender før den blir sendt videre i transportinfrastrukturen. For beskrivelse av valideringsprosessen, ref. kapittel 8. Validering kan utføres på ulike tidspunkt og av ulike tjenester:

  1. I ERP-systemet. Validering er inkludert i prosessen som oppretter faktura/kreditnota dokumentet. Hvis valideringen feiler, vil det ikke bli opprettet noe dokument. Grunnlagsdata for oppretting av faktura/kreditnota dokument må justeres og generering av faktura/kreditnota dokumentet kjøres på nytt.

  2. Tjenestetilbyder av aksesspunkttjenesten utfører validering ved mottak av dokument fra sine kunder. Hvis valideringen feiler, sendes melding tilbake til kunden og dokumentet sendes ikke videre i transportinfrastrukturen. Utsteder av dokumentet har i dette tilfellet 2 alternativer:

    1. Dersom dokumentet ikke er utstedt i regnskapsteknisk betydning, dvs. Ikke bokført i eget regnskap, kan det endres og sendes på nytt.

    2. Dersom dokumentet er utstedt, kan ikke dokumentet endres. Istedet må det opprettes kreditnota for fakturaen (intern kreditering). Merk at denne kreditnotaen IKKE må sendes til aksesspunktet siden original-fakturaen feilet ved validering og dermed ikke ble videresendt til fakturamottaker.

4.5.2. Avvikshåndtering, validering hos mottaker

Noen mottakere vil validere innkommende dokument selv om de skal være validert før utsendelse i transportinfrastrukturen. En får da følgende scenarier:

  1. Dokumentet feiler i valideringen:

    1. Grunnet bruk av ulike versjoner av EHF formatene (Ref. kap. 2.1.2). Mottaker må behandle EHF dokumentet manuelt.

    2. Andre årsaker. Mottaker sender Message Level Respons til leverandør for å få nytt korrekt EHF dokument. Dokumentet blir ikke behandlet hos mottaker.

  2. Validering OK, men mottaker bestrider hele eller deler av innholdet i dokumentet. Mottaker kontakter avsender manuelt og gir beskjed om dette. Avsender oppretter og sender kreditnota, og eventuelt en ny faktura.

4.6. Bruk av negativ 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.

4.7. Finansielt forskudd vs. A konto faktura

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.

5. Beskrivelse av utvalgte deler

Nedenfor følger beskrivelse av utvalgte deler av informasjonsinnholdet i EHF Faktura og Kreditnota. Komplett informasjonsinnhold er listet i tabellene i kapittel 7.

5.1. Roller og aktører

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.

Selger (AccountingSupplierParty)

Selger er obligatorisk informasjon i EHF.

Kjøper (AccountingCustomerParty)

Kjøper er obligatorisk informasjon i EHF.

Betalingsmottaker (PayeeParty)

Betalingsmottaker er valgfri informasjon i EHF. Dersom denne ikke er oppgitt, er betalingsmottaker samme som selger.

Eksempel på utfylling av selgerinformasjon på hodenivå i en EHF Fakturamelding
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">123456789</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="ZZZ">123456</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Salgsbedriften ASA</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Storgata 34</cbc:StreetName>
      <cbc:AdditionalStreetName>Suite 123</cbc:AdditionalStreetName>
      <cbc:CityName>Storevik</cbc:CityName>
      <cbc:PostalZone>1234</cbc:PostalZone>
      <cbc:CountrySubentity>Region A</cbc:CountrySubentity>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID schemeID="NO:VAT">123456789MVA</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Salgsbedriften ASA</cbc:RegistrationName>
      <cbc:CompanyID schemeID="NO:ORGNR" schemeName="Foretaksregisteret">123456789</cbc:CompanyID>
      <cac:RegistrationAddress>
        <cbc:CityName>Storevik</cbc:CityName>
        <cac:Country>
          <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
        </cac:Country>
        </cac:RegistrationAddress>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:ID>Vår ref</cbc:ID>
      <cbc:Name>Ola Nordmann</cbc:Name>
      <cbc:Telephone>46211230</cbc:Telephone>
      <cbc:Telefax>46211231</cbc:Telefax>
      <cbc:ElectronicMail>ola@salgsbedriften.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingSupplierParty>

Eksempel på utfylling av kjøperinformasjon på hodenivå i en EHF Fakturamelding.
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">987654321</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="GLN">5790000436033</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>AS Innkjøper</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Hovedgata 23</cbc:StreetName>
      <cbc:AdditionalStreetName>Bakdøra</cbc:AdditionalStreetName>
      <cbc:CityName>Lillevik</cbc:CityName>
      <cbc:PostalZone>8523</cbc:PostalZone>
      <cbc:CountrySubentity>Region B</cbc:CountrySubentity>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID schemeID="NO:VAT">987654321MVA</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>AS Innkjøper</cbc:RegistrationName>
      <cbc:CompanyID schemeID="NO:ORGNR">987654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:ID>3150bdn</cbc:ID>
      <cbc:Name>Kari Navnesen</cbc:Name>
      <cbc:Telephone>5121230</cbc:Telephone>
      <cbc:Telefax>5121231</cbc:Telefax>
      <cbc:ElectronicMail>kari.navnesen@innkjoper.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingCustomerParty>

5.1.1. Kundenummer

Kundenummer angis i <cac:PartyIdentification>. Hvilken type aktøridentifikasjon som benyttes, angis i attributtet schemeID. Gyldige verdier må være i henhold til PEPPOLs Policy for Identifiers.

De mest brukte aktøridentifikasjonene i Norge er:

schemeID Beskrivelse

ZZZ

Ukjent utsteder, brukes ved interne kundenummer

GLN

Global Location Number fra GS1

NO:ORGNR

Registrering i Brønnøysundregisteret

5.2. Rabatter og gebyrer, generelle regler

  1. Flere rabatter og gebyrer kan oppgis på dokumentnivå og linjenivå. Elementet ChargeIndicator indikerer om forekomsten i AllowanceCharge gjelder rabatt (false) eller gebyr (true).

  2. MVA håndtering av rabatter og gebyrer legges inn i AllowanceCharge/TaxCategory med underliggende elementer på dokumentnivå, ikke på linjenivå og pris. Dette fordi rabatter og gebyrer knyttet til linje forutsetter bruk av samme MVA kode som linjen. Rabatter og gebyrer knyttet til pris er kun ment som informasjon og inngår ikke i andre elementer. Dermed skal heller ikke MVA for rabatter og gebyrer knyttet til pris beregnes.

  3. Totale rabatter og gebyrer på dokumentnivå summeres i henholdsvis AllowanceTotal Amount og ChargeTotalAmount (Ref. pkt. 6.2.1.1.3).

  4. Totale rabatter og gebyrer på linjenivå må tas hensyn til (trekkes fra/legges til) ved beregning av linjetotal. Disse rabattene og gebyrene skal ikke summeres inn i elementene som gjelder dokumentnivå.

  5. Rabatter og gebyrer relatert til pris skal ikke inngå i beregning av andre elementer.

  6. Rabatter og gebyrer relatert til pris kan inneholde både beløp, grunnlagsbeløp (AllowanceCharge/BaseAmount) og multiplikator (AllowanceCharge/MultiplierFactorNumeric).

5.2.1. Faktura

EHF Faktura formatet har mulighet for rabatter og gebyrer relatert til 3 nivåer:

  1. På dokumentnivå som gjelder hele fakturaen og er med i beregningen av fakturasummen.

  2. På linjenivå som gjelder fakturalinjen og er med i beregningen av fakturalinjebeløpet.

  3. På linjenivå relatert til prisen. Dette er kun ment for å synliggjøre overfor kjøper hvordan prisen er fremkommet. Er i tillegg relevant dersom selger eller kjøper vil bokføre rabatten eller gebyret i sitt regnskap. Selve prisen i formatet skal alltid være pris etter at eventuelle rabatter/gebyrer knyttet til pris er trukket fra/lagt til.

Eksempel
  • Netto fakturabeløp eks. mva: kr. 3450. 2 fakturalinjer:

    • Linje 1: 10 stk av vare A. Kr. 100 pr. stk og 10% rabatt.

    • Linje 2: 15 stk av vare B. Kr. 200 pr. stk og 15% rabatt.

      • Prisen på kr. 200 er inkludert kampanjerabatt på 20% for å illustrere bruk av AllowanceCharge knyttet til pris.

  • Totalrabatt: 2 %

  • Fakturagebyr: kr. 75

  • Frakt: kr. 100

XML for rabatt og gebyr på dokumentnivå
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Frakt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">100.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID schemeID="UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Fakturagebyr</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">75.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID schemeID="UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>2% Totalrabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">69.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID schemeID="UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
XML for merverdiavgift på dokumentnivå
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="NOK">889.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="NOK">3556.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="NOK">889.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID schemeID="UNCL5305">S</cbc:ID>
      <cbc:Percent>25.00</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
XML for totaler på dokumentnivå
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="NOK">3450.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="NOK">3556.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="NOK">4445.00</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="NOK">69.00</cbc:AllowanceTotalAmount>
  <cbc:ChargeTotalAmount currencyID="NOK">175.00</cbc:ChargeTotalAmount>
  <cbc:PayableRoundingAmount currencyID="NOK">0.00</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="NOK">4445.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
XML for rabatter på linjenivå
Linje 1
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="NAR">10.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="NOK">900.00</cbc:LineExtensionAmount>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>10% Rabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">100.00</cbc:Amount>
</cac:AllowanceCharge>
Linje 2
<cbc:ID>2</cbc:ID>
<cbc:InvoicedQuantity unitCode="NAR">15.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="NOK">2550.00</cbc:LineExtensionAmount>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>15% Rabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">450.00</cbc:Amount>
</cac:AllowanceCharge>
XML for rabatt knyttet til pris for fakturalinje 2
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">200.00</cbc:PriceAmount>
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>20% Kampanjerabatt</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>0.200</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="NOK">50.00</cbc:Amount>
    <cbc:BaseAmount currencyID="NOK">250.00</cbc:BaseAmount>
  </cac:AllowanceCharge>
</cac:Price>

5.2.2. Kreditnota

EHF Kreditnota-formatet har mulighet for rabatter og gebyrer relatert til 3 nivåer for kreditnota:

  1. På dokumentnivå. Identisk med faktura (ref kapittel 6.2.1.1.1)

  2. På linjenivå. Identisk med faktura (ref kapittel 6.2.1.1.2).

  3. På linjenivå relatert til prisen. Identisk med faktura (ref kapittel 6.2.1.1.3).

5.3. Pris og linjesum

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.

Eksempel ved rabatt på linjenivå
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:Note>Scratch on box</cbc:Note>
  <cbc:InvoicedQuantity unitCode="NAR" unitCodeListID="UNECERec20">1</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="NOK">1273</cbc:LineExtensionAmount>
  <cbc:AccountingCost>BookingCode001</cbc:AccountingCost>
  <cac:InvoicePeriod>
    <cbc:StartDate>2013-06-01</cbc:StartDate>
    <cbc:EndDate>2013-06-30</cbc:EndDate>
  </cac:InvoicePeriod>
  <cac:OrderLineReference>
    <cbc:LineID>1</cbc:LineID>
  </cac:OrderLineReference>
  <cac:AllowanceCharge> (1)
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Testing</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="NOK">12</cbc:Amount>
  </cac:AllowanceCharge>
  <cac:Item>
    <cbc:Description>Processor: Intel Core 2 Duo SU9400 LV</cbc:Description>
    <cbc:Name>Laptop computer</cbc:Name>
    <cac:SellersItemIdentification>
      <cbc:ID>JB007</cbc:ID>
    </cac:SellersItemIdentification>
    <cac:StandardItemIdentification>
      <cbc:ID schemeID="GTIN">1234567890124</cbc:ID>
    </cac:StandardItemIdentification>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="UNSPSC">12344321</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID schemeID="UNCL5305">S</cbc:ID>
      <cbc:Percent>25</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
  </cac:Item>
  <cac:Price>
    <cbc:PriceAmount currencyID="NOK">1261</cbc:PriceAmount>
  </cac:Price>
</cac:InvoiceLine>
1 Her er gebyret angitt på linjenivå, og må derfor medtas ved beregning av linjesum. Linjesum = (1*1261)+12 =1273
Eksempel ved rabatt på prisnivå
<cac:InvoiceLine>
  <cbc:ID>3</cbc:ID>
  <cbc:InvoicedQuantity unitCode="NAR" unitCodeListID="UNECERec20">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="NOK">4.96</cbc:LineExtensionAmount>
  <cbc:AccountingCost>BookingCode003</cbc:AccountingCost>
  <cac:OrderLineReference>
    <cbc:LineID>3</cbc:LineID>
  </cac:OrderLineReference>
  <cac:Item>
    <cbc:Name>"Computing for dummies" book</cbc:Name>
    <cac:SellersItemIdentification>
      <cbc:ID>JB009</cbc:ID>
    </cac:SellersItemIdentification>
    <cac:StandardItemIdentification>
      <cbc:ID schemeID="GTIN">1234567890126</cbc:ID>
    </cac:StandardItemIdentification>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="UNSPSC">32344324</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID schemeID="UNCL5305">H</cbc:ID>
      <cbc:Percent>15</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
  </cac:Item>
  <cac:Price>
    <cbc:PriceAmount currencyID="NOK">2.48</cbc:PriceAmount>
    <cac:AllowanceCharge> (1)
      <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>Contract</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="NOK">0.48</cbc:Amount>
    </cac:AllowanceCharge>
  </cac:Price>
</cac:InvoiceLine>
1 Her er rabatten angitt på prisnivå, og skal derfor ikke hensyntas ved beregning av linjesum. Linjesum = 2.48 * 2 = 4.96

5.4. Avrunding

  1. Avrunding skal som hovedregel utføres ved beregning av sluttresultatet i en kalkulasjon, ikke i forbindelse med mellomregninger, for at resultatet skal bli matematisk korrekt.

  2. Avrunding skal utføres til 2 desimaler i henhold til standard regelverk. (Større enn eller lik 5 rundes opp, mindre en 5 rundes ned)

  3. EHF formatet forutsetter at alle beløp på dokumentnivå samt linjetotal på linjenivå maksimalt inneholder 2 desimaler. Beløp som er resultatet av en kalkulasjon (for eksempel merverdiavgift) må avrundes dersom antall desimaler overstiger 2. Beløp som fremkommer ved å addere eller subtrahere andre beløp er det ikke nødvendig å avrunde dersom de inngående beløpene allerede er avrundet. (For eksempel Betalingsbeløp og Totalbeløp inklusiv merverdiavgift)

5.4.1. Elementer som må avrundes

  1. Linjetotal (LineExtensionAmount). Må avrundes siden linjetotalen kan være gjenstand for bokføring i selgers eller kjøpers regnskap. Merk at elementene som inngår i linjetotalen (pris \* antall, rabatt og gebyr) må avrundes hver for seg ved beregning av linjetotalen.

  2. Avrundet beløp i pkt. a) skal inngå i beregningen av totalt linjebeløp (MonetaryTotal/Line Extension Amount).

  3. Avrundet beløp i pkt. a) skal inngå i MVA grunnlaget pr. MVA kategori på hodet. (Tax Subtotal/ TaxableAmount)

  4. Summen av rabatter på dokumentnivå må avrundes ved beregning av elementet Monetary Total/AllowanceTotalAmount.

  5. Summen av gebyrer på dokumentnivå må avrundes ved beregning av elementet Monetary Total/ChargeTotalAmount.

  6. MVA grunnlag pr. avgiftskategori (TaxSubTotal/TaxableAmount).

  7. MVA beløp pr. avgiftskategori (TaxSubTotal/TaxAmount).

5.4.2. Avrunding av betalingsbeløp

Avrunding av betalingsbeløp angis på dokumentnivå (Monetary Total/PayableRoundingAmount) som gjelder hele fakturaen/kreditnotaen og er med i beregningen av totalen TaxInclusiveAmount. Elementet benyttes kun for å få en «kosmetisk penere» fakturatotal.

Eks. Kr. 999.81 avrundes til kr. 1000. PayableRounding Amount = 0.19.

5.4.3. Eksempel på avrunding

  • Faktura med 3 fakturalinjer:

    • Linje 1: 24 stk av vare A. Kr. 51.304 pr. stk og 10% rabatt. 25% MVA.

    • Linje 2: 15 stk av vare B. Kr. 44.7823 pr. stk og 15% rabatt. 25 % MVA.

    • Linje 3: 21 stk av vare C. Kr. 134.95 pr. stk og 24.45 % rabatt. 15% MVA.

  • Totalrabatt: 2.35 %

  • Frakt: 100.345

  • Forhåndsbetalt: 100

  • Avrunding: -0.36

5.4.4. Innhold i beløpselementer

Linje Pris Antall Rabatt Pris * antall, avr Rabatt beløp, ar Linjetotal MVA %

1

51,304

24

10 %

1231,3

123,13

1108,17

25 %

2

44,7823

15

15 %

671,73

100,76

570,97

25 %

3

134,95

21

24,45 %

2833,95

692,9

2141,05

15 %

Total

3820,19

AllowanceCharge (Invoice)

Totalrabatt (25% mva)

2,35 %

89,774465

Frakt (25% mva)

100,345

AvgKat MVA grl % Kalkulert MVA Merverdiavgiftsbeløp pr. avgiftskategori

S

1689,72

25 %

422,43

422,43

H

2141,05

15 %

321,1575

321,16

Totalbeløp merverdiavgift

3830,77

743,5875

743,59

Totalbeløp på linjer

3820,19

Totalbeløp eksklusiv merverdiavgift

3830,77

Totalbeløp inklusiv merverdiavgift

4574,00

Totalbeløp rabatt

89,77

Totalbeløp gebyr

100,35

Forhåndsbetalt beløp

100,00

Avrundingsbeløp

-0,36

Betalingsbeløp

4474,00

XML for rabatt og gebyr på dokumentnivå
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>2.35% Totalrabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">89.7744</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID schemeID="UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Frakt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">100.345</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID schemeID="UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
XML for merverdiavgift på dokumentnivå
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="NOK">743,59</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="NOK">1689.72</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="NOK">422.43</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID schemeID="UNCL5305">S</cbc:ID>
      <cbc:Percent>25.00</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="NOK">2141.05</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="NOK">321.16</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID schemeID="UNCL5305">H</cbc:ID>
      <cbc:Percent>15.00</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
XML for totaler på dokumentnivå
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="NOK">3820.19</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="NOK">3830.77</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="NOK">4574.00</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="NOK">89.77</cbc:AllowanceTotalAmount>
  <cbc:ChargeTotalAmount currencyID="NOK">100.35</cbc:ChargeTotalAmount>
  <cbc:PrepaidAmount currencyID="NOK">100.00</cbc:PrepaidAmount>
  <cbc:PayableRoundingAmount currencyID="NOK">-0.36</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="NOK">4474.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
XML for fakturalinjer
Linje 1
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="NAR">24.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="NOK">1108.17</cbc:LineExtensionAmount>
<cbc:AccountingCost>123</cbc:AccountingCost>
<cac:OrderLineReference>
  <cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>10% Rabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">123.1296</cbc:Amount>
</cac:AllowanceCharge>
<cac:Item>
  <cbc:Name>Vare A</cbc:Name>
  <cac:SellersItemIdentification>
    <cbc:ID>AAA</cbc:ID>
  </cac:SellersItemIdentification>
  <cac:ClassifiedTaxCategory>
    <cbc:ID schemeID=" UNCL5305">S</cbc:ID>
    <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">51.304</cbc:PriceAmount>
</cac:Price>
Linje 2
<cbc:ID>2</cbc:ID>
<cbc:InvoicedQuantity unitCode="NAR">15.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="NOK">570.97</cbc:LineExtensionAmount>
<cbc:AccountingCost>123</cbc:AccountingCost>
<cac:OrderLineReference>
  <cbc:LineID>2</cbc:LineID>
</cac:OrderLineReference>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>15% Rabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">100.760175</cbc:Amount>
</cac:AllowanceCharge>
<cac:Item>
   <cbc:Name>Vare B</cbc:Name>
   <cac:SellersItemIdentification>
     <cbc:ID>BBB</cbc:ID>
   </cac:SellersItemIdentification>
  <cac:ClassifiedTaxCategory>
     <cbc:ID schemeID=" UNCL5305">S</cbc:ID>
     <cbc:Percent>25.00</cbc:Percent>
    <cac:TaxScheme>
       <cbc:ID>VAT</cbc:ID>
     </cac:TaxScheme>
   </cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">44.7823</cbc:PriceAmount>
</cac:Price>
Linje 3
<cbc:ID>3</cbc:ID>
<cbc:InvoicedQuantity unitCode="NAR">21.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="NOK">2141.05</cbc:LineExtensionAmount>
<cbc:AccountingCost>123</cbc:AccountingCost>
<cac:OrderLineReference>
  <cbc:LineID>2</cbc:LineID>
</cac:OrderLineReference>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>24.45% Rabatt</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="NOK">692.9007</cbc:Amount>
</cac:AllowanceCharge>
<cac:Item>
  <cbc:Name>Vare C</cbc:Name>
  <cac:SellersItemIdentification>
    <cbc:ID>CCC</cbc:ID>
  </cac:SellersItemIdentification>
  <cac:ClassifiedTaxCategory>
    <cbc:ID schemeID=" UNCL5305">H</cbc:ID>
    <cbc:Percent>15.00</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">134.95</cbc:PriceAmount>
</cac:Price>

5.5. Bruk av leverandør- og kjøperreferanse

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.

"Deres referanse" skal settes til "NA" kun i de tilfeller hvor slik referanse ikke er oppgitt av kjøper. Når referanse er oppgitt av kjøper må rett felt fylles ut med oppgitt referanse.

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.

5.6. Merverdiavgift

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 Beskrivelse Sats pr. 1. januar 2016

S

Utgående merverdiavgift, alminnelig sats,

25%

H

Utgående merverdiavgift, redusert sats – næringsmidler

15%

R

Utgående merverdiavgift, redusert sats – råfisk

11,11%

AA

Utgående merverdiavgift, redusert sats – lav sats

10%

E

Innenlands omsetning og uttak fritatt for merverdiavgift

0%

Z

Unntatt fra merverdiavgiftsloven (utenfor merverdiavgiftsloven)

Ingen (0%)

K

Klimakvoter til næringsdrivende eller offentlig virksomhet – kjøper beregner MVA

Ingen (0%)

AE

Innenlands omsetning med omvendt avgiftsplikt

0%

G

Utførsel av varer og tjenester

0%

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.

5.6.1. Fakturering i annen valuta

Dersom fakturaen er utstedt i annet enn selgers nasjonale/lokale valuta, kan det være ønskelig å angi MVA informasjon både i transaksjonsvaluta og i lokal valuta.

MVA beløp i transaksjonsvaluta angis i elementet cac:TaxTotal/cbc:TaxAmount. Selve valutakoden angis i cbc:DocumentCurrency. MVA beløp pr. MVA kategori i lokal valuta angis i elementet cbc:TransactionCurrencyTaxAmount. Valutakoden angis i cbc:TaxCurrency.

Beregningene mellom transaksjonsvaluta og lokalvaluta vises i komposittelementet cac:TaxExchangeRate.

I eksempelet under viser vi hvordan disse elementene fylles ut dersom fakturaen er utstedt i EUR, mens lokal valuta er NOK, og med en kurs på 8,3804:

....
<cbc:DocumentCurrencyCode listID="ISO4217">EUR</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode listID="ISO4217">NOK</cbc:TaxCurrencyCode>
....
<cac:TaxExchangeRate>
  <cbc:SourceCurrencyCode listID="ISO4217">EUR</cbc:SourceCurrencyCode>
  <cbc:TargetCurrencyCode listID="ISO4217">NOK</cbc:TargetCurrencyCode>
  <cbc:CalculationRate>8.3804</cbc:CalculationRate>
  <cbc:MathematicOperatorCode>Multiply</cbc:MathematicOperatorCode>
  <cbc:Date>2014-02-20</cbc:Date>
</cac:TaxExchangeRate>
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">225.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="EUR">900.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="EUR">225.00</cbc:TaxAmount>
    <cbc:TransactionCurrencyTaxAmount currencyID="NOK">1885.59</cbc:TransactionCurrencyTaxAmount>
    <cac:TaxCategory>
      <cbc:ID schemeID="UNCL5305">S</cbc:ID>
      <cbc:Percent>25</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
...

5.7. Særavgift

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.

5.8. Ordre-/bestillingsnummer

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.

Eksempel
<cac:OrderReference>
  <cbc:ID>123456</cbc:ID>
</cac:OrderReference>

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.

Bruk av "NA" for "Not Applicable" er ikke mulig da "NA" vil da behandles som om det er et reelt ordrenummer.

5.9. Kontraktsnummer

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

Eksempel
<cac:ContractDocumentReference>
  <cbc:ID>Kontrakt 321</cbc:ID>
  <cbc:DocumentTypeCode listID="UNCL1001">2</cbc:DocumentTypeCode>
  <cbc:DocumentType>Framework Agreement</cbc:DocumentType>
</cac:ContractDocumentReference>

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

5.10. Konteringsstrengen

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.

Eksempel
<cbc:AccountingCost>Prosjekt kostnadskode 123</cbc:AccountingCost>

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:

  • Format-ID. Fast tekst som indikerer vilken kontoplan som benyttes. (NS4102 = norsk standard)

  • Feltnavn. Her er det inntil 7 felt som kan benyttes:

    • Konto

    • Avd (Avdeling)

    • Prod (Produkt)

    • Prosj (Prosjekt)

    • MVAkode

    • Dim6

    • Dim7

  • Verdi

  • Verdi skilletegn: Bruke tegnet =

  • Feltskilletegn: Bruke tegnet ;

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.

Eksempel
<cbc:AccountingCost>NS4102;Konto=4010;Avd=25;Prod=5421;Prosj=4098;MVAkode=1</cbc:AccountingCost>

5.11. Vedleggshåndtering

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:

Koding

Base64

Dokumentformat

MIME typer anbefales:

  • PDF – applikasjon / pdf

  • TXT – tekst / txt

  • GIF – image / gif

  • TIFF – image / tiff

  • JPEG, JPG – image / jpeg

  • PNG – image / png

Størrelse

5MB

Beskrivelse av vedlegg

Det anbefales å gi en god beskrivelse av hva slag vedlegg det gjelder. Kodelisten DocumentTypeCode anbefales brukt og beskrivelsen gjøres i feltet: Invoice/Additional_DocumentReference/DocumentReference/DocumentType.
Elementet benyttes kun til å gi en beskrivelse av vedleggets innhold eller type dokument/vedlegg.

5.11.1. Kopi av faktura/kreditnota som vedlegg

Vedlegg skal i utgangspunktet ikke benyttes for å overføre en «pdf-versjon» av fakturaen/kreditnotaen. Det er kun i ett tilfelle hvor det er lovpålagt med kopi av selve fakturaen/kreditnotaen som vedlegg: I de tilfeller fakturautsteder benytter seg av en fakturaportal, hvor fakturautsteder har fakturert/kreditert i eget økonomi/faktura system. I denne situasjon skal fakturautsteder taste inn fakturainformasjonen som finnes på den systemgenererte fakturaen/kreditnotaen, for så å legge ved et bilde av original faktura/kreditnota. I dette tilfellet SKAL feltet for dokumenttype ha verdien «Commercial invoice» for faktura og «Credit note» for kreditnota.

5.11.2. Bruk av vedleggstyper utover anbefalte typer

Dersom man sender vedleggstyper utover anbefalte typer uten at det er avtalt med mottaker kan man ikke forvente at mottaker har programvare for å vise det som er sendt. I tilfeller hvor avsender benytter vedleggstyper som mottaker ikke har programvare for å vise må avsender belage seg på å sende forretningsdokumentet på nytt med oppdatert vedlegg ved forespørsel.

Eksempelvis vil de fleste i dag ha installert programvare for visning av HTML, men det betyr ikke at behandling av HTML i fakturasystemet er støttet. I slike tilfeller er vedlegget å regne som uleselig for mottaker.

5.12. Bruk av andre dokumentreferanser

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.

Eksempel, vedlegg
<cac:AdditionalDocumentReference>
  <cbc:ID>Doc1</cbc:ID>
  <cbc:DocumentType>Timesheet</cbc:DocumentType>
  <cac:Attachment>
    <cac:ExternalReference>
      <cbc:URI>http://www.suppliersite.eu/sheet001.html</cbc:URI>
    </cac:ExternalReference>
  </cac:Attachment>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>Doc2</cbc:ID>
  <cbc:DocumentType>Drawing</cbc:DocumentType>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf">mimecode</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>
Eksempel, referanse til abonnement
<cac:AdditionalDocumentReference>
  <cbc:ID>1442316</cbc:ID>
  <cbc:DocumentType>Abonnement</cbc:DocumentType>
</cac:AdditionalDocumentReference>

5.13. Fakturering av forbrukere (B2C)

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.

Eksempel
<cac:AdditionalDocumentReference>
  <cbc:ID>147987</cbc:ID>
  <cbc:DocumentType>elektroniskB2Cfaktura</cbc:DocumentType>
</cac:AdditionalDocumentReference>

Overfor forbrukermarkedet er Avtalegiro utbredt som betalingsmåte.

Eksempel, elektronisk faktura B2C med Avtalegiro
<cac:PaymentMeans>
  <cbc:PaymentMeansCode listID="UNCL4461">3</cbc:PaymentMeansCode>(1)
  <cbc:PaymentDueDate>2014-07-25</cbc:PaymentDueDate>
  <cbc:PaymentID>0265590215686</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID schemeID="BBAN">51401099999</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
1 PaymentMeansCode: 3 (Automated clearing house debit)

5.13.1. Støtte for utvidet bruk

Fra versjon 2.0.8 er det åpnet for en alternativ angivelse av faktura til forbruker. Ved å benytte Z01 som InvoiceTypeCode i fakturaen fungerer dette som er alternativ til elektroniskB2Cfaktura. Dette er ikke til hinder for å fortsette å benytte elektroniskB2Cfaktura.

Eksempel på angivelse av InvoiceTypeCode
<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0</cbc:CustomizationID> (1)
<cbc:ProfileID>urn:www.cenbii.eu:profile:bii04:ver2.0</cbc:ProfileID> (2)
<cbc:ID>42</cbc:ID> (3)
<cbc:IssueDate>2016-11-15</cbc:IssueDate>
<cbc:InvoiceTypeCode listID="UNCL1001">Z01</cbc:InvoiceTypeCode> (4)
1 CustomizationID som for vanlig faktura.
2 ProfileID som vanlig for faktura i profil 04.
3 Fakturanummber som for vanlig faktura.
4 Angivelse av at dette er faktura til forbruker ved å benytte koden Z01.

Ved bruk av Z01 åpnes det for å ha flere og alternative identifikatorer for fakturamottaker. Alternative identifikatorer legges inn ved å benytte PartyIdentification som kan repeteres. Identifikatorer angis ved å benytte ZZZ som schemeID og å benytte et prefiks foran identifikatoren for å angi type. Identifikatorer som er av samme type som annen kontaktinformasjon på fakturamottaker kan være avvikende.

Bruk av InvoiceTypeCode for angivelse av forbrukerfaktura skal ikke benyttes i løsninger som sender fakturaer til Sikker Digital Post (SDP)/Digital Post til Innbygger (DPI).
Eksempel på utfylling av fakturamottaker
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">987654325</cbc:EndpointID> (1)
    <cac:PartyIdentification>
      <cbc:ID schemeID="ZZZ">phone:98765432</cbc:ID> (2)
    </cac:PartyIdentification>
    <cac:PartyIdentification>
      <cbc:ID schemeID="ZZZ">pid:12345612345</cbc:ID> (3)
    </cac:PartyIdentification>
    <cac:PartyName> (4)
      <cbc:Name>Bob Buyer</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress> (5)
      <cbc:StreetName>Anystreet 8</cbc:StreetName>
      <cbc:AdditionalStreetName>Back door</cbc:AdditionalStreetName>
      <cbc:CityName>Anytown</cbc:CityName>
      <cbc:PostalZone>101</cbc:PostalZone>
      <cbc:CountrySubentity>RegionB</cbc:CountrySubentity>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:Contact> (6)
      <cbc:ID>3150bdn</cbc:ID>
      <cbc:Name>John Doe</cbc:Name>
      <cbc:Telephone>5121230</cbc:Telephone>
      <cbc:Telefax>5121231</cbc:Telefax>
      <cbc:ElectronicMail>john@buyercompany.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingCustomerParty>
1 Angivelse av endepunkt brukt for mottak.
2 Eksempel på bruk av telefonnummer som identifikator.
3 Eksempel på bruk av personnummer som identifikator.
4 Navn på mottaker.
5 Postadresse til mottaker.
6 Kontaktinformasjon for mottaker.
Tabell 1. Forslag til prefikser benyttet for identifikatorer
Prefiks Beskrivelse

email

E-post

phone

Telefonnummer

pid

Personnummer (forutsetter databehandleravtale)

reference

Felles referanse

5.14. Leveringsdetaljer (dato og sted)

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.

Eksempel
<cac:Delivery>
  <cbc:ActualDeliveryDate>2013-02-15</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cbc:ID schemeID="GSRN">707057500022939815</cbc:ID>
    <cac:Address>
      <cbc:StreetName>Storgata</cbc:StreetName>
      <cbc:BuildingNumber>12</cbc:BuildingNumber>
      <cbc:CityName>Bergen</cbc:CityName>
      <cbc:PostalZone>5000</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
</cac:Delivery>

5.15. Leverandørens MVA-nummer

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.

Eksempel
<cac:PartyTaxScheme>
  <cbc:CompanyID schemeID="NO:VAT">123456789MVA</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

5.15.1. Leverandører som ikke er registrert for MVA

Dersom leverandør ikke er registrert for MVA, så kan ikke fakturaen inneholde MVA. Det vil si at MVA kategori settes lik "Z", og MVA-beløp settes til 0,-. Elementet 'cac:PartyTaxScheme' skal heller ikke sendes.

Eksempel på leverandørinfo:
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">999888777</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="GLN">1234567898765</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Bedriften A/S</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Brugt. 10</cbc:StreetName>
      <cbc:CityName>Sarpsborg</cbc:CityName>
      <cbc:PostalZone>1710</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Supplier without VAT</cbc:RegistrationName>
      <cbc:CompanyID schemeID="NO:ORGNR">999888222</cbc:CompanyID>
      <cac:RegistrationAddress>
        <cbc:CityName>Sarpsborg</cbc:CityName>
        <cac:Country>
          <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
        </cac:Country>
      </cac:RegistrationAddress>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:ID>abc1234</cbc:ID>
    </cac:Contact>
  </cac:Party>
</cac:AccountingSupplierParty>
Eksempel MVA og totalbeløp
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="NOK">0.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="NOK">100.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="NOK">0.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID schemeID="UNCL5305">Z</cbc:ID>
      <cbc:Percent>0</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="NOK">100.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="NOK">100.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="NOK">100.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="NOK">100.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
Eksempler MVA på fakturalinje:
<cac:ClassifiedTaxCategory>
  <cbc:ID schemeID="UNCL5305">Z</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:ClassifiedTaxCategory>

5.16. Utfylling av bankkontonummer

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.

Eksempel
<cac:PaymentMeans>
  <cbc:PaymentMeansCode listID="UNCL4461">31</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2013-06-25</cbc:PaymentDueDate>
  <cbc:PaymentID>0265590215686</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID schemeID="BBAN">15032387680</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode listID="UNCL4461">31</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2013-06-25</cbc:PaymentDueDate>
  <cbc:PaymentID>0265590215686</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID schemeID="IBAN">NO7315032387680</cbc:ID>
    <cac:FinancialInstitutionBranch>
      <cac:FinancialInstitution>
        <cbc:ID schemeID="BIC">DNBANOKKXXX</cbc:ID>
      </cac:FinancialInstitution>
    </cac:FinancialInstitutionBranch>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

5.17. Endepunkt ID/Organisasjonsnummer

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.

5.18. Selgers MVA-representant

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.

Eksempel
<cac:TaxRepresentativeParty>
  <cac:PartyName>
    <cbc:Name>Company name AS</cbc:Name>
  </cac:PartyName>
  <cac:PartyTaxScheme>
    <cbc:CompanyID schemeID="NO:VAT">904312347MVA</cbc:CompanyID>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>

5.19. Bruk av valgfrie felt

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.

5.20. Utbetalingsanmodning

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.

Utbetalingsanmodning er ikke å regne som en faktura, og bruk utover forhåndsdefinerte prosesser i offentlig sektor er ikke tillatt.

5.20.1. Angivelse av variant

For identifisering av dokumenttype brukes normale verdier foruten når det gjelder InvoiceTypeCode.

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0</cbc:CustomizationID> (1)
<cbc:ProfileID>urn:www.cenbii.eu:profile:bii04:ver2.0</cbc:ProfileID> (2)
<cbc:ID>108</cbc:ID> (3)
<cbc:IssueDate>2016-01-01</cbc:IssueDate>
<cbc:InvoiceTypeCode listID="UNCL1001">Z02</cbc:InvoiceTypeCode> (4)
1 CustomizationID som for vanlig faktura.
2 ProfileID som vanlig for faktura i profil 04.
3 I stedet for fakturanummer skal en enhetlig referansekode benyttes, eksempelvis saksnummer.
4 Koden Z02 angir at dokumentet er en utbetalingsanmodning.

5.20.2. Aktører

I en utbetalingsanmodning benyttes felter for leverandør for å beskrive betalingsmottaker, mens felter for kjøper benyttes for å beskrive utbetaler.

For utbetaler gjelder alle regler som ellers i EHF. For betalingsmottaker er krav om organisasjonsnummer og MVA-registrering fjernet i de tilfeller hvor mottaker er en privatperson. I tilfeller hvor mottaker er registrert i Enhetsregisteret skal alle identifikatorer benyttes som for vanlige fakturaer.

Betalingsmottaker som er en privatperson
<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Kari Igloskaper</cbc:Name> (1)
    </cac:PartyName>
    <cac:PostalAddress> (2)
      <cbc:StreetName>Torgallmenningen 1337</cbc:StreetName>
      <cbc:CityName>Bergen</cbc:CityName>
      <cbc:PostalZone>5014</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
  </cac:Party>
</cac:AccountingSupplierParty>
1 Navn på betalingsmottaker.
2 Postadresse til betalingsmottaker.

5.20.3. Validering

En korrekt dokumentinstans bestående av en utbetalingsanmodning er ventet å ikke generere noen feil eller advarsler utover advarselen "EUGEN-T10-R039".

6. Validering

For å oppnå optimal fleksibilitet blir EHF dokumenter validert på ulike nivåer og med ulikt fokus. Pyramiden under illustrerer valideringshierarkiet:

Valideringspyramide

6.1. Valideringsprinsipper

Nivåer i valideringsprosessen:

  1. Validering av syntaks mot UBL XML Schema, for eksempel:

    • Tagnavn og eventuelle attributter må være korrekt skrevet og i riktig rekkefølge i henhold til UBL.

    • Alle obligatoriske tagnavn ihht UBL må være inkludert.

    • Innholdet i et element må ha lovlig verdi i henhold til type definisjon.

  2. Validering mot CEN BII for å sikre at meldingen er i henhold til internasjonale krav, for eksempel:

    • Lovlige koder for valuta, land, avgifter etc.

    • Logiske sammenhenger mellom informasjonselementer som at startdato må komme før sluttdato, subtotaler må summeres til korrekt totalsum, test på at faktorer som skal multipliseres får korrekt produkt etc.

  3. Validering mot PEPPOL (EU) regelverk

  4. Validering mot EHF Common som inneholder regler felles for alle dokumenttyper som inngår i EHF.

  5. Validering mot EHF regler og norsk lovverk, for eksempel:

    • Organisasjonsnummer må fylles ut for selger.

    • Deres referanse må være utfylt.

    • Adresse, postnr og sted må være utfylt for kjøper.

6.2. Dynamisk validering

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.

6.3. Valideringsregler per ProfileID og CustomizationID

6.5. Valideringstjenesten

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

7. Vedlegg

Vedlegg A: Strukturtabell

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

Vedlegg B: Meldingstabell

Vedlagt er komplett meldingstabell for aktuelle meldinger.

Vedlegg C: Kodelister

Gjeldende kodelister for EHF:

Vedlegg D: UBL 2.1

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.

Vedlegg E: Schematron

Valideringsfiler basert på Schematron er tilgjengelig i vårt Github-repoistory. Release "2018-11-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.

Vedlegg F: Eksempelfiler

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

Vedlegg G: Veiledning

Det er utarbeidet følgende bransjeveiledere: