Stripe Connect Marketplace Accounting Workflow

Q: Hvordan håndteres refusjoner som gjøres opp i en senere utbetaling?

De kommer som en refund-rad i den senere utbetalingens spesifiserte rapport og matches tilbake til den opprinnelige belastningen gjennom chargeid fra den tidligere matchede belastningen. En refusjon syntetisert fra en betalingseksport på belastningsnivå er bare en tilnærming i dette tilfellet, så den spesifiserte rapporten er den tryggere kilden.

En praktisk guide for regnskapsførere til å bokføre betalinger, gebyrer, overføringer, refusjoner, innsigelser og reservasjoner i en markedsplasshovedbok som stemmer rent.

De fleste regnskapsproblemer på markedsplasser kan spores tilbake til én enkelt feil: å behandle Stripe-utbetalingen til banken som om den skulle være omsetning. Utbetalingen er nettoresten av dusinvis av separate økonomiske hendelser, og å bokføre den som én enkelt inntektslinje visker ut plattformens provisjon, selgerens forpliktelse og alle gebyrer og tvister som er gjemt inni den. En korrekt arbeidsflyt dekomponerer utbetalingen før noe som helst berører hovedboken.

Denne guiden sporer hver enkelt Stripe Connect-balansetransaksjon (balance-transaction) til sin riktige regnskapsmessige plassering: kundefordringer, provisjonsinntekter, selgerforpliktelser, transaksjonskostnader og mellomværende/suspens. Den bruker Nordlets dokumenterte import- og avregningsendepunkter som bokføringsmekanisme, inkluderer et gjennomarbeidet avregningseksempel og avsluttes med en avstemmingssjekkliste du kan kjøre før hver periodeslutt.

Identifiser Connect-belastningsmodellen før du designer noe som helst

Regnskapsregler kan ikke skrives før du vet hvilken belastningsmodell (charge model) hver betalingsflyt bruker. Modellen avgjør hvem sin Stripe-saldo som belastes, hvem som bærer gebyrene, og hvor refusjoner og innsigelser treffer først.

Connect-modell	Belastning opprettet på	Bærer Stripe-gebyrer	Refusjoner/innsigelser reduserer	Regnskapsmessig konsekvens
Direktebelastninger (Direct charges)	Tilknyttet konto (connected account)	Kan konfigureres per part	Saldoen på den tilknyttede kontoen	Plattformen bokfører sitt påslag (application fee) som omsetning; selgerens betalingsaktivitet ligger mesteppet på den tilknyttede kontoens hovedbok
Destinasjonsbelastninger (Destination charges)	Plattformen, med umiddelbar overføring til én tilknyttet konto	Plattformen	Plattformen	Plattformen bokfører kundefordringen og Stripe-gebyret; selgerandelen er en gjeldspost, ikke omsetning
Separate belastninger og overføringer (Separate charges and transfers)	Plattformbelastning, deretter én eller flere separate overføringer	Plattformen	Plattformen	Belastning og selgeroverføringer er separate hendelser; selgerforpliktelsen spores uavhengig av kundebelastningen

Stripes egen veiledning om hvordan belastninger fungerer i en Connect-integrasjon bekrefter at plattformsaldoen bærer betalingsgebyrer, refusjoner og tilbaketrekking av betalinger (chargebacks) ved destinasjonsbelastninger samt separate belastninger og overføringer. Ved direktebelastninger mottar den tilknyttede kontoen belastningen, og gebyrer kan belastes hvilken som helst av partene.

Den praktiske regelen er: Ikke si at "Stripe-utbetalingen er selgeromsetning" eller at "selgeren betaler gebyrene" før du har skrevet ned belastningsmodellen for hver enkelt flyt. Lagre den modellen sammen med hver transaksjon. Å blande direktebelastninger og destinasjonsbelastninger under én enkelt bokføringsregel er den raskeste måten å feilrapportere både omsetning og gjeld på.

Denne guiden forutsetter destinasjonsbelastninger eller separate belastninger og overføringer, fordi det er der plattformsaldoen bærer den regnskapsmessige vekten, og hvor de fleste markedsplasshovedbøker blir bygget.

Kartlegg pengeflyten før du importerer en eneste rad

Før du rører en import, bør du tegne et transaksjonskart på én side for hver flyt:

Kundefordring
  -> Stripe-belastning / betalingsbalansetransaksjon
  -> Stripe-gebyr
  -> plattformens påslag (provisjon)
  -> overføring til tilknyttet konto
  -> refusjon eller innsigelse (hvis aktuelt)
  -> Stripe-utbetaling
  -> bankinnskudd

Hver pil er en distinkt balansetransaksjon med sin egen ID, kategori, beløp og datoer. Behandle Stripe-saldoen som en banklignende avregningskonto: Innbetalinger flyter inn, gebyrer og overføringer flyter ut, og utbetalingen flytter restbeløpet til den ekte banken. Nordlets dokumentasjon for bank- og betalingsimport anbefaler nøyaktig denne behandlingen for ordinær Stripe-aktivitet.

Velg riktig Stripe-kilderapport

For automatiske utbetalingsbatcher (settlement batches) bruker du Stripes rapport for Utbetalingsavstemming, spesifisert (Payout reconciliation, itemized). Den gir én rad per balansetransaksjon, grupperer rader etter reporting_category, knytter hver enkelt til en automatic_payout_id, og gir brutto-, gebyr- og nettosummer. Stripes veiledning for valg av rapport dokumenterer denne rapporten og bekrefter charge_id, connected_account_id og destination_payment_id som tilgjengelige Connect-felt.

Der automatiske utbetalinger ikke er aktivert (visse oppsett med manuelle utbetalinger), bruker du Balanserapporten (Balance report) i stedet. Ikke se på et utbetalingssammendrag fra dashbordet som tilstrekkelig dokumentasjon for bokføring. Sammendraget beviser batch-totalen; bare den spesifiserte rapporten forklarer komponentene.

Stripe anbefaler å klassifisere etter reporting_category i stedet for det eldre feltet type, og hver rad har en source-ID som kobles til det underliggende objektet. Merk deg tidskravet: Stripe oppgir at daglige rapportdata vanligvis er tilgjengelige ved lunsjtider dagen etter, og umiddelbare utbetalinger (instant payouts) kan ikke knyttes rent til individuelle transaksjoner, slik at de krever separat transaksjonshistorikkavstemming.

Klassifiser hver balansetransaksjon etter kategori

Bruk reporting_category som primær klassifisator, og inspiser deretter source_id, charge_id og beskrivelser. Mappingen som betyr noe:

Stripe-aktivitet	Rapporteringskategori (`reporting_category`)	Regnskapsmessig tolkning
Kundebelastning, kort eller lokal betalingsmetode	`charge`	Kundefinansiert fordring eller salgsavregning
Refusjon	`refund`	Reversering av den opprinnelige kundebetalingen
Behandlingsgebyr holdt tilbake av Stripe	`fee`	Betalingsbehandlingskostnad
Plattformpåslag (Application fee)	`platform_earning`	Provisjonsinntekt
Refusjon av plattformpåslag	`platform_earning_refund`	Reduksjon av provisjonsinntekt
Overføring til tilknyttet konto	`transfer`	Reduksjon av selgerforpliktelse
Reversert overføring	`transfer_reversal`	Innkreving fra den tilknyttede kontoen
Tilbaketrekking av betaling (Chargeback)	`dispute`	Tap på tilbaketrekking; inspiser kildetvistobjektet
Innsigelse vunnet eller reversert	`dispute_reversal`	Inndekning av tidligere bokført tap på innsigelse
Utbetaling til bank	`payout`	Bankbevegelse, ikke omsetning
Reversert utbetaling	`payout_reversal`	Midler returnerer til Stripe-saldoen
Tilbakeholdt reservasjon	`connect_reserved_funds` / `risk_reserved_funds`	Restriktive midler, ikke en kostnad som standard
Innkreving av langvarig negativ saldo	`connect_collection_transfer`	Finansierings- eller inndekningshendelse som krever en risikopolicy

En advarsel angående terminologi: Det eldre balansetransaksjonsfeltet type bruker andre etiketter for de samme hendelsene, blant annet payment, application_fee og adjustment. Stripes dokumentasjon om balansetransaksjonstyper lister opp begge vokabularer. Ikke bland en type-verdi inn i en reporting_category-regel, og ikke finn opp en kategori som dispute_loss som ikke eksporteres av Stripe. Hvis en eksport inneholder en etikett du ikke gjenkjenner, behold den eksporterte verdien og verifiser den mot kildeobjektet.

