Stripe Connect-regnskabsworkflow for markedspladser

Q: Hvilken Stripe-rapport skal jeg afstemme imod?

Rapporten Payout reconciliation, itemized (specificeret udbetalingsafstemning), fordi den giver én række pr. balancetransaktion med en reportingcategory, et automaticpayoutid og brutto-, gebyr- og nettobeløb. Et udbetalings-overblik fra kontrolpanelet (Dashboard) beviser kun batch-totalen. Hvor automatiske udbetalinger ikke er aktiveret, skal du bruge balancerapporten i stedet.

Q: Hvad sker der med en Stripe-række, hvis kategori importøren ikke genkender?

Den bogføres på afregnings-suspense-kontoen (standard 4440), og bogføringssvaret returnerer en advarsel, der navngiver de kategorier, der landede der. Reserver og usædvanlige reguleringer lander typisk på denne måde, hvilket er tilsigtet: pengene forbliver synlige, og kassebilaget forbliver i balance, indtil nogen beslutter, hvor de hører hjemme.

Q: Hvordan håndteres tilbagebetalinger, der afregnes i en senere udbetaling?

De ankommer som en refund-række i den senere udbetalings specificerede rapport og matches tilbage til den oprindelige betaling via chargeid for den tidligere matchede betaling. En tilbagebetaling syntetiseret fra en betalingsekport på betalingsniveau er i dette tilfælde kun en tilnærmelse, hvorfor den specificerede rapport er den sikrere kilde.

En praktisk guide til bogføring af betalinger, gebyrer, overførsler, tilbagebetalinger, indsigelser og reserver i en markedspladshovedbog, der stemmer rent af.

De fleste regnskabsproblemer på markedspladser kan spores tilbage til en enkelt fejl: at behandle Stripe-bankudbetalingen, som om den var omsætning. Udbetalingen er nettoresten af dusinvis af separate økonomiske hændelser, og hvis den bogføres som en enkelt indtægtslinje, sletter man platformens provision, sælgerens gældsforpligtelse samt alle de gebyrer og indsigelser, der er skjult indeni. Et korrekt workflow nedbryder udbetalingen, før noget som helst rammer hovedbogen.

Denne guide sporer hver enkelt Stripe Connect-balancetransaktionskategori til dens rette regnskabsmæssige plads: tilgodehavender, provisionsindtægter, sælgerforpligtelser, transaktionsomkostninger og uspecificerede midler (suspense). Den bruger Nordlets dokumenterede import- og afregningsslutpunkter som bogføringsmetode, indeholder et gennemarbejdet afregningseksempel og afsluttes med en afstemningstjekliste, som du kan køre før hver periodelukning.

Identificer Connect-betalingsmodellen, før du designer noget

Regnskabsregler kan ikke udarbejdes, før du ved, hvilken betalingsmodel hvert betalingsflow bruger. Modellen bestemmer, hvis Stripe-saldo der bærer betalingen, hvem der betaler gebyrerne, og hvor tilbagebetalinger og indsigelser rammer først.

Connect-model	Betaling oprettet hos	Bærer Stripe-gebyrer	Tilbagebetalinger/indsigelser reducerer	Regnskabsmæssig konsekvens
Direkte betalinger (Direct charges)	Tilknyttet konto	Kan konfigureres pr. part	Den tilknyttede kontos saldo	Platformen bogfører sit applikationsgebyr som omsætning; sælgerens betalingsaktivitet findes primært på den tilknyttede kontos hovedbog
Destinationsbetalinger (Destination charges)	Platformen, med øjeblikkelig overførsel til én tilknyttet konto	Platformen	Platformen	Platformen bogfører kundens tilgodehavende og Stripe-gebyret; sælgerens andel er en gældsforpligtelse, ikke omsætning
Separate betalinger og overførsler (Separate charges and transfers)	Platformbetaling, derefter en eller flere separate overførsler	Platformen	Platformen	Betaling og sælgeroverførsler er separate hændelser; sælgergæld følges uafhængigt af kundebetalingen

Stripes egen vejledning om hvordan betalinger fungerer i en Connect-integration bekræfter, at for destinationsbetalinger og separate betalinger og overførsler bærer platformsaldoen betalingsgebyrer, tilbagebetalinger og chargebacks. For direkte betalinger modtager den tilknyttede konto betalingen, og gebyrer kan trækkes fra begge parter.

Den praktiske regel: Sig ikke, at "Stripe-udbetalingen er sælgeromsætning", eller at "sælgeren betaler gebyrerne", før du har skrevet betalingsmodellen ned for hvert enkelt flow. Gem denne model sammen med hver enkelt transaktion. At blande direkte betalinger og destinationsbetalinger under én bogføringsregel er den hurtigste måde at fejlangive både omsætning og gæld på.

