Flusso di lavoro contabile per i marketplace con Stripe Connect

La maggior parte dei problemi contabili nei marketplace deriva da un unico errore: trattare il pagamento di Stripe sul conto bancario come se fosse un ricavo. Il pagamento è il residuo netto di decine di eventi economici distinti, e registrarlo come un'unica voce di entrata cancella la commissione della piattaforma, il debito verso il venditore e ogni commissione e contestazione inclusa al suo interno. Un flusso di lavoro corretto scompone il pagamento prima che qualsiasi importo tocchi il libro mastro.

Questa guida traccia ogni categoria di transazione del saldo (balance transaction) di Stripe Connect nella sua giusta collocazione contabile: crediti, ricavi da commissioni, debiti verso i venditori, costi di elaborazione e conti sospesi. Utilizza gli endpoint documentati di importazione e liquidazione di Nordlet come meccanismo di registrazione, include un esempio pratico di liquidazione e si conclude con una checklist di riconciliazione da eseguire prima di ogni chiusura.

Identificare il modello di addebito di Connect prima di progettare qualsiasi cosa

Le regole contabili non possono essere definite finché non si sa quale modello di addebito utilizza ciascun flusso di pagamento. Il modello determina su quale saldo Stripe grava l'addebito, chi sostiene le commissioni e dove si riflettono inizialmente rimborsi e contestazioni.

Modello Connect	Addebito creato su	Sostiene le commissioni Stripe	Rimborsi/contestazioni riducono	Conseguenza contabile
Addebiti diretti (Direct charges)	Account connesso	Configurabile per parte	Il saldo dell'account connesso	La piattaforma registra la propria commissione applicativa come ricavo; l'attività di pagamento del venditore risiede principalmente sul libro mastro dell'account connesso
Addebiti a destinazione (Destination charges)	Piattaforma, con trasferimento immediato a un account connesso	Piattaforma	Piattaforma	La piattaforma registra il credito verso il cliente e la commissione Stripe; la quota del venditore è un debito, non un ricavo
Addebiti e trasferimenti separati (Separate charges and transfers)	Addebito sulla piattaforma, poi uno o più trasferimenti separati	Piattaforma	Piattaforma	L'addebito e i trasferimenti al venditore sono eventi separati; il debito verso il venditore è tracciato indipendentemente dall'addebito del cliente

Le linee guida ufficiali di Stripe su come funzionano gli addebiti in un'integrazione Connect confermano che per gli addebiti a destinazione e gli addebiti e trasferimenti separati, il saldo della piattaforma sostiene le commissioni di pagamento, i rimborsi e i chargeback. Per gli addebiti diretti, l'account connesso riceve l'addebito e le commissioni possono essere addebitate a entrambe le parti.

La regola pratica: non dire "il pagamento di Stripe è un ricavo del venditore" o "il venditore paga le commissioni" finché non hai annotato il modello di addebito per ciascun flusso. Memorizza tale modello insieme a ogni transazione. Mescolare addebiti diretti e a destinazione sotto un'unica regola di registrazione è il modo più rapido per rappresentare in modo errato sia i ricavi che i debiti.

Questa guida presuppone l'uso di addebiti a destinazione o di addebiti e trasferimenti separati, poiché è in questi casi che il saldo della piattaforma assume rilevanza contabile ed è dove vengono costruiti la maggior parte dei libri mastro per i marketplace.

Mappare il flusso dei fondi prima di importare anche una sola riga

Prima di toccare qualsiasi importazione, disegna una mappa delle transazioni di una sola pagina per ogni flusso:

Pagamento del cliente
  -> Addebito Stripe / transazione di saldo del pagamento
  -> Commissione Stripe
  -> Commissione applicativa della piattaforma (provvigione)
  -> Trasferimento all'account connesso
  -> Rimborso o contestazione (se applicabile)
  -> Pagamento Stripe (payout)
  -> Incasso bancario

Ogni freccia è una transazione di saldo distinta con il proprio ID, categoria, importo e date. Tratta il saldo di Stripe come un conto transitorio simile a una banca: gli addebiti affluiscono, le commissioni e i trasferimenti defluiscono e il pagamento sposta la parte rimanente sulla banca reale. La documentazione sulle importazioni bancarie e di pagamento di Nordlet consiglia esattamente questo trattamento per la normale attività di Stripe.

