Hva er et regnskaps-API? En enkel guide for plattformbyggere

En enkel definisjon av et regnskaps-API, hva som skiller det fra et skatte-API eller et betalings-API, og hva du bør sjekke før du integrerer mot det.

Et regnskaps-API er et grensesnitt som lar ett program føre regnskapet for et annet program. Programvaren din sender en finansiell hendelse via HTTP. API-et omgjør hendelsen til balanserte regnskpsbilag med dobbel bokføring mot en kontoplan, lagrer dem slik at de ikke kan endres i det skjulte, håndterer mva.-behandling, og gir deg rapporter, dokumenter og eksportmuligheter tilbake gjennom det samme grensesnittet.

Den definisjonen gjør mesteparten av jobben. Alt annet i denne artikkelen er en konsekvens av det.

Versjonen på én setning

Et regnskaps-API aksepterer finansielle hendelser fra applikasjonen din, konverterer hver enkelt til et balansert bilag, lagrer det uforanderlig med mva.-behandling og tilhørende dokumentasjon, og eksponerer det resulterende hovedboken, dokumentene og rapportene som programmerbare endepunkter.

Hvis et produkt kaller seg et regnskaps-API, men ikke produserer regnskapsbilag, er det noe annet med et pent navn. Det er ikke nødvendigvis negativt. Det betyr bare at det ikke vil gjøre den jobben du er i ferd med å be det om.

Hva et regnskaps-API ikke er

Fire nærliggende produktkategorier blir ofte forvekslet med regnskaps-API-er, som regel sent i et prosjekt.

Kategori	Hva det gjør	Hva det ikke gjør
Skatte- og avgiftsberegnings-API	Returnerer riktig sats eller avgiftsbeløp for en transaksjon	Fører regnskapet ditt eller lagrer dokumentasjonen bak beslutningen i oppbevaringsperioden
Betalings-API	Flytter penger mellom parter og rapporterer om disse bevegelsene	Registrerer opptjent provisjon, skyldig mva. eller gjeld til en selger mellom betaling og utbetaling
Integrasjons- eller aggregator-API	Les og skriver data i kundenes eksisterende regnskapsprogramvare	Fungerer som hovedbok; regnskapet ditt ligger i det verktøyet kunden din allerede bruker
Rapporterings- eller BI-API	Henter tall ut fra en eksisterende hovedbok og visualiserer dem	Oppretter posteringene som tallene er avledet fra

Hver av disse har reelle bruksområder. En plattform som må være kilden til sannhet (system of record), trenger regnskaps-API-et i bunnen, ikke i stedet for det.

De fem tingene et regnskaps-API må gjøre

1. Registrere balanserte posteringer. Hver hendelse blir til debet og kredit som summerer seg opp til samme beløp. Når en kjøper betaler 100 EUR på en markedsplass som tar 15 EUR i provisjon, debiteres en klientkonto med 100 EUR, det krediteres leverandørgjeld til selger med 85 EUR, og det krediteres provisjonsinntekt med 15 EUR. Dette er ikke et byråkratisk regnskapsritual. Det er en strukturell sjekk som fanger opp hele klasser av integrasjonsfeil før de når en rapport.

2. Ta vare på historikken. En postert bilag linje redigeres ikke. En feil rettes opp ved hjelp av en tilbakeføring pluss et korrigert bilag, som begge er knyttet til originalen. Avsluttede måneder låses slik at ingenting nytt kan dateres tilbake til dem.

3. Håndtere avgifter. For internasjonal handel betyr det leveringssted, omvendt avgiftsplikt (reverse charge), MVA-numre sjekket mot det offisielle registeret, og dokumentasjonen som begrunnet avgjørelsen, alt lagret sammen med transaksjonen i stedet for å bli slettet etter beregningen.

4. Avstemme mot eksterne penger. Et regnskap som aldri møter et kontoutskrift, er bare en antagelse. API-et må hente inn kontoutskrifter eller oppgjør fra tilbydere og avstemme dem mot det som er registrert.

5. Eksportere. Rapporter, dokumenter og revisjonsfiler i formater som en regnskapsfører og skattemyndighetene godtar.

Et produkt som gjør de første tre, men ikke de to siste, vil fremdeles etterlate en person som gjør manuelt regnearkarbeid hver måned.

Slik ser et kall faktisk ut

Mekanikken er enklere enn regnskapet. I Nordlets API er hver operasjon en RPC-lignende POST med en forutsigbar struktur:

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

Du oppretter en salgsfaktura og utsteder den deretter. Utstedelsen er øyeblikket regnskapet skjer: dokumentet får sitt løpende nummer, det balanserte bilaget posteres, og MVA-linjene registreres sammen med det. Plattformen din setter aldri sammen debet og kredit manuelt.

Tre detaljer i det kodeeksemplet betyr mer enn selve endepunktsnavnet:

Omfanget på nøkkelen (scope). En nøkkel har tillatelser som sales:write, slik at en integrasjon bare får den tilgangen den trenger.
Idempotensnøkkelen (idempotency key). Hvis du sender den samme forespørselen på nytt med samme nyttelast (payload), får du det lagrede svaret tilbake i stedet for en ekstra faktura. Sender du den samme nøkkelen med en annen nyttelast, avvises forespørselen med idempotency_key_reuse i stedet for å bli stille akseptert.
Penger som strenger. Beløp er desimalstrenger, ikke flyttall (floats), fordi flyttall mister ørebeløp på måter som dukker opp ved årsskiftet.

