Almacenar dinero en centavos enteros para evitar errores de facturación en prototipos

Por qué los prototipos fallan con el dinero

Un prototipo puede verse perfecto en pantalla y aun así cobrar una cantidad incorrecta. La etiqueta muestra $19.99, el carrito indica $39.98, pero la confirmación de pago llega como $39.97 o $39.99. Nadie lo detecta en pruebas, y luego lo encuentran los usuarios reales.

Esto suele ocurrir porque el prototipo trata el dinero como cualquier otro número. Suma, divide y aplica porcentajes usando decimales que no siempre se representan exactamente. La UI redondea de una manera, el backend de otra, y el proveedor de pagos quizá de forma distinta otra vez. Esas pequeñas diferencias terminan en mensajes tipo “¿por qué me cobraron más?”.

Un centavo parece inofensivo, pero se acumula:

• Tickets de soporte y reembolsos consumen tiempo
• Contracargos generan comisiones y riesgo de cuenta
• Contabilidad se complica cuando los totales no coinciden con los informes
• La confianza baja cuando recibos y pantallas no concuerdan

El objetivo es la previsibilidad aburrida: las mismas entradas deben producir los mismos totales siempre, en carrito, checkout, recibo, facturas y reembolsos.

No necesitas un sistema financiero complejo para lograrlo. Necesitas unas pocas decisiones prácticas: almacenar montos de forma segura (el patrón más simple son centavos enteros), decidir dónde se permite el redondeo y acordar las reglas de la moneda antes de lanzar.

El problema oculto de los decimales y la aritmética en punto flotante

Los precios parecen sencillos en pantalla: $9.99, $19.00, $0.50. El problema es que muchos lenguajes de programación almacenan estos valores como números de punto flotante. El punto flotante está pensado para velocidad, no para aritmética monetaria exacta. Algunos valores decimales no se pueden representar perfectamente en binario, así que el valor almacenado queda ligeramente desviado.

Así es como $9.99 puede convertirse silenciosamente en algo como 9.9899999997 o 9.9900000003 dentro de tu app. Normalmente no lo notas al imprimir un número porque el formato lo redondea para mostrarlo. Pero el pequeño error sigue ahí.

Esos errores aparecen en tareas normales de facturación:

• Sumar muchas líneas
• Aplicar impuestos (multiplicar y luego redondear)
• Aplicar descuentos porcentuales
• Dividir o prorratear cargos

Un escenario común: un carrito suma $49.95 (cinco artículos a $9.99). La UI muestra $49.95. Luego añades 8.25% de impuesto. Si los valores subyacentes están ligeramente desviados, el impuesto puede redondearse distinto según cómo lo calcules (por artículo vs al final). El cliente ve un total, pero el procesador de pagos recibe otro, a veces con diferencia de $0.01.

Esa discrepancia es donde empiezan las disputas. A los usuarios no les importa que la diferencia sea “solo redondeo”. Les importa que la pantalla de checkout, el recibo y el cargo de la tarjeta no coincidan.

Decide la moneda y las reglas de redondeo antes de escribir código

Muchos errores de facturación no son causados por "malas matemáticas". Ocurren porque nadie acordó las reglas.

Empieza por elegir una moneda de precios. Para pruebas tempranas, suele ser suficiente una moneda. Puedes seguir mostrando un símbolo en la UI, pero el producto debería tener una moneda oficial para almacenar precios y cargos.

Luego decide cuándo se permite redondear. Redondear cada línea puede producir un resultado distinto que redondear solo el total final, especialmente cuando hay descuentos e impuestos. Cualquiera de los dos enfoques puede funcionar, pero necesitas uno y el mismo en todo el sistema.

Un pequeño conjunto de reglas evita la mayoría de las disputas:

• Una moneda de precios para los precios almacenados
• Un único momento de redondeo (por línea o en el total final)
• Un orden fijo de operaciones (por ejemplo: descuentos, luego impuesto, luego tasas)
• Una promesa clara sobre lo que se muestra vs lo que se cobra (lo que el usuario ve debe coincidir con lo que envías al procesador)
• Una única fuente de verdad cuando los números difieren (tus totales guardados, o el total del procesador)

