Tus informes de reembolsos nunca coinciden entre Apple, Google y tu servidor, aquí te explicamos cómo conciliarlos

Saca el recuento de reembolsos de App Store Connect, luego sácalo de tu servidor, y los dos números no coincidirán. Saca un tercero de tu financial report y tampoco coincidirá con ninguno de los dos. Esto no es un fallo en el sistema de nadie. Apple y Google informan de los reembolsos a través de más de una superficie cada uno, cada superficie cuenta un momento distinto en la vida del reembolso, y tu servidor ve un cuarto. Si alguna vez has intentado conciliar informes de reembolsos y has renunciado porque los totales se separan, aquí te explicamos por qué se separan, en qué número confiar para cada trabajo, y cómo cuadrarlos por transacción en lugar de por mes.

Por qué un mismo reembolso aparece como tres números distintos

Un solo reembolso pasa por varios sistemas antes de liquidarse, y cada sistema lo anota en un instante distinto. Tu servidor se entera primero, como un evento. Un informe de analítica rápida lo estima después. El informe de contabilidad lo registra el último, una vez que el dinero se ha movido de verdad. El mismo reembolso, tres marcas de tiempo, tres totales. El error está en tratar dos cualesquiera de ellos como si tuvieran que ser iguales el mismo día.

Apple te da dos familias de informes, más tu webhook

Apple informa de los reembolsos en dos lugares que no son la misma herramienta y que no están pensados para cuadrar en un día concreto. Sales and Trends es la vista rápida y estimada: los informes diarios llegan al día siguiente, los semanales los lunes, y los mensuales unos cinco días después de que termine el mes, por lo general antes de las 8 a.m., hora del Pacific. Estima las ventas y los ingresos en USD usando un promedio móvil de los tipos de cambio del mes anterior, lo que lo hace bueno para detectar una tendencia y malo para cuadrar un pago. Payments and Financial Reports es la vista liquidada: se genera una vez al mes según el calendario fiscal de Apple, está disponible el primer viernes del mes fiscal en curso para el mes fiscal anterior, y solo se genera si hubo compras o reembolsos en ese periodo. Usa el tipo de cambio finalizado aplicado a tu pago. Ese informe es el registro contable. Junto a ambos, tu servidor recibe la App Store Server Notification REFUND en el momento en que Apple concede un reembolso, vinculada a un único id de transacción.

Google se divide de la misma manera

Google Play refleja la misma división. El earnings report es el registro contable, se genera mensualmente y suele estar disponible hacia el 5 del mes siguiente, y enumera los reembolsos como sus propios tipos de transacción: Charge refund para el dinero devuelto al comprador y Google fee refund para la comisión de servicio que Google devuelve, cada uno etiquetado como Full o Partial. El estimated sales report es la vista de analítica de baja latencia que muestra lo que pagaron los compradores antes de impuestos y comisiones, y Google dice claramente que sirve para analítica y no se recomienda para la contabilidad. En el lado del servidor recibes la Real-time Developer Notification en tiempo real y puedes leer un reembolso desde la Voided Purchases API.

Cómo muestra Apple un reembolso dentro del informe, y la trampa de la línea negativa

Abre el Summary Sales Report y un reembolso no se resta en silencio de una venta. Aparece como su propia fila. Las Units y el Customer Price de esa fila son negativos, que es como identificas un reembolso, y la cifra de Developer Proceeds no se comporta como lo hace el precio. El informe no está neto de reembolsos de forma inherente. Enumera las líneas de reembolso junto a las líneas de venta, y es tu tarea agruparlas. Suma la columna de Units a ojo y contarás el doble o te saltarás los reembolsos por completo, porque una línea de reembolso de menos uno está en la misma columna que tus ventas positivas.

La regla práctica es sencilla: encuentra los reembolsos por las Units negativas, suma esas filas por separado, y nunca supongas que el informe ya te las ha restado. Un recuento de tus reembolsos para un featured snippet es el número de filas con Units negativas, no la suma aritmética de una columna.

El calendario fiscal es la razón por la que tus totales mensuales nunca cuadran

Esta es la mayor razón por la que una hoja de cálculo cuidadosa aun así se niega a cuadrar. Los informes financieros de Apple no se rigen por meses naturales. Se rigen por un calendario fiscal 4-4-5, donde la mayoría de los meses fiscales tienen cuatro semanas y cada tercero tiene cinco semanas. Un desarrollador que compara un Financial Report con una ventana normal de enero a enero está comparando dos tramos de días distintos, así que los totales de reembolsos no pueden coincidir aunque cada número subyacente sea correcto. Desarrolladores en los propios foros de Apple han visto cómo las cifras de Sales y las del Financial Report divergían en miles de dólares por exactamente esta razón, y la diferencia se ampliaba cada mes que la dejaban acumularse.