Denne guide forudsætter destinationsbetalinger eller separate betalinger og overførsler, fordi det er her, platformsaldoen bærer den regnskabsmæssige vægt, og hvor de fleste markedspladeshovedbøger opbygges.

Kortlæg pengestrømmen, før du importerer en eneste række

Før du rører ved en import, skal du tegne et et-sides transaktionskort for hvert flow:

Kundebetaling
  -> Stripe-betaling / balancetransaktion
  -> Stripe-gebyr
  -> platformens applikationsgebyr (provision)
  -> overførsel til tilknyttet konto
  -> tilbagebetaling eller indsigelse (hvis relevant)
  -> Stripe-udbetaling
  -> bankindbetaling

Hver pil er en særskilt balancetransaktion med sit eget ID, sin egen kategori, sit eget beløb og sine egne datoer. Behandl Stripe-saldoen som en banklignende afregningskonto: Betalinger flyder ind, gebyrer og overførsler flyder ud, og udbetalingen flytter resten til den rigtige bank. Nordlets dokumentation for bank- og betalingsimport anbefaler præcist denne behandling af almindelig Stripe-aktivitet.

Vælg den rette Stripe-kilderapport

Til automatiske udbetalings-afregningsbatcher skal du bruge Stripes Payout reconciliation, itemized-rapport (specificeret udbetalingsafstemning). Den giver én række pr. balancetransaktion, grupperer rækker efter reporting_category, knytter hver enkelt til et automatic_payout_id og giver brutto-, gebyr- og nettototaler. Stripes guide til valg af rapporter dokumenterer denne rapport og bekræfter charge_id, connected_account_id og destination_payment_id som tilgængelige Connect-felter.

Hvor automatiske udbetalinger ikke er aktiveret (visse arrangementer med manuel udbetaling), skal du i stedet bruge balancerapporten (Balance report). Betragt ikke et overblik over udbetalinger i kontrolpanelet (Dashboard) som tilstrækkeligt bevis for bogføring. Overblikket beviser batch-totalen, men kun den specificerede rapport forklarer komponenterne.

Stripe anbefaler at klassificere efter reporting_category i stedet for det ældre type-felt, og hver række bærer et source-ID, der knytter sig til det underliggende objekt. Bemærk tidsbegrænsningen: Stripe oplyser, at daglige rapportdata normalt er tilgængelige klokken 12 middag den følgende dag, og øjeblikkelige udbetalinger kan ikke tildeles rent til individuelle transaktioner, hvorfor de kræver separat transaktionshistorikaftemning.

Klassificer enhver balancetransaktion efter kategori

Brug reporting_category som den primære klassificering, og inspicer derefter source_id, charge_id og beskrivelser. Den afgørende kortlægning:

Stripe-aktivitet	Rapporteringskategori (`reporting_category`)	Regnskabsmæssig fortolkning
Kundebetaling, kort eller lokal betalingsmetode	`charge`	Kundefinansieret tilgodehavende eller salgsafregning
Tilbagebetaling	`refund`	Tilbageførsel af den oprindelige kundebetaling
Behandlingsgebyr tilbageholdt af Stripe	`fee`	Betalingsbehandlingsomkostning
Platformens applikationsgebyr	`platform_earning`	Provisionsindtægt
Tilbagebetalt applikationsgebyr	`platform_earning_refund`	Reduktion af provisionsindtægt
Overførsel til tilknyttet konto	`transfer`	Reduktion af sælgerforpligtelse
Tilbageført overførsel	`transfer_reversal`	Gendannelse fra den tilknyttede konto
Chargeback (indsigelse)	`dispute`	Chargeback-tab; inspicer kildeindsigelsesobjektet
Chargeback vundet eller tilbageført	`dispute_reversal`	Gendannelse af et tidligere bogført chargeback-tab
Udbetaling til bank	`payout`	Bankbevægelse, ikke omsætning
Tilbageført udbetaling	`payout_reversal`	Midler returneres til Stripe-saldoen
Tilbageholdt reserve	`connect_reserved_funds` / `risk_reserved_funds`	Restriktive midler, som som udgangspunkt ikke er en omkostning
Inddriver længe værende negativ saldo	`connect_collection_transfer`	Finansierings- eller genindvindingshændelse, der kræver en risikopolitik