Bokfør normal markedsplassaktivitet i hovedboken

For en plattform med destinasjonsbelastninger eller separate belastninger og overføringer, er de konseptuelle posteringene som følger.

Kundebelastning (kundepenger kommer inn på Stripe-avregningssaldoen):

Debet Stripe-avregningskonto       Brutto kundebelastning
    Kredit Kundefordringer        Brutto kundebelastning

Stripe-behandlingsgebyr:

Debet Stripe-gebyrkostnad         Stripe-gebyr
    Kredit Stripe-avregningskonto Stripe-gebyr

Ikke nettostill Stripe-gebyret mot omsetningen med mindre regnskapspraksisen din eksplisitt krever og støtter nettopresentasjon.

Plattformprovisjon (din omsetning, skåret ut fra det som ellers ville vært skyldig selgeren):

Debet Selgergjeld (leverandørgjeld/mellomværende) Provisjonsbeløp
    Kredit Provisjonsinntekt                     Provisjonsbeløp

Selgeroverføring (gjøre opp skyldige penger, ikke en kostnad):

Debet Selgergjeld                 Overføringsbeløp
    Kredit Stripe-avregningskonto Overføringsbeløp

En overføring er aldri automatisk en kostnad. Selgerens andel blir en gjeldspost i det belastningen lander, og overføringen gjør opp den gjelden. Nordlets bokføringsregler for avregning følger dette: platform_earning-rader posteres til provisjonsinntekt, mens transfer-rader reduserer selgergjelden. De dokumenterte standardbokføringsnøklene er settlements.commissionRevenue (standard 5001), settlements.sellerPayable (standard 4499), settlements.fees (standard 6800) og settlements.suspense (standard 4440), som hver kan overstyres per selskaps gjennom bokføringsreglene i Nordlet API-et.

Håndter refusjoner mot det opprinnelige salget, ikke som løse bankposter

En refusjon knytter seg til den opprinnelige belastningen eller fakturaen. Konseptuelt:

Debet Refusjoner / salgsreverseringer   Refusjonsbeløp
    Kredit Kundefordringer              Refusjonsbeløp

Den faktiske posteringen avhenger av om salget ble inntektsført, om mva. må reverseres, og om plattformens påslag (application fee) ble refundert. Én enkelt refusjon kan resultere i en fordringsreversering, en mva-reversering, en refusjon av påslaget, en overføringsreversering eller reduksjon i selgergjeld, samt en Stripe-gebyrkonsekvens som må kontrolleres fremfor å tas for gitt.

Tidsfellen: En refusjon blir ofte gjort opp i en senere utbetaling enn den opprinnelige belastningen. Foretrekk den spesifiserte utbetalingsavstemmingsrapporten fremfor en syntetisert refusjon fra en eksport på belastningsnivå. Nordlets dokumentasjon advarer eksplisitt om at en refusjon syntetisert fra en betalingseksport (Payments export) bare er en tilnærming når refusjonen gjøres opp på et senere tidspunkt. Avregningsimportøren kan innlemme refusjonsraden, matche den mot det opprinnelige salget og reversere fordringen når batchen bokføres.

Behandle innsigelser (disputes) separat fra refusjoner

En innsigelse er et krav fra kortholder eller utstedende bank, og Stripe kan belaste både det omstridte beløpet og et tvistebegyr før saken er avklart. For destinasjonsbelastninger og separate belastninger og overføringer belaster Stripe plattformsaldoen for begge deler, i henhold til deres veiledning for refusjoner og tvister. Plattformen kan forsøke innkreving ved å reversere selgeroverføringen.

Et tapt tvistemål, sett fra plattformens side:

Debet Tap på tilbakebetaling / gjenåpnet fordring   Omstridt beløp
Debet Kostnad for tvistebegyr                      Tvistebegyr
    Kredit Stripe-avregningskonto                  Kombinert beløp

Hvis selgeren bærer tapet og inndekning er bekreftet:

Debet Selgergjeld / inndekningskonto               Inndekningsbart beløp
    Kredit Innkreving fra tilbakebetaling          Inndekningsbart beløp

