Elektroniska fakturor för förvaltare: EU-standarden utan jargong

Leverantörsfakturan har gjort samma resa i tjugo år: den kommer som PDF till förvaltarens inkorg, någon läser av beloppet på skärmen, skriver in det i ett kalkylark eller ett bokföringsprogram, sparar PDF:en i en mapp och hoppas att de två förblir i takt. Multiplicera med varje hissavtal, städfirma, försäkring och enstaka reparation i en portfölj av föreningar, så är fakturainmatningen en verklig del av förvaltarens administration.

Den eran håller på att ta slut, genom lag, och inte bara i ett land. I EU går elektroniska fakturor mellan företag från frivilligt till obligatoriskt enligt en förskjuten tidsplan, och medlemsstaterna fasar in det under det här decenniet. I Sverige har leverantörer till offentlig sektor behövt skicka elektroniska fakturor sedan 2019. Tidpunkterna skiljer sig åt, men riktningen och standarden under gör det inte.

En bostadsrättsförening är inget vanligt företag, men dina leverantörer är företag, och det är ditt förvaltningsbolag också. I takt med att elektroniska fakturor blir standard mellan dem kommer föreningarnas fakturor allt oftare som strukturerad data, oavsett om mottagaren är redo eller inte.

Det mesta som skrivs om det här beskriver det som en regelbörda. För den som tar emot fakturor är det närmare en gåva. Kravet tvingar leverantörerna att skicka fakturor i ett format som en maskin kan läsa, och det betyder att inmatningens era kan ta slut, om mottagningsflödet är rätt byggt.

PDF:en är inte längre fakturan

En elektronisk faktura, i juridisk mening, är inte en PDF av en faktura. Den är en strukturerad datafil enligt den europeiska standarden EN 16931: säljaren, beloppen, datumen, betalningsuppgifterna, allt som maskinläsbara fält. Den gemensamma standarden är det viktiga. Oavsett nationell variant bär en faktura som följer standarden samma datamodell under ytan, och därför fungerar ett verktyg som är byggt för standarden över gränserna.

I praktiken dyker standarden upp i två former:

• Ren XML är maskinformen: en XML-fil utan visuellt lager. Öppnar du den i ett visningsprogram ser du vinkelparenteser. Den är oläsbar med flit, eftersom den är skriven för maskiner. Standarden tillåter två syntaxer, UBL och CII, och flera länder har sin egen profil av dem, men det är dialekter av EN 16931, inte separata världar.
• Hybriden (Factur-X är det mest spridda namnet) är en vanlig PDF med XML-filen inbäddad. Människan ser en faktura; maskinen ser data. Och det avgörande: det är den inbäddade XML-filen som gäller, inte pixlarna.

Hybridformatet döljer en fälla som är värd att känna till. En hybridfaktura som hanteras på gammalt sätt, genom att någon läser PDF:en och skriver av den, ignorerar i tysthet det strukturerade lagret. Siffrorna i det visuella lagret och i XML-filen ska stämma överens, men det är den maskinläsbara delen som är fakturan. Ett flöde som bara rör pixlarna hanterar en bild av en faktura och kastar bort själva fakturan.

Mottagning som den ska vara: läs, visa, bekräfta

Rätt mottagningsflöde har tre steg, och bara ett av dem kräver en människa.

Först går filen in, XML eller hybrid-PDF, och maskinen läser de strukturerade fälten: vem som har skickat den, fakturanumret, faktura- och förfallodatum, belopp exklusive moms, moms och totalbelopp, och kontot som ska betalas. Ingen inmatning, ingen avläsning av siffror från en skärm.

Sedan visas de avlästa fälten för dig i klar, läsbar form. Det spelar störst roll för ren XML, som utan det här steget är en vägg av vinkelparenteser som ingen kan göra något med, men det spelar roll för hybrider också: det du ser är vad maskinlagret faktiskt säger, inte vad PDF:en råkar visa.

Till sist bekräftar du, en gång, och fakturan blir ett utkast till utgift i föreningens bokföring, med beloppet och leverantören redan ifyllda. Från den stunden lever den som vilken utgift som helst: den väntar på kontoutdraget, betalningsraden kopplas till den och statusen räknar fram sig själv, som varje utgift i föreningen borde göra.

En fil in, en bekräftelse, en bokförd utgift. Det är hela den manuella delen av flödet.

