Underreskontra för marknadsplatssäljare: Intäkter vs leverantörsskulder

Det vanligaste misstaget inom marknadsplatsredovisning är att behandla köparens bruttobetalning som plattformens intäkt. En kund betalar 100 EUR, de 100 EUR landar på betaltjänstleverantörens konto och någon bokför hela beloppet som försäljning. Bokföringen balanserar ett tag, intäkterna ser bra ut och sedan frågar en revisor var säljarskulden finns. Det finns ingen sådan, eftersom säljarens 90 EUR aldrig bokfördes som en upplupen skuld.

Lösningen är strukturell, inte kosmetisk. En marknadsplats behöver en reskontramodell som separerar fem distinkta kassaflöden från första verifikationen: kundmedel i transit, plattformsprovision, säljarskulder, avgifter och reserver. Utbetalningar är en sjätte händelse som reglerar skulden, inte en egen intäkts- eller kostnadshändelse. Den här guiden visar de balanserade verifikationerna och datamodellen som håller isär dessa flöden.

Utgå från principen om huvudman versus agent (principal vs agent)

Innan någon kontoplan blir relevant måste plattformen fastställa vad den säljer. Enligt IFRS 15 (eller ASC 606) bedöms detta per specifik vara eller tjänst, och svaret avgör om intäkten redovisas brutto eller netto. En plattform kan vara huvudman (principal) för ett flöde och agent för ett annat.

Vid en typisk marknadsplatsförsäljning av en säljares varor är plattformen vanligtvis agent. Den ser till att säljarens produkt når köparen, den tar ingen lagerrisk och dess ersättning är en provision. Deloittes vägledning om huvudman versus agent enligt ASC 606 ramar in bedömningen kring kontroll: ansvar för att uppfylla åtagandet, lagerrisk och prissättningsdiscretion är indikatorer, snarare än en checklista som åsidosätter den underliggande kontrollbedömningen.

Anledningen till att detta hör hemma i kontoplanens design, och inte bara i en promemoria, är att slutsatsen styr varje efterföljande verifikation. Om plattformen är agent är säljarens andel en skuld i samma ögonblick som den intjänas. Om den är huvudman för en fullgörande- eller garantitjänst utgör den delen plattformens intäkt. Spara slutsatsen som data:

• principal_agent_role
• specified_good_or_service
• commission_rule_id
• control_assessment_version
• effective_from / effective_to

En granskare som tittar på en nettoprovisionsrad två år senare bör kunna se varför bruttoredovisning inte användas. Som BillingPlatform påpekar om ASC 606 principal vs agent avgör inte etiketten "marknadsplats" frågan. Det gör kontrollanalysen.

Definiera säljarens saldo innan du skriver en enda bokföringsregel

"Säljarsaldo" är inte en enda siffra. En säljare kan ha ett gott historiskt saldo men ändå sakna tillgängliga medel för utbetalning eftersom pengarna fortfarande är under behandling eller bundna i en reserv. Om du slår ihop dessa tillstånd felrapporterar du vad säljaren kan ta ut och vad plattformen fortfarande är skyldig.

Följ åtminstone upp följande:

• Väntande (Pending): intjänade eller inbetalda, ännu inte berättigade till utbetalning
• Tillgängliga (Available): berättigade till utbetalning enligt plattformens regler
• Reserverade (Reserved): undanhållna för att täcka förväntade återbetalningar, tvister eller betalningsinvändningar (chargebacks)
• Utbetalda (Paid out): överförda eller inlämnade för avräkning
• Negativa: belopp som säljaren är skyldig, vilka kan återvinnas från framtida intäkter
• Interimsaldo (Suspense): mottagna, men säljare eller hantering har ännu inte fastställts

Betaltjänstleverantörer modellerar redan denna uppdelning. Stripe separerar varje anslutet konto i väntande och tillgängliga saldon och behåller ett plattformsövergripande reserverat saldo för vissa negativa säljarsaldon. Om betaltjänsten skiljer på detta måste huvudboken göra det också, annars stämmer aldrig avstämningen.

Kontoplanen och de dimensioner som spelar roll

En fungerande startstruktur håller clearingkonton, skulder och intäkter isär och bär en säljardimension på varje väsentlig postering.

