Abre App Store Connect o Google Play Console y verás un número que parece tus ingresos. El mes pasado mostraba 7,000. Ninguno de los dos números es incorrecto, pero solo uno de ellos pertenece a tu estado de resultados como "ingresos", y tomar esa decisión al revés puede distorsionar silenciosamente tu margen bruto, tergiversar tu tasa de crecimiento y presentar a un prestamista o inversor una imagen de tu negocio que no es real.
Esta es la cuestión de principal versus agente, y según el estándar de reconocimiento de ingresos ASC 606 de los GAAP de EE. UU., no es un trámite opcional, es la regla que decide si reportas 3,000 en costo de ventas, o simplemente $7,000 en ingresos sin nada más que añadir. Para un desarrollador independiente que vende a través de la App Store de Apple o Google Play Store, la respuesta suele sorprender a la gente.
La Pregunta que Todo Desarrollador de Apps se Hace Tarde o Temprano
El detonante casi siempre es el mismo: un fundador está preparando una presentación para inversores, solicitando un préstamo para pequeñas empresas, o simplemente tratando de responder "cuánto gané realmente este trimestre", y se da cuenta de que ha estado registrando como "ventas" lo que llegaba a su cuenta bancaria. Ese número es neto de la comisión de Apple o Google, es decir, ya tiene descontada la parte de la plataforma.
El problema es que netear tus ingresos contra una tarifa de plataforma no es una elección de estilo. El ASC 606 tiene una prueba específica para exactamente esta situación, y se basa en una pregunta: ¿quién controla lo que se vende antes de que pase a manos del cliente?
La Prueba de Control del ASC 606, en Lenguaje Sencillo
El modelo de ingresos de cinco pasos del ASC 606 requiere que identifiques las obligaciones de desempeño en un contrato y determines quién las está cumpliendo. Cuando un mercado o plataforma se interpone entre tú y el cliente final (Apple, Google, Etsy, DoorDash, Uber), las normas contables llaman a esto la evaluación de principal versus agente, y la guía de ingresos de PwC señala que las ventas en las tiendas de aplicaciones son un ejemplo clásico de acuerdos que requieren este análisis cuidadoso.
- Principal: controlas el bien o servicio antes de que se transfiera al cliente. Reconoces el importe total bruto que pagó el cliente como ingreso, y la comisión de la plataforma se convierte en un costo de ventas (un gasto), no una reducción de los ingresos.
- Agente: la plataforma controla la oferta y tú solo estás organizando la venta en nombre de otro. Reconoces solo el importe neto que te quedas como tu tarifa.
Tres indicadores deciden cuál eres, según los marcos de Deloitte y PwC:
- Responsabilidad de cumplimiento: ¿quién es responsable si la aplicación no funciona, la suscripción no se entrega o un cliente se queja? Ese sueles ser tú, el desarrollador, no Apple.
- Riesgo antes de la transferencia: ¿quién asume el riesgo de que el "inventario" (tu aplicación, tu contenido, tu nivel de suscripción) no se venda o no satisfaga al cliente? Nuevamente, normalmente tú.
- Discreción en la fijación de precios: ¿quién determina lo que el cliente paga realmente? Tú eliges el nivel de precio de tu aplicación; la plataforma no lo negocia contigo transacción por transacción.
Debido a que la mayoría de los desarrolladores independientes controlan la experiencia del producto, poseen la relación con el cliente para soporte y actualizaciones, y establecen sus propios precios, se sitúan en el lado del principal de la prueba. Esto significa que la contabilidad correcta es registrar el importe bruto que pagó el cliente como ingreso, y tratar la parte de Apple o Google como una línea de costo de ingresos, no como una reducción invisible.
Los Números Detrás de la Reducción
Saber que eres el principal solo importa si conoces lo que realmente se está deduciendo. Las estructuras de tarifas de las plataformas cambiaron significativamente en los últimos años, y la mayoría de los desarrolladores aún presupuestan basándose en suposiciones obsoletas:
| Plataforma | Tarifa estándar | Tarifa reducida | Quién califica |
|---|---|---|---|
| App Store de Apple | 30% | 15% (Programa para Pequeñas Empresas de la App Store) | Desarrolladores con ≤$1M en ganancias anuales de la App Store |
| Suscripciones de Apple | 30% (año 1) | 15% (a partir del año 2) | Cualquier suscripción después de sus primeros 12 meses |
| Google Play | 30% | 15% sobre los primeros $1M ganados por año | Todos los desarrolladores, escalonado automáticamente |
| Suscripciones de Google Play | 15% fijo | — | Todos los ingresos por suscripciones |
| UE de Apple (términos de la Ley de Mercados Digitales) | ~17% + Tarifa de Tecnología Central | hasta ~20% combinado | Desarrolladores que optan por los términos comerciales alternativos de la UE |
Además de los costos anuales fijos que la mayoría olvida asignar en alguna parte: la tarifa de 25 de Google. Pequeños, pero pertenecen a algún lugar de tu plan de cuentas también, generalmente como un gasto operativo general, no como costo de ventas.
Registrarlo Correctamente: Un Ejemplo Práctico
Supón que un cliente compra una suscripción dentro de la aplicación de 9.99 al cliente, se queda con 6.99 en tu cuenta bancaria. Registrar $6.99 como "ingresos" subestima tu línea superior en un 30%, lo cual importa enormemente si estás comparando tu tasa de crecimiento con un competidor que vende directamente, o explicando tus márgenes a un prestamista.
Los asientos correctos reconocen la venta completa y luego contabilizan la comisión por separado como un gasto:
2026-07-18 * "Apple" "Suscripción iOS — venta bruta"
Activos:CuentasPorCobrar:AppStore 9.99 USD
Ingresos:VentasApp -9.99 USD
2026-07-18 * "Apple" "Comisión 30% App Store"
Gastos:CostoDeIngresos:TarifasPlataforma 3.00 USD
Activos:CuentasPorCobrar:AppStore -3.00 USD
2026-07-20 * "Apple" "Pago recibido"
Activos:CuentaCorriente 6.99 USD
Activos:CuentasPorCobrar:AppStore -6.99 USDObserva que la cuenta por cobrar se liquida a cero una vez que el pago se acredita, pero tu estado de resultados aún muestra 3.00 en costo de ingresos, un margen bruto del 70% en esa venta, no un misterioso 30% faltante. Este es exactamente el tipo de transacción que los libros de contabilidad en texto plano y control de versiones manejan bien: la venta bruta, la tarifa de la plataforma y el pago son tres eventos distintos y auditables en lugar de un único depósito bancario borroso.
Por Qué el Número del Panel no es Suficiente
Incluso una vez que conoces la regla, aplicarla manualmente es más difícil de lo que parece. Los informes estándar de App Store Connect y Play Console muestran totales agregados, no el detalle a nivel de suscriptor y transacción que el ASC 606 técnicamente requiere: los ingresos, reembolsos y conversiones de moneda a menudo llegan en una sola suma global días o semanas después de la venta real. Esa brecha es exactamente por qué un número creciente de negocios de aplicaciones de suscripción utilizan las API de las plataformas o herramientas como RevenueCat para reconstruir el detalle por transacción, en lugar de intentar aplicar ingeniería inversa a partir de un resumen mensual en PDF.
Saltarse este paso tiene un costo real. Un ejemplo ampliamente citado: un desarrollador vio 1,294 eran utilizables, una brecha de más del 60% entre los "ingresos" que creían tener y lo que el negocio realmente retuvo. Los desarrolladores que toman decisiones de contratación o gasto basándose en el número del panel de control, en lugar de la cifra conciliada, están presupuestando contra un número que nunca fue real.
Errores Comunes que Distorsionan tus Libros
- Registrar solo el depósito neto como ingreso. Este es el error más común y del que trata este artículo: subestima tanto los ingresos como el costo de ventas, aplanando tu imagen del margen bruto hasta convertirla en algo sin sentido.
- Ignorar reembolsos y contracargos. Tanto Apple como Google procesan los reembolsos de clientes en tu nombre, a veces semanas después de la venta original; si no estás conciliando por transacción, los ingresos reembolsados pueden permanecer en tus libros indefinidamente.
- Mezclar la tarifa de 25 de Google en el costo de ventas. Estos son costos operativos fijos, no comisiones a nivel de transacción; pertenecen a un grupo de gastos completamente diferente.
- Olvidar el calendario de tarifas separado de la UE. Si alguna parte de tu base de usuarios está en la UE y has optado por los términos alternativos de Apple, esos ingresos tienen una estructura de comisiones diferente al resto de tu negocio y necesitan su propia cuenta.
Mantén tus Finanzas Organizadas a Medida que Escalas
Ya seas un desarrollador en solitario con una sola aplicación en la tienda o dirijas un pequeño estudio con un puñado de productos de suscripción, la decisión de bruto versus neto se acumula cada mes que te equivocas; para cuando estés recaudando una ronda de financiación o solicitando un préstamo, una línea de ingresos subestimada es algo difícil de explicar. Beancount.io ofrece a los desarrolladores un libro de contabilidad en texto plano y con control de versiones, construido exactamente para este tipo de transacciones de múltiples pasos: venta bruta, comisión de plataforma y pago como tres asientos separados y auditables en lugar de un solo depósito bancario borroso. Comienza gratis y descubre por qué los desarrolladores que ya piensan en código prefieren una contabilidad que funcione de la misma manera.