Varför bekräftelsen inte är valfri

En rimlig fråga: om maskinen läser allt, varför bekräfta alls? Varför inte bokföra fakturorna automatiskt så fort de kommer?

För att avläsningen är pålitlig men ansvaret inte går att delegera. En faktura kan vara maskinellt perfekt och ändå fel: en dubblett, ett belopp som inte stämmer med avtalet, en tjänst som aldrig beställdes eller ett rent bedrägeri. Fakturabedrägerier med ändrade betalningsuppgifter är ett verkligt och växande problem, och bekräftelsesteget är precis där de stoppas: de avlästa betalningsuppgifterna ligger framför en människa som vet vilket konto hissföretaget alltid har haft. Ett flöde som bokför automatiskt tar bort det enda ögonblick då förvaltarens omdöme, det som föreningen faktiskt betalar för, kommer till användning.

Svenska föreningar har redan ett ord för det här ögonblicket: attest. Någon med ansvar ska ha sett fakturan innan den blir en utgift, och det gäller lika mycket när fakturan kommer som data. Rätt design är alltså medveten: maskinen gör all läsning, människan fattar det enda beslutet. Allt som är mer automatiskt än så optimerar bort själva poängen.

Arkivera originalet, inte återgivningen

Bokföringslagen kräver att räkenskapsinformation sparas i sju år, och här gäller samma logik som för hybridformatet: det som ska bevaras är originalfilen, XML-filen eller hybrid-PDF:en precis som den kom, inte en skärmdump, inte den läsbara återgivningen, inte en ny export. Återgivningen är en bekvämlighet för i dag; originalet är underlaget för den som granskar år sju.

Mottagningsverktyget ska därför spara originalet så att det inte kan ändras, tillsammans med utgiften det blev, och alltid kunna lämna tillbaka exakt de byte som kom in. Om ett verktyg genererar om eller ”städar” sparade fakturor arkiverar det sitt eget verk i stället för dokumentet.

Vart fakturan tar vägen sedan

Den tysta vinsten med att ta emot fakturor som data är allt som händer efteråt. Den bekräftade utgiften blir en del av föreningens transaktionskedja, och det betyder:

• Bostadsrättshavarna kan se den. Fakturan får sin plats i föreningens lista över verifikationer, där en bostadsrättshavare som går igenom årets siffror kan öppna det faktiska dokumentet bakom varje rad.
• Årsavräkningen tar upp den. Bokslutet kräver ingen fakturajakt längre, eftersom varje leverantörsfaktura redan ligger kategoriserad i bokföringen. Hela kretsloppet finns i föreningens ekonomiska år.
• Den som gör bokslutet får ren data. En bokföringsexport tar med utgiften och dess kategorier till den ekonomiska förvaltaren eller redovisningskonsulten, med originaldokumentet tillgängligt när det behövs.

Räkna de mänskliga handgreppen under hela den resan: ett. Fakturan bekräftades en gång, och alla som kommer efter, bostadsrättshavare, styrelse, stämma, redovisningskonsult och revisor, läser poster som bygger på det enda bekräftade faktumet.

Vad Kvaro inte gör, och vad som inte finns än

Det är bäst att säga det rakt ut: Kvaro tar emot elektroniska fakturor och gör dem till utgifter. Kvaro skickar inga fakturor och är inget faktureringsprogram. Kvaro läser de två syntaxerna i EN 16931, UBL och CII, och hybrid-PDF:en Factur-X.

Två leveranskanaler håller dessutom fortfarande på att mogna på marknaden: att fakturor som kommer via e-post tas emot automatiskt, och Peppol-nätverket för utbyte av strukturerade fakturor, som svensk offentlig sektor redan använder och som håller på att bli det gemensamma transportlagret mellan EU:s medlemsstater. Kvaro är inte anslutet till Peppol. I dag är den pålitliga grunden uppladdning: fakturafilen, hur den än nådde dig, laddas upp i verktyget, och flödet ovan tar över.

Den grunden är redan hela vinsten. Kostnaden för elektroniska fakturor var aldrig klicket för att ladda upp, det var inmatningen, mapparna som inte stämde och fakturajakten före varje bokslut. Allt det tar slut den dag mottagningsflödet börjar läsa den strukturerade datan i stället för du. Kravet fick leverantörerna att göra den svåra halvan; mottagningshalvan är nu ett val.