Sottoconti dei venditori nei marketplace: ricavi e debiti

Una guida pratica per separare incassi dei clienti, commissioni della piattaforma, debiti verso i venditori, riserve e pagamenti tramite registrazioni in partita doppia bilanciate e un modello di dati operativo dall'ordine al pagamento.

L'errore più comune nella contabilità dei marketplace consiste nel considerare il pagamento lordo dell'acquirente come ricavo della piattaforma. Un cliente paga 100 €, quella somma confluisce nel conto del payment processor e qualcuno registra l'intero importo tra le vendite. I conti tornano per un po', i ricavi sembrano ottimi, finché un revisore chiede dove sia la passività verso il venditore. Non c'è, perché i 90 € del venditore non sono mai stati registrati come debito.

La soluzione è strutturale, non cosmetica. Un marketplace necessita di un modello di mastro che separi fin dalla prima registrazione cinque distinte categorie: liquidità dei clienti in transito, ricavi da commissioni della piattaforma, debiti verso i venditori, commissioni di elaborazione e riserve. I pagamenti ai venditori costituiscono un sesto evento che estingue il debito, e non rappresentano autonomamente un ricavo o un costo. Questa guida illustra le registrazioni contabili bilanciate e il modello di dati che mantengono distinte queste categorie.

Partire dalla conclusione sull'essere principale o agente

Prima che qualsiasi struttura dei conti diventi rilevante, la piattaforma deve stabilire che cosa sta vendendo. Ai sensi dell'ASC 606, questa valutazione viene effettuata per singolo bene o servizio specificato, e la risposta determina se i ricavi debbano essere lordi o netti. Una piattaforma può agire come principale per un flusso e come agente per un altro.

Per una tipica vendita su un marketplace di beni di un venditore, la piattaforma solitamente agisce come agente. Essa fa in modo che il prodotto del venditore arrivi all'acquirente, non si assume il rischio di magazzino e il suo corrispettivo consiste in una commissione. La guida di Deloitte sulle considerazioni in merito al ruolo di principale o agente ai sensi dell'ASC 606 incentra l'analisi sul controllo: la responsabilità di adempiere all'obbligazione, il rischio di magazzino e la discrezionalità nella definizione del prezzo sono indicatori, non una checklist che sostituisce la valutazione sostanziale del controllo.

Il motivo per cui questo aspetto rientra nella progettazione del mastro, e non solo in una nota interna, è che la conclusione guida ogni successiva registrazione. Se la piattaforma è un agente, la quota del venditore costituisce una passività nel momento stesso in cui viene maturata. Se è principale per un servizio di evasione ordini o di garanzia, quella parte rappresenta un ricavo della piattaforma. È opportuno memorizzare la conclusione come dato:

principal_agent_role
specified_good_or_service
commission_rule_id
control_assessment_version
effective_from / effective_to

Un revisore che esamina una riga di commissioni nette due anni dopo dovrebbe essere in grado di vedere perché non è stato utilizzato il valore lordo. Come nota BillingPlatform sull'ASC 606 in merito a principale e agente, l'etichetta "marketplace" non risolve la questione. È l'analisi del controllo a farlo.

Definire il saldo del venditore prima di scrivere qualsiasi regola contabile

Il "saldo del venditore" non è un numero unico. Un venditore può avere un solido saldo complessivo e tuttavia non avere nulla di disponibile per il prelievo perché il denaro è ancora in sospeso o trattenuto a titolo di riserva. Se si aggregano questi stati, si rappresenteranno in modo errato sia ciò che il venditore può prelevare sia ciò che la piattaforma deve ancora pagare.

È necessario monitorare almeno:

In sospeso (Pending): maturato o incassato, non ancora idoneo per il pagamento
Disponibile (Available): idoneo per il pagamento secondo le regole della piattaforma
Riservato (Reserved): trattenuto a fronte di possibili rimborsi, controversie o chargeback
Pagato (Paid out): trasferito o inviato per il regolamento
Negativo (Negative): importo dovuto dal venditore, recuperabile dai proventi futuri
Transitorio (Suspense): ricevuto, ma venditore o trattamento non ancora definiti