El earnings report de Google es mensual, pero tiene su propia temporización y su propia zona horaria, y ninguna es el reloj UTC de tu servidor. La trampa más profunda es común a ambas tiendas: un reembolso se atribuye a la fecha en que se liquida, no a la fecha de la venta original. Reembolsa una compra de marzo a principios de abril y reducirá tus cifras de abril, no las de marzo. Alinea dos meses por sus etiquetas y el reembolso parecerá haber desaparecido de uno y haber aparecido en el otro.

Cuánto cuesta un reembolso, y en qué informe leerlo

La conciliación es en realidad una cuestión de contabilidad, así que sigue el dinero. En un reembolso la tienda devuelve su propia comisión, lo que significa que la cantidad que realmente sale de tu cuenta es tu parte de la venta, no el precio completo que ve devuelto el cliente. En Google Play esa devolución es una línea visible: el tipo de transacción Google fee refund en tu earnings report es la comisión de servicio que vuelve a ti, junto al Charge refund que fue al comprador. En el App Store, Apple deduce tus ingresos posteriores a la comisión y devuelve su comisión en el mismo movimiento, así que el financial report muestra la deducción neta de la parte de Apple.

La temporización del flujo de caja es donde los desarrolladores se llevan una sorpresa. En Google Play, si reembolsas un pedido antes de que Google te haya pagado por él, sencillamente nunca recibes esa cantidad. Si reembolsas después del pago, Google lo deduce de un pago futuro. Y si una ola de reembolsos deja tu saldo en negativo y sigue en negativo durante al menos 48 horas, Google cargará en la cuenta bancaria que normalmente recibe tus pagos el importe faltante. Un contracargo es la versión más dura del mismo evento: en Google Play, para los pedidos realizados a partir del August 3, 2026, el contracargo traslada el precio de compra más las comisiones del banco al desarrollador, y aparece en el informe de un mes posterior al de la venta.

Cómo conciliar tus informes de reembolsos, paso a paso

El trabajo se vuelve sencillo en cuanto dejas de intentar que cada número sea igual y en su lugar asignas cada número a la pregunta que responde. Solo hay dos preguntas: cuánto dinero se movió, y quién sigue teniendo acceso.

• Decide la pregunta antes de abrir un informe. Para el dinero, la respuesta está en el financial report de Apple y en el earnings report de Google, y punto. Para el acceso, la respuesta está en las notificaciones de tu servidor. Nunca concilies uno contra el otro.
• Elige el id de transacción como tu clave de unión en las cuatro superficies. Es el único campo que comparten una venta, su reembolso, los informes y tu webhook.
• Para Apple, cuando el Summary Sales Report y tu webhook no concuerdan, llama al endpoint Get Refund History del App Store Server API en /inApps/v2/refund/lookup/{transactionId}. Devuelve las transacciones reembolsadas firmadas de un cliente, con revocationDate y revocationReason, de un id de transacción a la vez, y pagina por su historial. Ese endpoint es el desempate.
• Para Google, coteja las líneas Charge refund del earnings report con lo que reporta la Voided Purchases API para los mismos pedidos, y recuerda que un reembolso parcial se etiqueta como Partial y no dejará a cero el cargo original.
• Ajústate al reloj del informe, no al tuyo. El de Apple es un mes fiscal en hora del Pacific. El earnings report de Google tiene su propio mes y zona horaria. Tus registros son casi con seguridad UTC. Convierte al calendario del informe antes de comparar, o los límites de día por sí solos crearán discrepancias fantasma.
• Espera que la estimación se mueva. Sales and Trends es una estimación y seguirá cambiando a medida que las transacciones se liquiden. Concilia con el financial report, nunca con la estimación, y nunca con la instantánea de ayer de la estimación.

Cuando tu servidor muestra más reembolsos que el informe

El pánico más común es encontrar más notificaciones REFUND en tu servidor que filas de reembolso en el sales report para la misma ventana. Normalmente no es dinero perdido. Las dos superficies cuentan momentos distintos, una notificación puede preceder a la fila del informe por días, y un reembolso parcial o una solicitud reenviada puede producir más de un evento. Los desarrolladores han reportado exactamente esta forma, miles de notificaciones REFUND frente a un recuento menor de filas con Units negativas para el mismo mes. Resuélvelo siempre de la misma manera: toma los id de transacción que vio tu servidor, pásalos por Get Refund History, y deja que el propio registro de Apple determine cuáles se reembolsaron realmente y por cuánto.

La versión corta

No puedes hacer que la estimación de Apple, el financial report de Apple, el earnings report de Google y tu webhook muestren todos el mismo total de reembolsos el mismo día, y deberías dejar de intentarlo. Lee cada uno por lo que está hecho para decirte. Confía en el financial report y en el earnings report para el dinero, confía en las notificaciones de tu servidor para el acceso, y cuando dos superficies se peleen, únelas por el id de transacción y deja que la consulta de Get Refund History o de Voided Purchases rompa el empate. Los reembolsos conciliados no son totales que coinciden. Son transacciones que coinciden.