Scegliere il report di origine Stripe corretto

Per i batch di liquidazione con pagamenti automatici, utilizza il report Riconciliazione dei pagamenti, dettagliata (Payout reconciliation, itemized) di Stripe. Fornisce una riga per ogni transazione di saldo, raggruppa le righe per reporting_category, associa ciascuna a un automatic_payout_id e fornisce i totali lordi, delle commissioni e netti. La guida alla scelta dei report di Stripe documenta questo report e conferma charge_id, connected_account_id e destination_payment_id come campi Connect disponibili.

Laddove i pagamenti automatici non siano abilitati (in alcune disposizioni con pagamenti manuali), utilizza invece il report del Saldo (Balance report). Non considerare un riepilogo dei pagamenti della Dashboard come prova sufficiente per la registrazione. Il riepilogo dimostra il totale del batch; solo il report dettagliato ne spiega i componenti.

Stripe consiglia di effettuare la classificazione in base a reporting_category anziché al campo precedente type, e ogni riga trasporta un ID source che si collega all'oggetto sottostante. Nota il vincolo temporale: Stripe afferma che i dati giornalieri del report sono normalmente disponibili entro mezzogiorno del giorno successivo e i pagamenti istantanei (instant payouts) non possono essere assegnati chiaramente a singole transazioni, pertanto richiedono una riconciliazione separata dello storico delle transazioni.

Classificare ogni transazione di saldo per categoria

Usa reporting_category come classificatore principale, quindi ispeziona source_id, charge_id e le descrizioni. La mappatura che conta:

Attività di Stripe	Categoria di reportistica (reporting_category)	Interpretazione contabile
Addebito al cliente, carta o metodo di pagamento locale	charge	Credito finanziato dal cliente o regolamento della vendita
Rimborso	refund	Storno del pagamento originale del cliente
Commissione di elaborazione trattenuta da Stripe	fee	Costo di elaborazione dei pagamenti
Commissione applicativa della piattaforma	platform_earning	Ricavo da commissioni
Commissione applicativa rimborsata	platform_earning_refund	Riduzione del ricavo da commissioni
Trasferimento all'account connesso	transfer	Riduzione del debito verso il venditore
Trasferimento stornato	transfer_reversal	Recupero dall'account connesso
Chargeback	dispute	Perdita per chargeback; ispezionare l'oggetto di contestazione di origine
Chargeback vinto o stornato	dispute_reversal	Recupero di un chargeback precedentemente contabilizzato
Pagamento verso la banca	payout	Movimento bancario, non un ricavo
Pagamento stornato	payout_reversal	Ritorno dei fondi nel saldo Stripe
Riserva trattenuta	connect_reserved_funds / risk_reserved_funds	Fondi vincolati, non un costo per impostazione predefinita
Riscossione di un saldo negativo di vecchia data	connect_collection_transfer	Evento di finanziamento o recupero che richiede una policy di rischio

Un avvertimento sulla terminologia: il vecchio campo type delle transazioni di saldo utilizza etichette diverse per gli stessi eventi, tra cui payment, application_fee e adjustment. La documentazione sui tipi di transazione di saldo di Stripe elenca entrambi i vocabolari. Non mischiare un valore di type in una regola basata su reporting_category, e non inventare una categoria come dispute_loss che Stripe non esporta. Se un'esportazione contiene un'etichetta che non riconosci, mantieni il valore esportato e verificalo rispetto all'oggetto di origine.

Registrare la normale attività del marketplace nel libro mastro

Per una piattaforma basata su addebiti a destinazione o addebiti e trasferimenti separati, le registrazioni concettuali sono le seguenti.

Addebito al cliente (il denaro del cliente entra nel saldo transitorio di Stripe):

Dr Saldo transitorio Stripe    Addebito lordo cliente
    Cr Crediti commerciali         Addebito lordo cliente

Commissione di elaborazione Stripe:

Dr Costo commissioni Stripe    Commissione Stripe
    Cr Saldo transitorio Stripe    Commissione Stripe

Non compensare la commissione Stripe sottraendola dai ricavi a meno che la tua policy contabile non richieda e supporti esplicitamente una presentazione al netto.

