I tuoi pagamenti di gennaio provenivano da Lemon Squeezy e quelli di agosto arrivano da Paddle, e ora il tuo commercialista pone una domanda a cui nessuna delle due dashboard può rispondere da sola: quanti ricavi da abbonamento hai effettivamente guadagnato quest'anno? Il vecchio fornitore incassava secondo un unico listino di commissioni, un'unica cadenza di pagamento e un unico insieme di fatture fiscali emesse dalle proprie entità. Il nuovo fornitore svolge lo stesso lavoro con report diversi, righe di commissioni diverse e documentazione diversa. Tra i due si colloca un saldo di ricavi differiti, una pila di piani annuali venduti su una piattaforma e serviti su un'altra, e una chiusura di fine anno che deve cucire due libri contabili incompatibili in un unico insieme credibile di scritture. È proprio questa cucitura — non l'integrazione API, che richiede giorni — il punto in cui le migrazioni merchant-of-record falliscono silenziosamente.
Questa è una decisione concreta per migliaia di venditori in questo momento. Stripe ha acquisito Lemon Squeezy nel luglio 2024, e l'aggiornamento di gennaio 2026 di Lemon Squeezy affermava che il suo futuro è un percorso di migrazione agevole verso Stripe Managed Payments, il prodotto merchant-of-record di Stripe stesso. Non è stata pubblicata alcuna scadenza e Lemon Squeezy funziona ancora, ma i venditori che non vogliono essere migrati secondo i tempi altrui stanno valutando gli indipendenti: Paddle e Polar, entrambi veri merchant of record allo stesso prezzo di listino del 5 percento più 50 centesimi. Se sei tra loro, il cambio del sistema di fatturazione è la parte facile. Mantenere la contabilità credibile durante il passaggio è il vero progetto.
Che cosa è davvero un merchant of record nei tuoi libri contabili
Un merchant of record è il venditore legale del tuo prodotto, non solo il tuo processore di pagamenti. Quando un cliente acquista tramite Paddle, Polar o Lemon Squeezy, l'estratto conto della carta indica il fornitore, la fattura fiscale è emessa da una delle entità del fornitore stesso, e le registrazioni dell'imposta sulle vendite e dell'IVA in Germania, Giappone o Texas appartengono al fornitore e non a te. Il fornitore calcola, incassa, dichiara e versa l'imposta, assorbe il rischio di chargeback e ti invia un pagamento per il resto.
Questa struttura legale determina l'aspetto delle tue registrazioni contabili. La fattura all'acquirente documenta la vendita del fornitore al tuo cliente — è la loro fattura, non la tua. Il tuo lato della transazione è documentato da registrazioni lato venditore: una fattura inversa che descrive la tua fornitura al fornitore e un avviso di pagamento che registra l'importo di ciascun pagamento. I tuoi ricavi sono un pagamento, al netto della commissione del fornitore, che arriva secondo la cadenza del fornitore anziché in modo continuo. La versione di quei documenti di ogni fornitore è diversa, ed è esattamente per questo che gestirne due in un solo anno divide le tue registrazioni in due.
La decisione lordo-contro-netto che devi prendere una volta sola
Prima di toccare l'una o l'altra piattaforma, risolvi l'unica politica contabile che la migrazione ti obbliga a difendere: riconosci come ricavo l'intero importo pagato dal cliente (lordo), o solo il pagamento che hai ricevuto (netto)?
Secondo l'ASC 606, questa è la questione principal-versus-agent, e si risolve in base al controllo — non in base a chi ha emesso la fattura o a chi compare sull'estratto conto della carta. La guida si trova negli ASC 606-10-55-36 fino a 55-40: un'entità è un principal se controlla il bene o servizio specificato prima di trasferirlo al cliente, e riporta i ricavi al lordo; se la sua promessa è solo quella di organizzare che un'altra parte lo fornisca, l'entità è un agent e riporta solo la propria commissione al netto. Per un fornitore di software che vende tramite un merchant of record in stile rivenditore, la stessa analisi stabilisce chi è il tuo cliente. Se il tuo cliente è l'utente finale, il ricavo è il prezzo per l'utente finale e la quota del fornitore è un costo di vendita sotto la linea dei ricavi. Se il tuo cliente è il fornitore stesso, il ricavo è il prezzo che il fornitore ti ha pagato — il pagamento.
Il profitto lordo è identico in entrambi i casi. Il ricavo riportato no, e quel numero alimenta il tuo tasso di crescita, i tuoi multipli di ricavo in un aumento di capitale o in un'acquisizione, e ogni confronto periodo-su-periodo che il tuo consiglio legge. La maggior parte dei fornitori di software che vendono tramite marketplace e rivenditori arriva al trattamento al lordo, ma entrambe le risposte sono difendibili se la tua analisi le supporta. Ciò che non è difendibile è la deriva: registrare i pagamenti di Lemon Squeezy al netto nella prima metà dell'anno e i pagamenti di Paddle al lordo nella seconda metà perché i report del nuovo fornitore rendevano il lordo più facile. Scegli una politica, scrivi l'analisi del controllo in un memo che il tuo revisore possa leggere, e applicala in modo identico ai pagamenti di entrambi i fornitori per l'intero anno.
Le cinque giunture in cui l'anno si divide in due
1. Gli abbonamenti non migrano; i clienti si riabbonano. Non esiste una migrazione automatica dei token tra processori di pagamento. Le carte salvate generalmente non possono essere esportate da un merchant of record in forma utilizzabile, quindi prevedi che gli abbonati reinseriscano i dati di pagamento sulla nuova piattaforma — oppure conferma per iscritto, prima di impegnarti, che il nuovo fornitore può trasferire per te gli abbonamenti attivi e le carte salvate. Finché ogni cliente non si riabbona, la vecchia piattaforma continua a fatturargli, il che significa che i due sistemi funzionano affiancati per mesi e la chiusura di ogni mese riconcilia due flussi di pagamento.
2. I prezzi grandfathering e le ancore di rinnovo devono essere ricostruiti a mano. Ogni abbonamento attivo porta con sé un prezzo, una data di rinnovo e spesso un piano grandfathering non più venduto. La nuova piattaforma non ne sa nulla finché non lo ricrei: prodotti, prezzi, piani legacy detenuti solo da clienti esistenti, comportamento delle prove, coupon, regole fiscali inclusive, e ancore di rinnovo. Salta un prezzo grandfathering e un cliente fedele viene addebitato alla nuova tariffa — un disastro per l'assistenza che registra anche ricavi che poi devi stornare.
3. I piani annuali creano un cutover dei ricavi differiti. Un cliente che ha acquistato un piano annuale da $1.200 a marzo ha pagato il vecchio fornitore, ma tu guadagni quel ricavo mese per mese fino al febbraio successivo. Alla data del cutover, parte di quel denaro è ancora non maturato, e resta nel tuo stato patrimoniale come ricavo differito indipendentemente da quale piattaforma serva i mesi rimanenti. I report del nuovo fornitore non mostreranno mai quella passività — conosce solo le vendite effettuate tramite lui — quindi la migrazione deve riportare il saldo esplicitamente, altrimenti i tuoi ricavi del secondo semestre sono sovrastimati dal denaro che hai già incassato.
4. Rimborsi e chargeback attraversano il cutover. Un rimborso emesso ad agosto per una vendita effettuata a maggio vive nel sistema del vecchio fornitore, secondo le vecchie regole sulle commissioni, mentre il ricavo che storna potrebbe essere già stato riconosciuto su due trimestri. Ogni fornitore assorbe i chargeback in qualità di merchant of record, ma le scritture contabili — storno del ricavo, registrazione di eventuali commissioni non rimborsabili, rettifica del pagamento che hai già ricevuto — finiscono nei tuoi libri, e i report di rettifica di ciascun fornitore le formattano diversamente.
5. Tempi di pagamento, valuta e documentazione fiscale cambiano tutti insieme. Le cadenze dei pagamenti variano da fornitore a fornitore, quindi le vendite della stessa settimana possono finire negli estratti conto di mesi diversi prima e dopo il passaggio. I venditori transfrontalieri affrontano nuove righe di cambio valuta e nuovi dettagli delle commissioni. E ogni fornitore riporta le proprie dichiarazioni fiscali secondo le proprie registrazioni, mentre i venditori statunitensi possono ricevere reportistica di pagamento separata da ciascuna piattaforma per l'anno. Nessuno di questi sono errori; sono due sistemi corretti che dissentono nel formato, e la tua chiusura deve normalizzarli tutti su un unico piano dei conti.
Il manuale di migrazione sicuro per la finanza
Procedi in questo ordine, e non comprimere il funzionamento in parallelo.
1. Fissa la data del cutover su un confine di periodo. I cutover a metà mese dividono i periodi di abbonamento, la proroga e i lotti di pagamento attraverso la giuntura. Un cutover a fine mese o a fine trimestre ti dà popolazioni pulite prima e dopo, e un'unica chiusura che contiene l'intera transizione.
2. Congela ed esporta tutto dalla vecchia piattaforma. Blocca i periodi contabili che il vecchio fornitore ha già fatturato. Esporta il catalogo completo dei piani, ogni abbonamento attivo con il suo prezzo e la data di rinnovo, la cronologia completa delle fatture e ogni report di pagamento con i dettagli delle commissioni. Mantieni il vecchio account in sola lettura, non cancellato, per almeno un ciclo di revisione completo — revisori e autorità fiscali chiedono specificamente dell'anno di migrazione proprio perché si aspettano la giuntura.
3. Ricrea il catalogo dei piani, inclusi i piani che non vendi più. I piani legacy e grandfathering devono esistere nel nuovo sistema prima che il primo cliente migrato si rinnovi lì. Documenta ogni mappatura da un vecchio ID di piano a uno nuovo; quella tabella di mappatura è la traccia di revisione che spiega perché le fatture di luglio sembrano diverse da quelle di giugno per lo stesso cliente.
4. Metti prima i nuovi clienti sulla nuova piattaforma. Esegui il nuovo fornitore in parallelo per le nuove vendite mentre gli abbonamenti esistenti arrivano al rinnovo sul vecchio, poi sposta le coorti ai confini naturali — date di rinnovo, fine mese, mai a metà ciclo. Ogni coorte ottiene la propria riconciliazione prima che inizi la successiva. Un cutover big-bang concentra ogni errore di riabbonamento, ogni piano grandfathering mancato e ogni caso limite di proroga in un'unica chiusura.
5. Mappa i report di pagamento di entrambi su un unico piano dei conti. Prima della prima chiusura che include entrambi i fornitori, costruisci la traduzione: ogni riga di commissione, riga fiscale, rettifica e codice di rimborso su ciascun report si mappa su uno dei tuoi conti di contabilità. I due fornitori non useranno mai le stesse etichette. Senza la mappatura, il tuo contabile la inventa in modo diverso ogni mese.
6. Riconcilia esplicitamente i ricavi differiti. Riconcilia il saldo non maturato piano per piano alla data del cutover, e registra qualsiasi differenza tra le registrazioni della vecchia piattaforma e il tuo libro contabile come una rettifica esplicita con una causa documentata — non come una voce di quadratura. Dal cutover in poi, riconosci il saldo rimanente secondo il piano, indipendentemente da quale piattaforma serva il cliente.
Come appare il mese del cutover nel tuo libro contabile
La connessione contabile è semplice una volta che separi i due fornitori con una tracciatura distinta delle commissioni invece di lasciare che entrambi registrino direttamente nei ricavi. Riconosci ogni pagamento al lordo — l'intero pagamento del cliente come ricavo, la quota del fornitore come spesa di vendita — e continua a riconoscere i saldi differiti pre-cutover secondo il loro piano originale. La documentazione di Beancount illustra la sintassi del libro contabile usata qui sotto, se qualcosa non ti è familiare.
Supponi che un cliente abbia acquistato un piano annuale da $1.200 tramite Lemon Squeezy a metà marzo. Il pagamento di marzo è arrivato al netto della commissione del 5 percento più 50 centesimi ($60,50), e al 30 giugno hai riconosciuto quattro mesi di ricavi ($400), lasciando $800 non maturati. Il 1° luglio è la tua data di cutover, e a luglio viene venduto un nuovo abbonamento mensile da $49 tramite Paddle. In un libro contabile in testo semplice appare così:
2026-01-01 open Income:SaaS:Subscriptions
2026-01-01 open Liabilities:Deferred-Revenue
2026-01-01 open Expenses:MoR-Fees:LemonSqueezy
2026-01-01 open Expenses:MoR-Fees:Paddle
2026-01-01 open Assets:Checking
2026-03-15 * "Annual plan sale via Lemon Squeezy, buyer paid 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Recognize June portion of annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Monthly plan sale via Paddle, buyer paid 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Recognize July portion of pre-cutover annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDTre dettagli sostengono l'intera migrazione. Primo, le commissioni di ciascun fornitore si registrano sul proprio sottoconto, così i totali di fine anno mostrano esattamente quanto ti è costata ogni piattaforma e i due listini di commissioni non si mescolano mai. Secondo, la scrittura di riconoscimento di luglio per la vendita di marzo è invariata dal cutover — i ricavi differiti sono una tua passività, maturati secondo il tuo piano, e non importa quale piattaforma abbia incassato il denaro. Terzo, ogni scrittura si collega a uno specifico report di pagamento: l'avviso di pagamento di Lemon Squeezy di marzo per la prima, il pagamento di Paddle di luglio per la terza. Quando il tuo commercialista chiede come sono stati guadagnati i ricavi dell'anno, ogni numero rimanda alla documentazione di esattamente un fornitore.
Chiudi la giuntura deliberatamente
Una migrazione merchant-of-record sono due progetti che portano un solo nome: spostare la fatturazione, che i tuoi ingegneri completano in settimane, e spostare i libri contabili, con cui il tuo contabile convive per un anno. Il progetto di fatturazione termina quando l'ultimo cliente si riabbona. Il progetto dei libri contabili termina quando ogni pagamento di entrambi i fornitori si riconcilia con la banca, ogni riga di commissione si mappa su un unico piano dei conti, il saldo dei ricavi differiti attraversa in modo pulito la data del cutover, e il memo lordo-contro-netto nel tuo fascicolo di revisione copre entrambe le metà dell'anno sotto un'unica politica. Programma il cutover su un confine di periodo, esegui le nuove vendite sulla nuova piattaforma mentre i vecchi abbonamenti arrivano al rinnovo, e mantieni il vecchio sistema leggibile finché i revisori non hanno visto l'anno di migrazione. Così facendo, il passaggio è una nota a piè di pagina nel bilancio dell'anno prossimo invece della varianza che nessuno riesce a spiegare.