Si después cambias a almacenar en centavos enteros, estas reglas te dirán qué guardar, qué calcular y qué comparar con los recibos del procesador.

El modelo más seguro: enteros para montos, moneda como código

Si quieres que los precios se comporten igual en todos los entornos, la opción más segura es simple: guarda el dinero en unidades menores enteras (centavos para USD) y guarda la moneda como un código separado.

Cuando guardas un monto como decimal, por ejemplo 9.99, muchos sistemas no pueden representarlo exactamente. Aunque la UI imprima “$9.99”, el valor almacenado podría estar algo por encima o por debajo. Esa diferencia puede cambiar los totales tras impuestos, descuentos o cálculos repetidos. Si guardas 999 en su lugar, las operaciones se mantienen exactas.

Un modelo de almacenamiento limpio tiene dos partes:

• Monto en unidades menores (entero)
• Código de moneda (como USD o EUR)

Usa nombres de campos que hagan difícil equivocarse:

• amount_cents (integer)
• currency (string)
• description (opcional, para recibos y logs)
• created_at (para auditorías)
• metadata (opcional, separado de los campos de dinero)

Mantén las cadenas formateadas fuera del almacenamiento. “$9.99” es una elección de visualización, no un valor. Formatea en el límite de la UI usando el amount + currency.

Planifica negativos desde el principio. Reembolsos, créditos y contracargos son normales. Un entero con signo deja claro un reembolso como -999 en la misma moneda.

Paso a paso: implementar precios en centavos enteros en un prototipo

Elige una moneda base y escríbelo: en qué cobras, qué símbolo muestras y cómo redondeas. Esa decisión única evita muchos sorpresas tipo “pensábamos que era USD”.

Luego almacena dinero en centavos en todos los lugares que importan. En tu base de datos, guarda amount_cents como entero (999 significa $9.99) y currency como un código corto como USD. En tu código, pasa los montos también como enteros.

Un flujo sencillo y predecible:

• Mantén listas de precios en centavos (plan_price_cents = 999)
• Multiplica y suma usando enteros (cantidad, complementos, unidades de uso)
• Aplica descuentos con aritmética entera, usando una única regla de redondeo
• Añade impuestos y tarifas usando esa misma regla
• Guarda resultados como subtotal_cents, tax_cents, total_cents, además de la moneda

Solo redondea donde tus reglas lo permitan. Un enfoque común es calcular el subtotal en centavos, calcular impuestos a partir de ese subtotal y luego redondear el impuesto una vez a centavos.

Para auditoría, registra entradas (precios, cantidades, descuento, tasa de impuesto, moneda) y salidas (subtotal_cents, tax_cents, total_cents). Cuando un total parece incorrecto, esos logs dejan claro el problema en lugar de que sea misterioso.

Impuestos, descuentos y tarifas sin sorpresas de redondeo

Si guardas precios base como centavos enteros, la mayoría de los problemas aparecen después: impuestos, propinas, tarifas y descuentos porcentuales. Esos pasos generan fracciones de centavo, así que necesitas reglas consistentes.

Elige una regla de redondeo y úsala en todas partes

Elige un método de redondeo y mantenlo. Dos opciones comunes son half-up (0.5 redondea hacia arriba) y half-even (redondeo bancario). Cualquiera puede ser válido. Mezclarlos es lo que causa los argumentos de “tu recibo difiere del mío”.

También decide cuándo se permite redondear. Una regla práctica es: haz los cálculos en unidades menores y solo redondea cuando tengas que convertir un resultado porcentual de nuevo a centavos.

Descuentos porcentuales: evita la trampa del centavo

Un 10% de descuento sobre 999 cents es 99.9 cents. Esa décima de centavo tiene que ir a algún lado, y debe ir siempre al mismo lugar.