Syfte	Konto eller dimension	Behandling
Betalningsmedelsmedel som väntar på avräkning	Clearingkonto betaltjänstleverantör	Omsättningstillgång
Bankförd betaltjänstutbetalning	Bank	Tillgång
Säljarbelopp intjänat men ej utbetalt	Leverantörsskuld säljare (Säljreskontra)	Skuld
Detaljnivå per säljare	Dimensionen seller_id	Skulddetalj, ej intäkt
Plattformsprovision	Provisionsintäkt	Intäkt
Moms eller försäljningsskatt	Skatteskuld	Skuld
Betalningsförmedlingsavgifter	Betalningskostnad	Kostnad
Säljarreserver	Resurskuld	Avtalsberoende
Återbetalningar	Kontraintäkt eller återbetalningar	Omvänder ursprunglig behandling
Betalningsinvändningar (Chargebacks)	Förlust, fordran eller säljaråtervinning	Beror på vem som bär förlusten
Utbetalningar som väntar på bankbekräftelse	Clearingkonto säljarutbetalning	Clearingkonto
Oallokerade belopp	Interimsaldo	Tillfälligt undantag

Varje väsentlig postering bör innehålla säljare, order, utbetalningsbatch, betaltjänstleverantör, valuta, juridisk enhet, momshantering, händelsetyp, extern referens och eventuell reverseringslänk. Utan dessa kan säljreskontran inte bevisa ett enskilt saldo och huvudboken kan inte bevisa totalsumman.

Du kan implementera reskontran som ett skuldkonto per säljare, ett samlat skuldkonto med seller_id som dimension, eller uppdelat på skuld, reserv och utbetalningsclearing. Tillvägagångssättet med samlingskonto och dimension skalar bättre när du passerar ett dussin säljare. Välj modell tillsammans med din redovisningskonsult, eftersom regler för klients medel och lokal betalningsreglering kan påverka hur medlen måste redovisas. För mekaniken bakom posteringarna behandlar vår artikel om dubbla bokföringars reskontra-API:er för marknadsplatser de grundläggande bokföringsprimitiver denna modell vilar på.

Bokför försäljningen med separata rader för säljare och plattform

Ta en agentförsäljning: kunden betalar 100 EUR, plattformsprovisionen är 10 EUR, säljaren tjänar 90 EUR. Vid den tidpunkt då provision och säljaranspråk intjänas:

Konto	Debet	Kredit
Clearingkonto betaltjänstleverantör	100 EUR
Säljreskontra – Säljare A		90 EUR
Provisionsintäkt		10 EUR

Den kontroll som spelar roll: 90 EUR krediterar en skuld, inte en intäkt. Plattformen intäktsför 10 EUR. Detta är det resultat som marknadsplatsexemplet i ASC 606 leder till för en agent, där plattformen redovisar sin provision snarare än säljarens fulla försäljningsbelopp.

Om skatt tas ut separat lägger du till skatteskuldsraden och minskar säljar- eller plattformsbeloppet i enlighet med skattebedömningen. Blanda inte in skatten i provisionen eller säljarskulden av bekvämlighetsskäl.

Håll betaltjänstavgifter borta från intäkts- och skuldberäkningen

Tre saker förväxlas ständigt: plattformsprovision, betaltjänstavgift och utbetalningsbelopp. De är olika och träffar olika konton.

Kunden betalar 100 EUR, provisionen är 10 EUR, betaltjänsten behåller 3 EUR.

• Provisionsintäkten förblir 10 EUR om det är vad avtalet säger.
• Betaltjänstavgiften på 3 EUR är en kostnad.
• Säljarskulden är 90 EUR om inte säljaravtalet anger att säljaren bär behandlingsavgiften. Endast då sjunker den till 87 EUR med en matchande debetpost på 3 EUR debiterad säljaren.

Att enbart bokföra de netto 97 EUR som landar på bankkontot raderar bruttologgen, provisionen och avgiften i ett enda drag. Vår referens för betalningsavstämning framhåller samma sak: bryt ner avräkningen, behandla betaltjänstavgifter som kostnader och låt aldrig nettobetalningen ersätta intäkten.

Modellera tillgänglighet, reserver och utbetalningar som separata händelser

Pengar byter status flera gånger mellan betalningsmottagning och slutgiltig avräkning. Varje övergång förtjänar sin egen verifikation, och en reserv är aldrig en oförklarlig nedskrivning av intäkten.

När tillgängliga medel flyttas till reserv:

Konto	Debet	Kredit
Säljreskontra – Säljare A	15 EUR
Säljarreservskuld		15 EUR

När reserven friges, reversera den. Säljarens totala skuld har inte förändrats; dess status har gjort det. Stripe dokumenterar reserverade transaktioner som ökar och friger reserver, plus insamlingsöverföringar för långvariga negativa saldon, vilket är varför dessa kräver identifierbara konton snarare än en enda nettobokföring.

Utbetalningar hanteras i två steg. Vid godkännande:

Konto	Debet	Kredit
Säljreskontra – Säljare A	90 EUR
Clearingkonto säljarutbetalning		90 EUR