Ikke bokfør selgerinndekning bare fordi det ble bedt om en overføringsreversering. Verifiser at reverseringen ble opprettet, ble vellykket og vises i Stripe-saldoen. Hvis innsigelsen vinnes, returnerer Stripe det omstridte beløpet gjennom en dispute_reversal-rad; reverser tapet på tilbakebetalingen og håndter separat eventuelle tvistebegyr som Stripe ikke returnerer. Nordlet matcher tilbakebetalingsrader ved hjelp av charge_id fra en tidligere matchet belastning, fra den samme filen eller fra en tidligere import.

Et gjennomarbeidet avregningseksempel

Ta én automatisk utbetalingsbatch. Den spesifiserte rapporten inneholder:

En charge-rad: brutto 100,00, Stripe-gebyr 3,20, netto 96,80
En platform_earning-rad: 15,00, plattformens provisjon
En transfer-rad: 81,80 til den tilknyttede selgeren
En refund-rad fra et tidligere salg: brutto 20,00, som gjøres opp i denne batchen
En payout-rad: batch-totalen som flyttes til banken

Utbetalingssammensetningen, i tråd med Stripes avregningsidentitet:

Bruttobelastninger             100,00
- refusjoner                    20,00
- Stripe-gebyrer                 3,20
- overføringer                  81,80
= netto til plattformsaldo      -5,00

platform_earning-raden flytter ikke penger en gang til. Den angir de 15,00 som blir værende på plattformsaldoen når gebyret og selgeroverføringen er ute, slik at plattformen kan inntektsføre provisjonen i stedet for å utlede den.

Her overstiger selgeroverføringen pluss refusjonen netto belastningsaktivitet, slik at batchen ender på et lite minusbeløp og reduserer neste utbetaling eller trekker på saldoen. Det bokførte bilaget reverserer den refunderte fordringen, inntektsfører 15,00 i provisjon, bokfører 3,20 i gebyrkostnad, reduserer selgergjelden med overføringen og bokfører refusjonsreverseringen. Banklinjen matcher nettoen som når kontoen. Ikke ett eneste tall tilsvarer "omsetning", og det er hele poenget.

Importér og bokfør gjennom Nordlets avregningsendepunkt

For avstemming på utbetalingsnivå bruker du:

POST /v1/bank/settlements/import

med Stripe-leverandøren og den spesifiserte CSV-filen. Nordlet grupperer rader etter automatic_payout_id, gjør hver utbetaling om til en avregningsbatch med brutto-, gebyr- og nettosummer, hopper over re-import av en allerede bokført utbetaling, utelater payout-rader fra utbetalingssammensetningen, og automatcher belastnings-, refusjons- og tvisterader ved hjelp av ordre-, faktura-, PaymentIntent-, belastnings-, kilde- eller metadata-referanser. Stripe deler den spesifiserte rapporten inn i én fil per seksjon, så importer belastnings-, refusjons- og gebyrfilene samlet: rader som tilhører en utbetaling som allerede er importert, men som ennå ikke er bokført, flettes inn i den eksisterende batchen. Dette er en import- og bokføringsflyt drevet av filer og avregningsendepunkter, ikke en direktetilkoblet Stripe-integrasjon; funksjonssiden lister opp hva bank- og avregningssiden dekker.

Match i følgende rekkefølge: belastninger mot fakturaer, refusjoner mot opprinnelige belastninger, tvister mot opprinnelige belastninger, provisjonsrader mot provisjonsbehandling. Hold Stripe-gebyrer, justeringer, reservasjoner og utbetalingsrader unna fakturamatching. Nordlets ordliste for betalingsavstemming slår fast at gebyr- og justeringslinjer av design ikke kan matche mot fakturaer; rute uavklarte pengeposter til mellomværende (suspens). Manuell korrigering gjøres ved hjelp av bank/settlements/match { lineId, invoiceId }, med en null invoiceId for å oppheve matchingen.

Bokfør deretter én balansert batch:

POST /v1/bank/settlements/post

Dette oppretter én balansert hovedbokstransaksjon, avregner matchede fakturaer, debiterer bankkontoens hovedbokskonto for nettoutbetalingen, debiterer gebyrer, krediterer fordringer for belastninger, reverserer fordringer for refusjoner og tilbakebetalinger, deler umatchede markedsplassbelastninger mellom provisjonsinntekt og selgergjeld når commissionPercent oppgis, og sender uavklarte beløp til mellomværende. Enhver kategori systemet ikke gjenkjenner, havner også i mellomværende, og responsen nevner disse kategoriene i en advarsel i stedet for å svelge dem i stillhet.

