Subadministraties voor marktplaatsverkopers: Omzet versus te betalen posten
Een praktijkgids voor het scheiden van klanttegoeden, platformprovisies, verkopersschulden, reserves en uitbetalingen met sluitende journaalposten en een werkend datamodel voor de volledige order-tot-uitbetalingstroom.
De meest gemaakte fout in de marktplaatsboekhouding is het beschouwen van de brutobetaling van de koper als omzet voor het platform. Een klant betaalt € 100, dat bedrag komt binnen op de betaalrekening van de payment service provider (PSP) en iemand boekt het hele bedrag als omzet. De boeking klopt tijdelijk qua sommen, de omzet ziet er fantastisch uit en dan vraagt een auditor waar de schuld aan de verkoper is gebleven. Die is er niet, omdat het aandeel van de verkoper van € 90 nooit is vastgelegd als verschuldigd bedrag.
De oplossing is structureel van aard, niet cosmetisch. Een marktplaats heeft een grootboekmodel nodig dat vanaf de allereerste boeking vijf verschillende geldstromen van elkaar scheidt: klanttegoeden onderweg, platformomzet uit provisies, verkopersschulden, transactiekosten en reserves. Uitbetalingen vormen een zesde gebeurtenis die de schuld afwikkelt, en zijn op zichzelf geen omzet- of kostenpost. Deze gids toont de sluitende journaalposten en het datamodel waarmee deze geldstromen zuiver gescheiden blijven.
Begin met de conclusie over principaal versus agent
Voordat de inrichting van de rekeningen ertoe doet, moet het platform bepalen wat het precies verkoopt. Onder ASC 606 wordt dit beoordeeld per specifiek goed of dienst, en het antwoord bepaalt of de omzet bruto of netto wordt verantwoord. Een platform kan voor de ene geldstroom als principaal optreden en voor de andere als agent.
Bij een typische marktplaatsverkoop van goederen van een verkoper treedt het platform doorgaans op als agent. Het regelt dat het product van de verkoper bij de koper terechtkomt, loopt geen voorraadrisico en ontvangt als vergoeding een provisie. De richtsnoeren van Deloitte over principaal versus agent onder ASC 606 richten de toets in rondom zeggenschap: verantwoordelijkheid voor het nakomen van de belofte, voorraadrisico en prijsvrijheid zijn indicatoren, en vormen geen afvinklijst die de onderliggende zeggenschapstoets opzijschuift.
De reden dat dit thuishoort in het grootboekontwerp en niet alleen in een memo, is dat deze conclusie elke volgende boeking aanstuurt. Als het platform als agent optreedt, is het aandeel van de verkoper een schuld vanaf het moment dat het is verdiend. Treedt het platform op als principaal voor een verzend- of garantiedienst, dan vormt dat deel platformomzet. Sla de conclusie op als data:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Een accountant die twee jaar later naar een nettoprovisieregel kijkt, moet kunnen zien waarom er geen brutobedrag is gehanteerd. Zoals BillingPlatform opmerkt over ASC 606 principaal versus agent, lost het etiket "marktplaats" de vraag niet op. De zeggenschapsanalyse doet dat wel.
Bepaal het verkoperssaldo voordat u ook maar één journaalregel schrijft
Het "verkoperssaldo" is geen enkelvoudig getal. Een verkoper kan een uitstekende historische omzet hebben en tegelijkertijd niets beschikbaar om uit te betalen, omdat het geld nog in behandeling is of gereserveerd staat. Wie deze statussen op een hoop gooit, rapporteert verkeerd over wat de verkoper kan opnemen en wat het platform nog verschuldigd is.
Houd ten minste het volgende bij:
- In afwachting (pending): verdiend of geïnd, nog niet in aanmerking komend voor uitbetaling
- Beschikbaar (available): in aanmerking komend voor uitbetaling volgens de platformregels
- Gereserveerd (reserved): ingehouden ter dekking van te verwachten terugbetalingen, geschillen of terugboekingen (chargebacks)
- Uitbetaald (paid out): overgemaakt of aangeboden ter vereffening
- Negatief: bedrag dat de verkoper verschuldigd is, te verrekenen met toekomstige opbrengsten
- Tussenrekening (suspense): ontvangen, maar verkoper of verwerking nog niet vastgesteld
Betalingsverwerkers modelleren dit onderscheid al. Stripe splitst elk gekoppeld account op in openstaande en beschikbare saldi en houdt een gereserveerd saldo op platformniveau aan voor bepaalde negatieve verkoperssaldi. Als de processor dit scheidt, moet het grootboek dat ook doen, anders klopt de aansluiting nooit.
Het rekeningschema en de dimensies die ertoe doen
Een werkbare beginstructuur houdt tussenrekeningen (clearing accounts), schulden en omzet uit elkaar en draagt bij elke materiële boeking een verkopersdimensie mee.
| Doel | Rekening of dimensie | Behandeling |
|---|---|---|
| Verwerkingstegoeden van PSP in afwachting van vereffening | Clearingrekening betaalprocessor | Vlottend activum |
| Gestorte uitbetaling van PSP | Bank | Activa |
| Verdiend maar onbetaald verkopersbedrag | Verkopersschulden | Passiva |
| Detail op verkopersniveau | Dimensie seller_id |
Verplichtingdetail, geen omzet |
| Platformprovisie | Provisieomzet | Omzet |
| Btw of omzetbelasting | Te betalen omzetbelasting | Passiva |
| Transactiekosten van PSP | Betaalverwerkingskosten | Kosten |
| Verkopersreserves | Reserveringsverplichting | Afhankelijk van contract |
| Terugbetalingen (refunds) | Correctie-omzet of restituties | Draait oorspronkelijke boeking terug |
| Terugboekingen (chargebacks) | Verlies, vordering of verkopersverhaal | Afhankelijk van wie het verlies draagt |
| Uitbetalingen in afwachting van bankbevestiging | Clearingrekening verkopersuitbetalingen | Tussenrekening |
| Niet-toegekende bedragen | Tussenrekening (suspense) | Tijdelijke uitzondering |
Elke materiële boeking moet voorzien zijn van de verkoper, order, uitbetalingsbatch, betalingsverwerker, valuta, juridische entiteit, btw-behandeling, gebeurtenistype, externe referentie en eventuele correctieverwijzing. Zonder deze gegevens kan de verkoperssubadministratie een individueel saldo niet onderbouwen en kan het grootboek het totaal niet bewijzen.
U kunt de subadministratie implementeren als één schuldrekening per verkoper, één verzamelrekening voor crediteuren met seller_id als dimensie, of als een opsplitsing in schuld, reserve en uitbetalingsclearing. De aanpak met een verzamelrekening plus dimensies schaalt beter zodra u tientallen verkopers passeert. Stem het model af met uw accountant, aangezien regels voor derdengelden en lokale betaalwetgeving invloed kunnen hebben op de presentatie van de tegoeden. Voor de technische achtergrond van deboekingen behandelt ons artikel over grootboek-api's met dubbel boekhouden voor marktplaatsen de grootboekbouwstenen waarop dit model rust.
Boek de verkoop met afzonderlijke regels voor verkoper en platform
Neem een verkopen via een agent: de klant betaalt € 100, de platformprovisie is € 10, de verkoper verdient € 90. Op het moment dat de provisie en het recht van de verkoper zijn verdiend:
| Rekening | Debet | Credit |
|---|---|---|
| Clearingrekening betaalprocessor | € 100 | |
| Verkopersschuld - Verkoper A | € 90 | |
| Provisieomzet | € 10 |
De cruciale controle: € 100 wordt gecrediteerd op een schuld, niet op de omzet. Het platform verantwoort € 10. Dit is het resultaat waarnaar het marktplaatsvoorbeeld van ASC 606 streeft voor een agent, waarbij het platform zijn provisie erkent in plaats van het volledige verkoopbedrag van de verkoper.
Als belasting apart wordt geïnd, voegt u de regel voor te betalen belasting toe en verlaagt u het bedrag van de verkoper of het platform op basis van de belastingconclusie. Voeg belasting nooit gemakshalve samen met de provisie of de verkopersschuld.
Houd betalingskosten buiten de omzet- en schuldendans
Drie dingen worden voortdurend door elkaar gehaald: platformprovisie, verwerkingskosten en uitbetalingsbedrag. Ze zijn verschillend en raken verschillende rekeningen.
Klant betaalt € 100, provisie is € 10, de processor houdt € 3 in.
- De provisieomzet blijft € 10 als dat in het contract staat.
- De verwerkingskosten van € 3 zijn kosten.
- De verkopersschuld bedraagt € 90, tenzij het contract van de verkoper bepaalt dat deze de verwerkingskosten draagt. Alleen dan daalt dit tot € 87 met een bijbehorende inhouding van € 3 bij de verkoper.
Het uitsluitend boeken van de netto € 107 (of in dit geval de netto € 97 die binnenkomt op de bank) wist in één klap de bruto verkoop, de provisie en de kosten uit. Onze referentie voor betalingsreconciliatie wijst op hetzelfde: ontleed de afwikkeling, behandel verwerkingskosten als kosten en laat de nettestorting nooit doorgaan voor omzet.
Modelleer beschikbaarheid, reserves en uitbetalingen als afzonderlijke gebeurtenissen
Geld verandert meerdere keren van status tussen ontvangst en definitief vereffend geld. Elke overgang verdient een eigen boeking, en een reserve is nooit een onverklaarde verlaging van de omzet.
Wanneer beschikbare tegoeden naar een reserve worden verplaatst:
| Rekening | Debet | Credit |
|---|---|---|
| Verkopersschuld - Verkoper A | € 15 | |
| Verplichting verkopersreserves | € 15 |
Wanneer de reserve vrijvalt, boekt u dit tegenovergesteld. De totale verplichting van de verkoper is niet veranderd, maar de status wel. Stripe documenteert reserveringstransacties die reserves verhogen en vrijgeven, plus invorderingsboeking voor langdurige negatieve saldi, en daarom vereisen deze identificeerbare rekeningen in plaats van een enkele saldoberekening.
Uitbetalingen krijgen een eigen behandeling in twee stappen. Bij goedkeuring:
| Rekening | Debet | Credit |
|---|---|---|
| Verkopersschuld - Verkoper A | € 90 | |
| Clearingrekening verkopersuitbetalingen | € 90 |
Bij bevestigde bankafwikkeling:
| Rekening | Debet | Credit |
|---|---|---|
| Clearingrekening verkopersuitbetalingen | € 90 | |
| Bank | € 90 |
Als de uitbetaling mislukt, boekt u de clearing terug naar de verkopersschuld. Een uitbetaling is de afwikkeling van een schuld, geen kostentoerekening. Dit als kosten behandelen leidt tot dubbeltelling ten opzichte van de verkoop waarvoor de schuld al was geboekt. Stripe scheidt de uitbetalingsstatus (pending, in_transit, paid, failed, canceled) en de verwachte aankomstdatum van het initiatief, en die datums mogen niet worden samengevoegd tot één tijdstempel.
Het datamodel van order tot uitbetaling
De subadministratie draait op gebeurtenissen (events), niet op de huidige orderstatus van de applicatie. Elke verkopersgerelateerde gebeurtenis draagt dezelfde envelop:
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
Vanuit deze gebeurtenissen berekent u het eindsaldo in plaats van een veranderend veld op te slaan:
Eindsaldo verkoper
= beginsaldo
+ verkopersbijschrijvingen
− verkopersafschrijvingen
− uitbetalingen
± reservebewegingen
± correcties
Elke externe gebeurtenis vereist een betrouwbare idempotentiesleutel (idempotency key), zodat hertry's en dubbele webhooks een verkoper niet dubbel crediteren of dubbel uitbetalen. Patronen die werken:
- Journaalgebeurtenis verkoper:
seller_id:order_id:event_type:version - Uitbetalingsbatch:
processor:payout_id - Gebeurtenis van betalingsverwerker:
processor:event_type:processor_event_id
De webhook-richtsnoeren van Stripe waarschuwen dat dubbele gebeurtenissen voorkomen, dus dubbele detectie is verplicht. Geboekte journaalposten blijven onveranderbaar (immutable). Correcties lopen via een tegenboeking plus een gecorrigeerde boeking, en het is uw eigen gebeurtenisenvelop die de reversal_of-link en de reden meedraagt. Het grootboek bevat de boekingen, niet die link: Nordlet biedt create-, get- en list-functies voor journaaltransacties in de API-referentie zonder update- of delete-mogelijkheid, waardoor een correctie altijd een nieuwe transactie is in plaats van een bewerking.
Terugbetalingen en chargebacks verwijzen altijd terug en zweven niet
Een terugbetaling die opduikt in de uitbetaling van volgende week mag nooit een nieuwe negatieve verkoop worden die aan die uitbetaling hangt. Koppel deze aan de oorspronkelijke transactie en behoud de oorspronkelijke verkopertoewijzing. Afhankelijk van het contract:
- Draai de provisie terug als het contract bepaalt dat deze restitueerbaar is
- Debiteer de verkopersschuld als de verkoper de terugbetaling draagt
- Debiteer een platformverliesrekening als het platform deze draagt
- Verhoog een reserve zolang een geschil openstaat, en geef deze vrij of spreek deze aan bij afhandeling
Chargebacks na uitbetaling zijn het moment waarop negatieve saldi ontstaan. Het geld van de verkoper is al verdwenen, dus het platform verhaalt dit op toekomstige opbrengsten of absorbeert het verlies. Het model moet negatieve verkoperssaldi toestaan en de verhaalsregel definiëren. De marktplaatsrapportage van Adyen toont terugbetalingen en chargebacks die afzonderlijke debetregels per rekeninghouder genereren, en dat is de gewenste fijnmazigheid.
Reconcilieer per uitbetaling, niet per maand
Ontleed elke afwikkeling van de betalingsverwerker voorafgaand aan de boeking en reconcilieer elke uitbetaling in plaats van een maand te aggregeren:
Bruto-afschrijvingen
− terugbetalingen
− betalingsverwerkingskosten
− chargebacks
± reserves en correcties
= netto uitbetaling door processor
Bewijs vervolgens dat vier saldi overeenkomen voor elke verkoper en valuta: de verkoperssubadministratie, het verkoperssaldo van de processor, het uitbetalingsrapport en de bankclearing. Wanneer deze verschillen, classificeer het verschil dan (tijdverschil, ontbrekende gebeurtenis, duplicaat, verkeerde toewijzing, verkeerde valuta, mislukte uitbetaling, chargeback geboekt op de verkeerde partij). Verschillen wegstrepen door middel van nettoleningen zorgt ervoor dat fouten elkaar compenseren en overleven tot de volgende afsluiting.
Het aggregeren van een hele maand zorgt ervoor dat tijdverschillen elkaar opheffen en verbergt echte omissies. Vergelijking per uitbetaling, gekoppeld op uitbetalings-ID en transactiereferentie in plaats van bedrag en datum, brengt deze aan het licht.
Veelvoorkomende faalmodi
| Faalmodus | Waarom het schadelijk is | Beheersmaatregel |
|---|---|---|
| Bruto betaling door klant geboekt als omzet | Blaast omzet op, verbergt verkopersschuld | Splits schuld en provisie bij de verdienste |
| Alleen nettestortingen geboekt | Verliest bruto omzet, kosten, restituties, reserves | Ontleed elke afwikkeling |
| Uitbetaling geboekt als kostenpost | Stelt schuldawikkeling verkeerd voor | Debiteer verkopersschuld bij uitbetaling |
| Eén verkoperssaldoveld | Mengt openstaand, beschikbaar, gereserveerd, betaald | Volg saldostatussen expliciet |
| Provisie berekend op uitbetalingsmoment | Omzet volgt uitbetalingsplanning | Verantwoord provisie wanneer deze wordt verdiend |
| Reserve behandeld als omzetverlaging | Vertroebelt timing en risico | Volg vasthouden, vrijgeven en verbruiken apart |
| Terugbetaling toegepast op laatste uitbetaling | Breekt orderattributie af | Koppel terugbetaling aan oorspronkelijke transactie |
| Bewerken van geboekte posten | Vernietigt audit trail | Boek tegen en herboekt |
| Opnieuw afgespeelde webhooks | Dubbele bijschrijvingen en uitbetalingen | Idempotentiesleutels, duplicaatdetectie |
| Matchen op alleen bedrag en datum | Verschillende items botsen | Match op uitbetalings-ID, transactie-ID, verkoper, valuta |
Wat ik als eerste zou doen
Breng de geldstroom in kaart voordat u het rekeningschema aanraakt. Schrijf elke gebeurtenis op, van betalingsontvangst tot het vrijgeven van reserves, en geef aan welke omzet creëren, welke een schuld vormen en welke enkel de status verplaatsen.
Bouw vervolgens één end-to-end-stroom en bewijs dat deze sluit: een normale verkoop, een gedeeltelijke terugbetaling, een chargeback na uitbetaling, een vastgehouden en vrijgegeven reserve en een mislukte uitbetaling. Voer deze uit met bekende verwachte saldi. Als de controle-rekening voor verkopersschulden gelijk is aan de som van de subadministratie, de processorclearing aansluit op het afwikkelingsrapport en de bankstorting aansluit op de uitbetalings-ID, hebt u een werkende ruggengraat.
Schakel periodevergrendeling pas in nadat de eerste maand netjes is afgesloten met een lege tussenrekening (suspense balance). Te vroeg vergrendelen bevriest simpelweg de fouten.
Nordlet boekt afwikkelingen volgens deze lijnen direct uit de doos: de provisie van het platform gaat naar provisieomzet, het aandeel van de verkoper naar een verkopersschuld, de verwerkingskosten van de processor naar betaalverwerkingskosten en alles wat nog niet is toegewezen naar een tussenrekening. Grootboekperiodes blijven open totdat u ze expliciet vergrendelt, zodat de eerste maand kan worden afgesloten zodra de tussenrekening leeg is. De functies-pagina somt op wat er is inbegrepen.
FAQ
Is de betaling van de koper ooit platformomzet?
Alleen voor de specifieke goederen of diensten waarbij het platform de principaal is. Bij de verkoop via een agentmarktplaats van goederen van een verkoper is de omzet de provisie en is het aandeel van de verkoper een schuld. Een platform kan principaal zijn voor een verzendservice en agent voor de onderliggende goederen in dezelfde order, dus de beoordeling is per specifiek goed of dienst, niet per bedrijf.
Moeten reserves de omzet verlagen?
Nee. Een reserve is een toewijzing van timing en risico, geen omzetcorrectie. Verplaats tegoeden van de verkopersschuld naar een reserveringsverplichting wanneer u ze vasthoudt, en draai dit terug bij vrijgave. Omzet en provisie worden niet beïnvloed door het feit dat het geld van de verkoper momenteel gereserveerd staat.
Hoe stop ik dubbele uitbetalingen door webhook-hertry's?
Voeg een idempotentiesleutel toe aan elke externe gebeurtenis, zoals processor:payout_id voor uitbetalingsbatches, en detecteer dubbele gebeurtenissen bij het wegschrijven. Providers waarschuwen uitdrukkelijk dat dubbele webhook-leveringen plaatsvinden, dus het grootboek moet de tweede poging afwijzen in plaats de boeking opnieuw uit te voeren.
Kan het saldo van een verkoper negatief worden?
Ja, en het model moet dat toestaan. Een chargeback die binnenkomt nadat de verkoper al is betaald, laat het platform achter met een vordering op de verkoper of een verlies dat het absorbeert. Het onderdrukken van negatieve saldi verbergt simpelweg een niet-geregistreerde verplichting.
Waarom elke uitbetaling reconciliëren in plaats van het maandtotaal?
Omdat tijdverschillen en fouten elkaar opheffen wanneer u een maand aggregeren, waardoor de totalen kunnen aansluiten terwijl individuele transacties onjuist zijn. Reconciliatie per uitbetaling, gematcht op uitbetalings- en transactie-ID's, brengt ontbrekende gebeurtenissen, duplicaten en verkeerd toegewezen chargebacks aan het licht vóór de afsluiting.