Vid bekräftad bankavräkning:

Konto	Debet	Kredit
Clearingkonto säljarutbetalning	90 EUR
Bank		90 EUR

Om utbetalningen misslyckas, reversera clearingen tillbaka till säljreskontran. En utbetalning är en skuldsanering, inte en kostnad. Att behandla den som en kostnad dubbelräknar mot den försäljning som redan bokfört skulden. Stripe skiljer på utbetalningsstatus (pending, in_transit, paid, failed, canceled) och förväntat ankomstdatum från initiering, och dessa datum bör inte slås samman till en enda tidsstämpel.

Datamodellen för order till utbetalning

Reskontran drivs av händelser, inte av applikationens aktuella orderstatus. Varje säljarpåverkande händelse bär samma struktur:

• seller_id, event_id, order_id
• event_type (sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)
• effective_date, posting_date
• currency, direction, gross, commission, fees, reserve
• refund_ref / dispute_ref
• payout_batch_id
• reversal_of
• source_status, idempotency_key

Från dessa händelser beräknar du utgående saldo istället för att lagra ett ändringsbart fält:

Säljarens utgående saldo
= ingående saldo
+ säljarkrediter
− säljardebeter
− utbetalningar
± reservrörelser
± korrigeringar

Varje extern händelse behöver en robust idempotensnyckel (idempotency key) så att omsändningar och dubbla webhooks inte krediterar en säljare eller betalar ut pengar två gånger. Mönster som fungerar:

• Säljarbokföringshändelse: seller_id:order_id:event_type:version
• Utbetalningsbatch: processor:payout_id
• Betaltjänsthändelse: processor:event_type:processor_event_id

Stripes egen vägledning för webhooks varnar för att dubbla händelser inträffar, så dubblettdetektering är ett krav. Bokförda verifikationer förblir oföränderliga. Korrigeringar görs genom en reversering följd av en korrigerad verifikation, och det är din egna händelsestruktur som bär länken reversal_of och orsaken. Huvudboken lagrar verifikationerna, inte den länken: Nordlet exponerar funktioner för att skapa, hämta och lista verifikationer i sin API-referens utan några uppdaterings- eller borttagningsfunktioner, vilket innebär att en korrigering alltid är en ny transaktion snarare än en redigering.

Återbetalningar och betalningsinvändningar länkas tillbaka, de svävar aldrig fritt

En återbetalning som dyker upp i nästa veckas utbetalning får aldrig bli en ny negativ försäljning kopplad till den utbetalningen. Länka den till ursprungstransaktionen och bevara den ursprungliga säljarallokeringen. Beroende på avtal:

• Reversera provisionen om avtalet gör den återbetalningsbar
• Debitera säljreskontran om säljaren bär återbetalningen
• Debitera ett förlustkonto för plattformen om plattformen bär den
• Öka en reserv medan en tvist pågår, frigör eller utnyttja den vid avgörande

Betalningsinvändningar (chargebacks) efter utbetalning är där negativa saldon uppstår. Säljarens pengar är redan borta, så plattformen antingen återvinner dem från framtida intäkter eller absorberar förlusten. Modellen måste tillåta negativa säljarsaldon och definiera återvinningsregeln. Adyens marknadsplatsrapportering visar återbetalningar och betalningsinvändningar som ger upphov till separata debetrader per kontoinnehavare, vilket är den detaljnivå man bör sikta på.

Stäm av per utbetalning, inte per månad

Bryt ner varje betaltjänstavräkning före bokföring och stäm av varje utbetalning i stället för att aggregera en månad:

Bruttoavgifter
− återbetalningar
− betaltjänstavgifter
− betalningsinvändningar
± reserver och korrigeringar
= netto utbetalning från betaltjänstleverantör

Verifiera sedan att fyra saldon stämmer överens för varje säljare och valuta: säljreskontran, betaltjänstleverantörens säljarsaldo, utbetalningsrapporten och bankclearingen. När de skiljer sig åt, klassificera differensen (tidsdifferens, saknad händelse, dubblett, felaktig attribuering, fel valuta, misslyckad utbetalning, betalningsinvändning bokförd på fel mottagning). Att netta bort skillnader är ett säkert sätt att dölja fel som annars följer med till nästa bokslut.

Att aggregera en hel månad gör att tidsdifferenser tar ut varandra och döljer faktiska avvikelser. Avstämning per utbetalning, baserad på utbetalnings-ID och transaktionsreferens snarare än belopp och datum, fångar upp dem.

Vanliga fel