Una secuencia fiable:

• Calcula discount_cents desde el subtotal original
• Redondea discount_cents una vez usando tu método elegido
• Sustrae discount_cents del subtotal_cents
• Calcula el impuesto desde el subtotal con descuento (si eso coincide con tu política)

Esto evita el doble redondeo, donde redondeas en medio del camino y luego vuelves a redondear al final.

Haz las tarifas explícitas

Las tarifas son más fáciles de entender y depurar cuando son campos separados, no enterradas en totales. Usa nombres claros como shipping_cents, service_fee_cents, platform_fee_cents y tip_cents. Tu recibo puede entonces reflejar tu base de datos.

Si puedes explicar cada centavo en la factura, normalmente evitas disputas.

Multimoneda: qué hacer ahora y qué posponer

La mayoría de los prototipos no necesita verdadera multimoneda desde el día uno. Si tus usuarios pagan en un país y liquidas en una moneda, mantenlo en una sola moneda y haz bien lo básico. Puedes seguir mostrando una estimación convertida, pero trátala solo como visualización, no como el monto que cobras.

Si sí soportas varias monedas, cada monto debe ir acompañado de un código de moneda (USD, EUR, GBP). El patrón de unidades menores enteras sigue aplicando, pero “centavos” no son universales. Algunas monedas no tienen unidades menores (JPY) y otras tienen tres decimales (KWD). Así que guarda:

• Monto entero en unidades menores
• Código de moneda
• La precisión de unidades menores de la moneda (derivada del código)

Acepta también que las tasas de cambio no son reversibles. Convertir USD a EUR y volver no devolverá el mismo monto entero. Eso es normal. El error es pretender que las conversiones no tienen pérdidas y luego discutir por el centavo que falta.

Si soportas varias monedas, anota:

• De dónde vienen las tasas
• Cuánto tiempo es válida una tasa
• Qué guardas (monto cobrado, tasa usada, cualquier conversión de referencia)
• Cuándo conviertes (checkout, factura, liquidación)
• Cómo redondeas

Evita mezclar monedas en un mismo total a menos que también definas el paso de conversión.

Errores comunes que llevan a disputas de facturación

La mayoría de las disputas comienzan pequeñas: una pantalla muestra $19.99, el recibo $20.00 y el cargo en tarjeta $19.98. A los usuarios no les importa por qué. Les parece descuidado o deshonesto.

Una causa frecuente es almacenar valores “bonitos” en vez de valores en crudo. Si guardas “$10.00” o “10.00” (ya formateado), distintas partes de la app lo re-parsearán, volverán a redondear o asumirán una moneda. Una opción de visualización inofensiva se convierte en totales incorrectos.

Otra causa raíz es tener múltiples lugares que calculan totales. Si el carrito redondea cada línea, la factura redondea el subtotal y la petición de pago redondea el total final, puedes obtener tres respuestas diferentes.

Patrones que suelen crear totales desajustados:

• Calcular totales en el navegador y confiar en ellos sin verificación en el servidor
• Generar correos o facturas desde una vía de cálculo distinta a la del checkout
• Hardcodear un símbolo de moneda y asumir que todas las monedas se comportan como USD
• Aplicar descuento-luego-impuesto en un lugar y impuesto-luego-descuento en otro
• Omitir pruebas de casos límite (montos pequeños, muchas líneas, agregar/quitar repetidamente)

Verificaciones rápidas antes de lanzar pagos

Antes de poner tarjetas reales detrás de un prototipo, haz una pasada de saneamiento del dinero. La mayoría de los errores de pago son inconsistencias pequeñas que generan grandes problemas de soporte.

Empieza por el almacenamiento: los montos deben ser enteros en la unidad más pequeña de esa moneda, incluidos reembolsos y créditos. Si ves decimales en columnas de monto de la base de datos, tómatelo como una bandera roja.

Luego verifica el manejo de moneda: cada monto debe viajar con un código de moneda. Si una API devuelve amount: 1999 sin currency: USD, alguien adivinará incorrectamente más adelante.