Sjekkliste for avstemming

Kjør disse kontrollene før hver periodeslutt:

Ingen doble balance_transaction_id
Ingen doble (provider, payout_id)-avregningsbatcher
Summen av linjenes netto er lik batch-nettoen
Batch-nettoen er lik bankutbetalingen, med forbehold om tidsforskjell og valutapolicy
Enhver refusjon har en opprinnelig belastning eller et logget unntak
Enhver innsigelse har en tviste- eller belastningsreferanse
Enhver overføring har en ID for tilknyttet konto
Enhver platform_earning-rad har en definert provisjonsbehandling
Mellomværende (suspens) er null eller fullstendig gjennomgått, inkludert eventuelle ukjente kategorier som nevnes i bokføringsadvarselen
Selgergjeld er ikke negativ uten en godkjent forskudds- eller inndekningspolicy
Bokførte batcher kan ikke re-importeres eller ombokføres i stillhet
En utbetaling i en annen valuta enn selskapets funksjonelle valuta konverteres til kursen på utbetalingsdatoen, der differansen mot hver fakturas egen kurs bokføres som en realisert valutagevinst eller -tap; en utbetaling som blander valutaer avvises ved import

Avstem på tre nivåer: rad (hver transaksjon har bevart ID, kategori, beløp, valuta, kilde), utbetaling (spesifiserte nettoer er lik Stripe-utbetalingen og bankinnskuddet) og hovedbok (det bokførte bilaget balanserer og gir de tiltenkte posisjonene for omsetning, gebyr, fordring, selgergjeld og mellomværende). For selgersaldoer spesifiserer du at inngående selgergjeld pluss ny selgerandel, minus overføringer og gyldige reverseringer, er lik utgående selgergjeld.

Den gjentakende feilen i enhver markedsplasshovedbok er den samme som den startet med: å slå sammen en strukturert utbetaling til ett eneste tall. Hold komponentene adskilt, forankre hver enkelt til en stabil Stripe-identifikator, og la mellomværendet holde på det du ikke kan forklare ennå. En ren periodeslutt er det en revisor vil stole på.

FAQ

Er Stripe-utbetalingen plattformens omsetning?

Nei. Utbetalingen er nettoen av belastninger, refusjoner, behandlingsgebyrer, selgeroverføringer, tvister og justeringer som tilfeldigvis ble gjort opp i samme batch. Å bokføre den som én inntektslinje sletter selgergjelden og behandlingskostnaden som ligger inni den. For en agentmarkedsplass er omsetningen provisjonen, noe platform_earning-radene identifiserer.

Hvilken Stripe-rapport bør jeg avstemme mot?

Rapporten for utbetalingsavstemming, spesifisert (Payout reconciliation, itemized), fordi den gir én rad per balansetransaksjon med en reporting_category, en automatic_payout_id og brutto-, gebyr- og nettobeløp. Et utbetalingssammendrag fra dashbordet beviser bare batch-totalen. Der automatiske utbetalinger ikke er aktivert, bruker du balanserapporten i stedet.

Skal en overføring til en selger bokføres som en kostnad?

Nei. Selgerens andel blir en gjeldspost i det kundebelastningen lander, og overføringen gjør opp den gjelden. Å bokføre overføringer som kostnad dobbeltteller kostnaden og etterlater selgergjelden permanent overdrevet.

Hva skjer med en Stripe-rad hvis kategori importøren ikke gjenkjenner?

Den posteres til avregningskontoen for mellomværende, som standard 4440, og bokføringsresponsen returnerer en advarsel som nevner kategoriene som havnet der. Reservasjoner og uvanlige justeringer havner vanligvis på denne måten, og det er med overlegg: pengene forblir synlige og hovedboken forblir i balanse til noen avgjør hvor de hører hjemme.

Hvordan håndteres refusjoner som gjøres opp i en senere utbetaling?

De kommer som en refund-rad i den senere utbetalingens spesifiserte rapport og matches tilbake til den opprinnelige belastningen gjennom charge_id fra den tidligere matchede belastningen. En refusjon syntetisert fra en betalingseksport på belastningsnivå er bare en tilnærming i dette tilfellet, så den spesifiserte rapporten er den tryggere kilden.