Nordlet

← Blog

Stripe Connect Marketplace Accounting Workflow

A practitioner's guide to posting charges, fees, transfers, refunds, disputes, and reserves into a marketplace ledger that reconciles cleanly.

Nordlet Team · · 14 min de citire

Cele mai multe probleme de contabilitate pe marketplace-uri își au originea într-o singură greșeală: tratarea transferului bancar (payout) de la Stripe ca și cum acesta ar fi venit. Transferul reprezintă rezultatul net a zeci de evenimente economice separate, iar înregistrarea lui ca o singură linie de venituri șterge comisionul platformei, datoria față de vânzător, precum și fiecare comision sau litigiu ascuns în interiorul său. Un flux de lucru corect descompune acest transfer înainte ca vreun element să atingă registrul contabil.

Acest ghid urmărește fiecare categorie de tranzacție din soldul Stripe Connect până înoul său amplasament contabil adecvat: creanțe, venituri din comisioane, datorii față de vânzători, cheltuieli de procesare și conturi de tranzitoriu (suspense). Ghidul utilizează punctele finale (endpoints) documentate de import și decontare ale Nordlet ca mecanism de înregistrare, include un exemplu practic de decontare și se încheie cu o listă de verificare pentru reconciliere pe care o puteți rula înainte de fiecare închidere contabilă.

Identificați modelul de plată Connect înainte de a concepe orice flux

Regulile contabile nu pot fi formulate până când nu știți ce model de plată utilizează fiecare flux de încasare. Modelul determină a cărui sold Stripe îi aparține încasarea, cine suportă comisioanele și unde se reflectă inițial rambursările și litigiile.

Model Connect Încasare creată în Suportă comisioanele Stripe Rambursările/litigiile reduc Consecință contabilă
Încasări directe (Direct charges) Contul conectat Configurabil per parte Soldul contului conectat Platforma își înregistrează comisionul de utilizare ca venit; activitatea de plată a vânzătorului se află în mare parte în registrul contului conectat
Încasări către destinație (Destination charges) Platformă, cu transfer imediat către un cont conectat Platformă Platformă Platforma înregistrează creanța de la client și comisionul Stripe; cota vânzătorului este o datorie, nu un venit
Încasări și transferuri separate (Separate charges and transfers) Încasare pe platformă, urmată de unul sau mai multe transferuri separate Platformă Platformă Încasarea și transferurile către vânzător sunt evenimente separate; datoria față de vânzător este urmărită independent de încasarea de la client

Ghidul oficial Stripe privind modul în care funcționează încasările într-o integrare Connect confirmă că, pentru încasările către destinație și pentru încasările și transferurile separate, soldul platformei suportă comisioanele de plată, rambursările și refuzurile de plată (chargebacks). În cazul încasărilor directe, contul conectat primește plata, iar comisioanele pot fi debitate de la oricare dintre părți.

Regula practică: nu afirmați că „transferul Stripe reprezintă venitul vânzătorului” sau că „vânzătorul plătește comisioanele” până când nu ați consemnat modelul de plată pentru fiecare flux în parte. Salvați acest model împreună cu fiecare tranzacție. Combinarea încasărilor directe și a celor către destinație sub o singură regulă de înregistrare este cea mai rapidă cale de a denatura atât veniturile, cât și datoriile.

Acest ghid presupune utilizarea încasărilor către destinație sau a încasărilor și transferurilor separate, deoarece în aceste cazuri soldul platformei poartă greutatea contabilă și tot aici se construiesc majoritatea registrelor contabile pentru marketplace-uri.

Mappați fluxul fondurilor înainte de a importa un singur rând

Înainte de a efectua orice import, schițați o hartă a tranzacțiilor pe o singură pagină pentru fiecare flux în parte:

Plata clientului
  -> Încasare Stripe / tranzacție sold plată
  -> Comision Stripe
  -> Comision de utilizare platformă (comision)
  -> Transfer către contul conectat
  -> Rambursare sau litigiu (dacă este cazul)
  -> Transfer bancar Stripe (payout)
  -> Încasare bancară

Fiecare săgeată reprezintă o tranzacție distinctă de sold, având propriul ID, categorie, sumă și date calendaristice. Tratați soldul Stripe ca pe un cont de clearing similar unuia bancar: încasările intră, comisioanele și transferurile ies, iar transferul bancar (payout) mută suma rămasă în banca reală. Documentația Nordlet privind importurile bancare și de plăți recomandă exact acest tratament pentru activitatea obișnuită pe Stripe.