Hvor det plasserer seg i arkitekturen din

Applikasjonen din forblir fronten og kilden til forretningshendelser. Regnskaps-API-et blir det finansielle regnskapssystemet bak den. Flyten er vanligvis slik:

Noe skjer i produktet ditt: en bestilling, en refusjon, en utbetaling, en abonnementsfornyelse.
Backend-systemet ditt kaller regnskaps-API-et med hendelsen og en idempotensnøkkel.
API-et bokfører bilaget, beregner MVA og returnerer identifikatorer som du lagrer mot egne registre.
En webhook som sale_invoice.paid forteller systemet ditt når en tilstand endres, slik at du reagerer på hendelser i stedet for å polle etter dem.
Banktransaksjoner ankommer via en bankstrøm (bank feed) eller filimport og avstemmes mot de registrerte dokumentene.
Ved periodens slutt genereres rapporter og avgiftsregistre fra de samme dataene, og den avsluttede måneden låses.

Ingenting på den listen krever at et menneske åpner et regnskapsprogram. Det er hele poenget med denne kategorien.

Hvordan det måler seg mot alternativene

Tilnærming	Innsats for å komme i gang	Revisjonssatser	Skalerer med transaksjonsvolum
Regneark og manuell registrering	Lavest	Svak; historikken kan redigeres	Nei
Regnskapsapp pluss CSV-eksport	Lav	Avhenger utelukkende av disiplin	Dårlig; noen må importere filer
Aggregator-API inn i hver kunders egne bøker	Medium	Arver det kunden sitt verktøy gjør	Ja, men du eier aldri bilagene
Innebygd regnskaps-API (embedded accounting)	Medium	Sterk hvis hovedboken er uforanderlig og perioder låses	Ja
Bygge din egen hovedbok	Høyst	Sterk bare hvis du også bygger kontrollene	Ja, og du vedlikeholder den for alltid

Å bygge sin egen løsning er et legitimt valg for enkelte team. Det er dekket mer detaljert i guiden vår om å bygge versus kjøpe for markedsplasser.

Hva du bør sjekke før du integrerer mot et API

Er saldi avledet eller lagret? Spør om en selgersaldo er et søk over regnskapslinjer eller en kolonne noen oppdaterer. Bare en av dem overlever en revisjon.
Hva skjer ved en ny forsøk (retry)? Send den samme forespørselen to ganger og tell bilagene.
Kan du redigere et postert bilag? Svaret bør være nei, med en dokumentert korrigeringsflyt.
Avviser en låst periode faktisk en postering? Test det i et sandkassesesjon (sandbox). Nordlet returnerer 409 for en postering datert i en låst periode.
Hvordan representeres penger? Desimalstrenger eller heltall (minor units). Aldri flyttall.
Hva finnes i revisjonsloggen? Aktør, handling, enhet og selve endringen, søkbar i stedet for begravet i loggfiler.
Hva er hastighetsbegrensningene (rate limits)? Nordlet tillater 300 forespørsler per minutt per API-nøkkel og rapporterer gjenværende kvote i responsheaders. Uansett tall, finn det ut før du designer synkroniseringen.
Hvordan får du dataene ut? Rapporter, dokumenter og bilag i formater du kan overlevere til en regnskapsfører.

Hvert enkelt av disse punktene kan testes på en ettermiddag mot et sandkasseselskap. Funksjonslister fra leverandører er ikke bevis; en reproduserbar test er det.

FAQ

Er et regnskaps-API det samme som regnskapsprogramvare?

Det er regnskapsprogramvare der grensesnittet er flyttet. Tradisjonell regnskapsprogramvare setter et menneske foran hovedboken; et regnskaps-API setter koden din der. De underliggende forpliktelsene, strukturen med dobbel bokføring og rapportene er de samme.

Trenger jeg fremdeles en regnskapsfører hvis jeg bruker en slik løsning?

Ja. Et API automatiserer registrering, beregning og rapportering. Det fanger ikke opp skjønnsmessige vurderinger om klassifisering, avsetninger eller hvordan en spesifikk kontrakt skal behandles, og i de fleste land signerer eller leverer det ikke dine lovpålagte regnskaper.

Kan jeg bruke et regnskaps-API uten å forstå dobbel bokføring?

Delvis. Et godt API setter sammen regnskapsbilagene for deg ut fra et forretningsdokument, for eksempel en faktura. Du må fremdeles forstå hva kontoene betyr når du leser en rapport eller forklarer en saldo for en revisor.

Hva er forskjellen mellom et regnskaps-API og et hovedbok-API (ledger API)?

Et hovedbok-API registrerer balanserte bevegelser mellom kontoer. Et regnskaps-API gjør det samme og legger det lovpålagte laget på toppen: dokumenter med lovbestemt nummerering, MVA-behandling, avgiftsregistre, anleggsmidler, periodeslutt og rapportene som en jurisdiksjon forventer. Hvert regnskaps-API inneholder en hovedbok, men ikke enhver hovedbok er et regnskapssystem.

Hvor lang tid tar det å integrere?

For en første fungerende flytt – opprett en kunde, utsted en faktura, motta en betaling, se bilaget – bør du planlegge for dager snarere enn uker med et typet SDK og et sandkassesesjon. En produksjonsintegrasjon som dekker refusjoner, korrigeringer, flerretningsvalutaer, avstemming og periodeslutt er et større stykke arbeid, og det ærlige estimatet avhenger av hvor mange av disse tilfellene produktet ditt faktisk genererer.