Bokföringsmotorn

Ingen roll i programmet kan ändra eller radera ett bokfört verifikat. Spärren ligger i databasen, inte i gränssnittet, så den gäller lika hårt för appen, ett API-anrop och SQL-editorn — alla ansluter som en vanlig applikationsanvändare. Rättelse sker på det sätt bokföringslagen anger: ett ändringsverifikat som vänder originalet och bokför rätt, med en spårbar koppling mellan de två.

Detsamma gäller verifikatraderna — de kan inte ändras eller raderas var för sig, vilket annars vore en bakväg runt spärren.

Det ska sägas rakt ut: databasens ägare kan tekniskt allt. Den som har ägarrollen i din Postgres kan stänga av en spärr och sedan röra vad som helst. Så är det i varje bokföringsprogram som körs på egen infrastruktur — och det är priset för att datan är din och inte någon annans. Skillnaden mot ett gränssnittsskydd är ändå avgörande: en ändring förbi spärren kräver ett medvetet ingrepp med ägarens behörighet, inte ett felklick i appen.

Verifikat- och fakturanummer delas ut atomiskt i databasen, en serie i taget. Det kan därför inte uppstå luckor eller dubbletter — inte ens om två personer bokför samtidigt, eller om ett anrop avbryts halvvägs.

Debet = kredit kontrolleras innan något sparas, tillsammans med tre andra krav: verifikatet måste ha minst två rader, ha ett belopp, och varje konto måste finnas och vara aktivt i kontoplanen. Ett obalanserat verifikat existerar aldrig, inte ens en kort stund.

Appen skriver aldrig direkt i verifikattabellen. All bokföring går genom databasens egna funktioner, som kontrollerar balansen, delar ut nästa nummer i serien, vägrar bokföra i en låst period eller ett stängt räkenskapsår, och vägrar sätta ett verifikatdatum utanför räkenskapsåret. Läsrättigheter och skrivrättigheter är åtskilda: bokföringsrollerna kan läsa verifikaten, men skrivvägen förbi funktionerna finns inte — oavsett hur man ansluter.

En månad som är låst tar inte emot fler verifikat. Är momsperioden dessutom godkänd går låset inte att öppna igen — annars skulle bokföringen kunna ändras under en redan inlämnad deklaration. Samma princip gäller momsrapporten själv: den kan bara skapas som utkast och bara godkännas genom programmets egen funktion, som gör beräkningen, omföringsverifikatet och eSKD-filen i ett sammanhang. En färdig "godkänd" rad går inte att lägga in vid sidan om.

Ett kvitto eller en faktura som är kopplad till ett verifikat kan inte raderas så länge verifikatet finns — arkiveringskravet är en regel i databasen, inte en påminnelse i gränssnittet. Filerna ligger i privat lagring i ditt eget projekt, och hela årets underlag kan när som helst hämtas som en zip tillsammans med SIE-filen och rapporterna.

Kräver företaget attest av leverantörsfakturor är det databasen som håller i spärren: en faktura som väntar på attest eller blivit avvisad kan inte betalas, varken från fakturan eller vid avprickningen mot banken. Vem som attesterade och när loggas.

Löftena ovan är designval, inte efterhandsfixar. De ligger på den lägsta nivån i systemet därför att det är den enda nivå där de faktiskt gäller: en spärr i gränssnittet skyddar mot misstag, en spärr i databasen skyddar mot allt annat också — felaktiga skript, ett trasigt API-anrop, en nyfiken administratör.

Och det vi inte lovar, för att det vore oärligt: programmet gör inte din bokföring korrekt åt dig. Det gör det svårt att bryta mot formkraven, lätt att hitta fel, och omöjligt att i efterhand dölja att något ändrats. Resten är fortfarande ditt ansvar — precis som i varje annat bokföringsprogram.