Obriu l'App Store Connect o la Google Play Console i veureu un nombre que sembla el vostre ingrés. El mes passat deia 10.000 €. El vostre compte bancari va rebre 7.000 €. Cap dels dos nombres és incorrecte, però només un d'ells pertany al vostre compte de resultats com a "ingressos", i equivocar-vos en aquesta decisió pot distorsionar silenciosament el vostre marge brut, falsejar la vostra taxa de creixement i donar a un prestador o inversor una imatge del vostre negoci que no és real.
Aquesta és la qüestió principal-versus-agent, i segons l'estàndard de reconeixement d'ingressos ASC 606 dels US GAAP, no és un tràmit opcional, sinó la regla que decideix si reporteu 10.000 € en ingressos i 3.000 € en cost de vendes, o simplement 7.000 € en ingressos sense res més a dir. Per a un desenvolupador independent que ven a través de l'App Store d'Apple o la Google Play Store, la resposta sol sorprendre la gent.
La Pregunta que Tots els Desenvolupadors d'Apps es Fan Tard o D'hora
El detonant és gairebé sempre el mateix: un fundador està preparant un pitch deck, sol·licitant un préstec per a petites empreses o simplement intentant respondre "quant vaig guanyar realment aquest trimestre", i s'adona que ha estat registrant tot el que arribava al seu compte bancari com a "vendes". Aquest nombre és net de la comissió d'Apple o Google, és a dir, ja té descomptada la part de la plataforma.
El problema és que netejar els vostres ingressos contra una comissió de plataforma no és una elecció d'estil. L'ASC 606 té una prova específica per a aquesta situació, i es basa en una pregunta: qui controla la cosa que es ven abans que canviï de mans amb el client?
El Test de Control de l'ASC 606, en Termes Senzills
El model d'ingressos de cinc passos de l'ASC 606 requereix que identifiqueu les obligacions de rendiment en un contracte i determineu qui les satisfà. Quan un mercat o plataforma se situa entre vosaltres i el client final — Apple, Google, Etsy, DoorDash, Uber — les normes comptables anomenen això l'avaluació principal versus agent, i la guia d'ingressos de PwC assenyala que les vendes d'App Store són un exemple clàssic d'acords que requereixen aquesta anàlisi acurada.
- Principal: controleu el bé o servei abans que es transfereixi al client. Reconeixeu l'import total i brut que el client va pagar com a ingressos, i la comissió de la plataforma es converteix en un cost de vendes (una despesa), no una reducció d'ingressos.
- Agent: la plataforma controla l'oferta i vosaltres només us encarregueu d'organitzar la venda en nom d'un altre. Reconeixeu només l'import net que us quedeu com a comissió.
Tres indicadors decideixen quin sou, segons els marcs de Deloitte i PwC:
- Responsabilitat de compliment — qui és el responsable si l'app no funciona, la subscripció no es lliura o un client es queixa? Normalment sou vosaltres, el desenvolupador, no Apple.
- Risc abans de la transferència — qui assumeix el risc que l'"inventari" (la vostra app, el vostre contingut, el vostre nivell de subscripció) no es vengui o no satisfaci el client? De nou, normalment vosaltres.
- Discreció sobre el preu — qui estableix què paga realment el client? Vosaltres trieu el nivell de preu de la vostra app; la plataforma no el negocia amb vosaltres cas per cas.
Com que la majoria de desenvolupadors independents controlen l'experiència del producte, tenen la relació amb el client per al suport i les actualitzacions, i estableixen els seus propis preus, acaben a la banda de principal del test, cosa que significa que la comptabilitat correcta és registrar l'import brut que el client va pagar com a ingressos i tractar la part d'Apple o Google com una línia de cost d'ingressos, no com una reducció invisible.
Els Nombres Darrere de la Comissió
Saber que sou el principal només importa si sabeu què es dedueix exactament. Les estructures de comissions de les plataformes han canviat significativament en els darrers anys, i la majoria de desenvolupadors encara fan pressupostos basats en suposicions obsoletes:
| Plataforma | Tarifa estàndard | Tarifa reduïda | Qui qualifica |
|---|---|---|---|
| App Store d'Apple | 30% | 15% (App Store Small Business Program) | Desenvolupadors amb ingressos anuals ≤1M $ a l'App Store |
| Subscripcions d'Apple | 30% (any 1) | 15% (a partir de l'any 2) | Qualsevol subscripció després dels primers 12 mesos |
| Google Play | 30% | 15% sobre els primers 1M $ guanyats per any | Tots els desenvolupadors, escalat automàticament |
| Subscripcions de Google Play | 15% fixa | — | Tots els ingressos per subscripció |
| Apple UE (termes de la Llei de Mercats Digitals) | ~17% + Core Technology Fee | fins a ~20% combinat | Desenvolupadors que optin pels termes comercials alternatius de la UE |
A més de costos anuals fixos que la majoria oblida assignar en algun lloc: la quota de 99 de Google. Petits, però pertanyen a algun lloc del vostre pla comptable també, normalment com a despesa general d'operació, no com a cost de vendes.
Com Registrar-ho Correctament: Un Exemple Pràctic
Suposem que un client compra una subscripció dins l'app de 9,99 € a través d'Apple, i esteu sota la tarifa estàndard del 30%. Apple cobra els 9,99 € al client, es queda 3,00 € i finalment diposita 6,99 € al vostre compte bancari. Registrar 6,99 € com a "ingressos" infravalora la vostra línia superior en un 30%, cosa que importa enormement si compareu la vostra taxa de creixement amb un competidor que ven directament, o si expliqueu els vostres marges a un prestador.
Les anotacions correctes reconeixen la venda completa i després registren la comissió per separat com a despesa:
2026-07-18 * "Apple" "Subscripció iOS — venda bruta"
Actius:ComptesACobrar:AppStore 9.99 USD
Ingressos:VendesApp -9.99 USD
2026-07-18 * "Apple" "Comissió App Store del 30%"
Despeses:CostIngressos:ComissionsPlataforma 3.00 USD
Actius:ComptesACobrar:AppStore -3.00 USD
2026-07-20 * "Apple" "Cobrament rebut"
Actius:CompteCorrent 6.99 USD
Actius:ComptesACobrar:AppStore -6.99 USDFixeu-vos que el compte a cobrar es neteja a zero un cop el pagament es liquida, però el vostre compte de resultats encara mostra 9,99 € en ingressos i 3,00 € en cost d'ingressos — un marge brut del 70% en aquella venda, no un 30% misteriosament desaparegut. Aquest és exactament el tipus de transacció que els llibres majors de text pla i control de versions gestionen bé: la venda bruta, la comissió de plataforma i el cobrament són tres esdeveniments diferents i auditables en lloc d'un sol dipòsit bancari borrós.
Per Què el Nombre del Panell de Control No és Suficient
Fins i tot un cop coneixeu la regla, aplicar-la manualment és més difícil del que sembla. Els informes estàndard d'App Store Connect i Play Console mostren totals agregats, no els detalls a nivell de subscriptor o transacció que l'ASC 606 teòricament demana — ingressos, reemborsaments i conversió de moneda sovint arriben en una suma global dies o setmanes després de la venda real. Aquest desfasament és exactament per què un nombre creixent d'empreses d'apps per subscripció utilitzen les API de les plataformes o eines com RevenueCat per reconstruir el detall per transacció en lloc d'intentar fer enginyeria inversa a partir d'un PDF de resum mensual.
Saltar-se aquest pas té un cost real. Un exemple àmpliament citat: un desenvolupador va veure 3.400 eren gastables — una diferència de més del 60% entre els "ingressos" que pensaven que tenien i el que el negoci va retenir realment. Els desenvolupadors que prenen decisions de contractació o despesa basant-se en el nombre del panell, en lloc de la xifra reconciliada, estan fent pressupostos contra un nombre que mai va ser real.
Errors Comuns que Distorsionen els Vostres Llibres
- Registrar només el dipòsit net com a ingressos. Aquest és l'error més comú i del qual tracta aquest article — infravalora tant els ingressos com el cost de vendes, aplanant la vostra imatge de marge brut fins a fer-la sense sentit.
- Ignorar reemborsaments i contracàrrecs. Apple i Google processen els reemborsaments dels clients en nom vostre, de vegades setmanes després de la venda original — si no feu la reconciliació per transacció, els ingressos reemborsats poden quedar-se als vostres llibres indefinidament.
- Barrejar la quota de 99 de Google al cost de vendes. Aquests són costos operatius fixos, no comissions a nivell de transacció — pertanyen a un grup de despeses diferent.
- Oblidar el calendari de tarifes separat de la UE. Si una part de la vostra base d'usuaris és a la UE i heu optat pels termes alternatius d'Apple, aquests ingressos tenen una estructura de comissions diferent de la resta del vostre negoci i necessiten el seu propi compte.
Mantingueu les Vostres Finances Organitzades a Mesura que Creixeu
Tant si sou un desenvolupador autònom amb una sola app a la botiga com si dirigiu un petit estudi amb un grapat de productes de subscripció, la decisió entre brut i net es va acumulant cada mes que us equivoqueu — quan esteu recaptant una ronda d'inversió o sol·licitant finançament, una línia d'ingressos infravalorada és difícil d'explicar. Beancount.io ofereix als desenvolupadors un llibre major en text pla i amb control de versions dissenyat exactament per a aquest tipus de transacció de múltiples passos — venda bruta, comissió de plataforma i cobrament com a tres entrades separades i auditables en lloc d'un sol dipòsit bancari borrós. Comença gratuïtament i descobreix per què els desenvolupadors que ja pensen en codi prefereixen una comptabilitat que funciona de la mateixa manera.