SIE

Ett förslag

2019-03-14/LH

SIE Faktura

1

Innehåll

Innehåll ............................................................................................................................. 1

Sammanfattning ............................................................................................................... 2

Bakgrund .......................................................................................................................... 3

Allmänt om elektroniska fakturor ............................................................................... 3 Nuläget för små och medelstora företag ................................................................................................................................. 3 Trender ...................................................................................................................................................................................... 3 Något om bankernas tjänster ................................................................................................................................................... 4

Vilken information ska finnas med i strukturerad form? ............................................. 4

Inbäddade konteringsförslag .................................................................................................................................................... 5 Alternativa lösningar ................................................................................................................................................................ 6

Framgångsfaktorer ........................................................................................................... 6

QR-kod (usingqr) ............................................................................................................. 6

Datainnehåll .................................................................................................................. 7

QR-koder för Swish ......................................................................................................... 7

E-fakturor inom offentlig sektor ..................................................................................... 8

Svefaktura...................................................................................................................... 8

PEPPOL ......................................................................................................................... 8

Användbarhet i privat sektor ....................................................................................... 9

Internationell utblick ....................................................................................................... 9

ZUGFeRD ..................................................................................................................... 9

Organisationer ............................................................................................................... 10

DIGG Myndigheten för digital förvaltning ........................................................... 10

SFTI ............................................................................................................................. 10

NEA Nätverket för elektroniska affärer ................................................................ 10

Tillväxtverket .............................................................................................................. 11

2

Sammanfattning

Detta förslag går ut på att utvald fakturainformation i PDF-fakturor ges en för-stärkt och enhetlig struktur, genom utnyttjande av metadata. Metadata är informat-ion som ligger inbäddad i filen, men som inte syns vid visning eller utskrift. Ofta re-presenteras metadata som XML eller JSON, vilket gör att enkla etablerade tekniker kan användas både för att skapa och extrahera informationen.

Förslaget innebär att en SIE-faktura innehåller samma strukturerade uppgifter som ibland finns utskrivna på fakturan i form av en QR-kod (usingqr).

PDF innehåller, liksom de flesta filformat, väldokumenterade möjligheter för att bi-foga metadata, och de programbibliotek som används för att skapa och läsa PDF-filer innehåller som regel stöd för läsning och skrivning av metadata.

Eftersom metadata inte inkräktar på presentationsytan kan denna typ av metadata enkelt införas utan att fakturalayouten påverkas. Om ett ekonomisystem kan pro-ducera PDF-fakturor kan man således med en väldigt liten insats etikettera dessa med lämpliga metadata. Investeringen från programtillverkarnas sida är alltså låg.

Förslaget kräver inte någon särskild infrastruktur för fakturaförmedling. Inträdes-kostnaden för både fakturautställare och fakturamottagare är därför noll.

Metadata i PDF-fakturor kan introduceras på bred front utan att de som hanterar fakturorna berörs av att nya metadata tillkommit. Så länge den nya informationen inte används så märks den inte, och redan etablerade rutiner för fakturahantering kan användas. Den nya informationen kan därefter utnyttjas i olika grad beroende på fakturamottagarens teknikmognad.

Införande av standardiserade metadata i PDF-fakturor skulle innebära följande för-delar:

För fakturamottagare/redovisningsbyråer

Merparten av den information som behövs för bokföring av fakturan kan extraheras automatiskt med stor säkerhet. Detta kan göras i fakturamotta-garens ekonomisystem utan att fakturan behöver behandlas av en extern tolkningstjänst, vilket ger snabbare hantering och minskade kostnader.

För fakturautställaren

När fakturamottagaren extraherar reskontradata korrekt ökar chanserna att få betalt i rätt tid, med rätt belopp och med en korrekt fakturareferens.

För företag som utför fakturatolkningstjänster

Om en SIE-faktura kommer in till en tolkningstjänst kan reskontradata ex-traheras enkelt och korrekt.