I fornitori di servizi di pagamento modellano già questa distinzione. Stripe separa ciascun account collegato in saldi in sospeso e disponibili, e mantiene un saldo di riserva a livello di piattaforma per determinati saldi negativi dei venditori. Se il processore separa queste voci, deve farlo anche il mastro, altrimenti la riconciliazione non quadrerà mai.

Il piano dei conti e le dimensioni rilevanti

Una struttura iniziale efficiente tiene separati i conti di transito, le passività e i ricavi, e riporta la dimensione del venditore su ogni registrazione rilevante.

Scopo	Conto o dimensione	Trattamento
Fondi del payment processor in attesa di regolamento	Clearing del payment processor	Attività di transito
Pagamento del processor accreditato in banca	Banca	Attività
Importo maturato dal venditore ma non ancora pagato	Debiti verso i venditori	Passività
Dettaglio a livello di venditore	Dimensione `seller_id`	Dettaglio di passività, non ricavo
Commissione della piattaforma	Ricavi da commissioni	Ricavo
IVA o imposta sulle vendite	Debiti tributari	Passività
Commissioni del payment processor	Costi per servizi di pagamento	Costo
Riserve del venditore	Passività per riserva	Dipendente dal contratto
Rimborsi	Rettifica di ricavo o resi	Inverte il trattamento originario
Chargeback	Perdita, credito o recupero dal venditore	Dipende da chi sostiene la perdita
Pagamenti in attesa di conferma bancaria	Clearing pagamenti ai venditori	Conto di transito
Importi non allocati	Transitorio (Suspense)	Eccezione temporanea

Ogni registrazione rilevante dovrebbe includere venditore, ordine, lotto di pagamento, payment processor, valuta, entità legale, trattamento fiscale, tipo di evento, riferimento esterno e qualsiasi collegamento di storno. Senza di questi, il sottoconto del venditore non può dimostrare un singolo saldo e il libro mastro generale non può dimostrare il totale.

È possibile implementare il sottoconto come un conto di debito per ciascun venditore, un conto debiti aggregato con seller_id come dimensione, oppure suddividendolo tra debiti, riserva e clearing dei pagamenti. L'approccio basato su aggregato più dimensione scala meglio una volta superate poche decine di venditori. È opportuno scegliere il modello insieme al proprio commercialista, poiché le norme di salvaguardia e la regolamentazione locale dei pagamenti possono influenzare le modalità di esposizione dei fondi. Per i meccanismi alla base delle registrazioni, il nostro articolo sulle API per mastri in partita doppia nella contabilità dei marketplace descrive le primitive contabili su cui si basa questo modello.

Registrare la vendita con righe separate per venditore e piattaforma

Si consideri la vendita di un agente: il cliente paga 100 €, la commissione della piattaforma è 10 €, il venditore guadagna 90 €. Nel momento in cui la commissione e il diritto del venditore sono maturati:

Conto	Dare	Avere
Clearing del payment processor	100 €
Debiti verso i venditori - Venditore A		90 €
Ricavi da commissioni		10 €

Il controllo fondamentale: 90 € vengono accreditati a un conto di passività, non a ricavo. La piattaforma rileva 10 €. Questo è il risultato a cui mira l'esempio di marketplace dell'ASC 606 per un agente, in cui la piattaforma riconosce la propria commissione anziché l'intero importo delle vendite del venditore.

Se l'imposta viene riscossa separatamente, si aggiunge la riga dei debiti tributari e si riduce la cifra del venditore o della piattaforma in base alle conclusioni fiscali. Non bisogna incorporare l'imposta nella commissione o nel debito verso il venditore per comodità.

Tenere le commissioni del processore fuori dal calcolo di ricavi e debiti

