Förslag: Nytt dataformat för bokföring - feedback från utvecklare önskas

TL;DR - jag vill kunna göra bokföring med AI-agenter utan gamla stökiga bokföringssystem. Jag tänker att det borde gå att skapa ett nytt dataformat som är både agent friendly och human friendly - välkomna att skjuta ner min idé!

Bokföring borde vara en perfekt domän för AI agenter. Det är en ganska välstrukturerad domän med hyfsat tydliga regelverk, men kräver ett visst mått av omdöme så svårt att programmatiskt automatisera. Vi har gjort POCar på jobbet med konterande AI-agenter och de är ruskigt bra. Jag är förvånad att det inte redan kommit fler AI-native produkter/tjänster inom området. Jag vet inte varför. Jag har länge varit lite irriterad på att bokföring är så dyrt, att tjänsterna är av så dålig kvalitet och att mjukvarusystemen är rätt kassa.

Så jag tänker att man får ta saken i egna händer och bygga sin egen bokföringsagent. Det finns lagar att hålla sig till, bla bokföringslagen, men som jag tolkar regelverken så är de egentligen inte superkomplicerade att uppfylla för småföretagare. Jag menar, det är ju ok att bokföra själv på papper. Det finns ytterligare utmaningar att lösa kopplat till bokföring, som tex inläsningar av banktransaktioner osv, men det finns lösningar på det också.

Följdfrågan blir då, hur skulle man spara egen bokföringsdata på ett sätt som uppfyller lagar och regler och skulle hålla vid en revision? Och som: 1) är enkelt för en AI-agent att förstå och manipulera 2) är läsbart för en människa 3) är okomplicerat och portabelt (dvs jag kan flytta min bokföringsdata mellan system/leverantörer utan problem). Det borde inte vara omöjligt?

Min nuvarande hypotes är en filbaserad, human readable huvudbok. Säg tex yaml. Sparandet av poster (och audit trail) görs med git. Immutability görs genom hash chaining, dvs varje post får en hash av föregående poster. Verifikationer (pdfer typiskt) sparas separat med en enkel referens till posten, men ingår inte i hashen. Bokföringsperioder blir egna hash-serier. Resultatet skulle bli en 100% portabel bokföring, som man kan validera automatiskt att den är komplett och inte manipulerad, som går att läsa med vilket textredigeringsverktyg som helst, eller med custom mjukvara med GUI, och som alla agenter skulle ha lätt för att läsa och skriva till. Sen behöver man lägga på en massa kringgrejer om man vill att det ska bli fullfjädrat bokföringssystem, tex SIE-export, ev ett derived databaslager för snabbare läsning, generering av vyer för resultat- och balansrapport, hantering av olika kontoplaner, osv osv. Men poängen skulle i första steget bara vara att göra min egen bokföring. Kanske prova parallellt med min vanliga bokföring i Spiris.

Själv är jag inte utvecklare, så jag killgissar mig fram lite. Vore kul med andras tankar! Varför är detta en kass idé?

2 gillningar

Tycker matte + llm känns lite läskigt, hur gör man för att få helt korrekt data? Vi ska börja bygga dashboards, excel, presentationer osv från Claude snart så får se hur det går. Tycker alla bara svarar ”self reflection” och jag undrar hur bra det kan bli? Kör själv plan → subagent som reviewar planen → gör kodändring —> ai review med flera modeller—> fixa feedbacken —> ai review igen (ofta) —> fixa feedback—>..

Tycker den alltid hittar saker även fast jag gör reviews med codex, claude och gemini och gör det flera gånger. Hur ska self reflection fixa det? Ska bli spännande att utforska mer. Håller med dig i sak men skeptisk.

1 gillning

Jag tror inte generellt att man ska förlita sig på att en llms matematik. Vill man att en agent ska göra matematiska beräkningar ger man den i allmänhet ett tool för det. Jag skulle avråda från att förlita sig på en modells egen matte, även fast de säkert klarar av det bra nuförtiden. Min frågeställning har dock principiellt inget med matematik att göra.

