Stripe Connect Marketplace Accounting Workflow

Q: Hur hanteras återbetalningar som regleras i en senare utbetalning?

De anländer som en refund-rad i den senare utbetalningens specificerade rapport och matchas tillbaka mot den ursprungliga debiteringen via chargeid för den tidigare matchade debiteringen. En återbetalning som sammanställts från en betalningsexport på debiteringsnivå är i det här fallet bara en uppskattning, så den specificerade rapporten är den säkrare källan.

En praktisk guide till hur du bokför debiteringar, avgifter, överföringar, återbetalningar, tvister och reserver i en marknadshuvudbok som går att stämma av utan problem.

De flesta bokföringsproblem på marknadsplatser spåras tillbaka till ett enda misstag: att behandla utbetalningen från Stripe som om den vore intäkt. Utbetalningen är nettosumman av dussintals separata ekonomiska händelser, och att bokföra den som en enda intäktspost suddar ut plattformens provision, säljarens skuld samt alla avgifter och tvister som döljer sig inuti den. Ett korrekt arbetsflöde bryter ner utbetalningen innan något över huvud taget når huvudboken.

Den här guiden visar hur varje balanspostkategori (balance-transaction category) i Stripe Connect hamnar på sin rätta bokföringsmässiga plats: kundfordringar, provisionsintäkter, säljarskulder, betalningsomkostnader och interimskonton. Den använder Nordlets dokumenterade import- och avstämningsslutpunkter som bokföringsmekanism, innehåller ett genomarbetat exempel på en avstämning och avslutas med en avstämningschecklista som du kan köra före varje bokslut.

Identifiera Connect-debiteringsmodellen innan du utformar något

Det går inte att skriva bokföringsregler förrän du vet vilken debiteringsmodell varje betalningsflöde använder. Modellen avgör vars Stripe-saldo som belastas av debiteringen, vem som bär avgifterna och var återbetalningar och tvister slår in först.

Connect-modell	Debitering skapad hos	Bär Stripe-avgifter	Återbetalningar/tvister minskar	Bokföringsmässig konsekvens
Direktdebiteringar (Direct charges)	Anslutet konto	Konfigurerbart per part	Det anslutna kontots saldo	Plattformen bokför sin plattformsavgift som intäkt; säljarens betalningsaktivitet finns till största delen på det anslutna kontots huvudbok
Destinationsdebiteringar (Destination charges)	Plattformen, med omedelbar överföring till ett anslutet konto	Plattformen	Plattformen	Plattformen bokför kundfordran och Stripe-avgift; säljarens andel är en skuld, inte en intäkt
Separata debiteringar och överföringar (Separate charges and transfers)	Plattformdebitering, därefter en eller flera separata överföringar	Plattformen	Plattformen	Debitering och säljaröverföringar är separata händelser; säljarskulden spåras oberoende av kunddebiteringen

Stripes egen vägledning om hur debiteringar fungerar i en Connect-integration bekräftar att vid destinationsdebiteringar samt separata debiteringar och överföringar bär plattformssaldot betalningsavgifter, återbetalningar och återbetalningskrav (chargebacks). Vid direktdebiteringar tar det anslutna kontot emot debiteringen, och avgifter kan debiteras endera parten.

Den praktiska regeln lyder: påstå inte att "Stripe-utbetalningen är säljarens intäkt" eller att "säljaren betalar avgifterna" förrän du har skrivit ner debiteringsmodellen för varje enskilt flöde. Lagra den modellen tillsammans med varje transaktion. Att blanda direkt- och destinationsdebiteringar under en och samma bokföringsregel är det snabbaste sättet att missvisa både intäkter och skulder.

Den här guiden förutsätter destinationsdebiteringar eller separata debiteringar och överföringar, eftersom det är där plattformssaldot bär den bokföringsmässiga tyngden och där de flesta marknadshuvudböcker byggs.

Måla upp flödet av medel innan du importerar en enda rad

Innan du rör vid en import bör du rita upp en transaktionskarta på en sida för varje flöde:

Kundbetalning
  -> Stripe-debitering / betalningsbalanstransaktion
  -> Stripe-avgift
  -> plattformsavgift (provision)
  -> överföring till anslutet konto
  -> återbetalning eller tvist (om tillämpligt)
  -> Stripe-utbetalning
  -> bankinsättning

