Hva er en API-basert dobbel bokføringsreskontro for markedsplasser?
En API-basert reskontro for dobbel bokføring registrerer pengestrømmer på markedsplasser som balanserte og uforanderlige posteringer, slik at du alltid vet hvem som skylder hva og hvorfor.
En markedsplass kan se sunn ut i orders-tabellen sin og likevel ta feil av sine egne penger. Bestillingen sier «betalt». Selgerens dashbord viser en saldo. Men ingenting i den tabellen beviser hvor mye kontanter plattformen faktisk besitter, hvor mye den skylder hver enkelt selger, hvor stor del av betalingen som er provisjonsinntekt, eller hvor mye merverdiavgift som nå er til betaling. En API-basert reskontro for dobbel bokføring (double-entry ledger API) eksisterer for å registrere disse økonomiske konsekvensene på en korrekt måte, én balanseroid transaksjon om gangen.
Kort sagt: en API-basert reskontro for dobbel bokføring er et programmerbart regnskapssystem. Applikasjonen din sender en finansiell hendelse til den, for eksempel en gjennomført betaling eller en godkjent utbetaling, og reskontroen skriver denne hendelsen som en journal med like store debet- og kreditbeløp på tvers av navngitte kontoer. Den flytter ikke penger. Den registrerer sannheten om pengene som har flyttet seg et annet sted.
Hva «dobbel bokføring» betyr i denne sammenhengen
En reskontro (ledger) er registreringen av endringer på kontoer, ikke en tabell som bare viser den siste saldoen. En fungerende reskontro bygger på tre sammenhengende ideer:
- Konto (Account): en navngitt finansiell posisjon, for eksempel kundefordring på betalingsformidler, leverandørgjeld til selger, provisjonsinntekt eller skyldig merverdiavgift.
- Transaksjon / journal (Transaction / journal): én atomisk finansiell hendelse som inneholder flere balanserte linjer.
- Postering (Entry / posting): én enkelt debet- eller kreditlinje inne i denne transaksjonen.
Det faste prinsippet som holder hele designet sammen, er enkelt: samlet debet er lik samlet kredit for hver eneste transaksjon og hver enkelt valuta. Reskontro-API-er avviser vanligvis en ubalansert skriveoperasjon før den når lagringen. Dokumentasjonen til Modern Treasury definerer en reskontrotransaksjon som en som involverer to eller flere kontoer med minst én debet og én kredit med like store totaler, og behandler en bokført transaksjon som uforanderlig (immutable).
Dobbel bokføring betyr ikke nøyaktig to rader. Et enkelt salg på en markedsplass krever ofte én debet og flere kreditter. Det er dette folk misforstår mest.
Hvorfor markedsplasser trenger en reskontro, ikke bare en betalingstabell
En markedsplass opprettholder flere finansielle relasjoner på samme tid. En kjøper betaler. En betalingsformidler gjør opp (settlement). Plattformen kontrollerer kanskje midlene midlertidig. Selgeren opparbeider seg enandel. Plattformen beholder en provisjon. Mva. blir påløpt. En reserve kan holdes tilbake. Senere flytter en utbetaling penger ut, og refusjoner eller tilbaketvinginger (chargebacks) reverserer deler av det.
En payments-tabell kan fortelle deg den kommersielle statusen til en bestilling. Den kan ikke på en pålitelig måte fortelle deg:
- hvor mye som står på fordringer fra betalingsformidleren eller i kontanter
- hvor mye som skyldes hver enkelt selger
- hvor stor inntekt som tilhører plattformen
- hvor mye mva. som skal betales, og i hvilket land
- hva som er reservert mot refusjoner eller tvister
- om en utbetaling reduserte riktig selgergjeld
- om oppgjørene fra betalingsformidleren samsvarer med det plattformen forventet
Nordlets guide til API-er for dobbel bokføringsreskontro for markedsplassregnskap trekker opp grensen tydelig: applikasjonstabeller beskriver produktets tilstand, mens reskontroen registrerer de finansielle konsekvensene av den tilstanden. Den peker også på noe som er verdt å gjenta, nemlig at rapporter fra betalingsformidlere er inndata for avstemming, ikke komplette regnskap med dobbel bokføring.
Et gjennomgått markedssalg
Tenk deg at en kjøper betaler 100 €, selgeren har krav på 85 €, og plattformens provisjon er 15 €. Vi ser bort fra mva. og formidlergebyrer for enkelhets skyld.
| Konto | Debet | Kredit | Årsak |
|---|---|---|---|
| Fordring på betalingsformidler | 100 € | Formidleren skylder plattformen den innkrevde betalingen | |
| Leverandørgjeld til selger | 85 € | Plattformen skylder selgeren | |
| Provisjonsinntekt | 15 € | Plattformen har tjent inn sin provisjon | |
| Totalt | 100 € | 100 € | Balansert |
Den viktige klassifiseringen her er at de 85 euroene som skyldes selgeren, er en gjeldskonto (liability), ikke plattformens inntekt. I henhold til det konseptuelle rammeverket til IFRS er en forpliktelse en nåværende anmodning om å overføre en økonomisk ressurs. En markedsplass bør ikke inntektsføre selgerens fulle salgsproveny som sin egen inntekt bare fordi kjøypen ble gjort gjennom den. Hvorvidt dere opptrer som agent, prinsipp eller ansett som leverandør (deemed supplier) endrer behandlingen, men reskontromekanismen forblir den samme.
Når selgeren blir berettiget til utbetaling, blir ingen ny inntekt anerkjent. Du gjør opp gjelden:
| Konto | Debet | Kredit |
|---|---|---|
| Leverandørgjeld til selger | 85 € | |
| Bank- eller utbetalingskonto | 85 € | |
| Totalt | 85 € | 85 € |
Hvis betalingsformidleren trekker et gebyr på 3 € før oppgjør, blir pengestrømmen en journal med tre linjer: 97 € til bankkontanter, 3 € til behandlingskostnad (processing expense), 100 € ut fra fordring på betalingsformidler. Hver endring i posisjon har en kilde og et reisemål.
Slik fungerer API-et, trinn for trinn
1. Applikasjonen din oppdager en forretningshendelse. En betaling blir fanget opp, en bestilling blir oppfylt, en utbetaling blir godkjent, en refusjon utstedes, en tvist åpnes, et oppgjør lander. Databasen din eier fremdeles den operasjonelle tilstanden. Reskontroen registrerer den monetære effekten.
2. Du sender en strukturert forespørsel. Den inneholder vanligvis hendelsestype, beløp og valuta, bestillings- eller betalings-ID, kjøper- og selgeridentifikatorer, provisjon, mva.-data, de involverte kontoene, virknings- og bokføringsdatoer, en idempotensnøkkel (idempotency key) og metadata som peker tilbake til formidler- og produktposter. Nordlets offentlige API-eksempel viser en konseptuell salgsforespørsel med selger-ID, salgstype, beløp, valuta samt mva.-land og -sats.
3. API-et validerer. Det sjekker at debet og kredit balanserer, at kontoene eksisterer og kan bokføres på, at valutaen støttes, at beløpet bruker presis håndtering av underenheter (minor units), at idempotensnøkkelen ikke gjenbrukes for et annet resultat, at perioden er åpen, og at påkrevde metadata er tilstede. En mislykket sjekk etterlater ingen delvise journaler.
4. Det bokfører atomisk. Hele transaksjonen skrives som én enhet. Du skal aldri kunne registrere debeten mens den matchende krediten feiler. For en markedsplass kan en delvis splitting skape en tilsynelatende selgersaldo uten tilhørende kontanter, eller bokføre provisjon uten selgerforpliktelsen.
5. Saldoer og rapporter utledes fra reskontroen. Etter bokføring kan du lese kontosaldoer, selgeres ventende og tilgjengelige saldoer, råbalanse (trial balance), hovedbokaktivitet, mva.-sammendrag og historikk per en dato i fortiden. Selgersaldoen skal kunne gjenopprettes fra posteringer, ikke stoles på fra et felt som kan endres.
6. Webhooks varsler produktet ditt. Hendelser som sale_invoice.paid, en bokført journal, en tilgjengelig utbetaling eller et avstemmingsavvik blir sendt til deg. Behandle dem idempotens. En webhook er et varsel, ikke tillatelse til å anvende den finansielle hendelsen en gang til. API-konvensjonene dekker omfang (scopes), idempotensnøkler, feilformer og webhook-signering i detalj.
Selgersaldoer er ikke bare én enkelt tallverdi
De fleste markedsplasser havner i problemer ved å behandle en selgersaldo som ett enkelt tall. Penger bør ligge fordelt på ulike statuser:
| Status | Betydning |
|---|---|
| Ventende (Pending) | Selgeren kan ha krav på midlene, men frigivelsesbetingelsene er ikke oppfylt |
| Tilgjengelig (Available) | Berettiget til utbetaling |
| Reservert (Reserved) | Holdes tilbake mot refusjoner, returer eller tvister |
| Utbetalt (Paid out) | Forpliktelsen er gjort opp via en overføring |
| Negativ (Negative) | Refusjoner, tvister eller gebyrer overstiger tilgjengelige midler |
Modellene til betalingsformidlere gjenspeiler dette. Stripes flyt med separate belastninger og overføringer (separate charges and transfers) lar en plattform belaste sin egen konto, og deretter overføre deler til tilknyttede kontoer, der gebyrer, refusjoner og tvister lander på plattformens saldo. Adyens markedsplassmodell skiller brukerbalansekontoer, som holder på midler frem til utbetaling, fra en ansvarlig balansekonto (liable balance account) som kan absorbere negative saldoer fra refusjoner eller tvister. Dette er nyttige inndata til reskontroen din. De er ikke din komplette regnskapsmodell.
Utbetalinger og selgerinntekter skjer på ulike tidspunkter
En selger kan tjene penger på mandag og få dem utbetalt mandagen etter. Mellom disse tidspunktene blir en bestilling oppfylt, en reserve holdes tilbake, en utbetalingsbatch bygges opp, en formidler gjør opp nettet etter gebyrer, og et bankinnskudd ankommer. En reskontro må bevare hvert trinn i stedet for å overskrive bestillingen med en endelig «betalt»-status. Det er dette som gjør at du kan forklare tidsforskjeller mellom bestillingsaktivitet, selgerens krav, oppgjør, iverksetting av utbetaling og bankmottak.
Refusjoner og tvister: reverser, ikke overskriv
Refusjoner og tvister er nye hendelser knyttet til den opprinnelige betalingen. I en uforanderlig reskontro korrigerer du med en reverserende postering etterfulgt av en korrigert en, slik dat den opprinnelige forblir synlig for revisjon. Modern Treasury behandler bokførte transaksjoner som uforanderlige og støtter idempotensnøkler for å forhindre dupliserte objekter ved gjentatte forsøk.
En refusjon reduserer vanligvis kontanter eller kundefordring, reverserer leverandørgjeld til selger, kan reversere deler av provisjonen avhengig av retningslinjene, justerer skatt og kan forbruke en refusjonsreserve. En tvist (chargeback) reduserer kontanter eller fordring på betalingsformidler, kan gjenåpne et beløp som skyldes av selgeren eller plattformen, registrerer en tvistekostnad og et formidlergebyr, og flytter midler gjennom en reskontrokonto.
Avstemming: å koble reskontroen til ekte penger
En reskontro kan være internt balansert og likevel ta feil av omverdenen. Avstemming sammenligner interne opptegnelser med eksterne bevis: oppgjørsrapporter fra betalingsformidler, kontoutskrifter, utbetalingsfiler samt refusjons- og tvisteposter.
En fungerende løkke ser slik ut:
- Importer oppgjørs- eller bankbatchen.
- Matche hver linje mot en bestilling, betaling, refusjon, gebyr, utbetaling eller tvist.
- Sammenlign forventet bruttobeløp, fradrag, reserver og nettobeløp.
- Bokfør bekreftede bevegelser i reskontroen.
- Send umatchere elementer til en navngitt mellomregningskonto for avvik (suspense account).
- Undersøk avvik.
- Lås perioden.
Nordlets avstemmingsmateriell beskriver nøyaktig dette: å importere oppgjørsbatcher, matche belastnings- og refusjonslinjer, og rutere umatchede innbetalinger til en mellomregningskonto i stedet for å gjette på en faktura. To sjekker betyr noe, og ingen av dem erstatter den andre: dobbel bokføringsvalidering spør om hver journal balanserer, og avstemming spør om den stemmer overens med betalingsformidleren, banken og forretningshendelsen.
Designdetaljer som avgjør om du treffer blink
Idempotens. Knytt nøkkelen til en stabil hendelse, for eksempel payment_captured:pi_123. Et nytt forsøk returnerer det opprinnelige resultatet, ikke en ekstra journal.
Atomisitet. Alle linjene i én hendelse bokføres sammen, eller ingen av dem gjør det.
Uforanderlighet og reverseringer. Bokført historikk kan ikke redigeres gjennom ordinære oppdateringer. Korrigeringer oppretter tilknyttede posteringer som bevarer opprinnelig beløp, dato, klassifisering, årsak og forfatter.
Presise penger. Ingen binære flyttall. Bruk heltallbaserte underenheter eller eksakte desimaler, eksplisitt valuta og en deterministisk avrundingsregel for oppdelinger. Hvis du deler 100 € på tvers av selgere og gebyrer uten dette, vil en tilfeldig øre ødelegge balansen din.
Virknings- vs. bokføringsdato. Når kjøperen betalte, når selgeren tjente pengene, når banken gjorde opp, og når posteringen ble bokført, er ulike datoer. Å blande disse sammen gjør perioderapportering og skattetidspunkt upålitelig.
Multivaluta. Debet og kredit bør balansere innenfor en gitt valuta. Konvertering krever en eksplisitt valutakurshendelse med kontoer for gebyr, avrunding og eventuell valutagevinst eller -tap. Å akseptere et currency-felt gjør ikke en reskontro til en valutamotor.
Hva en reskontro-API ikke vil gjøre for deg
Den vil ikke bestemme kontoplanen din for deg. Du må fremdeles avgjøre om du er prinsipp eller agent, når provisjonen er opptjent, hvilken part som bærer formidlergebyrene, hvordan refusjoner påvirker provisjonen, og hvordan mva. beregnes og rapporteres. Nordlets egen veiledning er å kartlegge pengestrømmene først, utarbeide kontoplanen, få en regnskapsfører til å gjennomgå den, og deretter implementere én fullstendig flyt fra bestilling til utbetaling og avstemming før dere skalerer opp.
Den vil ikke løse skattespørsmål. Mva. avhenger av kjøperens og selgerens lokasjon, produkttype, registreringsstatus og regler for avgiftspliktige formidlere (deemed-supplier rules); EUs mva.-guide viser hva motoren utleder og hva den flagger for menneskelig kontroll. Nordlets mva.-dekning er fokusert på EU og EØS, så den strekker seg ikke til amerikansk salgsmeskatt (US sales tax) eller latinamerikansk e-fakturering. Den vil heller ikke løse operasjonell tvetydighet – om et returvindu er stengt, om en utbetaling bør blokkeres, eller om en betaling er svindelaktig. Dette er beslutninger du må ta. Reskontroen registrerer det finansielle resultatet av dem.
Hvor Nordlet passer inn
Nordlet er et regnskaps-API bygget for plattformer og markedsplasser, med en uforanderlig reskontro for dobbel bokføring, utbetalinger, håndtering av EU-mva., REST-endepunkter, typpede SDK-er og webhooks som kan nås gjennom ett enkeltgrensesnitt. Det som skiller den ut, er innebygd regnskap i ditt eget produkt i stedet for en utsjekking fra tredjepart. Per i dag er produktet i tidlig tilgang med en sandkasse for designpartnere, så betrakte det som et sterkt eksempel på denne kategorien og vurder produksjonsmodenhet, oppetid og jurisdiksjonell dekning for ditt eget tilfelle før du forplikter deg.
For markedsplass- og plattformutviklere er den nyttige mentalmodellen skillet mellom betalingsbevegelse og finansiell sannhet. Betalingsformidleren din flytter pengene. En API-basert dobbel bokføringsreskontro registrerer hvem som skylder hva, hva du har tjent, hvilke avgifter og reserver du bærer, og om omverdenen stemmer overens med regnskapet ditt.
FAQ
Er en API-basert dobbel bokføringsreskontro det samme som en betalingsformidler?
Nei. En formidler autoriserer, innkrevd, gjør opp og betaler noen ganger ut midler. Et reskontro-API registrerer regnskapskonsekvensene av disse hendelsene. De fleste markedsplasser bruker begge deler – en formidler som Stripe eller Adyen for selve pengestrømmen, og en reskontro for regnskapet.
Kan jeg bare bruke betalingsformidlerens dashbord som hovedbok?
Du kan prøve, og det vil før eller siden feile under en revisjon. Rapporter fra betalingsformidlere viser transaksjoner, gebyrer, overføringer og oppgjør, men den viser vanligvis ikke dine fulle selgerforpliktelser, mva.-forpliktelser, ikke-formidlerrelaterte kostnader eller regnskapsmessige justeringer. Behandle det som inndata for avstemming.
Betyr en balansert reskontro at regnskapet mitt er korrekt?
Bare at posteringene dine oppfyller debet/kredit-regelen. En perfekt balansert transaksjon kan fremdeles være bokført på feil konto, på feil selger eller med feil merverdiavgiftsbehandling. Balanse er nødvendig, men ikke tilstrekkelig. Avstemming er det som fanger opp resten.
Hvordan retter jeg opp feil hvis reskontroen er uforanderlig?
Du bokfører en reverserende postering og deretter en korrigert en. Den opprinnelige posteringen forblir synlig, og det er hele poenget. Uforanderlighet beskytter revisjonssporet, den fanger deg ikke i feilene dine.
Gjør et regnskaps-API meg automatisk regeletterlevende (compliant)?
Nei. Det håndhever regnskapsstruktur og produserer brukbare opptegnelser. Juridisk etterlevelse avhenger fremdeles av din jurisdiksjon, din kontraktsmessige rolle, skattebehandling, betalingsforskrifter, KYC- og AML-prosesser samt rapporteringsforpliktelser.