Tre elementi vengono confusi continuamente: commissione della piattaforma, commissione del payment processor e importo del pagamento. Sono diversi e incidono su conti differenti.

Il cliente paga 100 €, la commissione è 10 €, il processore trattiene 3 €.

I ricavi da commissioni rimangono 10 €, se questo è quanto previsto dal contratto.
La commissione del processore di 3 € rappresenta un costo.
Il debito verso il venditore è di 90 €, a meno che il contratto non stabilisca che sia il venditore a farsi carico delle spese di incasso. Solo in tal caso l'importo scende a 87 € con un corrispondente addebito di 3 € imputato al venditore.

Registrare unicamente il netto di 97 € che arriva in banca cancella in un solo colpo la vendita lorda, la commissione e il costo. La nostra guida di riferimento per la riconciliazione dei pagamenti sottolinea lo stesso concetto: scomporre il regolamento, trattare le commissioni del processore come costi e non permettere mai che il versamento netto sostituisca i ricavi.

Modellare disponibilità, riserve e pagamenti come eventi separati

Il denaro cambia stato diverse volte tra l'incasso e la disponibilità effettiva. Ogni transizione merita la propria registrazione, e una riserva non è mai una riduzione ingiustificata dei ricavi.

Quando i fondi disponibili vengono vincolati a riserva:

Conto	Dare	Avere
Debiti verso i venditori - Venditore A	15 €
Passività per riserva del venditore		15 €

Quando la riserva viene svincolata, si procede allo storno. L'obbligazione totale del venditore non è cambiata; ne è cambiato lo stato. Stripe documenta le transazioni di riserva che aumentano e svincolano i fondi accantonati, oltre ai trasferimenti per la riscossione di saldi negativi di lunga data; per questo motivo tali operazioni richiedono conti identificabili anziché una singola registrazione di compensazione.

I pagamenti (payout) prevedono una gestione in due fasi. Al momento dell'approvazione:

Conto	Dare	Avere
Debiti verso i venditori - Venditore A	90 €
Clearing pagamenti ai venditori		90 €

Al momento del regolamento bancario confermato:

Conto	Dare	Avere
Clearing pagamenti ai venditori	90 €
Banca		90 €

Se il pagamento fallisce, si storna il conto di clearing riportando l'importo nei debiti verso i venditori. Un pagamento è l'estinzione di una passività, non un costo. Trattarlo come un costo comporterebbe una duplice contabilizzazione rispetto alla vendita che aveva già registrato il debito. Stripe separa lo stato del pagamento (pending, in_transit, paid, failed, canceled) e la data di arrivo stimata rispetto all'avvio, e tali date non dovrebbero essere compresse in un unico timestamp.

Il modello di dati dall'ordine al pagamento

Il sottoconto si basa sugli eventi, non sullo stato corrente dell'ordine nell'applicazione. Ogni evento che influisce sul venditore trasporta la stessa struttura di dati (envelope):

seller_id, event_id, order_id
event_type (vendita, rimborso, chargeback, accantonamento riserva, svincolo riserva, pagamento, rettifica)
effective_date, posting_date
currency, direction, gross, commission, fees, reserve
refund_ref / dispute_ref
payout_batch_id
reversal_of
source_status, idempotency_key

A partire da tali eventi si calcola il saldo finale anziché memorizzare un campo modificabile:

Saldo finale del venditore
= saldo iniziale
+ accrediti al venditore
− addebiti al venditore
− pagamenti effettuati
± movimenti di riserva
± rettifiche

Ogni evento esterno richiede una chiave di idempotenza duratura affinché i tentativi ripetuti (retries) e i webhook duplicati non accreditino due volte un venditore o eseguano un pagamento doppio. Pattern funzionali:

Evento contabile del venditore: seller_id:order_id:event_type:version
Lotto di pagamento: processor:payout_id
Evento del processore: processor:event_type:processor_event_id

