Marketplace-sælgerundersøgler: Omsætning vs. gæld
En praktisk guide til at adskille kundelikviditet, platformskommission, sælgergæld, reserver og udbetalinger ved hjælp af afstemte posteringer og en fungerende datamodel fra ordre til udbetaling.
Den mest almindelige fejl i marketplace-regnskab er at behandle køberens bruttobetaling som platformens omsætning. En kunde betaler 100 €, de 100 € lander på betalingsudbyderens konto, og nogen bogfører det hele som salg. Regnskabet balancerer et stykke tid, omsætningen ser fin ud, og så spørger en revisor, hvor sælgerforpligtelsen er. Den er der ikke, fordi sælgerens 90 € aldrig blev registreret som skyldne penge.
Løsningen er strukturel, ikke kosmetisk. En marketplace har brug for en hovedbogsmodel, der adskiller fem forskellige puljer fra den første postering: kundekontanter undervejs, platformskommissionsindtægter, sælgergæld, gebyrer og reserver. Udbetalinger er en sjette hændelse, der afregner gælden, ikke en omsætnings- eller omkostningshændelse i sig selv. Denne guide viser de afstemte posteringer og den datamodel, der holder disse puljer adskilte.
Start med princippet om hovedmand (principal) eller agent
Før nogen kontostruktur overhovedet betyder noget, skal platformen beslutte, hvad den sælger. I henhold til ASC 606 vurderes dette pr. specificeret vare eller tjenesteydelse, og svaret afgør, om omsætningen er brutto eller netto. En platform kan være hovedmand for ét pengestrøm og agent for et andet.
Ved et typisk marketplace-salg af en sælgers varer er platformen normalt agent. Den sørger for, at sælgerens produkt når ud til køberen, den påtager sig ikke lagerinvolvering og risiko, og dens vederlag er en kommission. Deloittes vejledning om principal-versus-agent i henhold til ASC 606 opstiller testen omkring kontrol: ansvar for at opfylde løftet, lagerrisiko og prisbestemmelsesret er indikatorer, ikke en tjekliste, der tilsidesætter den underliggende kontrolvurdering.
Årsagen til, at dette hører hjemme i designet af hovedbogen og ikke bare i et notat, er, at konklusionen styrer enhver downstream-postering. Hvis platformen er agent, er sælgerens andel en gældsforpligtelse i det øjeblik, den er optjent. Hvis den er hovedmand for en opfyldelses- eller garantitjeneste, er den del platformens omsætning. Gem konklusionen som data:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
En reviewer, der kigger på en nettokommissionslinje to år senere, skal kunne se, hvorfor bruttobeløbet ikke blev brugt. Som BillingPlatform bemærker om ASC 606 principal vs. agent, afgør mærkatet "marketplace" ikke spørgsmålet. Det gør kontrolanalysen.
Definér sæ saldo, før du skriver en eneste bogføringsregel
"Sælgers saldo" er ikke bare ét tal. En sælger kan have en sund historisk samlet saldo og intet tilgængeligt til udbetaling, fordi pengene stadig er undervejs eller tilbageholdt som reserve. Hvis du slår disse tilstande sammen, vil du fejlinformere om, hvad sælgeren kan hæve, og hvad platformen stadig skylder.
Som minimum skal du spore:
- Afventende (Pending): optjent eller indsamlet, endnu ikke berettiget til udbetaling
- Tilgængelig (Available): berettiget til udbetaling i henhold til platformens regler
- Reserveret (Reserved): tilbageholdt mod forventede tilbagebetalinger, tvister eller chargebacks
- Udbetalt (Paid out): overført eller indsendt til afregning
- Negativ: beløb som sælger skylder, der kan inddrives fra fremtidige provenuer
- Afventende/suspense (Suspense): modtaget, men sælger eller behandling er endnu ikke fastlagt
Betalingsudbydere modellerer allerede denne sondring. Stripe adskiller hver tilknyttet konto i afventende og tilgængelige saldi og bevarer en reservebalance på platformsniveau for visse negative sælgersaldi. Hvis betalingsudbyderen adskiller disse, skal hovedbogen også gøre det, ellers stemmer afstemningen aldrig.
Kontoplanen og de dimensioner, der betyder noget
En brugbar startstruktur holder clearingkonti, gældsforpligtelser og omsætning adskilt og bærer en sælgerdimension på hver væsentlig postering.
| Formål | Konto eller dimension | Behandling |
|---|---|---|
| Midler hos betalingsudbyder i ventetid på afregning | Betalingsudbyder-clearing | Omsætningsaktiver |
| Indsat betalingsudbyderudbetaling | Bank | Aktiv |
| Sælgerbeløb optjent men ubetalt | Sælgergæld | Gældsforpligtelse |
| Detaljer på sælgersniveau | Dimensionen seller_id |
Gældsdetalje, ikke omsætning |
| Platformskommission | Kommissionsindtægter | Omsætning |
| Moms eller salgsmoms | Skyldig moms | Gældsforpligtelse |
| Betalingsgebyrer | Betalingsbehandlingsomkostninger | Omkostning |
| Sælgerreserver | Reserveforpligtelse | Kontraktafhængig |
| Tilbagebetalinger | Mod-omsætning eller tilbagebetalinger | Omvender den oprindelige behandling |
| Chargebacks | Tab, tilgodehavende eller sælgerinddrivelse | Afhænger af, hvem der bærer tabet |
| Udbetalinger der afventer bankbekræftelse | Sælgerudbetalingsclearing | Clearingkonto |
| Ikke-allokerede beløb | Suspense | Midlertidig undtagelse |
Hver væsentlig postering bør bære sælger, ordre, udbetalingsbatch, betalingsudbyder, valuta, juridisk enhet, skattemæssig behandling, hændelsestype, ekstern reference og et eventuelt genoptagelses-link (reversal link). Uden disse kan sælgerundersøglen ikke bevise en individuel saldo, og hovedbogen kan ikke bevise totalen.
Du kan implementere undersøglen som én gældskonto pr. sælger, én samlet gældskonto med seller_id som dimension eller en opdeling på tværs af gæld, reserve og udbetalingsclearing. Tilgangen med samlet beløb plus dimension skalerer bedre, når du passerer et par dusin sælgere. Vælg modellen sammen med din revisor, da beskyttelsesregler og lokal betalingsregulering kan påvirke, hvordan midlerne skal præsenteres. For mekanikken bag posteringer dækker vores artikel om dobbelte hovedbogs-API'er til marketplace-regnskab de hovedbogsprimitiver, denne model hviler på.
Bogfør salget med separate linjer for sælger og platform
Tag et agentsalg: kunden betaler 100 €, platformskommissionen er 10 €, sælgeren tjener 90 €. På det tidspunkt, hvor kommission og sælgerkrav er optjent:
| Konto | Debet | Kredit |
|---|---|---|
| Betalingsudbyder-clearing | 100 € | |
| Sælgergæld – Sælger A | 90 € | |
| Kommissionsindtægter | 10 € |
Den kontrol, der betyder noget: 90 € krediteres en gældsforpligtelse, ikke omsætning. Platformen indregner 10 €. Dette er det resultat, som ASC 606's marketplace-eksempel når frem til for en agent, hvor platformen indregner sin kommission i stedet for sælgerens fulde salgsbeløb.
Hvis der opkræves moms separat, tilføjes linjen for skyldig moms, og sælger- eller platformstallet reduceres i overensstemmelse med momskonklusionen. Undlad at binde moms sammen med kommission eller sælgergæld af hensyn til bekvemmelighed.
Hold betalingsgebyrer ude af omsætnings- og gældsregnskabet
Tre ting bliver konstant forvekslet: platformskommission, betalingsgebyr og udbetalingsbeløb. De er forskellige, og de rammer forskellige konti.
Kunden betaler 100 €, kommissionen er 10 €, betalingsudbyderen tilbageholder 3 €.
- Kommissionsindtægterne forbliver 10 €, hvis det er det, kontrakten siger.
- Betalingsgebyret på 3 € er en omkostning.
- Sælgergælden er 90 €, medmindre sælgerkontrakten siger, at sælgeren bærer betalingsgebyret. Først da falder det til 87 € med et modsvarende beløb på 3 € debiteret sælgeren.
Hvis man kun bogfører de netto 97 €, der lander på banken, sletter man bruttosalget, kommissionen og gebyret i ét hug. Vores reference til betalingsafstemning gør det samme gældende: opdel afregningen, behandl betalingsgebyrer som omkostninger, og lad aldrig nettodepositumet stå i stedet for omsætning.
Modelér tilgængelighed, reserver og udbetalinger som separate hændelser
Penge skifter status flere gange mellem indsamling og afregnet kontantbeløb. Hver overgang fortjener sin egen postering, og en reserve er aldrig en uforklarlig nedsættelse af omsætningen.
Når tilgængelige midler flyttes til reserve:
| Konto | Debet | Kredit |
|---|---|---|
| Sælgergæld – Sælger A | 15 € | |
| Reserveforpligtelse over for sælger | 15 € |
Når reserven frigives, vendes posteringen om. Sælgers samlede forpligtelse har ikke ændret sig; dens status har. Stripe dokumenterer reserveretransaktioner, der forøger og frigiver reserver, samt inddrivelsesoverførsler for langvarige negative saldi, hvilket er grunden til, at disse kræver identificerbare konti i stedet for en enkelt nettobogføring.
Udbetalinger får deres egen to-trins-behandling. Ved godkendelse:
| Konto | Debet | Kredit |
|---|---|---|
| Sælgergæld – Sælger A | 90 € | |
| Sælgerudbetalingsclearing | 90 € |
Ved bekræftet bankafregning:
| Konto | Debet | Kredit |
|---|---|---|
| Sælgerudbetalingsclearing | 90 € | |
| Bank | 90 € |
Hvis udbetalingen mislykkes, føres clearingen tilbage til sælgergæld. En udbetaling er afregning af en gæld, ikke en omkostning. At behandle den som en omkostning dobbelttæller i forhold til det salg, der allerede har registreret gælden. Stripe adskiller udbetalingsstatus (pending, in_transit, paid, failed, canceled) og forventet ankomstdato fra igangsættelse, og disse datoer bør ikke flyde sammen til ét tidsstempel.
Datamodellen fra ordre til udbetaling
Undersøglen kører på hændelser, ikke på applikationens aktuelle ordrestatus. Hver sælgerpåvirkende hændelse bærer den samme konvolut:
seller_id,event_id,order_idevent_type(sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
Ud fra disse hændelser beregner du slutningen i stedet for at gemme et muterbart felt:
Sælgers slutsaldo
= startsaldo
+ sælgerkreditter
− sælgerdebiteringer
− udbetalinger
± reservebevægelser
± korrektioner
Hver ekstern hændelse kræver en holdbar idempotensnøgle (idempotency key), så gentagelser og dublerede webhooks ikke krediterer en sælger to gange eller udbetaler to gange. Mønstre der fungerer:
- Sælger-journalhændelse:
seller_id:order_id:event_type:version - Udbetalingsbatch:
processor:payout_id - Betalingsudbyderhændelse:
processor:event_type:processor_event_id
Stripes egne webhook-retningslinjer advarer om, at dublerede hændelser forekommer, så det er ikke valgfrit at opdage dubletter. Bogførte posteringer forbliver uforanderlige (immutable). Korrektioner foretages via en modsatrettet postering plus en korrigeret postering, og det er din egen hændelseskonvolut, der bærer reversal_of-linket og årsagen. Hovedbogen indeholder posteringerne, ikke det link: Nordlet eksponerer create, get og list for journaltransaktioner i sin API-reference og ingen update eller delete, så en korrektion er altid en ny transaktion i stedet for en redigering.
Tilbagebetalinger og chargebacks linker tilbage og flyder aldrig frit
En tilbagebetaling, der dukker op i næste uges udbetaling, må aldrig blive til et nyt negativt salg knyttet til den udbetaling. Knyt den til den oprindelige transaktion og bevar den oprindelige sælgerallokering. Afhængigt af kontrakten:
- Tilbagefør kommissionen, hvis kontrakten gør den refunderbar
- Debitér sælgergæld, hvis sælgeren bærer tilbagebetalingen
- Debitér en platformstabskonto, hvis platformen bærer den
- Forøg en reserve, mens en tvist er åben, og frigiv eller forbrug den ved afslutning
Chargebacks efter udbetaling er der, hvor negative saldi opstår. Sælgerens penge er allerede væk, så platformen enten inddriver dem fra fremtidige provenuer eller absorberer tabet. Modellen skal tillade negative sælgersaldi og definere inddrivelsesreglen. Adyens marketplace-rapportering viser tilbagebetalinger og chargebacks, der producerer separate debetrækker pr. kontohaver, hvilket er den granularitet, man skal gå efter.
Afstem pr. udbetaling, ikke pr. måned
Opdel enhver afregning fra betalingsudbyderen før bogføring, og afstem hver udbetaling i stedet for at samle en måned sammen:
Bruttobetalinger
− tilbagebetalinger
− betalingsgebyrer
− chargebacks
± reserver og korrektioner
= netto-udbetaling fra betalingsudbyder
Bevis derefter, at fire saldi stemmer overens for hver sælger og valuta: sælgerundersøglen, betalingsudbyderens sælgersaldo, udbetalingsrapporten og bankclearingen. Når de er forskellige, skal du klassificere forskellen (tidsforskydning, manglende hændelse, dublet, forkert attributering, forkert valuta, mislykket udbetaling, chargeback bogført på den forkerte part). At udligne forskelle ved nettotælling er vejen til, at fejl opvejer hinanden og overlever til næste periodelukning.
At aggregere en hel måned lader tidsforskydninger udligne hinanden og skjuler reelle uoverensstemmelser. Matchning pr. udbetaling, baseret på udbetalings-ID og transaktionsreference frem for beløb og dato, opdager dem.
Almindelige fejltyper
| Fejltype | Hvorfor det gør ondt | Kontrol |
|---|---|---|
| Bruttokundefebet bogført som omsætning | Opskriver omsætning, skjuler sælgergæld | Opdel gæld og kommission ved optjeningstidspunktet |
| Kun nettobetalinger bogført | Mister brutto, gebyrer, tilbagebetalinger, reserver | Opdel enhver afregning |
| Udbetaling bogført som omkostning | Fejlviser afregning af gældsforpligtelse | Debitér sælgergæld ved udbetaling |
| Ét sælgersaldofelt | Blander afventende, tilgængelige, reserverede, udbetalte | Spor saldistatus eksplicit |
| Kommission beregnet ved udbetalingstidspunkt | Omsætning følger udbetalingsplanlægning | Indregn kommission når den optjenes |
| Reserve behandlet som omsætningsnedgang | Slører timing og risiko | Spor tilbageholdelse, frigivelse, forbrug separat |
| Tilbagebetaling anvendt på seneste udbetaling | Bryder ordreallokering | Knyt tilbagebetaling til oprindelig transaktion |
| Redigering af bogførte posteringer | Ødelægger revisionssporet | Vend om og genbogfør |
| Afspillede webhooks | Dublerede kreditter og udbetalinger | Idempotensnøgler, dubletdetektering |
| Matchning på beløb og dato alene | Forskellige poster kolliderer | Match på udbetalings-ID, transaktions-ID, sælger, valuta |
Hvad jeg ville gøre først
Kortlæg pengestrømmen, før du rører ved kontoplanen. Skriv hver eneste hændelse ned fra betalingsindsamling til reserverfrigivelse, og marker, hvilke der skaber omsætning, hvilke der skaber gæld, og hvilke der kun flytter status.
Byg derefter ét end-to-end-forløb og bevis, at det balancerer: et normalt salg, en delvis tilbagebetaling, en chargeback efter udbetaling, en reserve holdt og frigivet, og en mislykked udbetaling. Kør disse med kendte forventede saldi. Hvis kontrolkontoen for sælgergæld svarer til summen af undersøglen, betalingsudbyderens clearing knytter sig til afregningsrapporten, og bankindskuddet knytter sig til udbetalings-ID'et, har du en fungerende rygrad.
Slå periodelås til, først efter at den første måned lukker rent med en tom suspense-saldo. At låse for tidligt fryser bare fejl fast.
Nordlet bogfører afregninger efter disse linjer ud af boksen: platformens kommission går til kommissionsindtægter, sælgerens andel til sælgergæld, betalingsgebyrer til betalingsomkostninger, og alt, der endnu ikke er tilskrevet, til en suspensekonto. Hovedbogsperioder forbliver åbne, indtil du låser dem eksplicit, så den første måned kan lukkes, når suspense er tom. Funktionssiden viser, hvad der er inkluderet.
FAQ
Er køberens betaling nogensinde platformens omsætning?
Kun for de specifikke varer eller tjenesteydelser, hvor platformen er hovedmand. For et agentsalg på en marketplace af en sælgers varer er omsætningen kommissionen, og sælgerens andel er en gældsforpligtelse. En platform kan være hovedmand for en opfyldelsestjeneste og agent for de underliggende varer i samme ordre, så vurderingen er pr. specificeret vare eller tjenesteydelse, ikke pr. virksomhed.
Bør reserver reducere omsætningen?
Nej. En reserve er en tids- og risikofordeling, ikke en omsætningsregulering. Flyt midler fra sælgergæld til en reserveforpligtelse, når du holder dem tilbage, og vend dem om, når du frigiver dem. Omsætning og kommission påvirkes ikke af, om sælgerens penge i øjeblikket er reserverede.
Hvordan stopper jeg dublerede udbetalinger fra webhook-gentagelser?
Tilknyt en idempotensnøgle til hver ekstern hændelse, såsom processor:payout_id for udbetalingsbatches, og opdag dublerede hændelser ved skrivning. Udbydere adskiller udtrykkeligt om, at dublerede webhook-leveringer forekommer, så hovedbogen er nødt til at afvise det andet forsøg i stedet for at bogføre det igen.
Kan en sælgers saldo blive negativ?
Ja, og modellen skal tillade det. En chargeback, der lander, efter at sælgeren er blevet betalt, efterlader platformen med enten et tilgodehavende hos sælgeren eller et tab, som den absorberer. At undertrykke negative saldi skjuler bare en uregistreret forpligtelse.
Hvorfor afstemme hver udbetaling i stedet for måneds total?
Fordi tidsforskydninger og fejl ophæver hinanden, når du aggregerer en måned, så totalerne kan stemme, mens individuelle transaktioner er forkerte. Afstemning pr. udbetaling, matchet på udbetalings- og transaktions-ID'er, afslører manglende hændelser, dubletter og forkert tilskrevne chargebacks før periodelukning.