Varje pil är en distinkt balanstransaktion med eget ID, egen kategori, eget belopp och egna datum. Behandla Stripe-saldot som ett bankliknande clearingkonto: debiteringar flyter in, avgifter och överföringar flyter ut, och utbetalningen flyttar resten till den riktiga banken. Nordlets dokumentation för bank- och betalningsimport rekommenderar exakt denna hantering för vanlig Stripe-aktivitet.

Välj rätt källrapport från Stripe

För automatiska utbetalningsomgångar (settlement batches) bör du använda Stripes rapport för Utbetalningsavstämning, specificerad (Payout reconciliation, itemized). Den ger en rad per balanstransaktion, grupperar rader efter reporting_category, kopplar var och en till ett automatic_payout_id och tillhandahåller summor för bruttobelopp, avgifter och nettobelopp. Stripes guide för val av rapport dokumenterar denna rapport och bekräftar att charge_id, connected_account_id och destination_payment_id är tillgängliga Connect-fält.

Där automatiska utbetalningar inte är aktiverade (vissa arrangemang med manuella utbetalningar) ska du i stället använda saldorapporten (Balance report). Betrakta inte en sammanställning av utbetalningar i kontrollpanelen (Dashboard) som tillräckligt underlag för bokföring. Sammanställningen bevisar batchtotalen; enbart den specificerade rapporten förklarar beståndsdelarna.

Stripe rekommenderar att man klassificerar efter reporting_category i stället för det äldre fältet type, och varje rad har ett source-ID som kopplas till det underliggande objektet. Observera tidsbegränsningen: Stripe anger att dagliga rapportdata normalt är tillgängliga vid middagstid dagen därpå, och omedelbara utbetalningar (instant payouts) kan inte snyggt tilldelas enskilda transaktioner, vilket innebär att de kräver separat transaktionshistorikavstämning.

Klassificera varje balanstransaktion efter kategori

Använd reporting_category som primär klassificerare och inspektera därefter source_id, charge_id och beskrivningar. Den mappning som spelar roll är följande:

Stripe-aktivitet	Rapporteringskategori (Reporting category)	Bokföringstolkning
Kunddebitering, kort eller lokal betalningsmetod	`charge`	Kundfinansierad kundfordran eller försäljningsavstämning
Återbetalning	`refund`	Återföring av den ursprungliga kundbetalningen
Behandlingsavgift som innehålls av Stripe	`fee`	Kostnad för betalningshantering
Plattformsavgift	`platform_earning`	Provisionsintäkt
Återbetalad plattformsavgift	`platform_earning_refund`	Minskning av provisionsintäkt
Overföring till anslutet konto	`transfer`	Minskning av säljarskuld
Återförd överföring	`transfer_reversal`	Återvinning från det anslutna kontot
Återbetalningskrav (Chargeback)	`dispute`	Förlust till följd av chargeback; inspektera det ursprungliga tvistobjektet
Tvist vunnen eller återförd	`dispute_reversal`	Återvinning av en tidigare bokförd chargeback
Utbetalning till bank	`payout`	Bankrörelse, inte intäkt
Återförd utbetalning	`payout_reversal`	Medel som återgår till Stripe-saldot
Kvarhållen reserv	`connect_reserved_funds` / `risk_reserved_funds`	Spärrade medel, inte en kostnad som standard
Indrivning av långvarigt negativt saldo	`connect_collection_transfer`	Finansierings- eller återvinningshändelse som kräver en riskpolicy

En varning när det gäller terminologi: det äldre balanstransaktionsfältet type använder andra etiketter för samma händelser, bland annat payment, application_fee och adjustment. Stripes dokumentation om balanstransaktionstyper listar båda vokabulärerna. Blanda inte ett type-värde med en regel för reporting_category, och hitta inte på en kategori som dispute_loss som Stripe inte exporterar. Om en export innehåller en etikett som du inte känner igen ska du behålla det exporterade värdet och verifiera det mot källobjektet.

Bokför normal marknadsplatsaktivitet i huvudboken

För en plattform med destinationsdebiteringar eller separata debiteringar och överföringar ser de konceptuella verifikationerna ut på följande sätt.