Le linee guida sui webhook di Stripe avvertono che i duplicati possono verificarsi, motivo per cui il rilevamento dei duplicati non è opzionale. Le registrazioni contabili pubblicate rimangono immutabili. Le correzioni avvengono tramite una scrittura di storno seguita da una scrittura corretta, ed è la propria struttura di eventi a trasportare il collegamento reversal_of e la causale. Il mastro conserva le registrazioni, non quel link: Nordlet espone le funzioni di creazione, lettura e elenco per le transazioni di prima nota nella sua documentazione API e non prevede funzioni di aggiornamento o eliminazione; di conseguenza, una correzione rappresenta sempre una nuova transazione piuttosto che una modifica.

Rimborsi e chargeback mantengono il collegamento, non fluttuano isolati

Un rimborso che appare nel pagamento della settimana successiva non deve mai trasformarsi in una nuova vendita negativa associata a quel pagamento. Va collegato alla transazione originaria preservando l'allocazione iniziale del venditore. A seconda del contratto:

Si storna la commissione se il contratto la rende rimborsabile
Si addebita il debito verso il venditore se quest'ultimo si fa carico del rimborso
Si addebita un conto di perdita della piattaforma se se ne fa carico quest'ultima
Si aumenta la riserva mentre una controversia è aperta, svincolandola o utilizzandola alla risoluzione

I chargeback successivi al pagamento sono il caso in cui compaiono i saldi negativi. Il denaro del venditore è già stato trasferito, quindi la piattaforma o lo recupera dai proventi futuri o si assume la perdita. Il modello deve consentire saldi negativi dei venditori e definire la regola di recupero. La rendicontazione per marketplace di Adyen mostra rimborsi e chargeback che generano righe di addebito separate per ciascun titolare di conto, livello di granularità a cui bisogna puntare.

Riconciliare per pagamento, non per mese

È necessario scomporre ogni regolamento del processore prima della registrazione e riconciliare ciascun pagamento anziché aggregare un intero mese:

Incassi lordi
− rimborsi
− commissioni del processore
− chargeback
± riserve e rettifiche
= pagamento netto del processore

Quindi bisogna verificare che quattro saldi coincidano per ciascun venditore e valuta: il sottoconto del venditore, il saldo del venditore presso il processore, il report dei pagamenti e il conto di clearing bancario. Quando differiscono, occorre classificare la discrepanza (tempistica, evento mancante, duplicato, errata attribuzione, valuta errata, pagamento fallito, chargeback imputato alla parte sbagliata). Compensare le differenze tra i totali è il modo in cui gli errori si elidono a vicenda per poi riapparire alla chiusura successiva.

Aggregare un intero mese consente alle differenze temporistiche di annullarsi a vicenda e nasconde scostamenti reali. La riconciliazione per singolo pagamento, basata sull'ID del pagamento e sul riferimento della transazione anziché su importo e data, permette di individuarli tempestivamente.

Frequenti modalità di errore

Modalità di errore	Perché è dannosa	Controllo
Pagamento lordo del cliente registrato come ricavo	Gonfia i ricavi, nasconde il debito verso il venditore	Separare debito e commissione al momento della maturazione
Registrati solo i versamenti netti	Perde il lordo, le commissioni, i rimborsi, le riserve	Scomporre ogni regolamento
Pagamento contabilizzato come costo	Rappresenta erroneamente l'estinzione di un debito	Addebitare il debito verso il venditore al momento del pagamento
Un unico campo per il saldo del venditore	Mescola importi in sospeso, disponibili, riservati, pagati	Tracciare esplicitamente gli stati del saldo
Commissione calcolata al momento del pagamento	I ricavi seguono la pianificazione dei pagamenti	Riconoscere la commissione quando viene maturata
Riserva trattata come riduzione dei ricavi	Oscura tempistica e rischio	Tracciare accantonamento, svincolo e utilizzo separatamente
Rimborso applicato all'ultimo pagamento	Interrompe l'attribuzione all'ordine	Collegare il rimborso alla transazione originaria
Modifica di registrazioni contabili pubblicate	Distrugge la pista di controllo (audit trail)	Stornare e ripubblicare
Webhook ripetuti	Accrediti e pagamenti duplicati	Chiavi di idempotenza, rilevamento dei duplicati
Corrispondenza basata solo su importo e data	Voci diverse si sovrappongono	Abbinare per ID pagamento, ID transazione, venditore, valuta

