El redondeo de moneda en apps financieras puede causar errores de un centavo. Aprende a almacenar en enteros (céntimos), reglas fiscales y a mostrar cifras coherentes en web y móvil.
Un error de un centavo es algo que los usuarios notan de inmediato. Un total de carrito muestra $19.99 en la lista de productos, pero pasa a $20.00 en el checkout. Un reembolso de $14.38 llega como $14.37. Una línea de factura dice “Impuesto: $1.45”, pero el total general parece haberse calculado con otro método de impuesto.
Estos problemas suelen venir de pequeñas diferencias de redondeo que se acumulan. El dinero no es solo “un número”. Tiene reglas: cuántos decimales usa una moneda, cuándo redondeas y si redondeas por línea o sobre el total final. Si tu app toma una decisión distinta en algún sitio, puede aparecer o desaparecer un céntimo.
También tienden a mostrarse solo a veces, lo que los hace difíciles de depurar. Las mismas entradas pueden producir céntimos distintos según el dispositivo o la configuración regional, el orden de operaciones o cómo se convierten los valores entre tipos.
Desencadenantes comunes incluyen calcular con float y redondear “al final” (pero “el final” no es el mismo en todas partes), aplicar impuestos por artículo en una pantalla y sobre el subtotal en otra, mezclar monedas o tasas de cambio y redondear en pasos inconsistentes, o formatear valores para mostrar y volver a parsearlos accidentalmente como números.
El daño se nota más donde la confianza es frágil y las cantidades se auditan: totales de checkout, reembolsos, facturas, suscripciones, propinas, pagos y informes de gastos. Una discrepancia de un centavo puede causar fallos de pago, problemas de conciliación y tickets de soporte que dicen “su app me está robando”.
El objetivo es simple: las mismas entradas deben producir los mismos céntimos en todas partes. Mismos ítems, mismo impuesto, mismos descuentos, misma regla de redondeo, sin importar pantalla, dispositivo, idioma o exportación.
Ejemplo: si dos artículos de $9.99 tienen 7.25% de impuesto, decide si redondeas impuesto por artículo o sobre el subtotal, y hazlo así en el backend, la UI web y la app móvil. La consistencia evita el momento de “¿por qué es distinto aquí?”.
float son arriesgados para el dineroLa mayoría de los lenguajes almacenan float y double en binario. Muchos precios decimales no pueden representarse exactamente en binario, así que el número que crees que guardaste a menudo es un poco mayor o menor.
Un ejemplo clásico es 0.1 + 0.2. En muchos sistemas queda 0.30000000000000004. Parece inofensivo, pero la lógica del dinero suele ser una cadena: precios de ítems, descuentos, impuesto, tarifas y luego el redondeo final. Errores pequeños pueden cambiar una decisión de redondeo y crear una diferencia de un centavo.
Síntomas que la gente nota cuando el redondeo del dinero falla:
El formateo a menudo oculta el problema. Si imprimes 9.989999 con dos decimales, muestra 9.99, así que todo parece correcto. El bug aparece después cuando sumas muchos valores, comparas totales o redondeas tras impuestos. Por eso a veces los equipos lo lanzan a producción y lo descubren durante la conciliación con proveedores de pago o exportes contables.
Una regla simple: no almacenes ni sumes dinero como número de punto flotante. Trata el dinero como un conteo entero de la unidad menor de la moneda (como céntimos), o usa un tipo decimal que garantice aritmética decimal exacta.
Si construyes un backend, una app web o móvil (incluso con una plataforma sin código como AppMaster), mantén el mismo principio en todas partes: guarda valores precisos, calcula con valores precisos y solo formatea para mostrar al final.
La mayoría de los errores monetarios comienzan antes de cualquier cálculo: el modelo de datos no coincide con cómo funciona realmente la moneda. Acierta el modelo desde el inicio y el redondeo pasa a ser un problema de reglas, no de adivinanza.
El predeterminado más seguro es almacenar el dinero como un entero en la unidad menor de la moneda. Para USD eso significa céntimos; para EUR, céntimos de euro. Tu base de datos y código manejan enteros exactos, y solo “añades decimales” al formatear para humanos.
No todas las monedas usan 2 decimales, así que tu modelo debe ser consciente de la moneda. JPY tiene 0 decimales menores (1 yen es la unidad más pequeña). BHD suele usar 3 decimales (1 dinar = 1000 fils). Si fijas “dos decimales en todas partes”, cobrarás de más o de menos sin darte cuenta.
Un registro monetario práctico suele necesitar:
amount_minor (entero, como 1999 para $19.99)currency_code (cadena como USD, EUR, JPY)minor_unit o scale (0, 2, 3) si tu sistema no puede consultarlo con fiabilidadGuarda el código de moneda con cada importe, incluso dentro de la misma tabla. Evita errores cuando luego añadas precios en varias monedas, reembolsos o reportes.
También decide dónde se permite redondear y dónde está prohibido. Una política que funciona bien es: no redondear dentro de totales internos, asignaciones, libros o conversiones en progreso; redondear solo en límites definidos (como un paso de impuesto, un paso de descuento o la línea final de la factura); y siempre registrar el modo de redondeo usado (half up, half even, round down) para que los resultados sean reproducibles.
Si quieres menos sorpresas, elige una forma interna para el dinero y no la rompas: almacena importes como enteros en la unidad menor de la moneda (a menudo céntimos).
Eso significa que $10.99 pasa a 1099 con moneda USD. Para monedas sin unidad menor como JPY, 1.500 yenes sigue siendo 1500.
Una ruta de implementación simple que escala conforme crece tu app:
amount_minor como entero de 64 bits más un código de moneda (como USD, EUR, JPY). Nombra la columna claramente para que nadie la confunda con un decimal.{ amount_minor: 1099, currency: "USD" }. Evita cadenas formateadas como "$10.99" y evita floats en JSON.amount_minor a una cadena usando reglas de idioma y moneda. Nunca vuelvas a parsear tu propio formato para hacer cálculos.Un ejemplo práctico de parsing: para USD, toma "12.3" y trátalo como "12.30" antes de convertirlo a 1230. Para JPY, rechaza los decimales desde el principio.
La mayoría de las disputas de un centavo no son errores matemáticos. Son errores de política. Dos sistemas pueden ser ambos “correctos” y aun así discrepar si redondean en momentos distintos.
Escribe tu política de redondeo y úsala en todas partes: cálculos, recibos, exportaciones y reembolsos. Opciones comunes incluyen redondeo half-up (0.5 hacia arriba) y half-even (0.5 hacia el centavo par más cercano). Algunas tarifas requieren siempre hacia arriba (ceiling) para nunca cobrar de menos.
Los totales cambian según decisiones como: redondear por línea o por factura, mezclar reglas (por ejemplo, impuesto por línea pero tarifas en la factura), y si los precios incluyen impuesto (se recalcula neto e impuesto) o no (el impuesto se calcula desde el neto).
Los descuentos añaden otra bifurcación. Un “10% de descuento” aplicado antes del impuesto reduce la base imponible, mientras que un descuento después del impuesto reduce lo que paga el cliente pero puede no cambiar el impuesto informado, según la jurisdicción y el contrato.
Un pequeño ejemplo muestra por qué importan reglas estrictas. Dos artículos de $9.99 con 7.5% de impuesto. Si redondeas impuesto por línea, cada línea tiene $0.75 de impuesto (9.99 x 0.075 = 0.74925). El impuesto total es $1.50. Si gravas el total de la factura, el impuesto también es $1.50 aquí, pero cambia los precios ligeramente y verás una diferencia de 1 centavo.
Escribe la regla en lenguaje sencillo para que soporte y finanzas puedan explicarla. Luego reutiliza el mismo helper para impuestos, tarifas, descuentos y reembolsos.
La matemática multicurrency es donde pequeñas decisiones de redondeo pueden cambiar los totales lentamente. El objetivo es simple: convertir una vez, redondear a propósito y conservar los hechos originales para más tarde.
Almacena las tasas de cambio con precisión explícita. Un patrón común es un entero escalado, como “rate_micro” donde 1.234567 se guarda como 1234567 con una escala de 1.000.000. Otra opción es un tipo decimal fijo, pero aun así escribe la escala en tus campos para que no pueda adivinarse.
Elige una moneda base para reportes y contabilidad (a menudo la moneda de la empresa). Convierte los importes entrantes a la moneda base para libros y análisis, pero conserva el importe y la moneda originales junto a ello. Así podrás explicar cada cifra después.
Reglas que previenen deriva:
Ejemplo: un cliente paga 19.99 EUR, y lo almacenas como 1999 unidades menores con currency=EUR. También guardas la tasa usada en el checkout (por ejemplo, EUR a USD en micro unidades). Tu libro registra el importe convertido a USD (redondeado por tu regla), pero los reembolsos usan el importe EUR almacenado y la moneda original, no una reconversión desde USD. Eso evita tickets tipo “¿por qué me devolvieron 19.98 EUR?”.
La última milla es la pantalla. Un valor puede ser correcto en almacenamiento y aun así parecer incorrecto si el formateo cambia entre web y móvil.
Diferentes locales esperan puntuación y posición del símbolo distintas. Por ejemplo, muchos usuarios en EE. UU. leen $1,234.50, mientras que en gran parte de Europa esperan 1.234,50 € (mismo valor, separadores distintos). Si fijas el formateo, confundirás a la gente y crearás trabajo de soporte.
Mantén una regla en todas partes: formatea en el borde, no en el núcleo. Tu fuente de verdad debe ser (código de moneda, entero de unidades menores). Solo convierte a cadena para mostrar. Nunca vuelvas a parsear una cadena formateada; ahí se esconden sorpresas de redondeo y separadores.
Para importes negativos como reembolsos, elige un estilo consistente y úsalo en todas partes. Algunos sistemas muestran -$12.34, otros ($12.34). Ambos están bien. Cambiar entre ellos en distintas pantallas parece un error.
Un contrato simple entre clientes que funciona bien:
Ejemplo: un cliente ve un reembolso de 10,00 EUR en móvil, luego abre el mismo pedido en escritorio y ve -€10. Si además muestras el código (10,00 EUR) y mantienes el estilo negativo consistente, no se preguntarán si cambió.
Un carrito simple:
Subtotal = 869 céntimos ($8.69). Aplica un descuento del 10% primero: 869 x 10% = 86.9 céntimos, redondea a 87 céntimos. Subtotal con descuento = 782 céntimos ($7.82). Ahora aplica impuesto al 8.875%.
Aquí es donde las reglas de redondeo pueden cambiar el último centavo.
Si calculas impuesto sobre el total de la factura: 782 x 8.875% = 69.4025 céntimos, redondea a 69 céntimos.
Si calculas impuesto por línea (después del descuento) y redondeas cada línea:
Impuesto por línea total = 70 céntimos. Mismo carrito, misma tasa, regla diferente válida, 1 céntimo de diferencia.
Añade una tarifa de envío después de impuestos, digamos 399 céntimos ($3.99). El total será $12.50 (impuesto a nivel factura) o $12.51 (impuesto por línea). Elige una regla, documéntala y mantenla consistente.
Ahora reembolsa solo el Artículo B. Reembolsa su precio con descuento (225 céntimos) más el impuesto que le corresponde. Con impuesto por línea, eso es 225 + 20 = 245 céntimos ($2.45). Tus totales restantes siguen conciliándose exactamente.
Para explicar cualquier discrepancia después, registra estos valores para cada cargo y reembolso:
La mayoría de los bugs monetarios no son “errores de matemática”. Son errores de redondeo, orden y formateo que aparecen solo en carritos o fechas específicas. Buenas pruebas vuelven esos casos aburridos.
Comienza con pruebas golden: entradas fijas con salidas exactas esperadas en unidades menores (como céntimos). Mantén las aserciones estrictas. Si un ítem es 199 céntimos y el impuesto 15 céntimos, la prueba debe comprobar valores enteros, no cadenas formateadas.
Un pequeño conjunto de goldens cubre mucho:
Luego añade pruebas basadas en propiedades (o pruebas aleatorias simples) para capturar sorpresas. En lugar de un número esperado, afirma invariantes: los totales igualan suma de líneas, nunca aparecen fracciones de la unidad menor y “total = subtotal + impuesto + tarifas - descuentos” siempre se cumple.
Las pruebas entre plataformas importan porque los resultados pueden derivar entre backend y clientes. Si tienes un backend en Go con una app web en Vue y móvil en Kotlin/SwiftUI, ejecuta los mismos vectores de prueba en cada capa y compara las salidas enteras, no cadenas de UI.
Finalmente, prueba casos dependientes del tiempo. Guarda la tasa de impuesto usada en una factura y verifica que facturas antiguas recalculen al mismo resultado incluso después de que cambien las tasas. Aquí nacen bugs de “antes coincidía”.
La mayoría de los errores de un centavo no son fallos de cálculo. Son fallos de política: el código hace exactamente lo que le dijiste, pero no lo que finanzas espera.
Trampas a vigilar:
Una comprobación de realidad: un checkout creado el lunes usa la tasa del mes pasado; el usuario se reembolsa el viernes después de que cambió la tasa. Si no guardaste la versión de la regla de impuesto y la política de redondeo original, tu reembolso no coincidirá con el recibo original.
Si quieres menos sorpresas, trata el dinero como un pequeño sistema con entradas, reglas y salidas claras. La mayoría de los errores de un centavo sobreviven porque nadie escribió dónde se permite redondear.
Checklist antes de lanzar:
Escribe una política de redondeo por tipo de cálculo. Por ejemplo: “El descuento se redondea por línea al céntimo más cercano; el impuesto se redondea sobre el total de la factura; los reembolsos repiten la ruta de redondeo original.” Pon estas políticas junto al código y en la documentación del equipo para que no se desvíen.
Añade logs ligeros para cada paso monetario que importe. Captura los valores de entrada, el nombre de la política usada y la salida en unidades menores. Cuando un cliente informe “me cobraron un centavo de más”, quieres una sola línea que explique por qué.
Planifica una pequeña auditoría antes de cambiar lógica en producción. Recalcula totales sobre una muestra de pedidos históricos, luego compara resultados antiguos vs nuevos y cuenta discrepancias. Revisa manualmente algunas discrepancias para confirmar que coincidan con tu nueva política.
Si quieres construir este flujo end-to-end sin reescribir las mismas reglas tres veces, AppMaster (appmaster.io) está diseñado para apps completas con lógica de backend compartida. Puedes modelar importes como enteros en unidades menores en PostgreSQL mediante el Data Designer, implementar pasos de redondeo e impuestos una vez en un Business Process y luego reutilizar la misma lógica en UIs web y nativas.
¿Por qué mi total cambia $0.01 entre el carrito y el checkout?Suelen ocurrir cuando distintas partes de la app redondean en momentos diferentes o con modos distintos. Si en la lista de productos se redondea en una etapa y en el checkout en otra, el mismo carrito puede terminar legítimamente en distintos céntimos.
¿Qué problema tiene usar float o double para precios?Porque la mayoría de los float no pueden representar con exactitud precios decimales comunes; se acumulan errores pequeños que después pueden cambiar una decisión de redondeo y causar una diferencia de un centavo.
¿Cuál es la forma más segura de almacenar dinero en la base de datos y en la API?Almacena el dinero como un entero en la unidad menor de la moneda, por ejemplo céntimos para USD (1999 para $19.99), junto con un código de moneda. Haz los cálculos en enteros y solo formatea a cadena decimal al mostrarlo a los usuarios.
¿Cómo manejo monedas que no tienen 2 decimales?Hardcodear dos decimales falla para monedas como JPY (0 decimales) o BHD (3 decimales). Siempre guarda el código de moneda con el importe y aplica la escala correcta de unidad menor al parsear entradas y al formatear salidas.
¿Debo redondear el impuesto por artículo o sobre el total de la factura?Elige una regla clara y aplícala en todos los lugares, por ejemplo redondear impuesto por línea o redondear impuesto sobre el subtotal de la factura. La clave es la consistencia entre backend, web, móvil, exportaciones y reembolsos, usando el mismo modo de redondeo cada vez.
¿En qué orden debo aplicar descuentos, impuestos y tarifas?Decide el orden desde el principio y trátalo como política, no como detalle de implementación. Un orden habitual es aplicar descuentos primero (para reducir la base imponible) y luego el impuesto, pero sigue la normativa y la práctica que tu negocio requiera y mantenlo idéntico en todas las pantallas y servicios.
¿Cómo hago conversiones de moneda sin que los totales se desvíen con el tiempo?Convierte una vez usando una tasa almacenada con precisión explícita, redondea intencionalmente en un paso definido y guarda el importe y la moneda originales para reembolsos. Evita convertir ida y vuelta porque los redondeos repetidos causan deriva.
¿Por qué los importes se ven diferentes en web y móvil aun cuando la matemática es correcta?Nunca vuelvas a parsear cadenas formateadas para hacer cálculos; los separadores de miles y decimales y el redondeo pueden cambiar el valor. Pasa valores estructurados como (amount_minor, currency_code) y formatea solo en la capa de UI usando las reglas locales.
¿Qué pruebas detectan errores de un centavo antes que los usuarios?Prueba con casos “golden” fijos que verifiquen salidas enteras exactas para cada paso, no cadenas formateadas. Luego añade comprobaciones de invariantes, como que los totales sean la suma de las partes y que los reembolsos reproduzcan el mismo camino de redondeo original.
¿Cómo mantengo reglas de redondeo consistentes entre backend, web y móvil?Centraliza la matemática del dinero en un único lugar y reutilízala para que las mismas entradas produzcan los mismos céntimos. En AppMaster, una vía práctica es modelar amount_minor como entero en PostgreSQL y poner la lógica de redondeo e impuestos en un Business Process que usen tanto web como móvil.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