Alegeți raportul sursă Stripe corect

Pentru loturile de decontare cu transferuri automate, utilizați raportul Stripe Reconcilierea transferurilor, detaliat (Payout reconciliation, itemized). Acesta oferă câte un rând pentru fiecare tranzacție de sold, grupează rândurile după reporting_category, asociază fiecare rând cu un automatic_payout_id și furnizează totalurile brute, comisioanele și valorile nete. Ghidul de selectare a rapoartelor publicat de Stripe documentează acest raport și confirmă că charge_id, connected_account_id și destination_payment_id sunt câmpuri Connect disponibile.

Acolo unde transferurile automate nu sunt activate (în cazul anumitor aranjamente cu transferuri manuale), utilizați în schimb raportul de sold (Balance report). Nu considerați că un sumar al transferurilor din Panoul de control (Dashboard) este o dovadă suficientă pentru înregistrare. Sumarul dovedește totalul lotului; doar raportul detaliat explică componentele acestuia.

Stripe recomandă clasificarea după reporting_category în loc de utilizarea mai vechiului câmp type, iar fiecare rând poartă un ID source care face legătura cu obiectul subiacent. Rețineți constrângerea de ordin temporal: Stripe menționează că datele zilnice din rapoarte sunt de obicei disponibile până la prânz în ziua următoare, iar transferurile instant nu pot fi atribuite în mod curat unor tranzacții individuale, motiv pentru care necesită o reconciliere separată a istoricului de tranzacții.

Clasificați fiecare tranzacție de sold după categorie

Utilizați reporting_category ca principal element de clasificare, apoi inspectați source_id, charge_id și descrierile. Maparea relevantă este următoarea:

Activitate Stripe Categorie de raportare (Reporting category) Interpretare contabilă
Încasare de la client, card sau metodă de plată locală charge Creanță finanțată de client sau decontare a vânzării
Rambursare refund Anularea plății inițiale a clientului
Comision de procesare reținut de Stripe fee Cheltuială cu procesarea plății
Comision de utilizare a platformei platform_earning Venit din comisioane
Comision de utilizare rambursat platform_earning_refund Reducere a veniturilor din comisioane
Transfer către contul conectat transfer Reducerea datoriei față de vânzător
Transfer inversat transfer_reversal Recuperare de la contul conectat
Refuz de plată (Chargeback) dispute Pierdere din refuz de plată; inspectați obiectul litigiu sursă
Litigiu câștigat sau inversat dispute_reversal Recuperarea unui refuz de plată înregistrat anterior
Transfer către bancă (Payout) payout Mișcare bancară, nu venit
Transfer inversat (Payout reversal) payout_reversal Returnarea fondurilor în soldul Stripe
Fonduri de rezervă reținute connect_reserved_funds / risk_reserved_funds Fonduri restricționate, nu reprezintă o cheltuială în mod implicit
Colectarea unui sold negativ vechi connect_collection_transfer Eveniment de finanțare sau recuperare care necesită o politică de risc

O mențiune de precauție privind terminologia: vechiul tip de tranzacție de sold (type) utilizează etichete diferite pentru aceleași evenimente, printre care payment, application_fee și adjustment. Documentația Stripe privind tipurile de tranzacții de sold enumeră ambele vocabulare. Nu combinați o valoare a tipului (type) într-o regulă bazată pe categoria de raportare (reporting_category) și nu inventați o categorie precum dispute_loss pe care Stripe nu o exportă. Dacă un export conține o etichetă pe care nu o recunoașteți, păstrați valoarea exportată și verificați-o în raport cu obiectul sursă.

Înregistrați activitatea normală de marketplace în registrul contabil

Pentru o platformă care utilizează încasări către destinație sau încasări și transferuri separate, înregistrările contabile conceptuale sunt următoarele.

Încasarea de la client (bani ai clientului intră în soldul de clearing Stripe):

Dr. Cont clearing Stripe       Încasare brută de la client
    Cr. Creanțe comerciale     Încasare brută de la client

Comisionul de procesare Stripe:

Dr. Cheltuieli cu comisioane Stripe    Comision Stripe
    Cr. Cont clearing Stripe            Comision Stripe

