Nordlet

← Blog

Hvad er en regnskabs-API? En ukompliceret guide for platformudviklere

En ukompliceret definition af regnskabs-API'en, forskellen på en skatte-API eller en betalings-API, og hvad du bør tjekke, før du bygger oven på en.

Nordlet Team · · 7 min. læsetid

En regnskabs-API er et grænseflade, der giver et program mulighed for at føre et andet programs regnskab. Din software sender en finansiel hændelse via HTTP. API'en omsætter denne hændelse til balancerede dobbeltbogholderiposteringer mod en kontoplan, gemmer dem, så de ikke kan ændres i det skjulte, anvender momsmæssig behandling og returnerer rapporter, dokumenter og eksportfiler gennem den samme grænseflade.

Den definition klarer det meste af arbejdet. Alt andet i denne artikel er en konsekvens af netop det.

Versionen på én sætning

En regnskabs-API modtager finansielle hændelser fra din applikation, konverterer hver enkelt til en balanceret postering, gemmer den uforanderligt sammen med dens momsmæssige behandling og understøttende dokumentation, og eksponerer det resulterende hovedbog, dokumenter og rapporter som programmerbare slutpunkter (endpoints).

Hvis et produkt kalder sig en regnskabs-API, men ikke genererer posteringer, er det noget andet med et godt navn. Det er ikke nødvendigvis en dårlig ting. Det betyder blot, at den ikke kan løse den opgave, du er ved at give den.

Hvad en regnskabs-API ikke er

Fire nærtliggende produktkategorier forveksles ofte med regnskabs-API'er, som regel sent i et forløb.

Kategori Hvad den gør Hvad den ikke gør
Skatteberegnings-API (Tax calculation API) Returnerer den korrekte sats eller skatte- og momsbeløb for en transaktion Fører dit regnskab eller gemmer dokumentationen bag beslutningen i opbevaringsperioden
Betalings-API (Payments API) Flytter penge mellem parter og rapporterer om disse bevægelser Registrerer optjent provision, skyldig moms eller gæld til en sælger i perioden mellem betaling og udbetaling
Unified- eller aggregator-API Læser og skriver data i dine kunders eksisterende regnskabsprogram Fungerer som hovedbog (system of record); dit regnskab findes i det værktøj, som den enkelte kunde allerede bruger
Rapporterings- eller BI-API Læser tal ud af en eksisterende hovedbog og visualiserer dem Opretter de posteringer, som tallene stammer fra

Hver af disse har reelle anvendelsesmuligheder. En platform, der skal fungere som hovedbog, har brug for regnskabs-API'en som fundament under sig, ikke i stedet for.

De fem ting, en regnskabs-API skal kunne

1. Registrere balancerede posteringer. Enhver hændelse bliver til debiteringer og krediteringer, der summer op til det samme beløb. Når en køber betaler 100 EUR på en markedsplads, der tager 15 EUR i provision, debiterer posteringer en mellemregningskonto med 100 EUR, krediterer en gældskonto til sælger med 85 EUR og krediterer provisionsindtægter med 15 EUR. Dette er ikke blot bogføringsceremoni. Det er et strukturelt kontroltjek, der opfanger hele klasser af integrationsfejl, før de når frem til en rapport.

2. Bevare historikken. En bogført postering redigeres ikke. En fejl rettes ved en tilbageførsel plus en korrigeret postering, hvor begge er knyttet til originalen. Afsluttede måneder låses, så intet nyt kan bogføres med dato i dem.

3. Håndtere moms og skat. Ved EU-handel betyder det leveringssted, omvendt betalingspligt (reverse charge), momsnumre valgt mod det officielle register og dokumentationen, der retfærdiggør beslutningen – alt sammen gemt sammen med transaktionen i stedet for at blive slettet efter beregningen.

4. Afstemme mod udefrakommende penge. Et regnskab, der aldrig møder et kontoudtog, er et gæt. API'en skal kunne indlæse kontoudtog eller udbetalinger fra udbydere og matche dem mod det, der er blevet registreret.

5. Eksportere. Rapporter, dokumenter og revisionsfiler i formater, som en menneskelig revisor og skattemyndighederne accepterer.

Et produkt, der kan de første tre, men ikke de sidste to, vil stadig efterlade en person med manuelt arbejde i regneark hver måned.

Hvordan et API-kalde faktisk ser ud

Mekanikken er enklere end bogholderiet. I Nordlets API er enhver handling et RPC-lignende POST med en forudsigelig struktur:

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

Du opretter en salgsfaktura og udsteder den derefter. Udstederen er det øjeblik, hvor bogføringen finder sted: dokumentet får sit fortløbende nummer, den balancerede postering bogføres, og momslinjerne registreres i samme ombæring. Din platform samler aldrig debiteringer og krediteringer manuelt.

Tre detaljer i det uddrag betyder mere end selve slutpunktets navn:

  • Omfanget (scope) på nøglen. En nøgle bærer tilladelser som f.eks. sales:write, så en integration kun får den adgang, der er brug for.
  • Idempotensnøglen (Idempotency key). Forsøg på at gentage den samme forespørgsel med det samme payload returnerer det gemte svar i stedet for at oprette en ekstra faktura. Sendes den samme nøgle med et andet payload, afvises forespørgslen med idempotency_key_reuse i stedet for at blive accepteret i stilhed.
  • Penge som strenge. Beløb er decimalstrenge og ikke flydende tal (floats), fordi flydende tal mister øre- og centbeløb på måder, der viser sig ved årets afslutning.

Hvor den placeres i din arkitektur

