12.05.2011 09:02
Elektronisk faktura – nå nærmer det seg
Av Jon Hovland - Avdeling for IKT og fornying
Noen ganger er det som er smart å gjøre, så innlysende at det bare er en fest å sette i gang. Faktura til det offentlige er et slikt tema. Det offentlige mottar i alt et tjuetalls millioner fakturaer i året. Av dette mottok staten i 2008 5,2 millioner fakturaer, tallet er nok noe høyere nå. En stor del av dette går på papir. Det vil si: Skrives ut fra et regnskapssystem, sendes i posten, skannes inn elektronisk og skrives så manuelt inn i regnskapssystemet til staten eller kommunen.
Selv om samfunnsøkonomiske analyser alltid ligger i bunnen, trenger en ikke være økonom for å skjønne at det er milliarder å spare her. Vi har jobbet med dette i flere år, og nå nærmer vi oss en bedre løsning med stormskritt.
Direktoratet for forvaltning og IKT (Difi) har etablert en standard for elektroniske fakturaer – EHF (Elektronisk handelsformat). Dette er en xml-basert standard for hva fakturaen skal inneholde og hvordan. Statlige virksomheter skal fra 1. juli 2011 være i stand til å ta imot elektronisk fakturaer på EHF. Ikke alle kommer til å rekke det, men de aller fleste er nå på god vei.
Felles infrastruktur
I tillegg bereder vi grunnen for en felles infrastruktur for formidling gjennom såkalte aksesspunkt. Dette er bygget på et elektronisk adresseregister som staten kommer til å forvalte, samt avtaler om standarder for formidling av fakturadokumenter som bygger på et europeisk samarbeid.
Dette innebærer at det ikke vil være nødvendig å ha enkeltavtaler mellom hver enkelt mottaker og avsender om hvem de skal bruke som formidler. Alle formidlere som går med på betingelsene for å bruke statens adresseregister, vil få lik tilgang og vil kunne kalle seg aksesspunkt.
Vi regner med at denne infrastrukturen vil begynne å feste seg i løpet av høsten, kanskje også tidligere. Vårt ønske og antakelse er også at denne infrastrukturen vil bli tatt i bruk i privat sektor, og å bidra til at næringslivet får en enklere jobb.
Videre framover
Fra neste år tar vi sikte på et pålegg om at alle fakturaer skal formidles elektronisk til staten. Her er det stadig noen uavklarte tema, slik som behov for krytpering av noen typer fakturaer, løsning for småleverandører som ikke har avanserte regnskapssystem og ikke minst hvordan pålegget konkret skal innrettes. Det blir en del jobb, men vi regner med at dette vil løse seg.
Dessuten ser vi at det vil være mye å hente for kommuner og fylkeskommuner og deres leverandører. Derfor har vi satt i gang en egen samfunnsøkonomisk utredning av konsekvenser av eventuelle tiltak overfor kommunal sektor, og om det vil være fornuftig å foreta seg noe mer aktivt i den retningen. Den utredningen vil være klar i slutten av september.
Uansett hvordan disse tingene kommer til å se ut: Vi er nå i ferd med å sette standarden for elektronisk formidling av handelsdokumenter, slik som faktura. Det er all grunn til å tro at når vi nå har både fakturabransjen og de offentlige virksomhetene med oss, vil standarden bre om seg. Takket være en profesjonell og framtidsrettet bransje, et driftig og innovativt direktorat og en vilje til standardisering er det snart enda en grunn til å kvitte seg med skriveren.
PS: Om du representerer en offentlig virksomhet eller en leverandør eller ønsker å opprette et aksesspunkt for formidling av faktura, arrangerer Difi egne informasjonsforum. Kontakt Difi for mer informasjon.