Nu compensați (net-uiți) comisionul Stripe direct din venituri decât dacă politica dumneavoastră contabilă impune și susține în mod explicit prezentarea la valoarea netă.

Comisionul platformei (venitul dumneavoastră, dedus din ceea ce altfel i s-ar datora vânzătorului):

Dr. Datorii față de vânzători           Valoarea comisionului
    Cr. Venituri din comisioane         Valoarea comisionului

Transferul către vânzător (decontarea banilor datorați, nu reprezintă o cheltuială):

Dr. Datorii față de vânzători           Valoarea transferului
    Cr. Cont clearing Stripe            Valoarea transferului

Un transfer nu reprezintă niciodată în mod automat o cheltuială. Cota vânzătorului devine o datorie în momentul în care încasarea este efectuată, iar transferul stinge această datorie. Regulile Nordlet de înregistrare a decontărilor urmează acest principiu: rândurile de tip platform_earning se înregistrează în veniturile din comisioane, în timp ce rândurile de tip transfer reduc datoria față de vânzător. Cheile implicite de înregistrare documentate sunt settlements.commissionRevenue (implicit 5001), settlements.sellerPayable (implicit 4499), settlements.fees (implicit 6800) și settlements.suspense (implicit 4440), fiecare putând fi suprascrisă pentru fiecare companie prin intermediul regulilor de înregistrare din API-ul Nordlet.

Tratați rambursările raportat la vânzarea inițială, nu ca articole bancare izolate

O rambursare face trimitere la încasarea sau factura inițială. Din punct de vedere conceptual:

Dr. Rambursări / stornări de vânzări    Valoarea rambursării
    Cr. Creanțe comerciale               Valoarea rambursării

Înregistrarea efectivă depinde de dacă vânzarea a fost recunoscută, dacă taxa trebuie stornată și dacă comisionul de utilizare a platformei a fost rambursat. O singură rambursare poate genera o stornare de creanță, o stornare de taxe, o rambursare a comisionului de utilizare, o inversare de transfer sau o reducere a datoriei față de vânzător, precum și un impact legat de comisionul Stripe care trebuie verificat, nu presupus.

Capcana legată de momentul înregistrării: o rambursare se decontă de obicei într-un transfer (payout) ulterior față de încasarea inițială. Prioritizați raportul detaliat de reconciliere a transferurilor în detrimentul unei rambursări sintetizate dintr-un export la nivel de încasare. Documentația Nordlet avertizează în mod explicit că o rambursare sintetizată dintr-un export de plăți (Payments) reprezintă doar o aproximare atunci când rambursarea se decontează ulterior. Modulul de import al decontărilor poate prelua rândul de rambursare, îl poate corela cu vânzarea inițială și poate storna creanța atunci când lotul este înregistrat.

Tratați litigiile separat de rambursări

Un litigiu este o solicitare din partea titularului de card sau a băncii emitente, iar Stripe poate debita atât suma aflată în litigiu, cât și un comision de litigiu înainte de soluționare. Pentru încasările către destinație și pentru încasările și transferurile separate, Stripe debitează soldul platformei pentru ambele sume, conform ghidului său privind rambursările și litigiile. Platforma poate încerca recuperarea prin inversarea transferului către vânzător.

Un litigiu pierdut, din perspectiva platformei:

Dr. Pierderi din refuzuri de plată / creanță redeschisă    Suma în litigiu
Dr. Cheltuieli cu comisioane de litigiu                     Comisionul de litigiu
    Cr. Cont clearing Stripe                                Suma combinată

Dacă vânzătorul suportă pierderea și recuperarea este confirmată:

Dr. Datorii față de vânzători / cont de recuperare        Suma recuperabilă
    Cr. Recuperări din refuzuri de plată                    Suma recuperabilă

Nu înregistrați recuperarea de la vânzător doar pentru că a fost solicitată o inversare de transfer. Verificați dacă inversarea a fost creată, a reușit și apare în soldul Stripe. Dacă litigiul este câștigat, Stripe returnează suma aflată în litigiu printr-un rând de tip dispute_reversal; stornați pierderea din refuzul de plată și tratați separat orice comision de litigiu pe care Stripe nu îl returnează. Nordlet corelează rândurile de refuz de plată utilizând charge_id-ul unei încasări corelate anterior, din același fișier sau dintr-un import anterior.

Un exemplu practic de decontare