En terminologisk advarsel: Det ældre type-felt for balancetransaktioner bruger andre etiketter for de samme hændelser, herunder payment, application_fee og adjustment. Stripes dokumentation for balancetransaktionstyper viser begge vokabularer. Bland ikke en type-værdi sammen med en reporting_category-regel, og opfind ikke en kategori som dispute_loss, som Stripe ikke eksporterer. Hvis en eksport indeholder en etiket, du ikke genkender, skal du bevare den eksporterede værdi og verificere den mod kildeobjektet.

Bogfør normal markedspladsaktivitet i hovedbogen

For en platform på destinationsbetalinger eller separate betalinger og overførsler ser de konceptuelle posteringer således ud:

Kundebetaling (kundens penge kommer ind på Stripe-clearing-saldoen):

Db Stripe-clearing       Bruttokundebetaling
    Kr Varesalg / tilgodehavender   Bruttokundebetaling

Stripe-behandlingsgebyr:

Db Stripe-gebyromkostninger      Stripe-gebyr
    Kr Stripe-clearing           Stripe-gebyr

Modregn ikke Stripe-gebyret i omsætningen, medmindre din regnskabspolitik udtrykkeligt kræver og understøtter nettorepraesentation.

Platformprovision (din indtægt, udskilt fra det, der ellers ville skyldes sælgeren):

Db Sælgergæld                    Provisionsbeløb
    Kr Provisionsindtægter       Provisionsbeløb

Sælgeroverførsel (afregning af skyldige penge, ikke en omkostning):

Db Sælgergæld                    Overførselsbeløb
    Kr Stripe-clearing           Overførselsbeløb

En overførsel er aldrig automatisk en omkostning. Sælgerens andel bliver en gældsforpligtelse, når betalingen lander, og overførslen indfrier denne gældsforpligtelse. Nordlets regler for afregningsbogføring følger dette: platform_earning-rækker bogføres som provisionsindtægter, mens transfer-rækker reducerer sælgergælden. De dokumenterede standard-bogføringsnøgler er settlements.commissionRevenue (standard 5001), settlements.sellerPayable (standard 4499), settlements.fees (standard 6800) og settlements.suspense (standard 4440), som hver især kan tilsidesættes pr. virksomhed via bogføringsreglerne i Nordlet API'et.

Håndter tilbagebetalinger i forhold til det oprindelige salg, ikke som løse bankposter

En tilbagebetaling knytter sig til den oprindelige betaling eller faktura. Konceptuelt:

Db Tilbagebetalinger / salgsretur   Tilbagebetalingsbeløb
    Kr Tilgodehavender              Tilbagebetalingsbeløb

Den faktiske postering afhænger af, om salget var indregnet, om momsen skal tilbageføres, og om et applikationsgebyr til platformen blev tilbagebetalt. En enkelt tilbagebetaling kan føre til tilbageførsel af et tilgodehavende, en momstilbageførsel, en tilbagebetaling af applikationsgebyret, en overførsels-tilbageførsel eller reduktion af sælgergæld samt en Stripe-gebyrkonsekvens, der skal kontrolleres frem for antages.

Tidsfælden: En tilbagebetaling afregnes ofte i en senere udbetaling end den oprindelige betaling. Foretræk den specificerede udbetalingsafstemningsrapport frem for en syntetisk tilbagebetaling fra en eksport på betalingsniveau. Nordlets dokumentation advarer udtrykkeligt om, at en tilbagebetaling syntetiseret fra en betalingsekport kun er en tilnærmelse, når tilbagebetalingen afregnes senere. Afregningsimportøren kan indlæse tilbagebetalingsrækken, matche den med det oprindelige salg og tilbageføre tilgodehavendet, når batch-filen bogføres.

Behandle indsigelser (disputes) separat fra tilbagebetalinger

En indsigelse (chargeback) er et krav fra kortholderen eller den udstedende bank, og Stripe kan debitere både det omstridte beløb og et indsigelsesgebyr før afslutningen. For destinationsbetalinger og separate betalinger og overførsler debiterer Stripe platformsaldoen for begge dele i henhold til sin vejledning om tilbagebetalinger og indsigelser. Platformen kan forsøge at inddrive beløbet ved at tilbageføre sælgeroverførslen.

Et tabt indsigelsessag fra platformens side:

Db Chargeback-tab / genåbnet tilgodehavende   Omstridt beløb
Db Indsigelsesgebyromkostninger              Indsigelsesgebyr
    Kr Stripe-clearing                       Samlet beløb

Hvis sælgeren bærer tabet, og genindvinding er bekræftet:

Db Sælgergæld / inddrivelseskonto            Indvindingsbart beløb
    Kr Chargeback-inddrivelse                Indvindingsbart beløb

