Bokföring, SIE4 och BAS.

SIE är det svenska utbytesformatet för bokföringsdata, och det är så en period av fakturor tar sig från ett företags system in i det program redovisningskonsulten faktiskt för böckerna i — Fortnox, Visma, BL Administration eller något annat.

Det är en ren textfil av poster som var och en inleds med ett brädgårdstecken. Ett huvud anger vilket företag det gäller, vilket program som skrev filen, vilken teckenuppsättning den använder och vilket räkenskapsår den täcker. Därefter kontona som berörs, vart och ett med nummer och namn. Därefter verifikationerna: en #VER per dokument med serie, nummer och datum, och inuti den en #TRANS-rad per kontering — konto, belopp, datum, text. Posterna avslutas med vagnretur och radmatning, inte med ett ensamt radslut.

Typen spelar roll. En 4E-fil är ett helt räkenskapsår med ingående och utgående balanser; en 4I-fil är en periods transaktioner. Den här modulen skriver 4I och vägrar skriva 4E, och vägran är inte en lucka i implementationen. Den för kundreskontran och ingenting annat — den har aldrig sett en lön, ett inköp eller ett bankkonto — så den kan inte ange en balans, och en 4E-fil utan balanser gör anspråk på en fullständighet den inte har.

Fakturorna i filen är bara utställda dokument, daterade efter datumet som står på dokumentet och inte efter radens tillkomsttid. En faktura som skrivs den 2 oktober men bär den 30 september är ett septemberdokument, och hela poängen med ett datum på en sida är att det, och inte klockan, avgör perioden. Filen revisorn får går igenom en.

SIE4 skrivs i CP437, den ursprungliga IBM PC-kodsidan. Inte UTF-8, inte Latin-1 och inte "vad editorn nu råkade spara som".

Det här är formatets vanligaste fel och det ser kosmetiskt ut tills man ser det. Skriv filen som UTF-8 och varje å, ä och ö kommer fram som två tecken skräp. Björkgården blir BjörkgÃ¥rden. Det som förvanskas är inte en etikett i vår programvara — det är kundens eget namn, kontonamnen och texten på varje verifikation, i någon annans bokföring.

Raden i huvudet som deklarerar teckenuppsättningen är #FORMAT PC8, där PC8 är formatets namn på kodsida 437. Det är raden som talar om för det mottagande programmet hur varje tecken under den ska läsas, och den är en lögn om inte byten verkligen konverterats. Konverteringen sker därför uttryckligen, en gång, allra sist, efter att hela filen satts ihop som text.

Två följder faller ur det. CP437 har varken ł eller €, och en strikt konvertering svarar på ett otolkbart tecken med att inte producera någonting alls — ett polskt efternamn i ett kundregister skulle förvandla en månads export till ingen fil. Konverteringen translittererar därför i stället: en approximation är ofullkomlig och syns på sidan, medan en tom export varken är det ena eller det andra. Och filen lämnas aldrig tillbaka i ett JSON-svar, eftersom JSON per definition är UTF-8 och en serialisering av byten skulle göra om precis det exporten finns till för att undvika. Exporten hämtas som en lagrad fil.

SIE är också det enda den här modulen producerar som den aldrig läser tillbaka. Allt annat kan lagas av någon som förstår systemet; en SIE-fil öppnas av någon som inte gör det, och det de ser när den är fel är ett radnummer och ett avslag.

BAS är den kontoplan nästan varje svenskt företag utgår från — och som nästan vart och ett av dem sedan ändrar i. Det här är alltså förvalen, som används när ingenting på raden säger något annat:

• 3001, 3002, 3003 — Försäljning inom Sverige med 25, 12 och 6 procents moms.
• 2611, 2621, 2631 — Utgående moms för samma tre satser.
• 1510 — Kundfordringar. Det kunden är skyldig.
• 1513 — Kundfordringar, delad faktura. Den halva av en ROT- eller RUT-faktura som Skatteverket reglerar, hållen borta från 1510 så att en åldersanalys inte kan jaga staten som vore den en kund.
• 3740 — Öres- och kronutjämning, som tar öresavrundningsraden.

Försäljningen delas per momssats därför att BAS delar den, och därför att delningen är en kontroll: intäktskontot och momskontot på en rad ska gå att stämma av mot varandra, och intäkt med 12 procents moms bokförd på 25-kontot bryter den kontrollen tyst.

Det är förval och inte sanningar. Radens egen kontokod går före, och den koden fästs på raden när raden skrivs i stället för att läsas ur artikelregistret när exporten körs. Den skillnaden är värd en mening: att läsa registret vid exporttillfället innebar att en artikel som kontoändrades i juni flyttade kontona på dokument som redan exporterats i mars. En nollskattad rad får inget förval alls, eftersom rätt konto beror på varför den är nollskattad — export, omvänd betalningsskyldighet och undantagen omsättning är tre olika konton, och bara företaget kan säga vilket. Den bokförs på standardkontot för försäljning och en varning säger det, i stället för att gissas tyst. BAS-kontoplan för tjänsteföretag tar kontona runt dessa.

