X.6.1.3 Digitale kvitteringsmeldinger
Her finner du prosessdefinisjonen for digital kvitteringsmelding også kalt eReceipt
1 Informasjon
| Navn på prosess | eKvittering ved kjøp av varer og tjenester |
| ID og navn i prosessoversikt | |
| Organisasjon | DFØ-ANS |
| Prosesseier | Jan Mærøe |
| Forespørsler | Jan Mærøe |
| Formålet med dokumentet | For å veilede brukere og tjenesteleverandører som implementerer prosessen |
2 Historikk
| Versjon | Dato | Informasjon | Forfatter / Rolle |
| 1.0 | 23.02.2024 | Dokument etablert | Petter Vinje |
3 Ord og uttrykk
eKvittering = Elektronisk kvittering (ofte kalt eReceipt)
EHF = Elektronisk Handelsformat
ViDA= VAT in the Digital Age
4 Om prosessen
Det er i dag vanlig å kunne motta eKvittering ved kjøp av varer og tjenester. Dette er en beskrivelse av 4 digitale prosesser knyttet til bruk av eKvittering. Fordi prosessene i utgangspunktet er de samme uansett hva man kjøper. Har vi valgt å beskrive de grunnleggende, generiske prosessene som enkelt kan tilpasses kjøp av ulike typer varer og tjenester.
De 4 prosessene (P1-P4) beskriver prosessen, det som skjer når:
P1: En virksomhet kjøper varer og tjenster og mottar en eKvittering.
P2: En virksomhet som matcher eKvittering mot faktura.
P3: En virksomhet som benytter eKvittering/faktura for å få refundert MVA.
P4: Den fjerde prosessen er en en mulig fremtidig prosess som viser hvordan en virksomhet kan bruke eKvittering og VIDA report ved rapportering av MVA til skattemyndighetene.
Prosessene beskriver/viser transaksjoner som både kan være nasjonalt og/eller mellom ulike land.
5 Bruk av KI/AI
Hvis du har kompetanse i bruk av "kunstig intelligens" KI eller "artificial intelligence" AI. Og ser muligheter for å forbedre prosessen ytterligere ved bruk av det. Vi vil gjerne ha en tilbakemelding/innspill fra deg om hvordan det kan gjøres.
Har du innspill, send det til EHF@dfo.no Merk melding med KI + navn på prosessen. Når vi mottar innspill, gjennomgår vi dem og legger dem inn fortløpende i den aktuelle prosessdefinisjonen.
6 Brukere og deres behov
Alle prosesser har en eller flere brukere. Fyll ut brukerne og hvilke behov prosessen skal dekke. Når vi beskriver brukerne og deres behov får vi også svar på hvorfor vi trenger prosessen. Hva formålet/hensikten er.
| Brukere | Når | Hvorfor | Forventninger |
| Kjøper | Behov for å få eKvittering ved kjøp av varer og tjenester. Behov for å bruke eKvittering i ulike sammenhenger, tilstøtende prosesser. | Behov for å forenkle og effektivisere mottak og bruk av kvitteringer. | Forventer å motta maskin-lesbar informasjon med riktig kvalitet i et standard format slik at man kan automatisere egen bruk av eKvittering (egne prosesser). |
| Selger | Når kvittering skal gis til kjøper | Forenkle og effektivisere egen kvitteringsprosess. Markedsføre tjenester. Forenkle revisjon. | Forventer at det er mottakere og systemer for digital overføring. |
| Skattemyndigheter i begge land | Når de trenger rapporter. | > Skattemyndighet: Korrekt MVA. Automatisert prosess for å redusere kostnader. > Bekrefte at informasjon fra selger og kjøper er korrekt. | Feilfri informasjon. Transparens. |
| Selgers system (Kasse og andre) | Kommunisere interne data til eksterne systemer. Dersom de bruker systemer for å rapportere til skattemyndigheter i eget land. | Mer forretning. | Mer effektive prosesser. |
| Service providers, Tjeneste/system leverandører(ERP) | Når transaksjoner skal overføres mellom systemer nasjonalt og mellom land. | Skape mer forretning ved å imøtekomme et markedsbehov. | Gjenbruke en etablert prosess i et nytt forretningsområde. |
| Aksesspunkt | Når kjøper og selger skal utveksle transaksjoner basert på standard format | Effektiv måte å utveksle transaksjoner på. | Mottar riktig strukturert informasjon. |
| Wallet (digital lommebok) | Når kjøper trenger å få overført digital kvitteringsmelding til sin digital lommebok | Tilby nye tjenester på ny teknologi | Riktig strukturert informasjon. |
7 Interessenter
| Interessenter | Interesse |
| Bransjeorganisasjoner | Bidra til en mer effektiv og konkurransedyktig bransje. |
| Kredittkort selskaper | Understøtte ny teknologi som kan bidra til forretningsutvikling. |
| EU | Digital informasjon for bedre dokumentasjon i henhold til lover og regler. Bidra til å forenkle og effektivisere hverdagen for virksomheter og brukere. |
| Offentlig sektor i Norge | Digital informasjon for bedre dokumentasjon i henhold til lover og regler. Bidra til å forenkle og effektivisere hverdagen for virksomheter og brukere (offentlig sektor). Bidra til økt digitalisering og tjenesteutvikling. |
8 Mål for prosessen
| Mål | Indikatorer | Måtall/resultat |
| Kvalitet: Komplett og riktig informasjon i alle prosesser. | Førstegangskvalitet (en indikator som forteller hvor stor andel kvitteringer som går gjennom prosessen ved første gangs forsøk uten feil, mangler. | 100% |
| Tid: Minst mulig bruk av tid fra kunde betaler til kunde mottar kvittering. Og i kundens eget bruk av eKvittering. | Ledetid | Vil kunne variere. Må måles og vurderes i hver prosess. Men bør generelt sett kunne gjennomføres på sekunder. |
| Ressursbruk: Frigjør tid til andre oppgaver, eventuelt redusere lønnskostnader | FTE (Full Tids Ekvivalenter) Lønnskostnader | Vil kunne variere. Må måles og vurderes i hver prosess. |
| Forenkling: Redusere og gjøre antallet trinn enklere: | Medarbeidertilfredshet med prosessen | 100% |
| Forenkle og effektivisere transaksjoner på tvers av landegrenser. | Antall systemer som håndterer prosess og format. | Må måles og vurderes i hvert enkelt tilfelle. |
9 Fordeler/gevinster
| Hvem kan ha fordel | Hvilke fordeler de kan oppnå |
| Kjøper | Sikre data. Trenger ikke tenke på forskjellige land, interoperabilitet. Automatisert bokføring. Informasjon kommer ikke til å forsvinne/gå tapt. Enklere å beregne miljøfotavtrykk gjennom informasjonsfelter i kvitteringsmeldingen. |
| Selger | Back-office prosesser mer effektive. Lojalitetsprogrammer enklere å administrere. Markedsføringskanal.. Rapportering – for eksempel miljødata. |
| Offentlige myndigheter | Reduser risikoen for svindel. Mer effektive måter å kontrollere. Data mer tilgjengelig i sanntid. Mulighet for mottak av rapportering av innhold i meldingen eks. MVA og miljø |
| eKvitteringsoperatører | Flere transaksjoner. Lag flere tjenester. Salg av data og analyser. |
| Peppol-kompatible og Wallet tjenesteleverandører | Nye tjenester å selge. Økt inntekt. Nye kunder. |
10. Utløsere og forutsetninger
| Utløser/trigger | Grunnleggende prosess for: P1: Kjøp av varer og tjenester: Igangsettes når det oppstår behov for kjøp av varer og tjenester P2: Match av eKvittering mot faktura: Igangsettes når faktura mottas. P3: Refusjon av MVA: Igangsettes når ev. regler for når man kan sende inn krav om refusjon er oppfylt – tidspunkt, beløp. P4: MVA rapportering ved bruk av ViDA report: Igangsettes når kjøper mottar eKvittering eller faktura for kjøp av varer og tjenester hvor MVA skal rapporteres til skattemyndighetene. |
| Forutsetninger | > Selger må ha eKvitterings tjenester (POS som kan sende transaksjonsdata til andre systemer). > Kjøper og selger må ha et system som er kompatibelt med eKvittering-format og mulighet for å sende transaksjoner gjennom Peppol-nettverk, APIer, Wallet teknologi(block chain). > Unik ID for virksomhet som sender og mottar. > Hvis eKvittering kan benyttes som MVA rapporteringsformat, må skattemyndighetene ha et system som mottar MVA informasjon basert på standard format. Kobling til økosystem. Se VIDA report prosessen. > Mottaker av eKvittering medlinger må være registrert i Peppol Nettverk – SMP og SML, eller andre løsninger. Mulig å sende og motta transaksjoner. > Tjenesteleverandører må ha kunnskap/kompetanse om standard transaksjonsform (Peppol Nettverk, Wallet osv). > Norske forskrifter: >> Norwegian regulations: Norwegian regulations >> Norwegian regulations >>> https://lovdata.no/forskrift/2009-10-01-1226/§18 >>> https://lovdata.no/forskrift/2009-10-01-1226/§17 > I tilfelle internasjonale transaksjoner også: >> Svenske forskrifter: Swedish regulations: >>> Lag (2007:592) om kassaregister m.m - Riksdagen >>> Taxitrafikfõrordning ( 2012:238) - Riksdagen > Finske forskrifter: Finnish regulations: >> https://www.finlex.fi/sv/laki/alkup/2013/20130658?search%5Btype%5D=pika&search%5Bpika%5D=658%2F2013 > Danske forskrifter: Danish regulations: >> Danish law about electronic cash register > I tilfelle rapportering av MVA basert på kvitteringsmeldinger må skattemyndighetene ha systemer for å motta informasjon. |
11. Input og leverandører
Dette er en samlet oversikt over input man trenger for å starte prosessen. Prosesser krever flere typer input/ressurser for å kunne utføres som kan leses ut av diagrammet dersom man ser på aktivitet for aktivitet. Se prosessdiagrammene for hvilke prosesser som benytter hvilken type input.
| Input | Navn på prosess | Navn på leverandør/avsender | Referanse |
| P1: Behov for varer og tjenester | Virksomhetsprosess | Kjøper | |
| P1: Kort eller Firma kort (Company card (pre-paid is like cash) | Virksomhetsprosess | Kjøper | |
| P1: Selskapets retningslinjer/kontrakt, Plassering av tilgjengelige bensinstasjoner | Kjøper og/eller offentlige myndigheter | ||
| P1-P4: Unik firma ID (i Norge org.nr) | Kjøper | Organisasjons nummer. GLN og andre. | |
| P2, P3, P4: eKvittering og faktura | Datalagringssystem | Kjøper, interne prosess |
12 Deltakere
Dette er en oversikt over ulike organisasjoner og roller. Slett de som ikke deltar i prosessen. Og legg til nye om nødvendig.
| Organisasjon | Rolle (om nødvendig) | Forkortelser | Kommentarer |
| Oppdragsgiver | O | O betyr at aktivitet utføres av oppdragsgiver | |
| Aksesspunkt oppdragsgiver | O-AP | O-AP betyr at aktivitet utføres av oppdragsgivers aksesspunkt | |
| Leverandør | L | L betyr at aktivitet utføres av leverandør | |
| Leverandør aksesspunkt | L-AP | L-AP betyr at aktivitet utføres av leverandørs aksesspunkt | |
| Kjøper | K | K betyr at aktivitet utføres av kjøpers virksomhet | |
| Kjøper | Person | K-per | K-per betyr at aktiviteten utføres av en person hos kjøper. |
| Kjøper | System | K-sys | K-sys betyr at aktiviteten utføres av et system hos kjøper. |
| Selger | S | S | S – betyr at aktivitetene utføres av selgers virksomhet. |
| Selger | Person | S-per | S-per betyr at aktiviteten utføres av en person hos selger. |
| Selger | System | S-sys | S-sys betyr at aktiviteten utføres av et system hos selger. |
| Tjenesteleverandør (POS, regnskap, etc.) | SL | SL is used when there is a need to indicate that the activity is performed by a service provider. As a rule, there is no need to specify the role that the activity of the system supplier performs | |
| Selger aksesspunkt | S-AP | S-AK betyr at aktivitet utføres av selgers aksesspunkt | |
| Skattemyndigheter | SK | SK betyr at aktivitet utføres av skattemyndigheten i det enkelte land |
13 Prosessdiagram
Overordnet diagram
Diagrammet beskriver de 4 prosessene som er nærmere detaljert i vedlagt Excel-ark.
Vedlagt et Excel ark med detaljerte tegninger av hver enkelt prosess. Ett diagram i bildeformat for klipp og lim og ett diagram i Visio format for de som har Visio eller kan importere Visio filer til eget system. Diagrammene er lagt inn over/under hverandre i samme arkfane.
OBS! For å åpne diagram i Visio sett peker i diagram og høyreklikk. Du får en meny hvor det står Visio-objekt. Velg åpne. Da får du diagrammet åpnet i Visio.
14 Aktiviteter
Dette er en beskrivelse av aktivitetene i prosessene som du finner i diagrammene i Excel-arket
| Id | Aktivitet | Ansvarlig | Beskrivelse: | SP (x) | Kommentarer |
| Prosess 1: Kjøp av varer og tjenester med eKvittering | |||||
| 1. Bruk kort | K | ||||
| 2. Registrer betaling i system (POS) | S | Kan skje automatisk eller manuelt for eksempel av en selger | |||
| 3. Aksepter beløp | K | ||||
| 4. Lagre informasjon | S-sys | Lenke til lovdata | |||
| 5. Lag kvittering | S-sys | ||||
| 6. Map kvitteringsdata til standard eKvittering format | S | ||||
| 7. Send eKvittering til aksesspunkt | S-sys | ||||
| 8. Oppslag mot digital adresse register (SML, SMP) | A | ||||
| 9. Send til mottaker | S-AP | ||||
| 10. Overfør eKvittering til kundens reise-økonomisystem | K-AP | ||||
| 11. Lagre eKvittering i regnskap-/økonomisystem | K-sys | ||||
| 12. Skrive ut papir -kvittering m/QR kode | S-sys | ||||
| 13. Motta papirkvittering m/QR-kode og eventuelt, scan og legg i Wallet og overfør denne til arbeidsgivers system | K-sys | ||||
| Prosess 2: Match av eKvittering mot faktura | |||||
| 1. Sammenlign eKvittering med fakturalinjer | K-sys | ||||
| 2. Sjekk og/eller legg til informasjon | K | ||||
| 3. Aksepter faktura og forbered utbetaling | K-sys | ||||
| Prosess 3: bruk av eKvittering for refusjon av MVA | |||||
| 1. Sjekk om produkter/tjenester er refunderbare basert på standard spesifikasjon f.eks UNSPC | K-sys | ||||
| 2. Separer nasjonale eKvitteringsmeldinger fra utenlandske | K-sys | ||||
| 3. Grupper pr. land | K-sys | ||||
| 4. Kalkuler hvert lands VAT | K-sys | ||||
| 5. Beslutt hvilke format som skal benyttes | K-sys | ||||
| 6. MAP eReceipt til format (SAF-T, SIE.SE. XBRL.FI?) | K-sys | ||||
| 7. Fyll ut MVA refusjons skjema og legg ved eKvitteringsmeldinger og/eller faktura | K-sys | ||||
| 8. Sjekk om utfylt skjema er korrekt i henhold til format (hvis XML). | K-sys | ||||
| 9. Korriger informasjon | K-sys | ||||
| 10. Send søknadsskjema og kvitteringsmeldinger til skattemyndigheter. (EU medlem sender til egen skattemyndighet. EØS/EU sender direkte til skattemyndigheter i landet du har handlet) | K-sys | ||||
| 11. Sjekk om søknadsskjema er korrekt i henhold til format. Hvis ikke sjekk og ev. korriger manuelt. | SK | ||||
| 12. Sjekk om søker er et lovlig registrert firmabasert på organisasjonsnummer (Kjøper og selger) | SK-sys | ||||
| 13. Sjekk om produkter/tjenester er refunderbar basert på standard klassifisering for eksempel UNSPC. | SK-sys | ||||
| 14. Varsle kjøper om avvik og korriger informasjon | SK-per | ||||
| 15. Valider om eKvittering er korrekt | SK-sys | ||||
| 16. Revisjon hvis noe er uklart ved situasjonen og beslutte om man skal akseptere, avvise eller delvis akseptere | SK-per | ||||
| 17. Beslutning om refusjon | SK-sys | ||||
| Prosess 4: Bruk av eKvittering ved rapportering av MVA og bruk av ViDA report process. | Lenke til ViDA report prosessen | ||||
| 1. Lag en faktura basert på mottatt ordre fra kunde/oppdragsgiver, kontrakt og en leveranse og mottak av leveransen | L-sys | ||||
| 2. Valider faktura i henhold til format EHF/Peppol BIS billing | L-AP | ||||
| 3. Mapp informasjon fra faktura/kvittering til ViDA report format transaksjon | L-AP | ||||
| 4. Utfør et oppslag mot adresseregister ELMA (SMP-SML) | L-AP | ||||
| 5. Forbered respons/bekreftelse for mottatt ViDA report | SK | ||||
| 6. Lagre ViDA report | SK | ||||
| 7. Lagre MLR | A-L | ||||
| 8. Analyser mottatt faktura/kvittering | O-AP | ||||
| 9. Mapp informasjon fra faktura til ViDA report format transaksjon | O-AP | ||||
| 10. Forbered forsendelse av faktura eller foreta en mapping til mottakende systems format | O-AP | ||||
| 11. Sammenlign faktura mot ordre som er sent og varer og tjenester som er mottatt | O-sys | ||||
| 12. Forbered utbetaling for mottatte varer og tjenester | O-sys | ||||
| 13. Forbered respons/bekreftelse for mottatt ViDA report | SK-sys | ||||
| 14. Lagre ViDA report | SK-sys | ||||
| 15. Lagre MLR | O-AP |
15 Sjekkpunkter
Her skal sjekkpunktene merket med x i punkt 14 beskrives.
| Aktivitet | Hva skal sjekkes | Hvordan sjekke | Hvorfor sjekke |
| Ingen | |||
16 Output og brukere
Beskriv prosessens output - det produktet / leveransen som brukeren mottar. Dersom du vet hvilken prosess produktet skal brukes I, skriver du navn på prosessen. Og/eller navn på personer/roller, organisasjoner. Bruk fellesbetegnelser når det er mange mottakere og brukere, og oppgi navn der det er aktuelt, for eksempel Brønnøysundregistrene.
| Output/leveranse | Navn på prosess som benytter output | Navn på mottaker / bruker | Referanse |
| P1: eKvittering, papirkvittering | |||
| P2: Akseptert/godkjent faktura klar for utbetaling | |||
| P3: Søknadsskjema og eKvittering, refusjon klar for utbetaling | |||
| P4: ViDA report |
17 Sluttkriterier
Ingen
18 Unntak og alternativer
| Hvor I prosessen | Unntak/alternativer som kan velges med begrunnelse |
| Ingen. | |
19 Risiko
Beskriv eventuelle risikofaktorer og hvor sannsynlige og alvorlige de er ned på aktivitetsnivå. Bruk lav, middels, høy på begge. Beskriv også hva som kan gjøres for å forhindr at noe galt skjer. Og hva som kan/må gjøres hvis det skjer. Skriv inn eventuelle referanser.
| Id + Aktivitet | Risiko | Sannsynlighet | Alvorlighet | Metode for å forebygge | Tiltak hvis risiko oppstår |
| Selge eKvittering data uten tillatelse. | Lav | Høy | Sikringstiltak | ||
| Sende data to ganger/hvis feil | Lav | Lav | Mottaker må ha kontroll på ID, slik at det ikke er noen duplikater. | ||
| Mangler system støtte | Lav | Høy | SLAer, Service level agreement som stiller krav til tilgjengelighet. | ||
| eKvitteringsidentifikator og fakturaidentifikatorer ikke matcher | Medium | Medium | Validator tjenester | Manuell sjekk | |
| Feil MVA grunnlag (bevisst/ubevisst) | Lav | Høy | Sikre identifikatorer | Sjekk om søker er lovlig registrert firma, og at de søker på varegrupper som er refunderbare. |
20 Behov for støtte
Beskriv eventuelle behov for støtte som de som utfører prosessen må ha.
| Støtte | Beskrivelse / Lenker |
| Opplæring i prosess og system. | |
Kobling til standardformat/spesifikasjon
NSG&B eReceipt spesifikasjonen er ikke formel godkjent som en standard. Spesifikasjonen bygger på Peppol BIS billing 3.0 og bruker additional item properties for spesifikk kvitteringsinformasjon. Spesifikasjonen er pilotert av Nordic Smart Government & Business
Lenke: https://nordicsmartgovernment.org/ereceipt-specification
Prosessen Digital rapportering av MVA baserer seg på en pilot utført av Nordic Smart Government & Business. Spesifikasjonen ViDA report er en pilotspesifikasjon som ble brukt av Nordic Smart Government & Business i samme pilot for overføring av MVA informasjon til alle Nordiske skattemyndigheter basert på mottatt Peppol BIS faktura.
Lenke: https://nordicsmartgovernment.org/vida-report-specification
22 Ytterligere informasjon
Klikke her for å se de ulike brukerhistoriene.
23 Vedlegg
No