3

Bakgrund

Allmänt om elektroniska fakturor

En väsentlig faktor för att åstadkomma en effektiv bokföring är att ha en tillförlitlig och effektiv elektronisk verifikationsfångst. Erfarenhetsmässigt utgörs 80-90 % av ett företags verifikationer av fakturor, varav kundfakturorna är enklast att fånga då de är både homogena och elektroniskt producerade (inom det egna affärssystemet).

Leverantörsfakturorna däremot är ofta extremt heterogena, och erhålls som en blandning av pappersfakturor och elektroniska fakturor.

Inom offentlig sektor har man genom krav vid upphandlingar, och nu även genom lagstiftning, kunnat ställa krav på enhetliga elektroniska fakturor. Inom privat sek-tor saknas oftast de påtryckningsmöjligheter som behövs för en total övergång till enhetliga elektroniska fakturor, även om vissa branscher, t.ex. fordonsindustrin och livsmedelskedjorna, har kommit långt.

Nuläget för små och medelstora företag

För mindre och medelstora företag, som vill effektivisera sin leverantörsfakturahan-tering, finns möjligheten att använda scanning och tolkning.

Det är en trestegsprocess med följande steg:

1. Ett pappersdokument scannas (avfotograferas) och blir en rastergrafisk bild. 2. Ur bilden extraheras text med hjälp av algoritmer för teckenigenkänning

(OCR). 3. Ur textmassan extraheras användbar fakturainformation, framför allt avsän-

dar- och betalinformation.

Dessa tre steg utförs oftast av en extern part som specialiserat sig på fakturascan-ning och/eller tolkning. I vissa fall sker scanning hos fakturamottagaren/redovis-ningsbyrån, medan tolkning överlåts åt den externa parten.

Detta sätt att hantera fakturor är dock relativt kostsamt. Scanning och tolkning kostar i dagsläget ca 5 + 5 kronor per faktura. Bokföringslagens krav på att en veri-fikation ska arkiveras i den form den tagits emot1 medför också en kostnad.

Såväl bilden som den extraherade informationen kan hanteras enhetligt, och till viss del automatiskt, i ett system för komplettering, attestering och betalning (faktura-hanteringssystem).

Behovet av komplettering varierar givetvis beroende på fakturans kvalitet och tolk-ningens säkerhet. Eftersom det finns en icke försumbar risk för feltolkning kan automatiseringen inte drivas alltför långt, utan en fel- och rimlighetskontroll i form av ett övervakande mänskligt öga behövs.

Trender

En stark och tydlig trend är att pappersfakturorna i stor utsträckning ersätts av e-postade digitala fakturor i PDF-format. I dessa representeras innehållet redan som

1 Se BFL 7 kap.

4

text, och därmed faller de två första stegen i processen ovan2. Samtidigt faller beho-vet av att arkivera en mottagen handling i pappersformat.

Det kvarstår dock att fakturorna layoutmässigt är otroligt heterogena, vilket försvå-rar och fördyrar tolkning, samtidigt som risken för tolkningsfel fortsatt är onödigt hög.

Ett enklare och enhetligare sätt att extrahera fakturainformation skulle reducera be-hovet av att anlita en extern part för tolkning, reducera kostnaderna för tolkning och radikalt minska risken för feltolkning.

Vår bedömning är att övergången till e-postade PDF-fakturor kommer att fortsätta, för att inom kort helt ersätta pappersfakturan. Med enkla medel reduceras på så sätt både hanterings- och portokostnader. Minskad miljöpåverkan blir en extra bonus. Några nya kostnader uppstår inte för fakturatransporten, då alla företag idag har tillförlitlig infrastruktur för förmedling av e-post.

En PDF-faktura kan hanteras antingen som en traditionell påsiktsverifikation eller som en elektronisk verifikation med extraherbara data. Denna dualitet gör att en PDF-faktura kan hanteras av alla fakturamottagare oavsett digitaliseringsgrad. De minst digitaliserade kan helt enkelt skriva ut fakturan och sätta den i en pärm till-sammans med andra pappersfakturor3.