Dubbel bokföring betyder att beloppen i en verifikation summerar till noll. Ett bokföringsprogram avvisar en hel import över en enda verifikation som inte gör det, och det rapporterar den som ett radnummer till någon som inte har något sätt att laga den.

Kontrollen sker därför här i stället, och den är sträng på ett bestämt sätt: summan tas i ören, över heltal, innan någonting formaterats. Samma kontroll på utskrivna kronor skulle släppa igenom en verifikation som är en hundradel fel — vilket är exakt storleken på felet ett avrundningsmisstag gör, och exakt det en importfunktion fångar. Går en verifikation inte ihop skrivs ingen fil alls. Inte en fil med en varning bifogad; ingen fil. Meddelandet namnger fakturan och differensen, framför den person som fortfarande kan göra något åt det.

Tre avvisningar till ligger bredvid, av samma form. En faktura i annan valuta än SEK avvisas i stället för att bokföras, eftersom en bokföring förd i kronor inte kan ta emot ett belopp i euro utan kursen det växlades till, och ingenting i modulen registrerar någon — att bokföra 1 000 EUR som 1 000 SEK vore tyst. Utkast och makulerade dokument når aldrig filen, eftersom ett utkast saknar nummer och kanske aldrig skickas, och att exportera ett bokför intäkt ingen har fakturerats för. Och en rad med en momssats som inte har något svenskt konto att bokföras på stoppar exporten i stället för att landa någonstans rimligt.

Exporten talar också om vad den antagit. Ett saknat organisationsnummer blir en varning och inte en uppfinning: ett uteblivet #ORGNR är en fråga revisorn ställer, medan ett påhittat importeras rent in i fel bolag och ingen upptäcker det förrän året är stängt.

En SIE-fil deklarerar ett räkenskapsår i sin #RAR-rad, och varje verifikation i filen måste falla inom det året.

Förvalet är kalenderåret, eftersom det är det räkenskapsår de flesta svenska företag håller. Ett företag med brutet räkenskapsår — maj till april, säg, eller september till augusti — anger startmånaden i sina egna inställningar, och #RAR följer den. Utan det skulle ett företag med maj-till-april-år få en fil vars deklarerade år motsäger varje verifikation i den, och importen skulle misslyckas i andra änden av ett skäl ingen där kunde ställa diagnos på.

En period som spänner över två räkenskapsår avvisas i stället för att tyst klippas eller tyst felmärkas. Det är nästan alltid en feltryckt månad, och när det inte är det är det två exporter. Att avvisa kostar någon trettio sekunder; att klippa kostar en avstämning.

Datum jämförs som datum mot en datumkolumn, aldrig via en tidsstämpel. Att ta någondera sidan genom en tidsstämpel flyttar gränsen med skillnaden mellan Stockholm och UTC, och släpper den sista fakturan i en månad ned i nästa för varje export som körs efter midnatt.

Innan filen skrivs går det att se vad den skulle innehålla: hur många fakturor, hur många konteringar, vilka konton som berörs, den första och sista verifikationen, varje varning — och, poängen med hela vyn, vad som redan exporterats för samma datum. Den som står i begrepp att exportera september ser att september gick ut den 3:e innan de skickar en andra fil, i stället för efter att månaden bokförts två gånger.

En andra export är tillåten, eftersom en rättad fil är en fullt vanlig begäran. Den är aldrig tyst. Filen som går ut skrivs till lagring och sparas i stället för att genereras om vid behov, eftersom en omgenerering ger en annan fil i samma stund något bakom den har ändrats — och hela värdet i noteringen är att den säger vad som faktiskt lämnades över.

Vad det här inte gör är värt att säga rakt ut, eftersom det är frågan en köpare bör ställa. Det är inte bokföring. Det finns ingen huvudbok, ingen verifikationsserie utanför försäljningen, ingen leverantörsreskontra, inga löner, inget bokslut, ingen årsredovisning och ingen momsdeklaration till Skatteverket. Det ersätter kostnaden för faktureringsprogrammet, inte revisorn — och den ärliga beskrivningen är att det ger er redovisningskonsult en ren SIE4-fil i stället för en bunt PDF:er att knappa in igen, vilket brukar sänka arvodet utan att ta bort det.

Och en sak vi inte påstår. Exporten är skriven till formatet och varje verifikation balanskontrolleras innan en enda byte produceras, men den har inte körts hela vägen in i en skarp Fortnox-installation. Vi skriver inte "validerad med Fortnox" förrän någon faktiskt har importerat en fil i en. Vill ni pröva det innan ni bestämmer er: ta en månads export till er redovisningskonsult och låt dem försöka. Det är rätt ordning att få veta i.