Vad är ett bokförings-API? En guide på vanlig svenska för plattformsutvecklare

En tydlig definition av bokförings-API:t, vad som skiljer det från ett skatte-API eller ett betal-API, och vad du bör kontrollera innan du integrerar mot ett.

Ett bokförings-API är ett gränssnitt som låter ett program sköta bokföringen åt ett annat program. Din programvara skickar en finansiell händelse via HTTP. API:t omvandlar händelsen till balanserade dubbla bokföringsposter (double-entry journal entries) mot en kontoplan (chart of accounts), lagrar dem så att de inte kan ändras i det tysta, tillämpar momshanteringen och ger dig rapporter, dokument och exporter tillbaka genom samma gränssnitt.

Den definitionen gör det mesta av arbetet. Allt annat i den här artikeln är en konsekvens av den.

Versionen på en mening

Ett bokförings-API tar emot finansiella händelser från din applikation, konverterar var och en till en balanserad bokföringsposter, lagrar dem oföränderligt tillsammans med momshantering och underlag, samt exponerar det resulterande huvudboken (ledger), dokument och rapporter som programmerbara slutpunkter.

Om en produkt kallas för ett bokförings-API men inte skapar bokföringsposter är det någonting annat med ett fint namn. Det behöver inte vara dåligt. Det betyder bara att det inte kommer att utföra det arbete du är på väg att be det om.

Vad ett bokförings-API inte är

Fyra närliggande produktkategorier förväxlas ofta med bokförings-API:er, vanligtvis en bit in i ett projekt.

Kategori	Vad det gör	Vad det inte gör
Skatteberäknings-API (Tax calculation API)	Returnerar rätt skattesats eller skattebelopp för en transaktion	Sköter inte din bokföring och lagrar inte underlaget bakom beslutet under arkiveringstiden
Betal-API (Payments API)	Flyttar pengar mellan parter och rapporterar om dessa flöden	Registrerar inte intjänad provision, skyldig moms eller skulden till en säljare mellan betalning och utbetalning
Samlings-API eller aggregator-API (Unified or aggregator API)	Läser och skriver data i dina kunders befintliga bokföringsprogram	Agerar inte huvudsystem; din bokföring ligger i det verktyg som respektive kund redan använder
Rapporterings- eller BI-API (Reporting or BI API)	Läser siffror ur en befintlig huvudbok och visualiserar dem	Skapar inte de verifikat som siffrorna har härletts från

Var och en av dessa har sina användningsområden. En plattform som behöver vara huvudsystem måste ha bokförings-API:t i botten, inte i stället för det.

De fem saker som ett bokförings-API måste göra

1. Registrera balanserade poster. Varje händelse blir debet och kredit som summerar till samma belopp. När en köpare betalar 100 EUR på en marknadsplats som tar 15 EUR i provision, debiterar posten ett avräkningskonto med 100 EUR, krediterar en leverantörsskuld till säljaren med 85 EUR och krediterar provisionsintäkter med 15 EUR. Det här är ingen bokföringscermoni. Det är en strukturell kontroll som fångar upp hela klasser av integrationsbuggar innan de når en rapport.

2. Spara historiken. En bokförd post redigeras inte. Ett misstag korrigeras genom en reversering plus en korrigerad post, där båda är länkade till originalet. Stängda månader låses så att ingenting nytt kan dateras till dem.

3. Hantera skatt. För EU-handel innebär det leveransplats, omvänd skattskyldighet (reverse charge), momsregistreringsnummer som kontrollerats mot det officiella registret, samt det underlag som motiverar beslutet. Allt detta lagras tillsammans med transaktionen i stället för att slängas bort efter beräkningen.

4. Avstämning mot externa pengar. Bokföring som aldrig möter ett kontoutdrag är en gissning. API:et måste läsa in kontoutdrag eller utbetalningar från betaltjänstleverantörer och matcha dem mot det som har registrerats.

5. Export. Rapporter, dokument och revisionsfiler i format som en mänsklig redovisningskonsult och Skatteverket accepterar.

En produkt som gör de tre första sakerna men inte de två sista kommer ändå att lämna en människa med att göra kalkylbladsarbete varje månad.

Hur ett anrop faktiskt ser ut

Mekaniken är enklare än bokföringen. I Nordlets API är varje åtgärd ett RPC-liknande POST-anrop med en förutsägbar struktur:

POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>

Du skapar en kundfaktura och utfärdar den sedan. Utfärdandet är det ögonblick då bokföringen sker: dokumentet får sitt löpande nummer, den balanserade bokföringsposten bokförs och momsrader registreras tillsammans med den. Din plattform sätter aldrig ihop debet och kredit för hand.

Tre detaljer i det kodavsnittet spelar större roll än slutpunktens namn:

Behörighetsnivån på nyckeln (scope). En nyckel bär uppgifter som sales:write, vilket gör att en integration enbart får den åtkomst den behöver.
Idempotensnyckeln (idempotency key). Om du gör om samma begäran med samma data får du det lagrade svaret tillbaka i stället för en andra faktura. Om du skickar samma nyckel med annan data avvisas begäran med idempotency_key_reuse i stället för att tyst accepteras.
Pengar som strängar. Belopp är decimalsträngar, inte flyttal (floating-point), eftersom flyttal tappar ören på ett sätt som visar sig vid årets slut.