Să luăm un lot de transferuri automate. Raportul detaliat conține:

  • Un rând charge: brut 100.00, comision Stripe 3.20, net 96.80
  • Un rând platform_earning: 15.00, comisionul platformei
  • Un rând transfer: 81.80 către vânzătorul conectat
  • Un rând refund de la o vânzare anterioară: brut 20.00, care se decontează în acest lot
  • Un rând payout: totalul lotului transferat în bancă

Compoziția transferului, conform identității de decontare Stripe:

Încasări brute               100.00
- rambursări                  20.00
- comisioane Stripe            3.20
- transferuri                 81.80
= net în soldul platformei    -5.00

Rândul platform_earning nu mută bani pentru a doua oară. El indică suma de 15.00 care rămâne în soldul platformei odată ce comisionul și transferul către vânzător au fost scăzute, permițând platformei să recunoască veniturile din comisioane în loc să le deducă prin deducții implicite.

În acest caz, transferul către vânzător plus rambursarea depășesc activitatea netă de încasare, astfel încât lotul ajunge la o valoare netă ușor negativă și reduce transferul următor sau apelează la sold. Jurnalul înregistrat stornează creanța rambursată, recunoaște venituri din comisioane de 15.00, înregistrează o cheltuială cu comisioane de 3.20, reduce datoria față de vânzător cu valoarea transferului și înregistrează stornarea rambursării. Linia bancară se potrivește cu valoarea netă care ajunge în cont. Nicio cifră unică nu este egală cu „venitul”, și exact acesta este scopul.

Importați și înregistrați prin intermediul punctului final de decontare Nordlet

Pentru reconcilierea la nivel de transfer, utilizați:

POST /v1/bank/settlements/import

utilizând furnizorul Stripe și fișierul CSV detaliat. Nordlet grupează rândurile după automatic_payout_id, transformă fiecare transfer într-un lot de decontare cu totaluri brute, de comisioane și nete, omite reimporturile unui transfer deja înregistrat, omite rândurile payout din compoziția transferului și autocorelează rândurile de încasare, rambursare și litigiu utilizând referințele la comenzi, facturi, PaymentIntent, încasări, surse sau metadate. Stripe împarte raportul detaliat într-un singur fișier per secțiune, așadar importați împreună fișierele pentru încasări, rambursări și comisioane: rândurile aparținând unui transfer care a fost deja importat, dar încă nu a fost înregistrat, se comasează în lotul existent. Acesta este un flux de lucru de import și înregistrare condus de fișiere și puncte finale de decontare, nu un conector Stripe în timp real; pagina de funcționalități prezintă ceea ce acoperă partea bancară și de decontare.

Faceți corelările în ordinea următoare: încasările cu facturile, rambursările cu încasările inițiale, litigiile cu încasările inițiale, rândurile de comisioane cu tratamentul aferent comisioanelor. Țineți comisioanele Stripe, ajustările, rezervele și rândurile de transfer afara corelării facturilor. Glosarul de reconciliere a plăților Nordlet precizează că liniile de comisioane și ajustări nu pot fi corelate cu facturile prin design; redirecționați elementele nerezolvate care implică sume de bani către conturile de tranzitoriu (suspense). Corectarea manuală utilizează bank/settlements/match { lineId, invoiceId }, cu un ID de factură null pentru a anula corelarea.

Apoi înregistrați un lot echilibrat:

POST /v1/bank/settlements/post

Această operațiune creează un singur jurnal echilibrat, decontează facturile corelate, debitează contul contabil al băncii pentru transferul net, debitează comisioanele, creditează creanțele pentru încasări, stornează creanțele pentru rambursări și refuzuri de plată, împarte încasările necorelate de pe marketplace între veniturile din comisioane și datoriile față de vânzători atunci când este furnizat un commissionPercent, și trimite sumele nerezolvate în contul de tranzitoriu. Orice categorie pe care o recunoaște ajunge, de asemenea, în contul de tranzitoriu, iar răspunsul menționează acele categorii într-un avertisment în loc să le absoarbă în mod silențios.

Lista de verificare pentru reconciliere