1 gillning

Superintressant tanke! Ny som medlem här men har lurkat i några år. Har själv skapat agent för kontering och det fungerar ju fruktansvärt bra.

Gällande “matte och LLM” för mer av ett bokföringsprogram ser jag inga som helst problem förutsatt att man använder konteringen som en referens. Skriv gärna ett PM om du diskutera mer.

1 gillning

Vore det fel att använda sig av det standardiserade formatet för bokföring? Jag tänker på filtypen som slutar på .sie typ. Den går ju redan idag att exportera och importera mellan befintliga bokföringsprogram, så synd att avvika ifrån den?

1 gillning

Man behöver defintivt kunna transformera till SIE. Men SIE är ett rätt gammalt format framtaget för export. Man kan nog inte hålla sig exakt till SIE eftersom vi behöver bland annat kryptografisk hashning men potentiellt kan man inspireras av det och försöka hålla sig nära. Eller extenda. En av poängerna med ett nytt format, om man tänker långsiktigt, skulle vara att det är helt portabelt. Dvs du behöver inte göra en expert och import, du flyttar bara befintlig data.

Jag skulle vilja dra en jämförelse till markdown. Kanske det mest perfekta filformatet som skapats? Hur kommer det sig att skolorna över hela världen inte lär ut detta perfekta system? Varför stödjer inte alla dokumentläsare detta? Varför envisas människor med att skapa PDFer så att vi fick använda åratal att skapa OCR för att kunna decoda bild till text som förbaskat nog var text från början?

För att adaption är det svåra. Att skapa det perfekta systemet eller formatet är inte svårt. Att ena människor kring en ny ordning, ny metod, det är det svåra.
Och så fort man lyckats åstadkomma en förändring i människor, då kommer någon ideologisk jävel och skapar en open source klon som är gratis att använda.

Varför är det som det är? För att Bokföringsprogrammen betalar kickback till Revisorer. De erbjuder gratis utbildningar och fortbildningar till revisorer. Revisorerna vill behålla sina enklaste jobb, sina cash cows. Småbolagen är för få för att ge lönsamhet.

Men för all del, börja med specen för SIE5 och sedan fortsätter du med Skatteverkets bibba av xml-format. Kör så det ryker!

Jag är den ideologiska jäveln då antar jag. Jag är inte ute efter att tjäna några pengar och jag har egentligen inte heller behov av att någon annan anammar formatet. Jag är mest ute efter att hitta ett format som funkar för mig själv så att min agent kan göra min bokföring, utan att bryta lagen. Om andra inspireras eller använder samma format är det positivt, men inte nödvändigt.

Jag tror inte att det finns någon vidare moat i en sån här produkt. Den är alldeles för lätt att bygga.

Lär behöva vara inbyggt i applikationen då en vanlig användare aldrig kommer vilja mecka med git och commits.

Tanken är att användaren inte kommer göra någon bokföring själv alls, det gör agenten. Så det viktiga är att det är lätt för agenten att förstå datamodellen och operationerna. Det är bra om dataformatet är human readable, mest för att inte låsa in det i något proprietärt format och för transparens, men användaren kommer inte skriva till det själv. Sen kan man alltid lägga på GUI ovanpå om man vill.

DEt finns väl redan helautmatiserade bokföringssystem typ Lennart AI och liknande?

Jag delar dock din syn på branschen men tror även att kunderna är lite avvaktande, bokföring är ändå inte jättedyrt för ett mindre företag idag och många litar inte på AI..

Jag ser inte att hashningen tillför något, vill du ändra något så kan du ändra hasharna också. Där är ju git i en kontrollerad miljö bättre.

Ska du få fler än några entusiaster som användare så behövs git+AI+GUI i ett paket.