Bogfør ikke sælgerinddrivelse blot fordi der er anmodet om en overførsels-tilbageførsel. Verificer, at tilbageføringen blev oprettet, lykkedes og fremgår af Stripe-saldoen. Hvis indsigelsen vundes, returnerer Stripe det omstridte beløb via en dispute_reversal-række; tilbagefør chargeback-tabet, og håndter separat eventuelle indsigelsesgebyrer, som Stripe ikke returnerer. Nordlet matcher chargeback-rækker ved hjælp af charge_id for en tidligere matchet betaling fra den samme fil eller fra en tidligere import.

Et gennemarbejdet afregningseksempel

Tag en enkelt automatisk udbetalingsbatch. Den specificerede rapport indeholder:

En charge-række: brutto 100,00, Stripe-gebyr 3,20, netto 96,80
En platform_earning-række: 15,00, platformens provision
En transfer-række: 81,80 til den tilknyttede sælger
En refund-række fra et tidligere salg: brutto 20,00, der afregnes i denne batch
En payout-række: batch-totalen, der bevæger sig til banken

Udbetalingens sammensætning i henhold til Stripes afregningsidentitet:

Bruttobetalinger             100,00
- tilbagebetalinger           20,00
- Stripe-gebyrer               3,20
- overførsler                 81,80
= netto til platformsaldo     -5,00

platform_earning-rækken flytter ikke penge en gang til. Den angiver de 15,00, der forbliver på platformsaldoen, når gebyret og sælgeroverførslen er ude af verden, så platformen kan indregne provisionsindtægter i stedet for at udlede dem.

Her overstiger sælgeroverførslen plus tilbagebetalingen nettokursaktiviteten, så batchen går i et lille minus og reducerer den næste udbetaling eller trækker på saldoen. Det bogførte kassebilag tilbagefører det tilbagebetalte tilgodehavende, indregner 15,00 i provisionsindtægter, registrerer 3,20 i gebyromkostninger, reducerer sælgergælden med overførslen og bogfører tilbagebetalingens tilbageførsel. Banklinjen matcher det nettobeløb, der når frem til kontoen. Intet enkelt tal svarer til "omsætning", hvilket netop er poienten.

Importér og bogfør via Nordlets afregningsslutpunkt

Til udbetalingsspecifik afstemning skal du bruge:

POST /v1/bank/settlements/import

med Stripe-udbyderen og den specificerede CSV-fil. Nordlet grupperer rækker efter automatic_payout_id, omdanner hver udbetaling til en afregningsbatch med brutto-, gebyr- og nettototaler, springer genimport af en allerede bogført udbetaling over, springer payout-rækker over fra udbetalingssammensætningen og automatcher betalings-, tilbagebetalings- og indsigelsesrækker ved hjælp af ordre-, faktura-, PaymentIntent-, betalings-, kilde- eller metadata-referencer. Stripe opdelere den specificerede rapport i én fil pr. sektion, så importér betalings-, tilbagebetalings- og gebyrfilerne samlet: rækker, der hører til en udbetaling, som allerede er importeret, men endnu ikke bogført, flettes ind i den eksisterende batch. Dette er et import- og bogførings-workflow styret af filer og afregningsslutpunkter, ikke et live Stripe-forbindelsesled; funktionsoversigten viser, hvad bank- og afregningssiden dækker.

Match i rækkefølge: Betalinger mod fakturaer, tilbagebetalinger mod oprindelige betalinger, indsigelser mod oprindelige betalinger, provisionsrækker mod provisionsbehandling. Hold Stripe-gebyrer, reguleringer, reserver og udbetalingsrækker ude af fakturamatchningen. Nordlets ordliste over betalingsafstemning fastslår, at gebyr- og reguleringslinjer per design ikke kan matches mod fakturaer; led uafstemte penge-bærende poster til suspense (uspecificerede midler). Manuel korrektion sker ved hjælp af bank/settlements/match { lineId, invoiceId }, hvor en null-værdi for invoiceId ophæver matchningen.

Bogfør derefter én afbalanceret batch:

POST /v1/bank/settlements/post

Dette opretter ét afbalanceret kassebilag, afregner matchede fakturaer, debiterer bankkontoens hovedbogskonto for netto-udbetalingen, debiterer gebyrer, krediterer tilgodehavender for betalinger, tilbagefører tilgodehavender for tilbagebetalinger og chargebacks, opdeler umatchede markedspladsbetalinger mellem provisionsindtægter og sælgergæld, når commissionPercent angives, og sender uafstemte beløb til suspense. Enhver kategori, den ikke genkender, lander ligeledes i suspense, og svartypen nævner disse kategorier i en advarsel i stedet for at sluge dem lydløst.

