Vad är ett dubbelt bokförings-API (ledger API) för marknadsplatser?
Ett dubbelt bokförings-API (ledger API) registrerar pengarnas flöde på en marknadsplats som balanserade, oföränderliga verifikat så att du alltid vet vem som ska ha vad och varför.
En marknadsplats kan se hälsosam ut i sin orders-tabell och ändå ha fel på pengarna. Beställningen visar "betald". Säljarens instrumentpanel visar ett saldo. Men ingenting i den tabellen bevisar hur mycket likvida medel plattformen innehar, hur mycket den är skyldig varje säljare, hur stor del av betalningen som utgör provisionsintäkt eller hur mycket moms som nu ska betalas. Ett dubbelt bokförings-API (ledger API) finns för att registrera dessa ekonomiska konsekvenser på ett korrekt sätt, en balanserad transaktion i taget.
Kort sagt: ett dubbelt bokförings-API är ett programmerbart redovisningssystem. Din applikation skickar en finansiell händelse till det, till exempel en genomförd betalning eller en godkänd utbetalning, och reskontran bokför den händelsen som ett verifikat med lika stora debet- och kreditbelopp på namngivna konton. Den flyttar inte pengar. Den registrerar sanningen om pengar som har flyttats någon annanstans.
Vad "dubbel bokföring" (double-entry ledger) betyder här
En reskontra är registret över förändringar på konton, inte en tabell som bara visar det senaste saldot. En fungerande reskontra vilar på tre sammankopplade begrepp:
- Konto (Account): en namngivd finansiell position, såsom kundfordringar hos betalleverantör, skulder till säljare, provisionsintäkter eller skuld avseende moms.
- Transaktion / Verifikat (Transaction / Journal): en atomär finansiell händelse som innehåller flera balanserade rader.
- Bokföringslagring (Entry / Posting): en enskild debet- eller kreditrad inom den transaktionen.
Den invariant som håller ihop hela konstruktionen är enkel: total debet är lika med total kredit, för varje transaktion och varje valuta. Reskontra-API:er brukar avvisa obalanserade skrivningar innan de når lagringen. Modern Treasurys dokumentation definierar en reskontratransaktion som något som involverar två eller flera konton med minst en debetpost och en kreditpost av lika stora totalbelopp, och behandlar en bokförd transaktion som oföränderlig (immutable).
Dubbel bokföring innebär inte exakt två rader. En enskild marknadsplatsförsäljning kräver ofta en debetpost och flera kreditposteringar. Det är den del som folk oftast missförstår.
Varför marknadsplatser behöver en reskontra, inte bara en betalningstabell
En marknadsplats hanterar flera finansiella relationer samtidigt. En köpare betalar. En betalningsförmedlare avräknar. Plattformen kan tillfälligt kontrollera medlen. Säljaren tjänar en del. Plattformen behåller en provision. Skatt uppstår som en skuld. En reserv kan hållas inne. Senare flyttar en utbetalning pengar ut från systemet, och återbetalningar eller chargebacks vänder delar av det.
En tabell för payments kan tala om den kommersiella statusen för en beställning. Den kan inte på ett tillförlitligt sätt tala om:
- hur mycket fordringar eller kassa som finns hos betalningsförmedlaren
- hur mycket som är skyldig varje säljare
- hur stor intäkt som tillhör plattformen
- hur mycket moms som ska betalas, och i vilket land
- vad som är reserverat mot återbetalningar eller tvister
- om en utbetalning minskade rätt säljarskuld
- om betalningsförmedlarens avräkningar matchar det plattformen förväntade sig
Nordlets guide till dubbla bokförings-API:er för marknadsplatsredovisning drar gränsen tydligt: applikationstabeller beskriver produktstatus, medan reskontran registrerar de finansiella konsekvenserna av den statusen. Den lyfter också fram en poäng som tål att upprepas, nämligen att betalningsförmedlarens rapporter är indata för avstämning, inte fullständiga dubbla bokföringsböcker.
En genomgång av en marknadsplatsförsäljning
Anta att en köpare betalar 100 EUR, säljaren har rätt till 85 EUR och plattformens provision är 15 EUR. Bortse från moms och avgifter från betalningsförmedlaren för tydlighetens skull.
| Konto | Debet | Kredit | Anledning |
|---|---|---|---|
| Kundfordran betalningsförmedlare | 100 EUR | Betalningsförmedlaren är skyldig plattformen den inbetalda summan | |
| Skuld till säljare | 85 EUR | Plattformen är skyldig säljaren | |
| Provisionsintäkt | 15 EUR | Plattformen har tjänat in sin provision | |
| Totalt | 100 EUR | 100 EUR | Balancerat |
Den viktiga klassificeringen här är att de 85 EUR som är skyldiga säljaren utgör en skuld, inte plattformsintäkt. Enligt IFRS begreppsram är en skuld en befintlig förpliktelse att överföra en ekonomisk resurs. En marknadsplats bör inte redovisa säljarens fullständiga försäljningsintäkt som sin egen inkomst enbart för att köparen betalade via den. Oavsett om du uppträder som agent, huvudman (principal) eller anses som säljare (deemed supplier) ändras behandlingen, men reskontramekanismen förblir densamma.
När säljaren blir berättigad till utbetalning bokförs ingen ny intäkt. Du reglerar skulden:
| Konto | Debet | Kredit |
|---|---|---|
| Skuld till säljare | 85 EUR | |
| Bank- eller utbetalningskonto | 85 EUR | |
| Totalt | 85 EUR | 85 EUR |
Om betalningsförmedlaren drar en avgift på 3 EUR före utbetalning blir kassaflödet ett verifikat med tre rader: 97 EUR till bankkassa, 3 EUR till behandlingskostnad (processing expense), 100 EUR ut från kundfordran hos betalningsförmedlaren. Varje förändring av en position har en källa och en destination.
Hur API:et fungerar, steg för steg
1. Din applikation upptäcker en affärshändelse. En betalning genomförs, en beställning uppfylls, en utbetalning godkänns, en återbetalning utfärdas, en chargeback öppnas, en avräkning landar. Din databas äger fortfarande den operationella statusen. Reskontran registrerar den monetära effekten.
2. Du skickar en strukturerad begäran. Den innehåller vanligtvis händelsetyp, belopp och valuta, order- eller betalnings-ID, köpar- och säljaridentifierare, provision, skattedata, inblandade konton, verifikations- och bokföringsdatum, en idempotensnyckel samt metadata som länkar tillbaka till betalningsförmedlare och produktposter. Nordlets publika API-exempel visar en konceptuell försäljningsbegäran med säljar-ID, försäljningstyp, belopp, valuta samt momskland och momssats.
3. API:et validerar. Det kontrollerar att debet och kredit balanserar, att kontona existerar och tillåter bokföring, att valutan stöds, att beloppet använder exakt hantering av mindre enheter (minor units), att idempotensnyckeln inte återanvänds för ett annat resultat, att perioden är öppen och att obligatorisk metadata finns med. En misslyckad kontroll lämnar inga partiella verifikat efter sig.
4. Det bokför atomärt. Hela transaktionen skrivas som en enhet. Det får aldrig vara möjligt att registrera debetposten medan matchande kreditpost misslyckas. För en marknadsplats kan en partiell uppdelning skapa ett skenbart säljarsaldo utan tillhörande kontanta medel, eller bokföra provision utan motsvarande säljarskuld.
5. Saldon och rapporter härleds från reskontran. Efter bokföring kan du läsa kontosaldon, säljarens väntande och tillgängliga saldon, en råbalans (trial balance), huvudbokstransaktioner, momssammanställningar och historik per ett visst tidigare datum. Säljarsaldot bör kunna återskapas från bokföringslagringarna i stället för att litas på från ett ändringsbart fält.
6. Webhooks meddelar din produkt. Händelser som sale_invoice.paid, ett bokfört verifikat, en tillgänglig utbetalning eller ett avstämningsundantag skickas till dig. Bearbeta dem idempotent. En webhook är en notis, inte ett tillstånd att tillämpa den finansiella händelsen en gång till. API-konventionerna täcker scope, idempotensnycklar, felstrukturer och webhook-signering i detalj.
Säljarsaldon är inte en enda siffra
De flesta marknadsplatser råkar i problem genom att behandla ett säljarsaldo som en enda siffra. Pengar bör ligga i olika tillstånd:
| Tillstånd | Betydelse |
|---|---|
| Väntande (Pending) | Säljaren kan ha rätt till pengarna, men frigörandevillkoren är inte uppfyllda |
| Tillgängligt (Available) | Berättigat till utbetalning |
| Reserverat (Reserved) | Innehållet mot återbetalningar, returer eller tvister |
| Utbetalt (Paid out) | Skulden är reglerad genom en överföring |
| Negativt (Negative) | Återbetalningar, chargebacks eller avgifter överstiger tillgängliga medel |
Betalningsförmedlarmodeller speglar detta. Stripes separata flöden för debiteringar och överföringar (charges and transfers) låter en plattform debitera sitt eget konto och sedan överföra delar till anslutna konton, där avgifter, återbetalningar och chargebacks landar på plattformssaldot. Adyens marknadsplatsmodell skiljer mellan användarsaldokonton (user balance accounts), som håller medel till utbetalning, och ett ansvarssaldokonto (liable balance account) som kan absorbera negativa saldon från återbetalningar eller chargebacks. Dessa är användbara indata för din reskontra. De är inte din fullständiga redovisningsmodell.
Utbetalningar och säljarintäkter sker vid olika tidpunkter
En säljare kan tjäna pengar på en måndag och få betalt måndagen därpå. Mellan dessa tidpunkter uppfylls en beställning, en reserv hålls inne, en utbetalningsbatch skapas, en betalningsförmedlare avräknar den med avdrag för avgifter, och en bankinsättning anländer. En reskontra måste bevara varje enskilt stadium i stället för att skriva över beställningen med ett slutgiltigt "betald". Det är det som gör att du kan förklara tidsdifferenser mellan orderaktivitet, säljarens rättighet, avräkning, initierad utbetalning och bankinbetalning.
Återbetalningar och chargebacks: vänd, skriv inte över
Återbetalningar och chargebacks är nya händelser kopplade till den ursprungliga betalningen. I en oföränderlig reskontra korrigerar du med en motverifikation följt av en korrigerad verifikation, så att originalet förblir synligt för granskning. Modern Treasury behandlar bokförda transaktioner som oföränderliga och stöder idempotensnycklar för att förhindra dubbletter vid omsändning.
En återbetalning minskar vanligtvis kassa eller kundfordran, vänder säljarskulden, kan vända en del av provisionen beroende på policy, justerar skatt och kan förbruka en återbetalningsreserv. En chargeback minskar kassa eller fordran på betalningsförmedlaren, kan öppna upp ett belopp som säljaren eller plattformen är skyldig, bokför en tvistkostnad och betalningsförmedlaravgift samt flyttar medel via ett reservkonto.
Avstämning: att koppla reskontran till riktiga pengar
En reskontra kan vara internt balanserad och ändå ha fel om omvärlden. Avstämning jämför interna register med extern bevisning: avräkningsrapporter från betalningsförmedlare, bankutdrag, utbetalningsfiler samt register över återbetalningar och tvister.
En fungerande process ser ut så här:
- Importera avräkningen eller bankbatchen.
- Matcha varje rad till en beställning, betalning, återbetalning, avgift, utbetalning eller tvist.
- Jämför förväntat bruttobelopp, avdrag, reserver och nettobelopp.
- Bokför bekräftade flöden till reskontran.
- Skicka omatchade poster till ett namngivet interimskonto (suspense account).
- Utred avvikelser.
- Lås perioden.
Nordlets avstämningsmaterial beskriver exakt detta: att importera avräkningsbatcher, matcha debet- och återbetalningsrader samt dirigera omatchade inbetalningar till interimskonton i stället för att gissa en faktura. Två kontroller är viktiga och ingen av dem ersätter den andra: dubbelbokföringsvalideringen frågar om varje verifikat balanserar, och avstämningen frågar om det stämmer överens med betalningsförmedlaren, banken och affärshändelsen.
Designdetaljer som avgör om du lyckas
Idempotens. Knyt nyckeln till en stabil händelse, till exempel payment_captured:pi_123. En omsändning returnerar det ursprungliga resultatet, inte ett andra verifikat.
Atomaritet. Alla rader i en händelse bokförs tillsammans eller inte alls.
Oföränderlighet och motverifikationer. Bokförd historik är inte redigerbar via vanliga uppdateringar. Korrigeringar skapar länkade poster som bevarar det ursprungliga beloppet, datumet, klassificeringen, orsaken och upphovspersonen.
Exakta pengar. Inga binära flyttal. Använd heltalsenheter för mindre enheter (minor units) eller exakta decimaler, explicit valuta och en deterministisk avrundningsregel för uppdelningar. Delar du upp 100 EUR mellan säljare och avgifter utan detta kommer en villfarelsecent att knäcka balansen.
Verifikations- vs bokföringsdatum. När köparen betalade, när säljaren tjänade pengar, när banken gjorde avräkning och när posten bokfördes är skilda datum. Att blanda ihop dem gör periodrapportering och skattetidpunkter otillförlitliga.
Flervaluta. Debet och kredit bör balansera inom en valuta. Omräkning kräver en explicit kurshändelse med konton för avgift, avrundning och eventuell valutakursvinst eller -förlust. Att acceptera ett currency-fält gör inte en reskontra till en valutamotor.
Vad ett reskontra-API inte gör åt dig
Det bestämmer inte din kontoplan. Du måste fortfarande fastställa om du är huvudman eller agent, när provisionen intjänas, vilken part som bär betalningsförmedlarens avgifter, hur återbetalningar påverkar provisionen samt hur moms beräknas och redovisas. Nordlets egen rekommendation är att kartlägga pengaflödena först, utarbeta kontoplanen, låta en revisor granska den och sedan implementera ett helt flöde från beställning till utbetalning och avstämning innan du skalar upp.
Det löser inte skattefrågor. Moms beror på köparens och säljarens plats, produkttyp, registreringsstatus och regler för betalningsförmedlare (deemed supplier-regler); EU-momsguiden anger vad motorn beräknar och vad den flaggar för en mänsklig handläggare. Nordlets momstäckning är inriktad på EU och EES, så den sträcker sig inte till amerikansk omsättningsskatt (sales tax) eller latinamerikansk e-fakturering. Och det löser inte operationella oklarheter, som om en returperiod har löpt ut, om en utbetalning bör blockeras eller om en betalning är bedräglig. Det är dina beslut. Reskontran registrerar deras finansiella resultat.
Var Nordlet passar in
Nordlet är ett redovisningsAPI byggt för plattformar och marknadsplatser, med en oföränderlig dubbel reskontra, utbetalningar, hantering av EU-moms, REST-slutpunkter, typade SDK:er och webhooks som nås via ett enda gränssnitt. Dess utmärkande val är inbäddad redovisning i din egen produkt i stället för en tredjepartskassa. I skrivande stund är produkten i tidig tillgång med en sandbox för designpartners, så betrakta den som ett starkt exempel på kategorin och utvärdera produktionsmognad, drifttid och jurisdiktionsmässig täckning för ditt eget fall innan du binder dig.
För marknadsplats- och plattformsutvecklare är den användbara mentala modellen uppdelningen mellan pengarnas rörelse och den finansiella sanningen. Din betalningsförmedlare flyttar pengarna. Ett dubbelt bokförings-API registrerar vem som är skyldig vad, vad du tjänade, vilka skatter och reserver du bär på, och om omvärlden stämmer överens med dina böcker.
FAQ
Är ett dubbelt bokförings-API samma sak som en betalningsförmedlare?
Nej. En betalningsförmedlare auktoriserar, genomför, avräknar och betalar ibland ut medel. Ett reskontra-API registrerar de redovisningsmässiga konsekvenserna av dessa händelser. De flesta marknadsplatser använder båda: en betalningsförmedlare som Stripe eller Adyen för penningflödet och en reskontra för böckerna.
Kan jag bara använda betalningsförmedlarens instrumentpanel som huvudbok?
Du kan försöka, och den kommer så småningom att misslyckas i en revision. Rapporteringen från betalningsförmedlaren visar debiteringar, avgifter, överföringar och avräkningar, men den återspeglar vanligtvis inte dina fullständiga säljarskulder, momsskulder, kostnader som inte rör betalningsförmedlaren eller bokföringsmässiga justeringar. Betrakta den som indata för avstämning.
Betyder en balanserad reskontra att mina böcker är korrekta?
Bara att dina poster uppfyller debet/kredit-regeln. En perfekt balanserad transaktion kan ändå bokföras på fel konto, på fel säljare eller med fel skattebehandling. Balans är nödvändigt, men inte tillräckligt. Avstämning är det som fångar upp resten.
Om reskontran är oföränderlig, hur åtgärdar jag misstag?
Du bokför en motverifikation och sedan en korrigerad verifikation. Originalet förblir synligt, vilket är hela poängen. Oföränderlighet skyddar revisionsspåret, den fångar inte in dina fel.
Gör ett redovisnings-API mig regelmässigt kompatibel automatiskt?
Nej. Det upprätthåller redovisningsstrukturen och producerar användbara register. Juridisk efterlevnad beror fortfarande på din jurisdiktion, din avtalsenliga roll, skattebehandling, betalningsregleringar, KYC- och AML-processer samt rapporteringsskyldigheter.