Något om bankernas tjänster

Stora fakturautställare har vid fakturering till konsument möjlighet att, om motta-garen så önskar, skicka en e-faktura via bankväsendet. Fakturan presenteras då i mottagarens internetbank, och betalning kan utföras utan att någon ytterligare in-formation behöver knappas in.

Vissa banker erbjuder samma tjänst även till företag. Även om det underlättar före-tagets betalningar har detta sätt att ta emot leverantörsfakturor vissa svagheter, som gör att det blir direkt olämpligt att använda:

Det är oklart vad som utgör mottagen verifikation4 och därmed hur arkive-ringsskyldigheten ser ut.

Bankerna erbjuder inte strukturerad fakturainformation på ett sätt som kan underlätta bokföringen.

Vilken information bör finnas i strukturerad form?

Vi föreslår att en SIE-Faktura såsom metadata ska innehålla samma information som QR-koden usingqr (se nedan).

Detta innebär:

Fakturatyp (debet eller kredit)

2 I sällsynta fall representeras innehållet i en mottagen PDF-faktura av en bild, och inte av text, och då krävs givetvis även en OCR-tolkning. Detta verkar dock bli allt mer ovanligt, och vi bortser därför från detta specialfall i återstoden av detta doku-ment.

3 BFL kräver dock att verifikationen arkiveras i den form den tagits emot, så man måste låta bli att tömma inkorgen i mailpro-grammet.

4 Rent formellt är det nog så att banken har tagit emot en elektronisk verifikation för den bokföringsskyldiges räkning. Det som visas i internetbanken är endast en presentation av (delar av) innehållet i e-fakturan, uppiffad med diverse formatering och presentationslogik, oftast i HTML, JavaScript och CSS. Detta får nog betraktas som n

banken mottagit, och som den bokförings-skyldige saknar tillgång till.

5

Företagets namn

Organisationsnummer Fakturanummer eller OCR-nummer Fakturadatum Förfallodatum

Belopp Moms Betalningstyp (pg/bg) Kontonummer

Utöver detta föreslår vi att en markering införs som anger om beloppet kommer att dras automatiskt via autogiro.

Inbäddade konteringsförslag

Det finns givetvis även en möjlighet att fakturautställaren i strukturerad form anger vad fakturan avser, i syfte att skapa automatiska konteringsförslag.

Vi föreslår dock att vi i detta läge avstår från att förse fakturan med sådan inform-ation. Skälen till detta är flera:

1. Hur en faktura ska konteras har fakturautställaren svårt att avgöra, då det är fakturamottagarens avsikt med affärshändelsen som styr hur den ska kon-teras. Ett inköp av skumgummi kan vara avsett för försäljning (varuinköp), som emballagematerial eller för att stoppa en soffa (förbättringsutgift för in-ventarie).

2. En faktura kan innehålla flera slag av varor eller tjänster. Att fullständigt re-dogöra för fakturans innehåll för väldigt långt.

Det finns naturligtvis inget som hindrar att man i framtiden utökar innehållet i me-tadata, så att det på sikt innehåller fakturans totala information i strukturerad form, på samma sätt som SIE-formatet gått från typ 1 till typ 4. Det är dock viktigt att er-bjuda programleverantörerna en låg inträdeströskel, för att initialt uppnå stora vo-lymer.

6

Alternativa lösningar

Ett alternativ skulle kunna vara att man även inom privat sektor övergick till att skicka och ta emot elektroniska fakturor i PEPPOL/Svefaktura-format.

Detta skulle dock medföra stora investeringar och vara intressant endast för företag med en hög digitaliseringsnivå.

Om stora volymer ska uppnås bör man begränsa ambitionerna till den information a

-filformat.

Framgångsfaktorer

För att SIE-fakturor ska bli en framgång krävs:

Att andelen fakturaproducerande programtillverkare/företag är tillräckligt stor för att uppnå en kritisk massa. Här krävs en stark uppslutning inte bara från SIE-föreningens medlemmar, utan även från stora fakturaproducenter typ energibolag och telekomleverantörer.

Att systemen för fakturamottagning verkligen utnyttjar den lätt tillgängliga informationen för att reducera kostnaderna för tolkning/hantering.

Att de som drar nytta av reducerade produktionskostnader inom faktura-hantering medverkar till att driva denna utveckling. Här kan redovisningsby-råer identifieras som en särskilt gynnad grupp.

QR-kod (usingqr)

För att underlätta betalning, framför allt för privatpersoner, förser en del faktura-producenter fakturan med en tvådimensionell streckkod, en s.k. QR-kod. Därmed blir utvald fakturainformation tillgänglig för scanning i mobila enheter, och kan ut-nyttjas i bankernas mobilappar.

Standarden för QR-koder på fakturor togs fram av Visma 20135. Förutom att Visma är en av landets största fakturapro-ducenter så har många stora fakturaleverantörer, t.ex. telekom- och energibolag, infört QR-koder på sina fakturor.

Det är dock bara ett fåtal banker (troligen bara Nordea) som infört stöd för QR-koder i sina bankappar, och tekniken verkar inte marknadsföras särskilt aktivt.

En nackdel med QR-koder är att de upptar värdefullt utrymme på fakturan. Detta ger en stor investeringströskel för de leverantörer som vill införa QR-koder. För att införa QR-koder i ett faktureringsprogram måste nämligen hela fakturalayouten ses över.

Standarden är en öppen standard6, men den officiella webbplatsen verkar vara tagen ur drift.

QR-kod på fakturor kan rent teoretiskt användas vid scanning/tolkning av fakturor för att ersätta, komplettera eller bekräfta annan tolkning.

5 Infördes i Visma Administration 5.5

6 http://www.usingqr.se/

7

Datainnehåll

QR-koden som skrivs ut på fakturan innehåller följande:

Fakturatyp (debet eller kredit) Företagets namn Organisationsnummer

Fakturanummer eller OCR-nummer Fakturadatum Förfallodatum Belopp Moms

Betalningstyp (pg/bg) Kontonummer

Datainnehållet är alltså helt anpassat för svenska förhållanden.

QR-koder för Swish

Bankerna har, genom Swish-samarbetet, tagit fram en egen QR-kod7 för betalningsinformation, som på-minner om Vismas initiativ.

Datainnehållet i denna kod är dock mer begränsat. Betalningsvägen är endast Swish, och betalningsin-formationen behöver inte avse en faktura. Därmed kan denna kod användas även för kontantköpslik-nande situationer, t.ex. biljettköp.

7 www.getswish.se/qr

8

E-fakturor inom offentlig sektor

Offentlig sektor i Sverige har en lång tradition inom e-handel. Grunden var ur-sprungligen handelsdokumenten inom UN EDIFACT. Dessa standarder visade sig dock tidigt vara stora och ohanterliga, och ett arbete med att ta fram hanterbara delmängder gjordes tidigt. Olika delmängder av handelsdokumenten (som omfattar mycket mer än bara fakturor) har tagits fram under beteckningarna EDIT och SFTI (Single Face To Industry).

För att ytterligare förenkla och för att få upp volymerna infördes Svefaktura, som ytterligare eliminerar varianter, framför allt på teknisk nivå. Med Svefaktura inför-des också ett kraftigt förenklat konsensus-baserat avtalsförfarande. Den som skickar en Svefaktura anses helt enkelt ha accepterat Svefaktura-avtalsvillkoren.

Idag utgörs 63 % av alla fakturor till statliga myndigheter av elektroniska fakturor. Motsvarande siffra för kommuner och landsting är 50 %.