Afstemningstjekliste

Kør disse udsagn før hver periodelukning:

Ingen dublerede balance_transaction_id
Ingen dublerede (provider, payout_id)-afregningsbatcher
Summen af linjernes net er lig med batch-nettoen
Batch-nettoen er lig med bankudbetalingen, med forbehold for tidsmæssige forskydninger og valutapolitik
Hver tilbagebetaling har en oprindelig betaling eller en logget undtagelse
Hver indsigelse har en indsigelses- eller betalingsreferencen
Hver overførsel har et tilknyttet konto-ID
Hver platform_earning-række har en defineret provisionsbehandling
Suspense er nul eller fuldt gennemgået, herunder eventuelle ukendte kategorier nævnt i bogføringsadvarslen
Sælgergælden er ikke negativ uden en godkendt forudbetaling eller inddrivelsespolitisk godkendelse
Bogførte batcher kan ikke genimporteres eller genbogføres i det stille
En udbetaling i en anden valuta end virksomhedens basisvaluta omregnes til udbetalingsdagens kurs, og differencen i forhold til den enkelte fakturas egen kurs bogføres som en realiseret kursgevinst eller -tab; en udbetaling, der blander valutaer, afvises ved importen

Afstem på tre niveauer: række (hver transaktion har et bevaret ID, kategori, beløb, valuta, kilde), udbetaling (specificerede nettoer svarer til Stripe-udbetalingen og bankindbetalingen) og hovedbog (det bogførte bilag balancerer og frembringer de tilsigtede positioner for omsætning, gebyrer, tilgodehavender, sælgerforpligtelser og suspense). For sæ saldoer specifikt skal det verificeres, at indledende sælgergæld plus ny sælgerandel minus overførsler og gyldige tilbageførsler er lig med afsluttende sælgergæld.

Den tilbagevendende fejl på tværs af enhver markedspladshovedbog er den samme, som den startede med: at komprimere en struktureret udbetaling til et enkelt tal. Hold komponenterne adskilt, forankr hver enkelt til en stabil Stripe-identifikator, og lad suspense holde på alt det, du endnu ikke kan forklare. En ren lukning er det, en revisor vil have tillid til.

FAQ

Er Stripe-udbetalingen platformens omsætning?

Nej. Udbetalingen er nettoresultatet af betalinger, tilbagebetalinger, behandlingsgebyrer, sælgeroverførsler, indsigelser og reguleringer, som tilfældigvis faldt i samme batch. Hvis man bogfører den som én indtægtslinje, sletter man sælgergælden og behandlingsomkostningen indeni. For en agenturmarkedsplads er omsætningen provisionen, hvilket platform_earning-rækkerne identificerer.

Hvilken Stripe-rapport skal jeg afstemme imod?

Rapporten Payout reconciliation, itemized (specificeret udbetalingsafstemning), fordi den giver én række pr. balancetransaktion med en reporting_category, et automatic_payout_id og brutto-, gebyr- og nettobeløb. Et udbetalings-overblik fra kontrolpanelet (Dashboard) beviser kun batch-totalen. Hvor automatiske udbetalinger ikke er aktiveret, skal du bruge balancerapporten i stedet.

Skal en overførsel til en sælger bogføres som en omkostning?

Nej. Sælgerens andel bliver en gældsforpligtelse i det øjeblik, kundebetalingen lander, og overførslen indfrier denne gældsforpligtelse. Bogføring af overførsler som omkostninger dobbelttæller omkostninger og efterlader sælgergælden permanent overdrevet.

Hvad sker der med en Stripe-række, hvis kategori importøren ikke genkender?

Den bogføres på afregnings-suspense-kontoen (standard 4440), og bogføringssvaret returnerer en advarsel, der navngiver de kategorier, der landede der. Reserver og usædvanlige reguleringer lander typisk på denne måde, hvilket er tilsigtet: pengene forbliver synlige, og kassebilaget forbliver i balance, indtil nogen beslutter, hvor de hører hjemme.

Hvordan håndteres tilbagebetalinger, der afregnes i en senere udbetaling?

De ankommer som en refund-række i den senere udbetalings specificerede rapport og matches tilbage til den oprindelige betaling via charge_id for den tidligere matchede betaling. En tilbagebetaling syntetiseret fra en betalingsekport på betalingsniveau er i dette tilfælde kun en tilnærmelse, hvorfor den specificerede rapport er den sikrere kilde.