Kjempebra! Må si at jeg gjerne skulle ha hatt dette på plass for lenge siden, men er uansett bra at dette er et fokuspunkt. Lavthengende frukter som dette her er er viktig å kapitalisere på. Fortsett å press på for liknende løsninger i alle ledd.
Så hyggelig! Takk skal du ha. Vi fortsetter å presse på.
(Frukten viste seg å ikke henge lavere enn at vi måtte bygge en stige først. Men vi gjør det som skal til, vi.)
Spennende tiltak! Hvordan er dette forskjellig fra eFaktura som aktører i banksektoren tilbyr? Har DIFI samarbeidet med det miljøet?
Enda en hyggelig melding. Du verden.
Jo, Difi har god dialog med nets (tidl. BBS) og bankene. Vi snakker ikke her om alternativ ordning istedenfor eFaktura, men en tilrettelegging. Så bankenes eFaktura-avtaler vil bestå slik vi møter det som brukere (eller sagt på en annen måte – det vet jeg ingenting om, det er bankenes business, men det er jo ingenting som tyder på noe annet). Men dersom bankene er frampå vil de kunne få økt volum på digital formidling ved å tilpasse seg infrastrukturen som staten nå legger til rette for.
Jeg stiller meg litt i det kritiske hjørnet som vanlig.
Det skrives at ”Fra neste år tar vi sikte på et pålegg om at alle fakturaer skal formidles elektronisk til staten.”. Personlig har jeg hatt lyst til å stille et slikt krav til mine personlige fakturaer. Det har jeg selvfølgelig ikke mulighet til. Offentlige aktører er de som ofte har vært sist med å innføre mulighet for e-faktura. Jeg synes det derfor er betenkelig at det offentlige fra å være sinke med å tilby e-faktura, fort skal stille krav om e-faktura fra andre.
Jeg synes derfor det er for tidlig med et slikt krav til neste år. Dersom et slikt krav skal innføres må det etter min mening være balanse i kravene. Det betyr at det også må stilles krav til det offentlige om å tilby e-faktura.
Takk for innspill, Vivi.
Jeg synes det er mye fornuft i det du skriver. Samtidig, selv om det høres ut som to sider av samme sak, er det veldig ulike prosesser å kreve elektronisk faktura fra private og offentlige leverandører på den ene siden, og på den andre siden å se til at privatpersoner og virksomheter får tilsendt elektronisk faktura. I det første tilfellet har staten mye større muligheter for tilrettelegging av systemene. Dessuten, selv om jeg henger med på rettferdighetstankegangen, er det en dårlig idé å fortsette ineffektiv drift på ett område fordi et annet hadde vært like viktig.
Når det er sagt, tror jeg alt i alt du har helt rett: Vi bør se på elektronisk faktura fra staten, det gir ikke mening å sende ut papirpost når folk ikke vil ha det. Mulig det kommer noe mer på denne bloggen om det i løpet av våren.
Innlegget over viser ovenfra og ned holdning overfor den som har gitt kommentaren som kommenteres.
Synes du? Det var i tilfelle virkelig ikke meningen. Jeg beklager. Det var et forsøk på å komme i møte og vise noe hva som er tenkt rundt det.
Viktig at det blir efaktura begge veier. Kong Salomo må også kunne sende e-faktura til Jørgen Hattemaker, i dag kommer det papirfaktura fra NAV og Skatteetaten på syketrygd og forskuddsskatt osv. bare 2-3 uker før forfall. Det skal ikke mye rot til i posten før det skaper problemer, spesielt i ferietider. Og gjett hvem som får problemer hvis betalingsfristen overskrides…
Hvis dette ble en diskusjon «for eller mot elektronisk faktura begge veier», så snakker vi nok litt forbi hverandre her. Jeg er helt enig i at det er viktig, og irriterer meg selv over alt jeg ikke kan få digitalt (for før jeg vet ordet av det er det borte i en haug med reklame).
Men da kan jeg kanskje sende en utfordring tilbake: Hvordan bør innkrevingen komme? Er det bare bank som gjelder? Hva bør uansett komme på papir? Hvilke instanser er det greit å få elektronisk fra? Når kan virksomhetene ta det for gitt at mottaker aksepterer elektronisk faktura?
Her er det mye regelverk som gir svarene i dag, men det ville være interessant å høre hva dere mener.
Bank vil være «autostradaen» for dette, og staten kan med fordel bruke energiselskapenes modell, de var jo blant de første til å tilby valg mellom efaktura og avtalegiro når man betaler første papirfaktura i nettbanken.
Det er viktig å få denne muligheten fra alle offentlige myndigheter og tjenester som er obligatoriske og der unnlatelse å betale medfører sanksjoner, som skatter og avgifter. Deretter frivillige ordninger, som syketrygd for selvstendig næringsdrivende.
Med tanke på faktura G2C (faktura fra det offentlige til borgeren) så vil dette kunne styres gjennom søknad/samtykke slik som det idag gjøres for eFaktura i bankene.
Hvis en vil ta det et steg videre for det offentlige kan en tenke at et fremtidig samtykkeregister også håndterer samtykke til/aksept for bruk av elektronisk faktura for de offentlige instanser som benytter/vasker mot samtykkeregisteret. Se også egen kommentar om samtykkeregister på http://blogg.regjeringen.no/fiks/2011/11/04/en-felles-digital-postkasse/comment-page-1/#comment-687
Hei, og beklager sent svar. Jeg er for tiden paa gjesteopphold i utlandet, saa jeg er ikke 100 pst oppdatert, og har nok ikke helt oversikt over hva kollegene hjemme har foretatt seg.
Jeg er helt enig med deg, et samtykkeregister for elektronisk faktura fra det offentlige ville paa mange maater loese alt.
Men det er ikke minst en ting vi maa ha svar paa: Et slikt register ville innebaere at man ved ett klikk godtar aa motta faktura fra alle statlige (og kommunale?) virksomheter rett i nettbanken. Er det lov, vil bankene godta det, og hvis ikke – er det gode grunner for det?
Personlig vet jeg at jeg ville forstaa hva klikket innebar, og at jeg ville oenske det. Men hvor sikre maa vi vaere paa dette? Maa vi differensiere dersom innbyggerne har ulik grad av tillit til ulike statlige virksomheter? Disse spoersmaalene trenger svar.
Hei, Jon!
Jeg var for noen år siden med å tilrettelegge krypterte vaksinasjonsmeldinger fra helsestasjoner til Folkehelsa via Norsk Helsenett.
Selve vaksinasjonsmeldingen var en fil i en mappe på helsestasjonens Microsoft Windows-maskin, et lite Perl-skript tok meldingen og gav den til den frie programvaren GNU Privacy Guard og krypterte den på helsestasjonens maskin.
Skriptet tok så kontakt via FTP gjennom Helsenettet med Folkehelsa og leverte meldingen i en mappe der.
Et skript hos Folkehelse tok tak i den mottatte meldingen, dekrypterte vaksinasjonsmeldingen, og sendte en kvitteringsfil – melding mottatt – tilbake til helsestasjonens system via FTP.
Bytt ut vaksinasjonsmeldingen med faktura-filer og du har en løsningen basert på fri programvare for ethvert fakturasystem innen jul.
Her er hjemmesiden til GNU Privacy Guard http://www.gnupg.org/ og her er hjemmesiden til Perl – http://www.perl.org/ .
Begge er naturligvis tilgjengelig for de mest brukte operativsystemene – GNU/Linux og de andre.
Beste hilsen
Haakon Meland Eriksen, Drammen
Hei,
GNU/Linux og de andre, ja
Tenker du da som et system for utsending av faktura mellom offentlige virksomheter, eller generell utsending av faktura?
PS. Jeg rettet trykkfeilen og slettet kommentaren der du gjorde oppmerksom på den. Håper det var ok.
Hehe – det franske politiet har GNU/Linux på skrivebordet og det kan vi her også, men det er en annen sak.
Jeg tenkte på det du skrev under «Videre framover», at små leverandører også skal få til dette fra og til sine systemer. To av tre foretak i Norge har eier som eneste ansatt. Foretak med mer enn 100 ansatte utgjør bare en halv prosent av foretakene. Det er litt i underkant av en halv million foretak i Norge. Mange av disse bruker høyst sannsynlig bare regneark, eller et eller annet rimelig og enkelt system. Om leverandøren av systemet har nok kunder til å betale for å legge til støtte for e-faktura er jeg noe usikker på.
Hvis det var slik at alle disse små kan få noen av komponentene som trengs som fri programvare, så tror jeg tilpasninger kan bli gjort og gjennomført innen tre til fem år hos disse små.
Vaksinasjonsmeldingen greide journalsystemet å opprette og lagre i en mappe.
Dette var så vidt jeg husker en tekstfil der informasjonsfeltene var adskilt med komma eller semikolon (Comma Separated Values – CSV). Et regneark fra dere, som dere vet følger fakturamalen og som dere vet kan lagres som CSV vil være til stor hjelp for disse små.
Problemet med CSV er at filen inneholder ingen hjelp som forteller hva hvert felt gjør eller strukturen mellom dem. Den informasjonen sitter utenfor filen. En fordel er at det sparer plass – filen blir mindre.
Dere har valgt å legge inn markører i filen som forteller hva hvert felt er og hvordan disse er strukturert, såkalt XML. Dokumentasjonen av dette er god, så vidt jeg kunne bedømme, og store leverandører vil klare dette rimelig raskt, mens små vil bruke lang tid eller ikke i det hele tatt.
Uansett, XML betyr at «noe» må klare å legge riktige markører rundt hvert informasjonsfelt og på en slik måte at strukturen mellom dem ivaretas. Dette tar mer plass, men er lett for både mennesker og maskiner å fortolke på en sikker måte. Hvis et regneark fra dere kan lagres som riktig XML, så vil dette være helt supert.
Første steg er altså – hva kan du få ut av fakturasystemet? Kan du få ut CSV eller XML? Er dataene i feltene overhodet riktig? I de store systemene kan du forvente det, mens i de små er kanskje så som så?
Begge deler kan behandles av en liten tilleggskomponent for å få ønsket XML-format før transport, dersom direkte eksport ikke er mulig.
GNU Privacy Guard kan så signere meldingen med avsenders elektroniske signatur og kryptere den med mottakers offentlige krypteringsnøkkel. Mottaker dekrypterer meldingen med sin private nøkkel og sjekker signaturen til avsender mot avsenders offentlige nøkkel. Det springende punkt er egentlig om man stoler på at den offentlige nøkkelen tilhører avsender. De små kan ordne dette ved å ta en tur innom likningskontoret en dag de skal likevel. De kan ta med sin offentlige nøkkel på en minnepinne og få den signert der, og siden bruke den når de signerer fakturaer.
Løsningen med vaksinasjonsmeldinger var som nevnt bygget på File Transfer Protocol – FTP. Denne krever kommunikasjon i begge retninger – en transportkanal og en kommandokanal, og må gjøres på en bestemt måte for å komme igjennom beskyttende brannmurer, som må vite at dette skal være lovlig kommunikasjon. Jeg laget en plan og anbefalte å få dette over på en annen transport sammen med andre meldingstyper, og tror det er gjennomført etter min tid. Her mener jeg de små bør bruke e-post til faktura@min.kommune.no med fakturaen som kryptert vedlegg og få en kvitteringsmelding på mottatt i retur.
Ok, dette ble litt langt, men poenget er at oppgaven kan deles opp i disse stegene:
1. Eksport av fakturainformasjon fra fakturasystemet.
2. Formatering til ønsket format (eventuelt – kan vente til etter mottak).
3. Signering og kryptering med GNU Privacy Guard – helt gratis, men trenger at avsenders nøkkel blir elektronisk signert på f.eks. likningskontoret.
3. Transport – e-post er enkelt og «alle» har det, FTP mer krøllete å få til.
4. Dekryptering hos mottaker med GNU Privacy Guard
5. Fakturamelding hentes over til vanlig mottak som de store benytter.
6. Kvitteringsmelding utstedes fra mottakersystemet.
7. Kvitteringensmeldingen signeres med avsenders nøkkel og krypteres med mottakers offentlige nøkkel – altså fakturautsteders offentlige nøkkel.
8. E-post med kryptert kvitteringsmelding som vedlegg går tilbake til fakturautsteder.
9. Faktura betales.
Tusen takk for grundig tilbakemelding!
Beklager at jeg har brukt lang tid på å svare deg.
For å være helt presis: Vi kommer ikke til å kreve at små virksomheter som bruker enkle regneark må implementere nye tekniske løsninger, uansett hvor billige eller enkle de er.
Løsningen du skisserer er nok svært god, men den forutsetter at alle virksomhetene har mer enn mikroskopisk IKT-kompetanse. Det kan vi dessverre ikke forutsette.
Derfor vil vi i utgangspunktet fokusere på å få opp webfakturaportal, som et lavterskeltilbud.
Og så bør vi nok i tillegg se på en slik løsning som du skisserer. Dette kan være nyttig for virksomheter som ser det som hensiktsmessig.
Jeg sender innspillet til Difi, slik at de kan vurdere om dette er noe å koble inn i prosjektet.
Dere må selvfølgelig tilby et xml API. På den måten kan tredjeparts regnskapsystemer av alle størrelser enkelt kunne sende fakturaer.
Jepp, det gjør vi. All nødvendig dokumentasjon skal ligge på http://www.anskaffelser.no/e-handel/dokumenter/ehandel.no-formatet
Se tredje vedlegg nr. tre i høyre kolonne.
Kanskje mer relevant, verktøykasse for utviklere: http://www.difi.no/anskaffelser/elektronisk-faktura/verktoykasse-for-elektronisk-handel
Vi leverer et system for fakturering, reskontro etc, men i et lite opplag. Skjønner at XML bare er en enkel tekstfil, men skjønner ikke hvordan vi i praksis skal levere dataene (fakturaene). Hvordan kan vi sette oss inn i hvordan vi skal få sendt fakturaene elektronisk? (Vi er ikke web-programmerere, men av den gamle skolen).
http://www.difi.no/anskaffelser/elektronisk-faktura/verktoykasse-for-elektronisk-handel forteller hvilken tekst som må ligge rundt faktura-dataene for å lage en gyldig XML-formatert fakturafil med mer.
Kan man så forutsette at offentlige kontorer i det minste må tilby en «Last opp faktura-fil» via et web-grensesnitt over HTTPS, eller må man implementere sikret sending via kryptert e-post, eller en annen måte?
Hei. Du var nok en gang raskere enn meg
Vi kan ikke forutsette at offentlige kontorer tilbyr en «last opp faktura» på web. Det vi kommer til å gjøre er å se til at det blir mulig å sende faktura gjennom webportal – d.v.s. for dem som ikke allerede har avtale med store regnskapssystemleverandører, de ordner dette på sin egen måte. Med webfakturaportal blir alt som går på formidling og adresse en sak mellom webportal og mottaker. Når det gjelder krytpering, ligger ikke dette inne som et krav per nå, ettersom det i utgangspunktet skal være mulig å holde sensitiv informasjon i kontrakten, og bare ikke-sensitiv informasjon i fakturaen, men her er det mye dårlig praksis, så vi kommer til å se mer på mulige løsninger utover høsten.
Hei.
Se også kommentaren fra Eriksen under, men jeg skjønner spørsmålet ditt er hvordan du skal få sendt fakturaene. Dette er ikke helt på plass ennå, og som en veldig midlertidig løsning kommer Difi til å publisere oversikt over elektronisk adresse for fakturaene på nettsidene sine. Det vi jobber på spreng for å få på plass nå er et elektronisk adresseregister som en kan slå opp i, enten ved å inngå avtale om å bli et såkalt Aksesspunkt for elektroniske fakturaer, eller ved å inngå en avtale med et slikt aksesspunkt. Jeg går ikke i detaljer på det her, Difi jobber med å forenkle aksesspunktfunksjonaliteten slik at det blir anvendelig for flest mulig, det står litt mer om det i blogg-teksten, og det er ellers bare å ta kontakt.