Facturación de suscripciones multimoneda: reglas prácticas de redondeo y enfoques mínimos de tabla para mantener totales consistentes en web, móvil y exportaciones contables.
Un problema habitual: el checkout web muestra un total, la app móvil muestra un total ligeramente distinto y la exportación contable termina con un tercer número. Cada sistema está haciendo una aritmética “razonable”, pero no la misma.
Las suscripciones empeoran esto porque repites el cálculo una y otra vez. Las pequeñas diferencias se acumulan a través de renovaciones, prorratas cuando alguien sube de plan a mitad de ciclo, créditos y reembolsos, cargos por reintentos después de pagos fallidos y períodos parciales al inicio o fin de un plan.
La deriva suele empezar con elecciones diminutas que permanecen invisibles hasta que ya no: cuándo redondear (por línea o al final), qué base fiscal usar (neto vs bruto), cómo manejar monedas con 0 o 3 decimales en unidades menores, y qué tipo de cambio se aplica (qué marca temporal, qué proveedor, qué precisión). Si web redondea a 2 decimales por línea y móvil solo redondea el total final, puedes obtener una diferencia de 0,01 aun con las mismas entradas.
El objetivo es aburrido pero importante: la misma factura debería producir los mismos totales en todas partes, siempre. Eso mantiene tranquilos a los clientes, reduce tickets de soporte y resiste auditorías.
"Consistente" significa que para un ID de factura y versión dados:
Ejemplo: un cliente sube de EUR 19.99 a EUR 29.99 a mitad de mes, recibe un cargo prorrateado y luego un pequeño crédito por inactividad. Si un sistema redondea cada línea prorrateada y otro redondea solo el total final, la factura exportada puede discrepar con lo que el cliente vio, aunque cada número parezca “lo suficientemente cercano”.
Antes de debatir sobre tipos de cambio o reglas de redondeo fiscal, asegura lo básico. Si esto está difuso, las facturas derivarán entre tu app web, la app móvil y las exportaciones contables.
Cada línea de factura y cada total debería llevar claramente tres importes: neto (antes de impuesto), impuesto y bruto (neto + impuesto). Elige uno como fuente de verdad para almacenamiento y cálculo, y luego deriva los otros siempre de la misma forma. Muchos equipos almacenan neto e impuesto, y luego calculan bruto como neto + impuesto porque facilita auditorías y reembolsos.
Sé explícito sobre en qué moneda está cada número. Los equipos a menudo mezclan tres ideas distintas:
Pueden ser iguales, pero no tienen por qué. Si tu factura está en EUR pero la tarjeta liquida en USD, la factura debe seguir siendo consistente en EUR aunque el depósito bancario difiera.
A continuación, trata el dinero como enteros en unidades menores (por ejemplo, céntimos). Almacenar 9.99 como número de punto flotante es una forma común de crear problemas tipo 9.989999 más adelante, especialmente cuando añades impuestos, descuentos, prorratas o varios ítems. Almacena 999 (céntimos) con un código de moneda y solo formatea para mostrar.
Finalmente, decide tu modo de precios con respecto al impuesto:
Una comprobación concreta: un plan mostrado como 10.00 (impuesto incluido, 20% IVA) debería producir el mismo bruto almacenado en unidades menores en web y móvil, y luego derivar neto e impuesto con una regla compartida.
Las diferencias de FX muchas veces comienzan antes de las reglas de impuestos y redondeo. Dos sistemas pueden estar ambos “correctos” y aun así discrepar porque usaron orígenes distintos, marcas temporales distintas o precisiones distintas.
Los proveedores de tipos raramente coinciden exactamente. Algunos cotizan tipo medio, otros incluyen un spread. Algunos actualizan cada minuto, otros cada hora o día. Incluso con el mismo proveedor, un sistema puede redondear la tasa a 4 decimales mientras otro mantiene 8+, lo que cambia los totales al multiplicar importes de suscripción e impuestos.
La decisión más importante es qué significa tu marca temporal del tipo. Si cobras en EUR pero el cliente paga en USD, ¿fijas el tipo de cambio al emitir la factura o cuando se captura el pago? Ambos son comunes, pero mezclarlos entre web, móvil y exportaciones asegura desajustes.
Una vez que eliges la regla, almacena la tasa exacta usada en la factura. No la recomputes luego a partir de tasas “actuales”, aunque puedas consultar históricas. Correcciones del proveedor, diferencias de zona horaria y pequeños cambios de precisión harán que facturas antiguas deriv en exportaciones o al regenerar PDFs.
Un ejemplo sencillo: emites una factura a las 23:59 pero el pago se confirma a las 00:02. Esas marcas suelen caer en “días” distintos del proveedor, así que una tabla diaria puede producir números distintos.
Decide y documenta estos detalles de FX:
Casos especiales para manejar desde el principio: monedas sin decimales (como JPY), tasas de muy alta precisión y reembolsos. Los reembolsos deberían, por lo general, reutilizar la tasa FX almacenada en la factura original. De lo contrario, el importe del reembolso puede diferir de lo que el cliente espera y de lo que muestra tu exportación contable.
Si quieres que las facturas coincidan entre web, móvil y exportaciones, tu modelo de datos debe guardar resultados, no solo entradas. La meta es simple: la misma factura debería renderizar las mismas unidades menores en todas partes, incluso meses después.
Un pequeño conjunto de entidades suele ser suficiente:
Regla clave: los campos de dinero deben ser enteros en unidades menores. Almacena tanto el precio unitario como los totales de línea calculados. Eso evita recalcular más tarde con una regla de redondeo distinta o una fuente FX distinta.
FX debe capturarse en la factura, no inferirse. Incluso si guardas una tabla FX compartida, la factura debe mantener el fx_rate_value exacto usado al momento de la finalización (y de dónde vino) para que las exportaciones puedan reproducir los mismos números.
Solo necesitas una tabla separada de desglose de impuestos cuando una factura pueda tener múltiples tasas o jurisdicciones a la vez (por ejemplo, ítems mixtos, IVA de la UE + gravamen local, o cambios de impuesto basados en dirección dentro de una factura). Entonces guarda una fila por tasa con taxable_base_minor y tax_amount_minor.
Finalmente, trata una factura finalizada como inmutable. Guarda una instantánea de los valores calculados en el momento en que se vuelve final, y nunca recalcules totales desde la suscripción después. Esa decisión elimina la mayoría de los bugs de “¿por qué cambiaron los céntimos?”.
El redondeo no es un detalle matemático: es una regla de producto. Si tu web redondea de una forma, tu móvil de otra y la exportación contable de una tercera, obtendrás totales distintos aun cuando las entradas parezcan idénticas.
Hay tres estrategias comunes, y difieren en dónde "congelas" las unidades menores:
Para suscripciones, un buen valor por defecto es redondear por línea. Es predecible para los clientes (cada línea se ve correcta), fácil de auditar (puedes explicar cada total de línea) y estable en renovaciones. Redondear por unidad puede derivar cuando cambia la cantidad o cuando muestras precios unitarios en la UI. Redondear solo en el total de la factura a menudo crea tickets de “¿por qué esta línea no suma?” porque las sumas visibles por línea pueden no coincidir con el total mostrado.
El clásico problema del céntimo aparece cuando tienes muchos ítems pequeños o impuestos fraccionarios. Ejemplo: 20 líneas que cada una produce un resto de redondeo de 0.004. Redondeado por línea, eso puede convertirse en 0.08 de diferencia frente a redondear solo al final. Con conversiones FX, estos pequeños restos aparecen más a menudo y se acumulan con el tiempo en exportaciones e informes de ingresos.
Sea cual sea tu elección, hazla determinista. Las mismas entradas deben siempre producir las mismas salidas en web, móvil y exportaciones:
Si construyes flujos de facturación tanto en web como en móvil, escribe la regla de redondeo como una especificación testeable, no como un comportamiento de UI.
Para mantener los mismos números en web, móvil y en exportaciones contables, trata el cálculo como una receta. La idea clave: calcula con alta precisión, pero almacena y suma solo enteros en la moneda de la factura.
Comienza con cada importe neto de línea en alta precisión. Mantén decimales extra mientras multiplicas por cantidad, aplicas descuentos y (si es necesario) conviertes moneda. Luego redondea una vez a unidades menores de la factura usando la regla elegida. Almacena ese entero como el line_net.
Calcula el impuesto a partir del line_net almacenado (o desde un subtotal de grupo fiscal si tus reglas permiten agrupar por tasa). Aplica la misma regla de redondeo y almacena el impuesto como entero en unidades menores. Aquí es donde los sistemas suelen desviarse: un lado redondea antes del impuesto, el otro después.
Calcula cada bruto de línea como (neto almacenado + impuesto almacenado). Los totales de factura son sumas de los menores almacenados. No recalcules totales a partir de valores en punto flotante para mostrarlos. Las vistas y exportaciones deben leer los enteros almacenados y formatearlos.
Si tus normas locales requieren totales fiscales a nivel de factura, puede que necesites distribuir un resto. Ejemplo: tres líneas con 0.01 de impuesto cada una podrían sumar 0.03, pero el redondeo a nivel de factura diga 0.02. Decide un desempate determinista (por ejemplo, sumar o restar 1 unidad menor empezando por la línea imponible más grande, luego ordenar de forma estable por id de línea). Almacena el ajuste como una pequeña corrección fiscal en las líneas afectadas para que cada sistema pueda reproducirlo.
Bloquea la factura. Después del redondeo final y cualquier distribución de restos, trata la factura como inmutable. Si el precio de una suscripción cambia después, crea una nueva factura o una nota de crédito, pero nunca reescribas los números antiguos.
Una comprobación concreta: si un plan en EUR 9.99 tiene 19% IVA, tu neto almacenado puede ser 999 céntimos, impuesto 190 céntimos, bruto 1189 céntimos. Cada cliente debería mostrar 11.89 EUR a partir de esos enteros almacenados, no recomputando el IVA al vuelo.
El redondeo del impuesto es donde la matemática correcta se convierte en facturas discordantes. El problema central es simple: redondear antes cambia la suma final.
Si redondeas el impuesto por línea (o por cantidad) y luego sumas, puedes obtener un total distinto que si sumas el impuesto no redondeado de toda la factura y luego redondeas una vez al final. Con muchas líneas, las brechas se acumulan, especialmente cuando las unidades menores y las conversiones FX ya generan fracciones.
Un ejemplo concreto (2 decimales): dos líneas con base imponible 0.05 cada una y 10% de impuesto. El impuesto no redondeado por línea es 0.005. Si redondeas por línea, cada una se convierte en 0.01, total impuesto 0.02. Si redondeas a nivel de factura, la base imponible total es 0.10, impuesto 0.01. Ambas posturas son defendibles. Simplemente discrepan.
Cuando debas mostrar impuesto por línea pero también necesites que el total de la factura coincida exactamente, asigna el resto de redondeo de forma determinista:
Las exportaciones aún pueden derivar cuando la contabilidad agrupa líneas (por producto, tasa de impuesto o jurisdicción). Para mantener los totales exportados iguales a los totales de la factura, asigna restos dentro de cada grupo requerido primero y luego verifica que los totales de grupo se agreguen al mismo impuesto y bruto de la factura.
Si la contabilidad exige dividir impuestos por tasa o jurisdicción pero la UI muestra un solo número de impuesto, guarda igualmente el desglose (totales por tasa o jurisdicción más una regla de asignación auditable). La UI puede mostrar un único total, mientras las exportaciones llevan cubetas detalladas sin cambiar el total general de la factura.
La mayoría de los desajustes de facturas ocurren en las esquinas. Decide las reglas temprano y dejan de ser sorpresas.
Las monedas sin decimales necesitan cuidado especial. JPY y KRW no tienen unidades menores, así que cualquier paso que asuma “céntimos” creará silenciosamente diferencias. Decide si redondeas en cada línea, a nivel de impuesto o solo en el total final, y asegúrate de que todos los clientes usen las mismas configuraciones de moneda.
El IVA/GST transfronterizo puede cambiar la tasa según la ubicación del cliente y la evidencia que aceptes (dirección de facturación, IP, ID fiscal). Lo difícil no es la tasa en sí, sino cuándo la fijas. Elige el punto en el tiempo (checkout, fecha de emisión de la factura o inicio del período de servicio) y mantente en él.
La prorrata es donde las fracciones se multiplican. Una subida a mitad de ciclo puede crear importes como 9.3333... por día. Decide si prorrateas importes netos, importes brutos o el período de servicio primero, y luego calcula lo demás. Cambiar el orden cambia la última unidad menor.
Escribe estas reglas para que no se diluyan con el tiempo:
Los reembolsos son la trampa final. Si la factura original tenía un resto de 0.01 asignado a una línea, tu reembolso debería invertir exactamente esa asignación. De lo contrario, el cliente verá un total y tu contabilidad otro.
La mayoría de los desajustes no vienen de “matemáticas difíciles”. Surgen de decisiones pequeñas e inconsistentes en distintas partes del stack.
Un gran error es almacenar dinero como punto flotante. Un valor como 19.99 no puede representarse exactamente en muchos sistemas, así que se generan errores pequeños al sumar líneas, aplicar descuentos o calcular impuestos. Almacena importes como enteros en unidades menores, más el código de moneda y la escala de la unidad menor.
Otro problema común es recalcular FX durante la exportación. Un cliente pagó según una tasa específica en un momento específico. Si tu exportación contable recupera el tipo “de hoy”, puedes acabar con un total distinto aun cuando cada paso fuese correcto. Trata la factura como una snapshot: guarda la tasa FX usada, los importes convertidos y los resultados de redondeo.
Las diferencias de redondeo también surgen cuando la UI y el backend redondean en etapas distintas. Por ejemplo, el backend puede redondear impuestos por línea mientras la UI redondea solo al total. Ambos parecen razonables, pero no coincidirán.
Cinco reincidencias explican la mayoría de las brechas:
Una verificación rápida: una app móvil muestra tres ítems a EUR 9.99 con 20% de impuesto. Si la app redondea el impuesto al final pero el backend redondea por línea, puedes estar fuera por EUR 0.01. Ese céntimo es suficiente para romper la reconciliación y disparar tickets de soporte.
La solución más simple es aburrida pero efectiva: calcula una vez en el backend, guarda la snapshot completa de la factura y deja que web y móvil muestren esos números almacenados exactamente.
Cuando los números difieren entre tu app web, la app móvil y la exportación contable, normalmente no es un problema matemático. Es un problema de almacenamiento y redondeo.
Parte del principio de que los clientes deben mostrar lo que la factura almacena, no recalcularlo. Tu backend debe ser la única fuente de verdad, y cada canal debe leer los mismos valores guardados.
Los reembolsos y notas de crédito deben reproducir los resultados de redondeo de la factura original. Si la factura original redondeó impuestos por línea, el reembolso debe hacerlo igual, usando la misma precisión de moneda y la misma tasa FX almacenada. Si no, pueden aparecer pequeños restos que se acumulan con el tiempo.
Una forma práctica de aplicar esto es almacenar una snapshot clara de cálculo con cada factura: moneda, precisión de unidad menor, modo de redondeo, tasa FX y marca temporal, y los menores finalizados por línea.
Aquí hay una factura que se mantiene consistente en todas partes.
Supón que la factura se emite en EUR (2 decimales), el IVA es 20% y el cliente es cobrado en USD. El backend guarda un snapshot FX: 1 EUR = 1.0857 USD.
| Item | Neto (EUR) |
|---|---|
| Pro plan (mensual) | 19.99 |
| Asientos extra | 10.00 |
| Descuento (10% de 29.99, redondeado) | -3.00 |
Total neto (EUR) = 26.99
IVA 20% (EUR) = 5.40 (porque 26.99 x 0.20 = 5.398, redondeado a 5.40)
Total bruto (EUR) = 32.39
Ahora el backend deriva los totales en moneda de cobro a partir de los totales EUR almacenados y el snapshot FX:
Si también almacenas importes por línea en USD, a menudo obtendrás una diferencia de 0.01 cuando redondeas cada línea convertida y las sumas. Ahí es donde suelen derivar las facturas.
Hazlo determinista: convierte y redondea cada línea, luego distribuye los céntimos sobrantes (positivos o negativos) en un orden fijo (por ejemplo por line_id ascendente) hasta que la suma por línea coincida con el total bruto USD ya fijado.
Web y móvil deben mostrar los totales de línea, totales de impuesto, tasa FX y bruto almacenados por el backend, no recalcularlos. La exportación contable debe emitir los mismos números almacenados más el snapshot FX (tasa, marca temporal o fuente) para que el libro mayor coincida con lo que vio el cliente.
Un siguiente paso práctico es implementar el cómputo como un servicio compartido que emita una sola snapshot de factura (líneas, impuestos, totales, FX, ajustes de redondeo) y hacer que todos los canales rendericen desde ella. Si estás construyendo estos flujos en Koder.ai (koder.ai), mantener este modelo de snapshot en el centro ayuda a que web, móvil y exportaciones se mantengan alineados porque todos pueden leer los mismos valores guardados.
Porque cada sistema suele tomar decisiones ligeramente distintas sobre cuándo redondear, qué redondear (neto vs bruto) y qué precisión mantener para impuestos y FX. Esas pequeñas diferencias aparecen como brechas de 0,01–0,02, sobre todo cuando la prorrata, los créditos y los reintentos repiten los cálculos con el tiempo.
Almacena los importes como enteros en unidades menores (por ejemplo, céntimos) junto con el código de moneda, y solo formatealos para mostrar. Los números en punto flotante no pueden representar muchas decimales de forma exacta, por lo que aparecen errores pequeños al sumar impuestos, descuentos o varias líneas.
Elige uno como la fuente de verdad y deriva los demás de la misma forma en todas partes. Una elección común es almacenar neto y impuesto en unidades menores y calcular bruto = neto + impuesto, porque facilita reembolsos y auditorías y mantiene los totales estables.
La moneda de la factura es en la que legalmente se expresan los totales y contra la que debes conciliar. La moneda de visualización es la que muestras al navegar precios, y la moneda de liquidación es lo que el proveedor de pagos ingresa; pueden diferir sin que la factura esté "mal", siempre que los cálculos en la moneda de la factura sean coherentes.
No vuelvas a buscar tipos al generar exportaciones o PDFs antiguos. Almacena el tipo de cambio exacto usado en la factura (valor, precisión, proveedor y momento efectivo) y reutilízalo para que las facturas antiguas reproduzcan los mismos números meses después.
Fija una regla: o bien “tipo al emitir la factura” u “tipo al capturar el pago”, y aplícala en todas partes. Mezclar marcas temporales entre sistemas es una causa común de desajustes, sobre todo alrededor de medianoche o en límites de zona horaria.
Como predeterminado, redondear por línea suele ser lo más seguro para facturas de suscripción. Después suma las unidades almacenadas por línea para obtener los totales. Es más fácil de explicar, evita tickets por “las líneas no suman” y se mantiene estable en renovaciones si todos los canales usan la misma regla.
Decide explícitamente entre redondear el impuesto por línea o a nivel de factura y hazlo determinista. Si debes conciliar con un objetivo a nivel de factura, asigna el resto de redondeo de forma fija y almacena los importes de impuesto por línea resultantes para que todos los sistemas muestren el mismo resultado.
La prorrata genera decimales repetidos (por ejemplo, tarifas diarias), así que el orden de operaciones importa. Elige un método (por ejemplo, prorratear el neto primero y luego calcular el impuesto desde el neto almacenado), redondea en el paso acordado y guarda las unidades menores finalizadas para que upgrades, downgrades, créditos y reembolsos reflejen la misma aritmética original.
Haz que el backend produzca un snapshot finalizado de la factura (líneas, impuestos, totales, reglas de precisión de moneda, snapshot FX, modo de redondeo) y trátalo como inmutable una vez finalizado. Luego web, móvil, PDFs y exportaciones deben renderizar esos enteros almacenados en lugar de recomputar; esto también es un buen patrón si construyes flujos de facturación en Koder.ai.