Kunddebitering (kundens pengar kommer in på Stripes clearingkonto):

Debet  Stripe clearingkonto    Bruttokreditering för kund
    Kredit Kundfordringar      Bruttokreditering för kund

Stripe-behandlingsavgift:

Debet  Avgiftskostnad Stripe   Stripe-avgift
    Kredit Stripe clearingkonto    Stripe-avgift

Nettobokför inte Stripe-avgiften mot intäkten såvida inte din bokföringspolicy uttryckligen kräver och stöder nettopresentation.

Plattformsprovision (din intäkt, som bryts ut ur det som annars skulle ha betalats ut till säljaren):

Debet  Säljarskuld             Provisionsbelopp
    Kredit Provisionsintäkt    Provisionsbelopp

Säljarsöverföring (reglering av skuld, inte en kostnad):

Debet  Säljarskuld             Överföringsbelopp
    Kredit Stripe clearingkonto    Överföringsbelopp

En överföring är aldrig automatiskt en kostnad. Säljarens andel blir en skuld i samma ögonblick som debiteringen landar, och överföringen reglerar den skulden. Nordlets regler för avstämningsbokföring följer detta: rader med platform_earning bokförs mot provisionsintäkter medan rader med transfer minskar säljarskulden. De dokumenterade standardnycklarna för bokföring är settlements.commissionRevenue (standard 5001), settlements.sellerPayable (standard 4499), settlements.fees (standard 6800) och settlements.suspense (standard 4440), där var och en kan åsidosättas per bolag via bokföringsreglerna i Nordlet API.

Hantera återbetalningar mot den ursprungliga försäljningen, inte som lösa bankposter

En återbetalning kopplas till den ursprungliga debiteringen eller fakturan. Konceptuellt:

Debet  Återbetalningar / försäljningsreturer    Återbetalningsbelopp
    Kredit Kundfordringar                     Återbetalningsbelopp

Den faktiska verifikationen beror på om försäljningen har intäktsförts, om skatt måste återföras och om en plattformsavgift har återbetalats. En enda återbetalning kan ge upphov till en återförd fordran, en skatteåterföring, en återbetalning av plattformsavgift, en återförd överföring eller minskad säljarskuld samt en Stripe-avgiftskonsekvens som måste kontrolleras i stället för att antas.

Tidsfällan: en återbetalning regleras ofta i en senare utbetalning än den ursprungliga debiteringen. Föredra den specificerade utbetalningsavstämningsrapporten framför en syntetiserad återbetalning från en export på debiteringsnivå. Nordlets dokumentation varnar uttryckligen för att en återbetalning som sammanställts från en betalningsexport (Payments export) endast är en uppskattning när återbetalningen regleras senare. Avstämningsimportören kan läsa in återbetalningsraden, matcha den mot den ursprungliga försäljningen och återföra fordran när batchen bokförs.

Behandla tvister separat från återbetalningar

En tvist är ett anspråk från kortinnehavaren eller utgivande bank, och Stripe kan debitera både det omtvistade beloppet och en tvistavgift innan ärendet är löst. För destinationsdebiteringar samt separata debiteringar och överföringar debiterar Stripe plattformssaldot för båda, i enlighet med riktlinjerna för återbetalningar och tvister. Plattformen kan försöka återvinna medlen genom att återföra säljarsöverföringen.

En förlorad tvist, ur plattformens perspektiv:

Debet  Förlust vid chargeback / återöppnad fordran    Omtvistat belopp
Debet  Kostnad för tvistavgift                         Tvistavgift
    Kredit Stripe clearingkonto                        Kombinerat belopp

Om säljaren bär förlusten och återvinning har bekräftats:

Debet  Säljarskuld / återvinningskonto                 Återvinningsbart belopp
    Kredit Återvinning av chargeback                   Återvinningsbart belopp

Bokför inte säljaråtervinning enbart för att en återföring av en överföring har begärts. Verifiera att återföringen skapades, lyckades och syns i Stripe-saldot. Om tvisten vinns betalar Stripe tillbaka det omtvistade beloppet via en dispute_reversal-rad; återför chargeback-förlusten och hantera eventuell tvistavgift som Stripe inte betalar tillbaka separat. Nordlet matchar chargeback-rader med hjälp av charge_id för en tidigare matchad debitering, från samma fil eller från en tidigare import.