Din applikation forbliver frontend og kilden til forretningshændelser. Regnskabs-API'en bliver det finansielle system of record bag den. Flowet er som regel:

  1. Noget sker i dit produkt: en ordre, en tilbagebetaling, en udbetaling, et abonnementsfornyelse.
  2. Din backend kalder regnskabs-API'en med hændelsen og en idempotensnøgle.
  3. API'en bogfører posteringen, anvender moms og returnerer identifikatorer, som du gemmer sammen med dine egne data.
  4. En webhook som f.eks. sale_invoice.paid fortæller dit system, når status ændrer sig, så du reagerer på hændelser i stedet for at polle efter dem.
  5. Banktransaktioner ankommer via et bankfeed eller en filimport og matches mod de registrerede dokumenter.
  6. Ved periodens udløb genereres rapporter og momsindberetninger fra de samme data, og den afsluttede måned låses.

Intet på den liste kræver, at et menneske åbner et regnskabsprogram. Det er hele formålet med kategorien.

Hvordan den adskiller sig fra alternativerne

Tilgang Startindsats Revisionsmæssig position Skalerer med transaktionsvolumen
Regneark og manuel indtastning Lavest Svag; historikken kan redigeres Nej
Regnskabsprogram plus CSV-eksport Lav Afhænger fuldstændigt af disciplinen Dårligt; nogen skal importere filer
Aggregator-API ind i hver kundes eget regnskab Medium Arver det, som kundens værktøj kan Ja, men du ejer aldrig selv dataene
Integreret regnskabs-API (Embedded accounting API) Medium Stærk, hvis hovedbogen er uforanderlig og perioder kan låses Ja
Byg din egen hovedbog Højest Stærk, kun hvis du også bygger kontrolmekanismerne Ja, og du vedligeholder den for evigt

At bygge selv er et reelt valg for nogle hold. Det er beskrevet mere dybdegående i vores guide om at bygge versus købe for markedspladser.

Hvad du bør tjekke, før du bygger oven på en

  • Er saldoen afledt eller gemt? Spørg om en sæ saldo er forespørgsel over posteringslinjer eller blot en kolonne, som nogen opdaterer. Kun én af disse overlever en revision.
  • Hvad sker der ved et gentaget kald (retry)? Send den samme forespørgsel to gange og tæl posteringerne.
  • Kan du redigere en bogført postering? Svaret bør være nej, ledsaget af en dokumenteret rettelsessti.
  • Afviser en låst periode rent faktisk en bogføring? Test det i et sandkasse-miljø (sandbox). Nordlet returnerer 409 for en bogføring med dato i en låst periode.
  • Hvordan repræsenteres penge? Decimalstrenge eller underenheder som heltal (integers). Aldrig flydende tal (floats).
  • Hvad indeholder revisionssporet (audit record)? Aktør, handling, entitet og selve ændringen, som kan forespørges i stedet for at være gemt væk i logfiler.
  • Hvad er hastighedsgrænserne (rate limits)? Nordlet tillader 300 forespørgsler i minuttet pr. API-nøgle og rapporterer dit resterende budget i svarskrankerne (response headers). Uanset tallet skal du kende det, før du designer din synkronisering.
  • Hvordan får du dine data ud? Rapporter, dokumenter og journaler i formater, du kan udlevere til en revisor.

Hvert af disse punkter kan testes på en eftermiddag mod et sandkasseselskab. Leverandørernes funktionslister er ikke beviser; en reproducerbar test er.

FAQ

Er en regnskabs-API det samme som regnskabsprogrammer?

Det er regnskabsprogrammer, hvor grænsefladen er flyttet. Traditionelt regnskabsprogram sætter et menneske foran hovedbogen; en regnskabs-API sætter din kode der. De underliggende forpligtelser, dobbeltbogholderiets struktur og rapporterne er de samme.

Har jeg stadig brug for en revisor, hvis jeg bruger en?

Ja. En API automatiserer bogføring, beregning og rapportering. Den foretager ikke skønsmæssige vurderinger af kontoklassificering, hensættelser eller hvordan en specifik kontrakt skal behandles, og i de fleste lande underskriver eller indberetter den ikke dit årsregnskab.

Kan jeg bruge en regnskabs-API uden at forstå dobbelt bogholderi?

Delvist. En god API opretter posteringerne for dig ud fra et forretningsdokument som f.eks. en faktura. Du skal dog stadig forstå, hvad kontiene betyder, når du læser en rapport eller forklarer en saldo over for en revisor.

Hvad er forskellen på en regnskabs-API og en hovedbogs-API (ledger API)?

En hovedbogs-API registrerer balancerede bevægelser mellem konti. En regnskabs-API gør det samme og tilføjer det lovpligtige lag ovenpå: dokumenter med juridisk nummerserie, momsmæssig behandling, momsregnskaber, anlægsaktiver, periodelukning og de rapporter, som de lokale myndigheder forventer. Enhver regnskabs-API indeholder en hovedbog, men ikke enhver hovedbog er et regnskabssystem.

Hvor lang tid tager det at integrere en?

For et første fungerende flow – opret en kunde, udsted en faktura, modtag en betaling, se posteringen – skal du regne med dage snarere end uger, når du bruger et typet SDK og et sandkasseselskab. En produktionsintegration, der dækker tilbagebetalinger, rettelser, acontobetalinger, flervaluta, afstemning og periodelukning, er en større opgave, og det ærlige estimat afhænger af, hvor mange af disse scenarier dit produkt rent faktisk genererer.

Yderligere læsning