Rulați aceste aserțiuni înainte de fiecare închidere contabilă:

  • Niciun ID de tranzacție de sold (balance_transaction_id) duplicat
  • Niciun lot de decontare duplicat de tip (provider, payout_id)
  • Suma valorilor nete (net) ale rândurilor este egală cu valoarea netă a lotului
  • Valoarea netă a lotului este egală cu transferul bancar, sub rezerva politicii de moment și de valutar
  • Fiecare rambursare are o încasare originală sau o excepție înregistrată
  • Fiecare litigiu are o referință la litigiu sau la încasare
  • Fiecare transfer are un ID de cont conectat
  • Fiecare rând platform_earning are un tratament definit pentru comisioane
  • Soldul de tranzitoriu (suspense) este zero sau pe deplin revizuit, incluzând orice categorii nerecunoscute menționate în avertismentul de înregistrare
  • Datoria față de vânzător nu este negativă în absența unei politici aprobate de avans sau recuperare
  • Loturile înregistrate nu pot fi reimportate sau reînregistrate în mod silențios
  • Un transfer într-o altă monedă decât moneda de bază a companiei se convertește la cursul din data transferului, diferența față de cursul propriei facturi fiind înregistrată ca un câștig sau o pierdere de curs valutar realizată; un transfer care combină mai multe monede este respins la import

Reconciliați la trei niveluri: rând (fiecare tranzacție are un ID păstrat, categorie, sumă, monedă, sursă), transfer (valorile nete detaliate sunt egale cu transferul Stripe și încasarea bancară) și registru (jurnalul înregistrat se echilibrează și produce pozițiile dorite de venituri, comisioane, creanțe, datorii față de vânzători și conturi de tranzitoriu). În ceea ce privește soldurile vânzătorilor în mod special, verificați că datoria inițială față de vânzător plus noua cotă a vânzătorului, minus transferurile și stornările valide, este egală cu datoria finală față de vânzător.

Eșecul recurent înregistrat în orice registru contabil de marketplace este același cu cel de la care a pornit: comprimarea unui transfer structurat într-o singură cifră. Păstrați componentele separate, ancorați-le pe fiecare de un identificator Stripe stabil și lăsați contul de tranzitoriu să preia tot ceea ce nu puteți explica încă. O închidere contabilă curată este cea în care un auditor va avea încredere.

FAQ

Reprezintă transferul Stripe venitul platformei?

Nu. Transferul reprezintă rezultatul net al încasărilor, rambursărilor, comisioanelor de procesare, transferurilor către vânzători, litigiilor și ajustărilor care s-au decontat în același lot. Înregistrarea acestuia ca o singură linie de venituri șterge datoria față de vânzător și cheltuiala de procesare din interiorul său. Pentru un marketplace de tip agent, venitul este comisionul, pe care rândurile platform_earning îl identifică.

Cu ce raport Stripe ar trebui să fac reconcilierea?

Cu raportul de reconciliere a transferurilor, detaliat (Payout reconciliation, itemized), deoarece oferă câte un rând per tranzacție de sold cu o categorie de raportare (reporting_category), un ID de transfer (automatic_payout_id) și sume brute, de comisioane și nete. Un sumar al transferurilor din Panoul de control dovedește doar totalul lotului. Acolo unde transferurile automate nu sunt activate, utilizați în schimb raportul de sold (Balance report).

Ar trebui ca un transfer către un vânzător să fie înregistrat ca o cheltuială?

Nu. Cota vânzătorului devine o datorie în momentul în care încasarea de la client este efectuată, iar transferul stinge acea datorie. Înregistrarea transferurilor ca cheltuieli dublează costul și lasă datoria față de vânzător supraevaluată permanent.

Ce se întâmplă cu un rând Stripe a cărui categorie nu este recunoscută de modulul de import?

Acesta se înregistrează în contul de tranzitoriu (suspense) pentru decontări, implicit 4440, iar răspunsul la înregistrare returnează un avertisment care menționează categoriile care au ajuns acolo. Rezervele și ajustările neobișnuite ajung de obicei în acest mod, iar acest lucru este deliberat: banii rămân vizibili, iar jurnalul rămâne echilibrat până când cineva decide căruia dintre conturi îi aparțin.

Cum sunt gestionate rambursările care se decontează într-un transfer ulterior?

Ele sosesc ca un rând de tip refund în raportul detaliat al transferului ulterior și sunt corelate înapoi cu încasarea inițială prin intermediul charge_id-ului încasării corelate anterior. O rambursare sintetizată dintr-un export de plăți la nivel de încasare reprezintă doar o aproximare în acest caz, motiv pentru care raportul detaliat este sursa cea mai sigură.

Lecturi suplimentare