Cosa fare per primo

Mappare il flusso del denaro prima di toccare il piano dei conti. Annotare ogni evento dall'incasso del pagamento allo svincolo della riserva, indicando quali generano ricavi, quali una passività e quali modificano esclusivamente lo stato.

Successivamente, costruire un flusso end-to-end e verificarne il bilanciamento: una vendita normale, un rimborso parziale, un chargeback successivo al pagamento, una riserva trattenuta e svincolata, e un pagamento fallito. Eseguire questi test con saldi attesi noti. Se il conto di controllo dei debiti verso i venditori è uguale alla somma dei sottoconti, il clearing del processore quadra con il report di transazione e il versamento bancario coincide con l'ID del pagamento, si dispone di una struttura portante funzionante.

Attivare il blocco dei periodi contabili solo dopo che il primo mese si è chiuso correttamente con un saldo transitorio pari a zero. Bloccare troppo presto serve solo a congelare gli errori.

Nordlet registra i regolamenti secondo questi principi nativamente: la commissione della piattaforma va nei ricavi da commissioni, la quota del venditore in un debito verso i venditori, le commissioni del processore in un costo per servizi di pagamento e tutto ciò che non è ancora attribuito in un conto transitorio. I periodi contabili rimangono aperti finché non vengono bloccati esplicitamente, consentendo di chiudere il primo mese non appena il conto transitorio risulta azzerato. La pagina delle funzionalità elenca ciò che è incluso.

FAQ

Il pagamento dell'acquirente è mai un ricavo della piattaforma?

Solo per i beni o servizi specifici in cui la piattaforma agisce come principale. Per la vendita tramite marketplace in qualità di agente dei beni di un venditore, il ricavo è costituito dalla commissione e la quota del venditore è una passività. Una piattaforma può agire come principale per un servizio di evasione ordini e come agente per i beni sottostanti nello stesso ordine, pertanto la valutazione va fatta per singolo bene o servizio specificato, non per azienda.

Le riserve dovrebbero ridurre i ricavi?

No. Una riserva rappresenta un'allocazione temporale e di rischio, non una rettifica di ricavo. I fondi vanno spostati dal debito verso il venditore a una passività per riserva al momento dell'accantonamento, stornandoli al momento dello svincolo. I ricavi e le commissioni non sono influenzati dal fatto che il denaro del venditore sia attualmente accantonato a riserva.

Come si prevengono pagamenti doppi dovuti ai tentativi ripetuti dei webhook?

È necessario associare una chiave di idempotenza a ogni evento esterno, come ad esempio processor:payout_id per i lotti di pagamento, rilevando gli eventi duplicati in fase di scrittura. I fornitori avvertono esplicitamente che si verificano consegne duplicate di webhook, pertanto il mastro deve rifiutare il secondo tentativo anziché registrarlo nuovamente.

Il saldo di un venditore può diventare negativo?

Sì, e il modello deve consentirlo. Un chargeback che arriva dopo che il venditore è già stato pagato lascia alla piattaforma un credito verso il venditore oppure una perdita da assorbire. Sopprimere i saldi negativi serve solo a nascondere un'obbligazione non registrata.

Perché riconciliare ciascun pagamento anziché il totale mensile?

Perché le differenze temporistiche e gli errori si annullano quando si aggrega un mese intero, facendo tornare i totali anche se le singole transazioni sono errate. La riconciliazione per singolo pagamento, basata su ID di pagamento e di transazione, fa emergere eventi mancanti, duplicati e chargeback erroneamente attribuiti prima della chiusura.