Felaktighet	Varför det ställer till problem	Kontroll
Bruttokundbetalning bokförd som intäkt	Blåser upp intäkterna, döljer säljarskuld	Dela upp skuld och provision vid intäktstillfället
Endast nettobetalningar bokförda	Förlorar brutto, avgifter, återbetalningar, reserver	Bryt ner varje avräkning
Utbetalning bokförd som kostnad	Felaktig redovisning av skuldsanering	Debitera säljreskontran vid utbetalning
Ett enda säljarsaldofält	Blandar väntande, tillgängliga, reserverade, betalda	Spåra saldostatus explicit
Provision beräknad vid utbetalningstillfället	Intäkter följer utbetalningsschemat	Intäktsför provision när den intjänas
Reserv behandlad som intäktsminskning	Döljer timing och risk	Spåra innehållande, frigörelse och utnyttjande separat
Återbetalning tillämpad på senaste utbetalningen	Bryter orderattributionen	Länka återbetalning till ursprungstransaktion
Redigering av bokförda verifikationer	Förstör granskningsspåret	Reversera och ombokför
Återuppspelade webhooks	Dubbla krediter och utbetalningar	Idempotensnycklar, dubblettdetektering
Matchning enbart på belopp och datum	Olika transaktioner krockar	Matcha på utbetalnings-ID, transaktions-ID, säljare, valuta

Vad jag skulle göra först

Mappa kassaflödet innan du rör kontoplanen. Skriv ner varje händelse från betalningsmottagning till reservfrigörelse, och markera vilka som skapar intäkter, vilka som skapar en skuld och vilka som enbart flyttar status.

Bygg sedan ett fullständigt flöde från början till slut och bevisa att det balanserar: en normal försäljning, en delvis återbetalning, en betalningsinvändning efter utbetalning, en reserverad och frigjord reserv samt en misslyckad utbetalning. Kör dessa med kända förväntade saldon. Om säljreskontrans kontrollkonto motsvarar summan av reskontran, betaltjänstens clearing stämmer mot avräkningsrapporten och bankinsättningen stämmer mot utbetalnings-ID:t har du en fungerande grundstruktur.

Aktivera periodlåsning först när den första månaden har stängts rent utan interimsaldon. Att låsa för tidigt fryser bara in misstag.

Nordlet bokför avräkningar efter dessa principer direkt ur lådan: plattformens provision går till provisionsintäkt, säljarens andel till en säljreskontra, betaltjänstavgifter till en betalningskostnad och allt som ännu inte har attribuerats till ett interimskonto. Bokföringsperioder förblir öppna tills du uttryckligen låser dem, så den första månaden kan stängas när interimsaldot är noll. Funktionssidan listar vad som ingår.

FAQ

Är köparens betalning någonsin plattformens intäkt?

Endast för de specifika varor eller tjänster där plattformen är huvudman. Vid en agentmarknadsplatsförsäljning av en säljares varor är intäkten provisionen och säljarens andel en skuld. En plattform kan vara huvudman för en fullgörandetjänst och agent för de underliggande varorna i samma order, så bedömningen görs per specifik vara eller tjänst, inte per företag.

Bör reserver minska intäkten?

Nej. En reserv är en tids- och riskfördelning, inte en intäktsjustering. Flytta medel från säljreskontran till en reservskuld när du håller dem, och reversera när du friger dem. Intäkter och provision påverkas inte av om säljarens pengar för närvarande är reserverade.

Hur förhindrar jag dubbla utbetalningar från omsända webhooks?

Koppla en idempotensnyckel till varje extern händelse, som processor:payout_id för utbetalningsbatchar, och upptäck dubbla händelser vid skrivning. Leverantörer varnar uttryckligen för att dubbla webhook-leveranser inträffar, så huvudboken måste avvisa det andra försöket i stället för att bokföra det igen.

Kan ett säljarsaldo bli negativt?

Ja, och modellen måste tillåta det. En betalningsinvändning som landar efter att säljaren har fått betalt lämnar plattformen med antingen en fordran på säljaren eller en förlust som den absorberar. Att dölja negativa saldon döljer bara en oredovisad skuld.

Varför stämma av varje utbetalning i stället för månadstotalen?

Eftersom tidsdifferenser och fel tar ut varandra när du aggregerar en månad, vilket gör att totalbeloppen kan stämma trots att enskilda transaktioner är felaktiga. Avstämning per utbetalning, matchad på utbetalnings- och transaktions-ID, blottlägger saknade händelser, dubbletter och felaktigt tilldelade betalningsinvändningar innan bokslut.

Vidare läsning

• Dubbla bokföringars reskontra-API:er för marknadsplatser
• Betalningsavstämning: matcha PSP-utbetalningar mot huvudboken
• ASC 606 principal-versus-agent considerations (Deloitte)