Underspesifikasjoner for markedsplasselgere: Omsetning mot gjeld
En praktisk guide til å skille kundebetalinger, plattformprovisjon, selgergjeld, avsetninger og utbetalinger med balanserte bokføringsbilag og en velfungerende ordre-til-utbetaling-datamodell.
Den vanligste feilen i markedsplassregnskap er å behandle kjøperens bruttobetaling som plattformens omsetning. En kunde betaler 100 €, de 100 euroene havner på betalingsformidlerens konto, og noen bokfører hele beløpet som salgsinntekt. Regnskapet stemmer en stund, omsetningen ser flott ut, og så spør en revisor hvor selgerforpliktelsen er. Det finnes ingen, fordi selgerens 90 € aldri ble registrert som skyldig beløp.
Løsningen er strukturell, ikke kosmetisk. En markedsplass trenger en hovedbokmodell som skiller fem ulike pengestrømmer fra første postering: kundepenger på avveie i transitt, plattformprovisjon, selgergjeld, gebyrer og avsetninger. Utbetalinger er en sjette hendelse som gjør opp gjelden, ikke en omsetnings- eller kostnadshendelse i seg selv. Denne guiden viser de balanserte bilagene og datamodellen som holder disse strømmene adskilt.
Start med prinsippet om prinsipal versus agent
Før en hvilken som helst kontostruktur betyr noe, må plattformen avgjøre hva den selger. I henhold til ASC 606 vurderes dette per spesifiserte vare eller tjeneste, og svaret avgjør om omsetningen skal føres brutto eller netto. En plattform kan være prinsipal for en pengestrøm og agent for en annen.
For et typisk markedsplássalg av en selgers varer er plattformen vanligvis en agent. Den sørger for at selgerens produkt når kjøperen, den tar ingen varelagerhåndteringsrisiko, og vederlaget dens er en provisjon. Deloittes veiledning om prinsipal versus agent i henhold til ASC 606 rammer inn testen rundt kontroll: ansvaret for å oppfylle løftet, varelagerhåndteringsrisiko og prissettingsmyndighet er indikatorer, ikke en sjekkliste som overstyrer den underliggende kontrollvurderingen.
Grunnen til at dette hører hjemme i hovedbokdesignet, ikke bare i et notat, er at konklusjonen styrer hver eneste nedstrømspostering. Hvis plattformen er en agent, er selgerens andel en gjeld fra det øyeblikket den er opptjent. Hvis den er prinsipal for en oppfyllings- eller garantitjeneste, er den delen plattformomsetning. Lagre konklusjonen som data:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
En kontrollør som ser på en netto provisjonslinje to år senere, skal kunne se hvorfor bruttobeløpet ikke ble brukt. Som BillingPlatform bemerker om ASC 606 prinsipal vs. agent, avgjør ikke merkelappen "markedsplass" spørsmålet. Det gjør derimot kontrollanalysen.
Definer selgers saldo før du skriver en eneste bokføringsregel
"Selgers saldo" er ikke ett enkelt tall. En selger kan ha en sunn historisk saldo, men ingenting tilgjengelig for utbetaling fordi pengene fremdeles er underveis eller holdes tilbake som en avsetning. Slår du sammen disse tilstandene, vil du feilrapportere hva selgeren kan ta ut, og hva plattformen fremdeles skylder.
Du bør som et minimum spore:
- Ventende (Pending): opptjent eller innkrevd, ennå ikke kvalifisert for utbetaling
- Tilgjengelig (Available): kvalifisert for utbetaling i henhold til plattformens regler
- Avsatt (Reserved): holdt tilbake mot forventede refusjoner, tvister eller tilbakeføringer (chargebacks)
- Utbetalt (Paid out): overført eller sendt til oppgjør
- Negativ: beløp som selgeren skylder, som kan kreves inn fra fremtidige inntekter
- Ufordelt (Suspense): mottatt, men selger eller behandling er ennå ikke avklart
Betalingsleverandører modellerer allerede dette skillet. Stripe deler hver tilknyttet konto inn i ventende og tilgjengelige saldoer, og opprettholder en reservert saldo på plattformnivå for visse negative selgersaldoer. Hvis betalingsformidleren skiller mellom disse, må hovedboken gjøre det også, ellers vil avstemmingen aldri gå opp.
Kontoplanen og dimensjonene som betyr noe
En brukbar startstruktur holder clearingkontoer, forpliktelser og omsetning adskilt, og fører en selgerdimensjon på hver enkelt vesentlig postering.
| Formål | Konto eller dimensjon | Behandling |
|---|---|---|
| Betalingsformidler midler som avventer oppgjør | Betalingsformidler clearing | Clearing-eiendel |
| Innkjørt betalingsformidlerutbetaling | Bank | Eiendel |
| Selgerbeløp opptjent, men ubetalt | Selgergjeld | Forpliktelse |
| Detaljer på selgernivå | seller_id-dimensjon |
Forpliktelsesdetalj, ikke omsetning |
| Plattformprovisjon | Provisjonsomsetning | Omsetning |
| Mva. eller salgsavgift | Skyldig merverdiavgift | Forpliktelse |
| Betalingsformidlerens gebyrer | Transaksjonskostnad | Kostnad |
| Selgeravsetninger | Avsetningsforpliktelse | Kontraktsavhengig |
| Refusjoner | Redusert omsetning eller refusjoner | Reverserer opprinnelig behandling |
| Tilbakeføringer (chargebacks) | Tap, fordring eller selgerinnkreving | Avhenger av hvem som bærer tapet |
| Utbetalinger som avventer bankbekreftelse | Utbetalingsclearing for selger | Clearingkonto |
| Ufordelte beløp | Ufordelt (Suspense) | Midlertidig unntak |
Hver vesentlig postering bør inneholde selger, ordre, utbetalingsbatch, betalingsformidler, valuta, juridisk enhet, mva.-behandling, hendelsestype, ekstern referanse og eventuell reverseringslenke. Uten disse kan ikke reskontroen for selgere bevise en individuell saldo, og hovedboken kan ikke bevise totalsummen.
Du kan implementere reskontroen som én gjeldskonto per selger, én samlet gjeldskonto med seller_id som dimensjon, eller en oppsplitting på tvers av gjeld, avsetning og utbetalingsclearing. Tilnærmingen med samlet sum og dimensjon skalerer bedre når du passerer noen dusin selgere. Velg modell sammen med regnskapsfører, fordi verneregler og lokalt betalingsregelverk kan påvirke hvordan midlene må presenteres. For mekanikken bak posteringene dekker vår artikkel om dobbel bokføring-API-er for markedsplassregnskap hovedbokprimitivene som denne modellen hviler på.
Bokfør salget med separate linjer for selger og plattform
Ta et agentsalg: kunden betaler 100 €, plattformprovisjonen er 10 €, selgeren tjener 90 €. I det øyeblikket provisjon og selgerrettighet er opptjent:
| Konto | Debet | Kredit |
|---|---|---|
| Betalingsformidler clearing | 100 € | |
| Selgergjeld - Selger A | 90 € | |
| Provisjonsomsetning | 10 € |
Kontrollen som betyr noe: 90 € krediteres en forpliktelse, ikke omsetning. Plattformen inntektsfører 10 €. Dette er resultatet ASC 606s markedsplasseksempel oppnår for en agent, der plattformen inntektsfører sin provisjon i stedet for selgerens fulle salgsbeløp.
Hvis merverdiavgift kreves inn separat, legger du til mva.-linjen og reduserer selger- eller plattformbeløpet i henhold til mva.-konklusjonen. Ikke bak mva. inn i provisjonen eller selgergjelden for enkelhets skyld.
Hold betalingsformidlerens gebyrer unna omsetnings- og gjeldsregnestykket
Tre ting blir stadig vekk blandet sammen: plattformprovisjon, betalingsformidlerens gebyr og utbetalingsbeløp. De er forskjellige, og de treffer ulike kontoer.
Kunden betaler 100 €, provisjonen er 10 €, betalingsformidleren beholder 3 €.
- Provisjonsomsetningen forblir 10 € hvis det er det kontrakten sier.
- Betalingsformidlerens gebyr på 3 € er en kostnad.
- Selgergjelden er 90 €, med mindre selgerkontrakten sier at selgeren bærer transaksjonsgebyret. Først da synker den til 87 € med en matchende sum på 3 € belastes selgeren.
Å bare bokføre nettosummen på 97 € som lander i banken, utsletter bruttoesalget, provisjonen og gebyret i én operasjon. Vår referanse for betalingsavstemming påpeker det samme: dekomponer oppgjøret, behandle formidlerens gebyrer som kostnader, og la aldri nettobetalingsinnskuddet erstatte omsetningen.
Modeller tilgjengelighet, avsetninger og utbetalinger som separate hendelser
Penger endrer status flere ganger mellom registrering og oppgjort kontanter. Hver overgang fortjener sitt eget bilag, og en avsetning er aldri et uforklarlig kutt i omsetningen.
Når tilgjengelige midler flyttes til avsetning:
| Konto | Debet | Kredit |
|---|---|---|
| Selgergjeld - Selger A | 15 € | |
| Selgeravsetningsforpliktelse | 15 € |
Når avsetningen frigis, reverserer du den. Selgerens samlede forpliktelse har ikke endret seg, men statusen har det. Stripe dokumenterer avsetningstransaksjoner som øker og frigir avsetninger, i tillegg til innkrevingsoverføringer for langvarige negative saldoer, og det er derfor disse trenger identifiserbare kontoer i stedet for en enkel motregningspostering.
Utbetalinger får sin egen behandling i to trinn. Ved godkjenning:
| Konto | Debet | Kredit |
|---|---|---|
| Selgergjeld - Selger A | 90 € | |
| Utbetalingsclearing for selger | 90 € |
Ved bekreftet bankoppgjør:
| Konto | Debet | Kredit |
|---|---|---|
| Utbetalingsclearing for selger | 90 € | |
| Bank | 90 € |
Hvis utbetalingen feiler, reverserer du clearingen tilbake til selgergjeld. En utbetaling er et gjeldsforlik, ikke en kostnad. Å behandle den som en kostnad vil innebære dobbeltsumering mot salget som allerede har registrert gjelden. Stripe skiller utbetalingsstatus (pending, in_transit, paid, failed, canceled) og forventet ankomstdato fra igangsetting, og disse datoene bør ikke slås sammen til ett tidsstempel.
Ordre-til-utbetaling-datamodellen
Reskontroen kjører på hendelser, ikke på applikasjonens gjeldende ordrestatus. Hver selgerpåvirkende hendelse bærer den samme omslaget (envelope):
seller_id,event_id,order_idevent_type(salg, refusjon, tilbakeføring, reserve_hold, reserve_release, payout, justering)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
Fra disse hendelsene beregner du utgående saldo i stedet for å lagre et muterbart felt:
Selgers utgående saldo
= inngående saldo
+ selgerkreditter
− selgerdebeter
− utbetalinger
± avsetningsbevegelser
± korreksjoner
Hver ekstern hendelse trenger en robust idempotensnøkkel slik at forsøk på nytt (retries) og dupliserte webhooks ikke krediterer en selger dobbelt eller utbetaler to ganger. Mønstre som fungerer:
- Selgerbokføringshendelse:
seller_id:order_id:event_type:version - Utbetalingsbatch:
processor:payout_id - Betalingsformidlerhendelse:
processor:event_type:processor_event_id
Stripes egen webhook-veiledning advarsler om at dupliserte hendelser skjer, så duplikatdeteksjon er ikke valgfritt. Bokførte posteringer forblir uforanderlige (immutable). Korreksjoner går gjennom en reverserende postering pluss en korrigert postering, og det er din egen hendelsesomslag som bærer reversal_of-lenken og årsaken. Hovedboken holder posteringene, ikke den lenken: Nordlet eksponerer oppretting, henting og opplisting for hovedboktransaksjoner i sin API-referanse og ingen oppdatering eller sletting, så en korreksjon er alltid en ny transaksjon i stedet for en redigering.
Refusjoner og tilbakeføringer henviser tilbake, de flyter aldri fritt
En refusjon som dukker opp i neste ukes utbetaling, skal aldri bli et nytt negativt salg knyttet til den utbetalingen. Knytt den til den opprinnelige transaksjonen og behold den opprinnelige selgerallokeringen. Avhengig av kontrakten:
- Reverser provisjonen hvis kontrakten gjør den refunderbar
- Belast selgergjelden hvis selgeren bærer refusjonen
- Belast en plattformtapskonto hvis plattformen bærer den
- Øk en avsetning mens en tvist er åpen, frigi eller forbruk den ved løsning
Tilbakeføringer (chargebacks) etter utbetaling er der negative saldoer oppstår. Selgerens penger er allerede borte, så plattformen enten krever dem inn fra fremtidige inntekter eller absorberer tapet. Modellen må tillate negative selgersaldoer og definere innkrevingsregelen. Adyens markedsplassrapportering viser refusjoner og tilbakeføringer som produserer separate debetlinjer per kontoinnehaver, noe som er det detaljnivået man bør sikte mot.
Avstem per utbetaling, ikke per måned
Dekomponer hvert oppgjør fra betalingsformidleren før bokføring, og avstem hver utbetaling i stedet for å samle opp en måned:
Bruttobeløp
− refusjoner
− betalingsformidlerens gebyrer
− tilbakeføringer
± avsetninger og justeringer
= netto utbetaling fra betalingsformidler
Bevis deretter at fire saldoer stemmer overens for hver selger og valuta: selgerreskontroen, betalingsformidlerens selgersaldo, utbetalingsrapporten og bankclearingen. Når de avviker, klassifiser avviket (tidsforskyvning, manglende hendelse, duplikat, feil attributt, feil valuta, feilet utbetaling, tilbakeføring bokført på feil part). Å motregne bort avvik er slik feil opphever hverandre og overlever til neste månedsstengning.
Å samle opp en hel måned gjør at tidsavvik opphever hverandre og skjuler faktiske brudd. Utbetalingsspesifikk matching, basert på utbetalings-ID og transaksjonsreferanse i stedet for beløp og dato, fanger dem opp.
Vanlige feilmønstre
| Feilmønster | Hvorfor det gjør skade | Kontroll |
|---|---|---|
| Bruttokundebetaling bokført som omsetning | Blåser opp omsetningen, skjuler selgergjeld | Del opp gjeld og provisjon ved opptjeningstidspunktet |
| Kun nettobetalinger bokført | Mister brutto, gebyrer, refusjoner, avsetninger | Dekomponer hvert oppgjør |
| Utbetaling ført som kostnad | Feilrepresenterer et gjeldsforlik | Debiter selgergjelden ved utbetaling |
| Én enkelt selgersaldofelt | Blander ventende, tilgjengelige, avsatte, utbetalte | Spor saldotilstander eksplisitt |
| Provisjon beregnet ved utbetalingstidspunktet | Omsetning følger utbetalingsplanlegging | Inntektsfør provisjon når den opptjenes |
| Avsetning behandlet som omsetningskutt | Tåkelegger tidsbruk og risiko | Spor tilbakeholdelse, frigivelse, forbruk separat |
| Refusjon brukt på siste utbetaling | Ødelegger ordrekobling | Knytt refusjon til opprinnelig transaksjon |
| Redigering av bokførte posteringer | Ødelegger revisjonssporet | Reverser og bokfør på nytt |
| Avspilte webhooks (Replayed webhooks) | Dupliserte kreditter og utbetalinger | Idempotensnøkler, duplikatdeteksjon |
| Matching kun på beløp og dato | Ulike elementer kolliderer | Match på utbetalings-ID, transaksjons-ID, selger, valuta |
Hva jeg ville gjort først
Kartlegg pengestrømmen før du rører kontoplanen. Skriv ned hver hendelse fra betalingsfangst til reservefrigivelse, og merk av hvilke som skaper omsetning, hvilke som skaper en gjeld, og hvilke som bare flytter status.
Bygg deretter én helhetlig flyt og bevis at den balanserer: et normalt salg, en delvis refusjon, en tilbakeføring etter utbetaling, en avsetning holdt tilbake og frigitt, og en feilet utbetaling. Kjør disse med kjente forventede saldoer. Hvis selgergjelds kontrollkonto er lik summen av reskontroen, betalingsformidlerens clearing knytter seg til oppgjørsrapporten, og bankinnskuddet knytter seg til utbetalings-ID-en, har du en fungerende ryggrad.
Slå på periodebetinget låsing først etter at den første måneden er lukket rent med en tom ufordelt (suspense) saldo. For tidlig låsing bare fryser feil.
Nordlet bokfører oppgjør etter disse linjene rett ut av esken: plattformens provisjon går til provisjonsomsetning, selgerens andel til en selgergjeld, betalingsformidlerens gebyrer til en transaksjonskostnad, og alt som ennå ikke er attributtert, til en ufordelt konto. Hovedbokperioder forblir åpne til du låser dem eksplisitt, slik at den første måneden kan lukkes når ufordelt er tomt. Funksjonssiden lister opp hva som følger med.
FAQ
Er kundens betaling noen gang plattformomsetning?
Bare for de spesifikke varene eller tjenestene der plattformen er prinsipal. For et agentsalg på en markedsplass av en selgers varer er omsetningen provisjonen og selgerens andel en forpliktelse. En plattform kan være prinsipal for en oppfyllingstjeneste og agent for de underliggende varene i samme ordre, slik at vurderingen er per spesifiserte vare eller tjeneste, ikke per selskap.
Bør avsetninger redusere omsetningen?
Nei. En avsetning er en tids- og risikofordeling, ikke en omsetningsjustering. Flytt midler fra selgergjeld til en avsetningsforpliktelse når du holder dem tilbake, og reverser når du frigir dem. Omsetning og provisjon påvirkes ikke av om selgerens penger for tiden er avsatt.
Hvordan stopper jeg dupliserte utbetalinger fra webhook-forsøk på nytt?
Knytt en idempotensnøkkel til hver ekstern hendelse, for eksempel processor:payout_id for utbetalingsbatcher, og oppdag dupliserte hendelser ved skriving. Leverandører advarer eksplisitt om at dupliserte webhook-leveranser forekommer, så hovedboken må avvise det andre forsøket i stedet for å bokføre det på nytt.
Kan en selgersaldo bli negativ?
Ja, og det må modellen tillate. En tilbakeføring som lander etter at selgeren har fått utbetalt pengene, etterlater plattformen med enten en fordring på selgeren eller et tap den absorberer. Å undertrykke negative saldoer skjuler bare en uregistrert forpliktelse.
Hvorfor avstemme hver utbetaling i stedet for månedssummen?
Fordi tidsavvik og feil opphever hverandre når du samler opp en måned, slik at totalene kan stemme selv om enkeltransaksjoner er feil. Utbetalingsspesifikk avstemming, matchet på utbetalings- og transaksjons-ID-er, avdekker manglende hendelser, duplikater og feilplasserte tilbakeføringer før avslutning.