Finalmente, elige un propietario para los totales. Una función o servicio calcula subtotal, impuesto, descuentos, tarifas y total general. Todos los demás leen los resultados guardados. Si la página de checkout y el handler del webhook vuelven a calcular, acabarán en desacuerdo.

Una lista corta que atrapa la mayoría de los problemas:

• Montos enteros en todos los lugares que importan (incluidos reembolsos)
• Código de moneda presente en cada valor monetario
• Totales calculados en un solo lugar, guardados y reutilizados
• Reglas de redondeo documentadas y cubiertas por tests
• Números de factura/recibo que coinciden con el monto cobrado al centavo

Prueba con casos límite reales, no solo ejemplos como “$1.00”: descuentos porcentuales más impuestos, reembolsos parciales después de descuentos, tarifas añadidas antes vs después de impuestos, y carritos con muchos artículos pequeños.

Un ejemplo realista: dónde se pierde un centavo

Imagina que vendes un plan de $9.99, ofreces 20% de descuento y cobras 8.25% de impuesto de ventas. El plan se factura para 3 asientos en una factura.

Con centavos enteros, cada asiento es 999 cents. La diferencia viene de cuándo redondeas.

Dos maneras razonables de redondear

Método A: redondear cada asiento tras el descuento

El descuento por asiento es 20% de 999 = 199.8 cents, redondeado a 200 cents. Neto por asiento: 999 - 200 = 799 cents. Para 3 asientos: 799 x 3 = 2,397 cents ($23.97). Impuesto: 2,397 x 0.0825 = 197.7525 cents, redondeado a 198 cents. Total: 2,397 + 198 = 2,595 cents ($25.95).

Método B: redondear solo en el subtotal

Subtotal = 999 x 3 = 2,997 cents ($29.97). Descuento = 20% de 2,997 = 599.4 cents, redondeado a 599 cents. Neto: 2,997 - 599 = 2,398 cents ($23.98). Impuesto: 2,398 x 0.0825 = 197.835 cents, redondeado a 198 cents. Total: 2,398 + 198 = 2,596 cents ($25.96).

Ambos métodos son defendibles. Difieren en un centavo. Si tu UI muestra un método y el backend cobra el otro, has creado una disputa.

En la factura, explícalo en lenguaje claro para que las cuentas sean fáciles de seguir. Para reembolsos, no vuelvas a calcular. Reembolsa los centavos exactos cobrados, o puedes crear una discrepancia más adelante.

Registra suficiente información para reproducir la decisión:

• Código de moneda, tasa de impuesto, tasa de descuento
• Regla de redondeo y dónde ocurre
• Líneas, cantidades y centavos finales cobrados
• Valores intermedios clave (antes y después del redondeo)
• IDs del procesador para cargo y reembolso

Próximos pasos: haz que el manejo del dinero sea aburrido y fiable

El objetivo no es un código de facturación ingenioso. Es que los totales siempre coincidan: carrito, factura, recibo, reembolsos e informes.

Escribe tus reglas de dinero en un breve documento compartido: moneda soportada, método de redondeo, dónde se permite redondear y el orden de operaciones. Luego añade un pequeño conjunto de tests que fije esos comportamientos, especialmente alrededor de descuentos pequeños, muchas líneas y reembolsos parciales.

Si heredas un prototipo generado por IA (especialmente de herramientas como Lovable, Bolt, v0, Cursor o Replit), vale la pena una limpieza rápida antes de que lo usen clientes reales. La aritmética en float suele esconderse en helpers, funciones de formato de UI o columnas de base de datos con precisión inconsistente.

FixMyMess (fixmymess.ai) ayuda a equipos a convertir prototipos donde “los pagos funcionan más o menos” en flujos de facturación listos para producción diagnosticando la aritmética, normalizando el almacenamiento del dinero y ajustando las reglas de redondeo para que el monto cobrado sea consistente en cada paso.