Var det placeras i din arkitektur

Din applikation förblir gränssnittet och källan till affärshändelser. Bokförings-API:et blir det finansiella huvudsystemet bakom den. Flödet ser vanligtvis ut så här:

Något händer i din produkt: en order, en återbetalning, en utbetalning, en prenumerationsförnyelse.
Din back-end anropar bokförings-API:et med händelsen och en idempotensnyckel.
API:et bokför verifikatet, tillämpar moms och returnerar identifierare som du lagrar i era egna system.
En webhook som sale_invoice.paid meddelar ditt system när tillståndet ändras, så att du reagerar på händelser i stället för att polla efter dem.
Banktransaktioner anländer via ett bankflöde eller en filinläsning och matchas mot de registrerade dokumenten.
Vid periodens slut genereras rapporter och skatterapporter utifrån samma data, och den stängda månaden låses.

Ingenting på den listan kräver att en människa öppnar ett bokföringsprogram. Det är hela poängen med kategorin.

Hur det står sig mot alternativen

Tillvägagångssätt	Insats för att komma igång	Revisionsstatus	Skalar med transaktionsvolym
Kalkylblad och manuell inmatning	Lägst	Svag; historiken är redigerbar	Nej
Bokföringsapp plus CSV-exporter	Låg	Beror enbart på disciplin	Dåligt; någon måste importera filer
Samlings-API till varje kunds egen bokföring	Medium	Ärver vad kundens verktyg än har för egenskaper	Ja, men du äger aldrig posten
Inbäddat bokförings-API (Embedded accounting API)	Medium	Stark om huvudboken är oföränderlig och perioder låses	Ja
Bygga din egen huvudbok	Högst	Stark endast om du också bygger kontrollerna	Ja, och du underhåller den för evigt

Att bygga själv är ett fullt rimligt val för vissa team. Det tas upp mer detaljerat i vår guide om att bygga versus köpa för marknadsplatser.

Vad du bör kontrollera innan du integrerar mot ett

Är saldot härlett eller lagrat? Fråga om ett säljarsaldo är en sökning över verifikatsrader eller en kolumn som någon uppdaterar. Endast det ena överlever en revision.
Vad händer vid ett omsändning (retry)? Skicka samma begäran två gånger och räkna posterna.
Kan du redigera en bokförd post? Svaret bör vara nej, med en dokumenterad korrigeringsväg.
Avvisar en låst period faktiskt en bokföring? Testa det i en sandlåda (sandbox). Nordlet returnerar 409 för en bokföring som daterats inom en låst period.
Hur representeras pengar? Decimalsträngar eller heltal i minsta enhet (minor units). Aldrig flyttal.
Vad finns i revisionsloggen (audit record)? Aktör, åtgärd, entitet och själva ändringen, sökbar i stället för begravd i loggfiler.
Vilka är frekvensbegränsningarna (rate limits)? Nordlet tillåter 300 anrop per minut och API-nyckel och rapporterar din återstående kvot i svarshuvudena. Oavsett siffra, ta reda på den innan du designar din synkning.
Hur får du ut din data? Rapporter, dokument och verifikat i format som du kan överlämna till en redovisningskonsult.

Var och en av dessa punkter går att testa på en eftermiddag mot ett sandlådeföretag. Leverantörernas funktionslistor är inga bevis; ett reproducerbart test är det.

FAQ

Är ett bokförings-API samma sak som bokföringsprogram?

Det är bokföringsprogramvara där gränssnittet har flyttats. Traditionell bokföringsprogramvara sätter en människa framför huvudboken; ett bokförings-API sätter din kod där. De underliggande skyldigheterna, dubbla bokföringsstrukturen och rapporterna är desamma.

Behöver jag fortfarande en redovisningskonsult om jag använder ett?

Ja. Ett API automatiserar registrering, beräkning och rapportering. Det gör inga bedömningar kring klassificering, avsättningar eller hur ett specifikt avtal bör behandlas, och i de flesta länder undertecknar eller lämnar det inte in dina lagstadgade räkenskaper.

Kan jag använda ett bokförings-API utan att förstå dubbel bokföring?

Delvis. Ett bra API sätter ihop bokföringsposterna åt dig utifrån ett affärsdokument som en faktura. Du behöver ändå förstå vad kontona betyder när du läser en rapport eller förklarar ett saldo för en revisor.

Vad är skillnaden mellan ett bokförings-API och ett huvudboks-API (ledger API)?

Ett huvudboks-API registrerar balanserade flöden mellan konton. Ett bokförings-API gör det och lägger till det lagstadgade lagret ovanpå: dokument med lagstadgade nummerserier, momshantering, skatteregister, anläggningstillgångar, periodavslut och de rapporter som en jurisdiktion förväntar sig. Varje bokförings-API innehåller en huvudbok; alla huvudböcker är inte ett bokföringssystem.

Hur lång tid tar det att integrera ett?

För ett första fungerande flöde – skapa en kund, utfärda en faktura, ta emot en betalning, se bokföringsposten – bör du räkna med dagar snarare än veckor med ett typat SDK och en sandlåda. En produktionsintegration som omfattar återbetalningar, korrigeringar, flervaluta, avstämning och periodavslut är ett större arbete, och den ärliga tidsuppskattningen beror på hur många av dessa fall din produkt faktiskt genererar.