Ett genomarbetat exempel på en avstämning

Ta en automatisk utbetalningsbatch. Den specificerade rapporten innehåller:

En charge-rad: bruttobelopp 100.00, Stripe-avgift 3.20, nettobelopp 96.80
En platform_earning-rad: 15.00, plattformens provision
En transfer-rad: 81.80 till den anslutna säljaren
En refund-rad från en tidigare försäljning: bruttobelopp 20.00, som regleras i denna batch
En payout-rad: batchtotalen som flyttas till banken

Utbetalningens sammansättning, enligt Stripes avstämningsidentitet:

Bruttodebiteringar             100.00
- återbetalningar               20.00
- Stripe-avgifter                3.20
- överföringar                  81.80
= netto till plattformssaldo    -5.00

Raden platform_earning flyttar inte pengar en gång till. Den anger de 15.00 som stannar kvar på plattformssaldot när avgiften och säljarsöverföringen har dragits av, så att plattformen kan redovisa provisionsintäkter i stället för att behöva härleda dem.

Här överstiger säljarsöverföringen plus återbetalningen nettot av debiteringsaktiviteten, vilket gör att batchen landar på ett litet minus och antingen minskar nästa utbetalning eller drar från saldot. Den bokförda verifikationen återför den återbetalda kundfordran, redovisar 15.00 i provisionsintäkt, bokför 3.20 i avgiftskostnad, minskar säljarskulden med överföringen samt bokför återbetalningsreturen. Bankraden matchar det nettobelopp som når kontot. Ingen enskild siffra är lika med "intäkt", vilket också är poängen.

Importera och bokför via Nordlets avstämningsslutpunkt

För avstämning på utbetalningsnivå använder du:

POST /v1/bank/settlements/import

med Stripe som leverantör och den specificerade CSV-filen. Nordlet grupperar rader efter automatic_payout_id, förvandlar varje utbetalning till en avstämningsbatch med bruttosumman, avgifter och nettosumma, hoppar över omimportering av en redan bokförd utbetalning, hoppar över payout-rader från utbetalningssammansättningen samt matchar automatiskt rader för debiteringar, återbetalningar och tvister med hjälp av referenser till ordrar, fakturor, PaymentIntent, debiteringar, källor eller metadata. Stripe delar upp den specificerade rapporten i en fil per avsnitt, så importera filerna för debiteringar, återbetalningar och avgifter tillsammans: rader som hör till en utbetalning som redan har importerats men ännu inte bokförts slås samman med den befintliga batchen. Detta är ett arbetsflöde för import och bokföring som styrs av filer och avstämningsslutpunkter, inte en direkt Stripe-anslutning; funktionssidan listar vad bank- och avstämningsdelen täcker.

Matcha i följande ordning: debiteringar mot fakturor, återbetalningar mot ursprungliga debiteringar, tvister mot ursprungliga debiteringar, provisionsrader mot provisionshantering. Håll Stripe-avgifter, justeringar, reserver och utbetalningsrader utanför fakturamatchningen. Nordlets ordlista för betalningsavstämning anger att avgifts- och justeringsrader av design inte går att matcha mot fakturor; skicka olösta poster som innehåller pengar till interimsredovisning (suspense). Manuell korrigering görs med bank/settlements/match { lineId, invoiceId }, där ett null-värde för invoiceId tar bort matchningen.

Bokför därefter en balanserad batch:

POST /v1/bank/settlements/post

Detta skapar en balanserad verifikation, reglerar matchade fakturor, debiterar bankkontots huvudbokskonto för nettoutbetalningen, debiteras avgifter, krediterar kundfordringar för debiteringar, återför kundfordringar för återbetalningar och chargebacks, delar upp omatchade marknadsplatsdebiteringar mellan provisionsintäkter och säljarskulder när commissionPercent tillhandahålls, samt skickar oklara belopp till interimsredovisning. Alla kategorier som systemet inte känner igen hamnar också på interimsredovisningen, och svaret anger dessa kategorier i en varningsflagga i stället för att svälja dem tyst.

