Apri App Store Connect o la Google Play Console e vedrai un numero che sembra essere il tuo fatturato. Il mese scorso indicava $ 10.000. Il tuo conto bancario ha ricevuto $ 7.000. Nessuno dei due numeri è sbagliato — ma solo uno di essi appartiene al tuo conto economico come "entrate", e sbagliare questa decisione può silenziosamente distorcere il tuo margine lordo, falsare il tuo tasso di crescita, e fornire a un finanziatore o investitore un quadro della tua attività che non è vero.
Questo è il problema principale-vs-agente, e secondo lo standard di riconoscimento delle entrate ASC 606 dei GAAP statunitensi, non è una formalità opzionale — è la regola che decide se segnali $ 10.000 di entrate e $ 3.000 di costo del venduto, o solo $ 7.000 di entrate senza altro da dire. Per uno sviluppatore indipendente che vende tramite l'App Store di Apple o il Google Play Store, la risposta di solito sorprende.
La Domanda Che Ogni Sviluppatore di App Prima o Poi Si Pone
L'innesco è quasi sempre lo stesso: un fondatore sta preparando una presentazione per investitori, richiedendo un prestito per piccole imprese, o semplicemente cercando di rispondere a "quanto ho effettivamente guadagnato questo trimestre," e si rende conto di aver registrato come "vendite" tutto ciò che è arrivato sul conto bancario. Quel numero è al netto della commissione di Apple o Google — significa che ha già la quota della piattaforma sottratta.
Il problema è che nettarizzare le entrate contro una commissione di piattaforma non è una scelta stilistica. L'ASC 606 ha un test specifico per esattamente questa situazione, e si basa su una domanda: chi controlla la cosa venduta prima che passi di mano al cliente?
Il Test di Controllo dell'ASC 606, in Parole Semplici
Il modello di riconoscimento delle entrate in cinque fasi dell'ASC 606 richiede di identificare le obbligazioni di performance in un contratto e determinare chi le soddisfa. Quando una piattaforma o marketplace si interpone tra te e il cliente finale — Apple, Google, Etsy, DoorDash, Uber — gli standard contabili chiamano questo la valutazione principale versus agente, e la guida alle entrate di PwC osserva che le vendite dell'app store sono un esempio da manuale di accordi che richiedono questo esame attento.
- Principale: controlli il bene o servizio prima che venga trasferito al cliente. Riconosci l'importo lordo e completo che il cliente ha pagato come entrate, e la commissione della piattaforma diventa un costo del venduto (una spesa), non una riduzione delle entrate.
- Agente: la piattaforma controlla l'offerta e tu stai solo organizzando la vendita per conto di qualcun altro. Riconosci solo l'importo netto che trattieni come tua commissione.
Tre indicatori decidono quale dei due sei, secondo i quadri di riferimento di Deloitte e PwC:
- Responsabilità di adempimento — chi è responsabile se l'app non funziona, l'abbonamento non viene erogato, o un cliente si lamenta? Di solito sei tu, lo sviluppatore, non Apple.
- Rischio prima del trasferimento — chi sopporta il rischio che l'"inventario" (la tua app, i tuoi contenuti, il tuo livello di abbonamento) non venda o non soddisfi il cliente? Anche qui, tipicamente tu.
- Discrezionalità nella determinazione del prezzo — chi stabilisce ciò che il cliente effettivamente paga? Scegli tu la fascia di prezzo della tua app; la piattaforma non la negozia con te contratto per contratto.
Poiché la maggior parte degli sviluppatori indipendenti controlla l'esperienza del prodotto, possiede la relazione con il cliente per supporto e aggiornamenti, e stabilisce i propri prezzi, si collocano dalla parte del principale nel test — il che significa che la contabilità corretta è registrare l'importo lordo pagato dal cliente come entrate, e trattare la quota di Apple o Google come una voce di costo del venduto, non come una riduzione invisibile.
I Numeri Dietro la Commissione
Sapere di essere il principale ha senso solo se sai cosa viene effettivamente detratto. Le strutture delle commissioni di piattaforma sono cambiate significativamente negli ultimi anni, e la maggior parte degli sviluppatori sta ancora facendo budget basandosi su presupposti obsoleti:
| Piattaforma | Tariffa standard | Tariffa ridotta | Chi ne ha diritto |
|---|---|---|---|
| Apple App Store | 30% | 15% (Programma Small Business App Store) | Sviluppatori con ≤$ 1M di guadagni annuali sull'app store |
| Abbonamenti Apple | 30% (anno 1) | 15% (dal secondo anno in poi) | Qualsiasi abbonamento oltre i primi 12 mesi |
| Google Play | 30% | 15% sui primi $ 1M guadagnati all'anno | Tutti gli sviluppatori, a scaglioni automatici |
| Abbonamenti Google Play | 15% fisso | — | Tutte le entrate da abbonamenti |
| Apple UE (termini Digital Markets Act) | ~17% + Core Technology Fee | fino a ~20% combinati | Sviluppatori che aderiscono ai termini commerciali alternativi dell'UE |
Più costi annuali fissi che la maggior parte delle persone dimentica di allocare da qualche parte: la quota annuale di $ 99/anno del programma per sviluppatori Apple, e la tassa di registrazione una tantum di $ 25 di Google. Piccoli, ma appartengono anch'essi al tuo piano dei conti — di solito come spese operative generali, non costi del venduto.
Registrarlo Correttamente: Un Esempio Pratico
Supponiamo che un cliente acquisti un abbonamento in-app di $ 9,99 tramite Apple, e che tu sia sotto la tariffa standard del 30%. Apple incassa i $ 9,99 dal cliente, trattiene $ 3,00, e alla fine deposita $ 6,99 sul tuo conto bancario. Registrare $ 6,99 come "entrate" sottostima la tua prima linea del 30% — il che conta enormemente se stai confrontando il tuo tasso di crescita con un concorrente che vende direttamente, o spiegando i tuoi margini a un finanziatore.
Le registrazioni corrette riconoscono l'intera vendita, poi contabilizzano separatamente la commissione come spesa:
2026-07-18 * "Apple" "Abbonamento iOS — vendita lorda"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "Apple" "Commissione App Store 30%"
Expenses:CostOfRevenue:PlatformFees 3.00 USD
Assets:Receivable:AppStore -3.00 USD
2026-07-20 * "Apple" "Pagamento ricevuto"
Assets:Checking 6.99 USD
Assets:Receivable:AppStore -6.99 USDNota che il conto dei crediti si azzera una volta che il pagamento viene liquidato, ma il tuo conto economico mostra ancora $ 9,99 di entrate e $ 3,00 di costo del venduto — un margine lordo del 70% su quella vendita, non un misterioso 30% mancante. Questo è esattamente il tipo di transazione che i registri contabili in testo semplice e versionati gestiscono bene: la vendita lorda, la commissione di piattaforma e il pagamento sono tre eventi distinti e verificabili invece di un unico deposito bancario sfocato.
Perché il Numero della Dashboard Non Basta
Anche una volta che conosci la regola, applicarla manualmente è più difficile di quanto sembri. I report standard di App Store Connect e Play Console mostrano totali aggregati, non il dettaglio a livello di abbonato e transazione che l'ASC 606 tecnicamente richiede — proventi, rimborsi e conversione di valuta spesso arrivano in un'unica somma forfettaria giorni o settimane dopo la vendita effettiva. Questo divario è esattamente il motivo per cui un numero crescente di attività basate su abbonamenti usa API di piattaforma o strumenti come RevenueCat per ricostruire il dettaglio per transazione piuttosto che cercare di ricostruirlo al contrario da un PDF di riepilogo mensile.
Saltare questo passaggio ha un costo reale. Un esempio ampiamente citato: uno sviluppatore ha guardato i $ 3.400 che apparivano nella sua dashboard per il mese, e dopo commissioni, tasse e altre detrazioni della piattaforma, solo $ 1.294 erano utilizzabili — un divario superiore al 60% tra le "entrate" che pensava di avere e ciò che l'attività aveva effettivamente trattenuto. Gli sviluppatori che prendono decisioni di assunzione o di spesa basandosi sul numero della dashboard, invece che sulla cifra riconciliata, stanno facendo budget su un numero che non è mai stato reale.
Errori Comuni Che Distorcono i Tuoi Libri Contabili
- Registrare solo il deposito netto come entrate. Questo è l'errore più comune ed è ciò di cui parla questo articolo — sottostima sia le entrate che i costi del venduto, appiattendo il quadro del margine lordo in qualcosa di privo di significato.
- Ignorare rimborsi e storni di addebito. Apple e Google processano entrambi i rimborsi dei clienti per tuo conto, a volte settimane dopo la vendita originale — se non stai riconciliando per transazione, le entrate rimborsate possono rimanere sui tuoi libri contabili indefinitamente.
- Mescolare la quota di $ 99 per sviluppatori Apple o la tassa di registrazione di $ 25 Google nei costi del venduto. Questi sono costi operativi fissi, non commissioni a livello di transazione — appartengono a una categoria di spesa completamente diversa.
- Dimenticare il programma tariffario separato dell'UE. Se una parte della tua base utenti è nell'UE e hai aderito ai termini alternativi di Apple, quella entrata ha una struttura di commissioni diversa dal resto della tua attività e necessita del proprio conto.
Mantieni le Tue Finanze Organizzate Mentre Cresci
Che tu sia uno sviluppatore singolo con un'app nello store o gestisca un piccolo studio con una manciata di prodotti in abbonamento, la decisione lordo-vs-netto si accumula ogni mese in cui la sbagli — quando arrivi a raccogliere un round di finanziamento o a richiedere un prestito, una linea di entrate sottostimata è una cosa difficile da spiegare. Beancount.io offre agli sviluppatori un registro contabile in testo semplice e versionato, progettato esattamente per questo tipo di transazione multi-fase — vendita lorda, commissione di piattaforma e pagamento come tre voci separate e verificabili invece di un unico deposito bancario confuso. Inizia gratuitamente e scopri perché gli sviluppatori che già pensano in codice preferiscono una contabilità che funziona allo stesso modo.