I bl.a. Danmark har man lagstiftningsvägen kommit upp i betydligt högre andelar, och genom ett EU-direktiv ställs nu krav på motsvarande lagstiftning inom övriga EU-länder.

Svefaktura

Svefaktura8 är ett XML-baserat fakturaformat, framtaget av SKL, och baserat på SFTI. En Svefaktura innehåller endast elektroniskt läsbar (strukturerad) fakturain-formation, d.v.s. det är upp till fakturamottagarens programvara att presentera fil-innehållet på ett vettigt sätt.

SFTI har tagit fram en s.k. referensstilmall, för att göra det möjligt att på begäran kunna visa upp fakturor och kreditnotor i ett referensformat och utan informations-förlust.

SFTI har även tagit fram en webbaserad verifieringstjänst Svefaktura. Tjänsten är främst tänkt som stöd för utvecklare och vid uppföljnings av orsaker till problem vid meddelandeutväxling.

PEPPOL

För alla offentliga upphandlingar som påbörjas efter den 1 april 2019, inklusive di-rektupphandlingar, gäller ett lagkrav om den upphandlade myndigheten ska kunna ta emot e-fakturor enligt den europeiska standarden PEPPOL9, som är en paneuro-peisk motsvarighet till Svefaktura.

Alla leverantörer till offentlig sektor måste skicka e-fakturor som följer den nya europeiska standarden, om man inte har avtalat om någon annan standard. PDF-fakturor eller inskannade pappersfakturor räknas inte som e-faktura. Ett företag som efter flera påminnelser ändå inte fakturerar enligt de nya lagkraven kan få före-läggande om att betala vitesbelopp.

Lagen gäller även för de flesta kommunala och landstingsägda bolag, samt för en del statliga bolag.

8 Aktuell version av specifikationen kallas Svefaktura BIS 5A 2.0

9 I Sverige heter standarden PEPPOL BIS Billing 3.

9

Standarden föreskriver även en reglerad infrastruktur för fakturatransport. Leveran-tören måste därför använda ett ekonomisystem som är accesspunkt till PEPPOL.

Några lättnadsregler förekommer:

Om parterna har avtalat om en annan e-fakturastandard än den europeiska, kan leverantören fortsätta skicka fakturor enligt avtalad standard.

För mindre leverantörer ska myndigheten tillhandahålla en portal (webb-sida), där leverantören manuellt kan registrera fakturan.

De leverantörer som idag använder Svefaktura BIS 5A 2.0 kan utan större svårighet gå över till PEPPOL BIS Billing 3.

Användbarhet i privat sektor

För de företag som levererar till offentlig sektor blir det, som framgått ovan, i prin-cip obligatoriskt att leverera elektroniska fakturor i Svefaktura/PEPPOL-format, och dessa företag måste investera i programvara som klarar detta.

Svefaktura/PEPPOL kan dock inte användas för allmän fakturering till andra före-tag inom privat sektor eller till privatpersoner, eftersom dessa filer, till skillnad från PDF-filer, inte är humanläsbara. Överföringen av Svefaktura/PEPPOL omöjliggörs också om mottagaren inte är ansluten till en PEPPOL-accesspunkt.

För företag som endas tillfälligtvis ställer ut fakturor till offentlig sektor måste andra lösningar hittas för elektronisk fakturering, helst en lösning som kan hantera till mottagare med varierande digitaliseringsgrad. E-postade PDF-fakturor torde bli förstahandsvalet.

Internationell utblick

ZUGFeRD

I Tyskland finns en myndighetsövergripande organisation för elektroniska fakturor, FeRD10. Denna organisation har tagit fram filformatet ZUGFeRD11, som används både av myndigheter och inom det privata näringslivet.

Framväxten underlättades av lättnader som 2011 infördes i den tyska momslagen, då elektroniska fakturor i stor utsträckning jämställdes med pappersfakturor.

En ZUGFeRD-faktura består av två delar: en visuell representation av räkningen för människor och maskinläsbar strukturerad data. Fakturans visuella representation är följer PDF/A-3. Den maskinläsbara informationen lagras som inbäddade metadata i XML-format.