Avstämningschecklista

Kör igenom dessa kontroller före varje bokslut:

Inga dubbla balance_transaction_id
Ingen dubbel (provider, payout_id) i avstämningsbatchen
Summan av radernas net-belopp är lika med batchandelsnettot
Batchnettot är lika med bankutbetalningen, med reservation för tidsförskjutning och valutapolicy
Varje återbetalning har en ursprunglig debitering eller ett loggat undantag
Varje tvist har en tvist- eller debiteringsreferens
Varje överföring har ett ID för ett anslutet konto
Varje platform_earning-rad har en definierad provisionshantering
Interimsredovisningen är nollställd eller fullständigt genomgången, inklusive eventuella okända kategorier som nämns i bokföringsvarningen
Säljarskulden är inte negativ utan en godkänd förskotts- eller återvinningspolicy
Bokförda batcher kan inte importeras om eller bokföras på nytt i tysthet
En utbetalning i en annan valuta än företagets basvaluta omräknas till växelkursen på utbetalningsdagen, där differensen mot varje fakturas egen kurs bokförs som en realiserad valutakursvinst eller förlust; en utbetalning som blandar valutor avvisas vid importen

Stäm av på tre nivåer: radnivå (varje transaktion har ett bevarat ID, kategori, belopp, valuta, källa), utbetalningsnivå (specificerade netton är lika med Stripe-utbetalningen och bankinsättningen) och huvudboksnivå (den bokförda verifikationen balanserar och skapar avsedda positioner för intäkter, avgifter, kundfordringar, säljarskulder och interimsredovisning). För säljarsaldon specifikt bör du verifiera att ingående säljarskuld plus nya säljarandelar, minus överföringar och giltiga återföringar, är lika med utgående säljarskuld.

Det återkommande problemet i alla marknadshuvudböcker är detsamma som det började med: att komprimera en strukturerad utbetalning till en enda siffra. Håll isär komponenterna, förankra var och en i ett stabilt Stripe-identifieringsnummer och låt interimsredovisningen fånga upp allt du ännu inte kan förklara. Ett rent bokslut är det som en revisor kommer att lita på.

FAQ

Är Stripe-utbetalningen plattformens intäkt?

Nej. Utbetalningen är nettot av debiteringar, återbetalningar, betalningsavgifter, säljarsöverföringar, tvister och justeringar som råkade regleras i samma batch. Att bokföra den som en enda intäktspost raderar säljarskulden och betalningskostnaden som finns inuti den. För en förmedlande marknadsplats är intäkten den provision som raderna med platform_earning identifierar.

Vilken Stripe-rapport bör jag stämma av mot?

Rapporten för utbetalningsavstämning, specificerad (Payout reconciliation, itemized), eftersom den ger en rad per balanstransaktion med en reporting_category, ett automatic_payout_id samt bruttobelopp, avgifter och nettobelopp. En utbetalningssammanställning i kontrollpanelen (Dashboard) bevisar enbart batchtotalen. Om automatiska utbetalningar inte är aktiverade ska du i stället använda saldorapporten.

Ska en överföring till en säljare bokföras som en kostnad?

Nej. Säljarens andel blir en skuld i samma sekund som kunddebiteringen landar, och överföringen reglerar den skulden. Att bokföra överföringar som kostnad dubbelräknar utgiften och lämnar säljarskulden permanent överställd.

Vad händer med en Stripe-rad vars kategori importören inte känner igen?

Den bokförs på avstämningskontot för interimsredovisning, standard 4440, och bokföringssvaret returnerar en varning som namnger de kategorier som hamnade där. Reserver och ovanliga justeringar landar vanligtvis på det här sättet, vilket är medvetet: pengarna förblir synliga och verifikationen förblir balanserad tills någon bestämmer var de hör hemma.

Hur hanteras återbetalningar som regleras i en senare utbetalning?

De anländer som en refund-rad i den senare utbetalningens specificerade rapport och matchas tillbaka mot den ursprungliga debiteringen via charge_id för den tidigare matchade debiteringen. En återbetalning som sammanställts från en betalningsexport på debiteringsnivå är i det här fallet bara en uppskattning, så den specificerade rapporten är den säkrare källan.