Commissione della piattaforma (il tuo ricavo, trattenuto da ciò che altrimenti sarebbe dovuto al venditore):

Dr Debiti verso venditori      Importo della commissione
    Cr Ricavi da commissioni   Importo della commissione

Trasferimento al venditore (regolamento del denaro dovuto, non un costo):

Dr Debiti verso venditori      Importo del trasferimento
    Cr Saldo transitorio Stripe    Importo del trasferimento

Un trasferimento non è mai automaticamente un costo. La quota del venditore diventa un debito quando l'addebito va a buon fine, e il trasferimento estingue tale debito. Le regole di registrazione delle liquidazioni di Nordlet seguono questo principio: le righe platform_earning vengono registrate nei ricavi da commissioni mentre le righe transfer riducono il debito verso il venditore. Le chiavi di registrazione predefinite documentate sono settlements.commissionRevenue (predefinito 5001), settlements.sellerPayable (predefinito 4499), settlements.fees (predefinito 6800) e settlements.suspense (predefinito 4440), ciascuna modificabile per azienda tramite le regole di registrazione nell'API di Nordlet.

Gestire i rimborsi rispetto alla vendita originale, non come voci bancarie slegate

Un rimborso si collega all'addebito o alla fattura originale. Concettualmente:

Dr Rimborsi / storni di vendita    Importo del rimborso
    Cr Crediti commerciali             Importo del rimborso

La registrazione effettiva dipende dal fatto che la vendita sia stata riconosciuta, che l'imposta debba essere stornata e che sia stata rimborsata una commissione applicativa della piattaforma. Un singolo rimborso può generare uno storno di credito, uno storno d'imposta, un rimborso della commissione applicativa, uno storno di trasferimento o una riduzione del debito verso il venditore, e una conseguenza sulle commissioni Stripe che deve essere verificata anziché data per scontata.

La trappola temporale: un rimborso spesso viene liquidato in un pagamento successivo rispetto all'addebito originale. È preferibile utilizzare il report di riconciliazione dei pagamenti dettagliato rispetto a un rimborso sintetizzato da un'esportazione a livello di addebito. La documentazione di Nordlet avverte esplicitamente che un rimborso sintetizzato da un'esportazione dei pagamenti è solo un'approssimazione quando il rimborso viene liquidato in un secondo momento. L'importatore di liquidazioni può acquisire la riga di rimborso, abbinarla alla vendita originale e stornare il credito quando il batch viene contabilizzato.

Trattare le contestazioni separatamente dai rimborsi

Una contestazione è un reclamo del titolare della carta o della banca emittente, e Stripe può addebitare sia l'importo contestato che una commissione di contestazione prima della risoluzione. Per gli addebiti a destinazione e gli addebiti e trasferimenti separati, Stripe addebita il saldo della piattaforma per entrambi, secondo le proprie linee guida su rimborsi e contestazioni. La piattaforma può tentare il recupero stornando il trasferimento al venditore.

Una contestazione persa, dal punto di vista della piattaforma:

Dr Perdita su chargeback / credito riaperto    Importo contestato
Dr Costo commissione di contestazione           Commissione di contestazione
    Cr Saldo transitorio Stripe                Importo combinato

Se il venditore si assume la perdita e il recupero è confermato:

Dr Debiti verso venditori / conto di recupero    Importo recuperabile
    Cr Recupero chargeback                       Importo recuperabile

Non contabilizzare il recupero dal venditore solo perché è stato richiesto lo storno di un trasferimento. Verifica che lo storno sia stato creato, sia andato a buon fine e compaia nel saldo Stripe. Se la contestazione viene vinta, Stripe restituisce l'importo contestato tramite una riga dispute_reversal; storna la perdita per chargeback e gestisci separatamente qualsiasi commissione di contestazione che Stripe non restituisce. Nordlet abbina le righe di chargeback utilizzando il charge_id di un addebito precedentemente abbinato, dallo stesso file o da un'importazione precedente.

Un esempio pratico di liquidazione

Prendi un batch di pagamenti automatici. Il report dettagliato contiene:

• Una riga charge: lordo 100.00, commissione Stripe 3.20, netto 96.80
• Una riga platform_earning: 15.00, la commissione della piattaforma
• Una riga transfer: 81.80 al venditore connesso
• Una riga refund da una vendita precedente: lordo 20.00, liquidata in questo batch
• Una riga payout: il totale del batch trasferito in banca

La composizione del pagamento, seguendo l'identità di liquidazione di Stripe:

Addebiti lordi                100.00
- rimborsi                     20.00
- commissioni Stripe            3.20
- trasferimenti                81.80
= netto sul saldo piattaforma  -5.00

La riga platform_earning non muove denaro una seconda volta. Specifica i 15.00 che rimangono nel saldo della piattaforma una volta detratti la commissione e il trasferimento al venditore, in modo che la piattaforma possa contabilizzare i ricavi da commissioni anziché dedurli.

Qui il trasferimento al venditore più il rimborso superano l'attività di addebito netta, quindi il batch risulta in un piccolo importo negativo e riduce il pagamento successivo o attinge dal saldo. Il giornale registrato storna il credito rimborsato, riconosce 15.00 di ricavi da commissioni, registra 3.20 di costi per commissioni, riduce il debito verso il venditore dell'importo del trasferimento e contabilizza lo storno del rimborso. La voce bancaria corrisponde al netto che arriva sul conto. Nessuna singola cifra equivale al "ricavo", ed è questo il punto.

Importare e registrare tramite l'endpoint di liquidazione di Nordlet

Per la riconciliazione a livello di pagamento, utilizza:

POST /v1/bank/settlements/import

specificando il provider Stripe e il file CSV dettagliato. Nordlet raggruppa le righe per automatic_payout_id, trasforma ciascun pagamento in un batch di liquidazione con totali lordi, di commissioni e netti, salta le re-importazioni di un pagamento già contabilizzato, salta le righe payout dalla composizione della liquidazione e associa automaticamente le righe di addebito, rimborso e contestazione utilizzando riferimenti a ordini, fatture, PaymentIntent, addebiti, origini o metadati. Stripe divide il report dettagliato in un file per sezione, quindi importa insieme i file di addebito, rimborso e commissioni: le righe appartenenti a un pagamento già importato ma non ancora contabilizzato si uniscono al batch esistente. Si tratta di un flusso di lavoro di importazione e registrazione guidato da file ed endpoint di liquidazione, non di un connettore Stripe in tempo reale; la pagina delle funzionalità elenca ciò che l'aspetto bancario e delle liquidazioni copre.

Effettua l'abbinamento nell'ordine: addebiti alle fatture, rimborsi agli addebiti originali, contestazioni agli addebiti originali, righe di commissione al trattamento delle commissioni. Tieni le commissioni Stripe, le rettifiche, le riserve e le righe di pagamento fuori dall'abbinamento delle fatture. Il glossario sulla riconciliazione dei pagamenti di Nordlet afferma che le linee di commissione e rettifica non sono abbinabili alle fatture per progettazione; instrada le voci di denaro non risolte verso i conti sospesi. La correzione manuale utilizza bank/settlements/match { lineId, invoiceId }, con un valore null per invoiceId per annullare l'abbinamento.

Quindi registra un batch bilanciato:

POST /v1/bank/settlements/post

Questo crea un primo giornale bilanciato, liquida le fatture abbinate, addebita il conto contabile del conto bancario per il pagamento netto, addebita le commissioni, accredita i crediti per gli addebiti, storna i crediti per rimborsi e chargeback, suddivide gli addebiti del marketplace non abbinati tra ricavi da commissioni e debiti verso i venditori quando viene fornito commissionPercent, e invia gli importi non risolti ai conti sospesi. Qualsiasi categoria non riconosciuta finisce anch'essa nei conti sospesi, e la risposta elenca tali categorie in un avviso anziché assorbirle silenziosamente.

Checklist di riconciliazione

Esegui queste verifiche prima di ogni chiusura:

• Nessun balance_transaction_id duplicato
• Nessun batch di liquidazione (provider, payout_id) duplicato
• La somma del campo net delle righe equivale al netto del batch
• Il netto del batch equivale al pagamento bancario, fatte salve le tempistiche e le policy valutarie
• Ogni rimborso ha un addebito originale o un'eccezione registrata
• Ogni contestazione ha un riferimento a una contestazione o a un addebito
• Ogni trasferimento ha un ID di account connesso
• Ogni riga platform_earning ha un trattamento delle commissioni definito
• Il conto sospeso è a zero o completamente revisionato, incluse eventuali categorie non riconosciute menzionate nell'avviso di registrazione
• Il debito verso il venditore non è negativo in assenza di un anticipo approvato o di una policy di recupero
• I batch registrati non possono essere re-importati o registrati nuovamente in modo silenzioso
• Un pagamento in una valuta diversa da quella di base dell'azienda viene convertito al tasso della data di pagamento, con la differenza rispetto al tasso della singola fattura registrata come utile o perdita di cambio realizzata; un pagamento che unisce più valute viene rifiutato in fase di importazione

Riconcilia a tre livelli: riga (ciascuna transazione ha un ID preservato, categoria, importo, valuta, origine), pagamento (i netti dettagliati equivalgono al pagamento Stripe e all'incasso bancario) e libro mastro (il giornale registrato si bilancia e produce le posizioni previste di ricavi, commissioni, crediti, debiti verso i venditori e conti sospesi). Nello specifico per i saldi dei venditori, verifica che il debito iniziale verso il venditore più la nuova quota del venditore, meno i trasferimenti e gli storni validi, sia pari al debito finale verso il venditore.

Il problema ricorrente in ogni libro mastro di marketplace è lo stesso da cui si è partiti: comprimere un pagamento strutturato in un unico numero. Mantieni i componenti separati, ancora ciascuno a un identificatore Stripe stabile e lascia che il conto sospeso gestisca tutto ciò che non puoi ancora spiegare. Una chiusura pulita è ciò di cui un revisore si fiderà.

FAQ

Il pagamento di Stripe rappresenta i ricavi della piattaforma?

No. Il pagamento è il netto di addebiti, rimborsi, commissioni di elaborazione, trasferimenti ai venditori, contestazioni e rettifiche che sono stati liquidati nello stesso batch. Registrarlo come un'unica voce di entrata cancella il debito verso il venditore e il costo di elaborazione in esso contenuti. Per un marketplace di intermediazione, il ricavo è la commissione, che le righe platform_earning identificano.

Con quale report di Stripe dovrei effettuare la riconciliazione?

Con il report di riconciliazione dei pagamenti dettagliato (Payout reconciliation, itemized), poiché fornisce una riga per ogni transazione di saldo con una reporting_category, un automatic_payout_id e importi lordi, delle commissioni e netti. Un riepilogo dei pagamenti della Dashboard dimostra solo il totale del batch. Laddove i pagamenti automatici non siano abilitati, utilizza invece il report del Saldo (Balance report).

Un trasferimento a un venditore deve essere contabilizzato come un costo?

No. La quota del venditore diventa un debito nel momento in cui l'addebito del cliente va a buon fine, e il trasferimento estingue tale debito. Contabilizzare i trasferimenti come costi duplica il conteggio delle spese e lascia il debito verso il venditore permanentemente sovrastimato.

Cosa succede a una riga di Stripe la cui categoria non è riconosciuta dall'importatore?

Viene registrata nel conto sospeso di liquidazione, predefinito su 4440, e la risposta di registrazione restituisce un avviso che nomina le categorie finite lì. Le riserve e le rettifiche insolite solitamente finiscono in questo modo, ed è una scelta deliberata: il denaro rimane visibile e il giornale rimane bilanciato finché qualcuno non decide dove debba essere collocato.

Come vengono gestiti i rimborsi liquidati in un pagamento successivo?

Arrivano come una riga refund nel report dettagliato del pagamento successivo e vengono abbinati all'addebito originale tramite il charge_id dell'addebito precedentemente abbinato. Un rimborso sintetizzato da un'esportazione dei pagamenti a livello di addebito è solo un'approssimazione in questo caso, quindi il report dettagliato è la fonte più sicura.

Ulteriori letture

• Importazioni bancarie e di pagamento, inclusa la riconciliazione delle liquidazioni Stripe
• Riconciliazione dei pagamenti: abbinamento dei pagamenti PSP al libro mastro
• Sottocontabilità dei venditori nei marketplace: ricavi vs debiti
• Come funzionano gli addebiti in un'integrazione Connect (Stripe)