Några krav på speciell transportinfrastruktur ställs inte.

10 Forum elektronische Rechnung Deutschland.

11 Zentraler User Guide des Forums elektronische Rechnung Deutschland. (Det är också en lek med ord Zugpferd betyder arbetshäst)

10

Organisationer

DIGG Myndigheten för digital förvaltning

Denna myndighet har två regeringsuppdrag, som båda handlar om digitalisering inom offentlig sektor.

Det ena, och för detta sammanhang relevanta uppdraget, är att ta fram förslag som ska bidra till att skapa säkrare och mer effektiva elektroniska informationsut-byten inom och med den offentliga sektorn. Uppdraget ska bland annat undersöka en ökad form av standardisering . Uppdraget genomförs tillsammans med Bolags-verket, Domstolsverket, eHälsomyndigheten, Försäkringskassan, Lantmäteriet, och Skatteverket genom ett gemensamt projekt.

SFTI

SFTI är en organisation med företrädare för både offentliga köpare, leverantörer av varor och tjänster samt IT-systemleverantörer som ska implementera standarden.

Bakom SFTI står Sveriges Kommuner och Landsting (SKL), Myndigheten för digital förvaltning (DIGG) och Upphandlingsmyndigheten.

Det finns en etablerad organisation för SFTI:s verksamhet. Denna organisation för SFTI består av en styrgrupp, en beredningsgrupp samt arbetsgrupper.

Till stöd för arbetet finns vidare ett tekniskt kansli samt handläggare hos de olika huvudmännen, SKL, DIGG och Upphandlingsmyndigheten.

NEA Nätverket för elektroniska affärer

NEA (Nätverket för Elektroniska Affärer) uppger sig vara en ideell medlemsstyrd intresseorganisation utan vinstintresse. NEA erbjuder en neutral och oberoende mö-tesplats för alla som är intresserade av eller verksamma inom e-affärer.

NEA har drygt 40 direktanslutna medlemmar och 10.000-tals indirekt anslutna medlemmar. Vem som är medlemmar framgår inte av organisationens hemsida.

oberoende branschorganisation verka för ökad an-vändning av e-affärer genom:

Visa på goda exempel Påverkan av harmonisering av infrastruktur och standardisering (nationellt

och internationellt) Vara pådrivande när det gäller användandet av standarder och tillämpningar Verka för en infrastruktur som ökar företags och organisationers konkur-

renskraft Ta fram identifierade produkter och tjänster Utökande av möjligheten till branschöverskridande e-affärer Via nätverk främja erfarenhetsutbyte, där medlemmar kan bygga sitt kon-

taktnät, diskutera och lära av varandra och dela best of practice Information & kunskap där vi sprider nyttan och effekter av e-affärer genom

NEAs hemsida, nyhetsbrev, NEA index, rapporter och publikationer om e-affärer och Programrådet som anordnar kurser, seminarier och webinar

11

Driva frågor om e-affärer för att utveckla, sprida och samordna frågor inom området e-affärer genom våra aktiva arbetsgrupper Juridik & Säkerhet, Handel & Logistik samt genom PR

NEA ska mot bakgrund av sin breda medlemsbas, vara en stark aktör inom e-affärer. Genom NEAs verksamhet ska fler se ett mervärde i att vara med-lemmar i NEA.

Tillväxtverket

Tillväxtverket förmedlar projektmedel för olika tillväxtprojekt, bl.a. projekt för ökad digitalisering.

Man har bland annat en check för digital utveckling, som av enskilda företag kan användas för att ta in konsulter eller projektanställda för att:

ta fram en digital strategi ta fram en plan för fortsatt digitalisering och hjälp att genomföra en digital

transformation

ta fram nya tjänster genom att använda existerande datamängder utveckling av kundrelationer juridiska villkor kring digitala tjänster och produkter.