Soporte multidivisa: precios, cobros, redondeo y visualización

El soporte multidivisa significa que un cliente en Tokio, en Londres y en Valencia ve cada uno un precio en su propia divisa, con el formato que su mercado espera, calculado sin errores de redondeo. Suena a problema de visualización. En realidad es un problema de almacenamiento de datos y de lógica de negocio disfrazado de problema de visualización. Muchos errores aparecen cuando el proyecto no define desde el principio el almacenamiento, el cálculo y el formato de los importes.

Practicamos el desarrollo de software multilingüe con las divisas bien gestionadas desde el primer commit, porque los fallos de precio son de los que un cliente nota al instante y perdona despacio. Esto es lo que exige de verdad "lo multidivisa": por qué la conversión al cambio del día no es una tarificación multidivisa real, cómo almacenar importes sin errores de coma flotante, por qué el número de decimales varía según la divisa, cómo las reglas de redondeo cambian según el mercado, y qué añaden el cobro y el IVA cuando vendes desde España.

La tarificación multidivisa no es una conversión al cambio del día

Un error frecuente en los sistemas multidivisa es guardar un único precio base y convertirlo al tipo de cambio del momento en el pago. Parece soporte multidivisa. No lo es, y los clientes notan la diferencia en unas pocas compras.

La conversión en tiempo real hace que tu precio se mueva cada vez que se mueve el tipo de cambio: el mismo producto puede costar un importe distinto al mismo cliente dos días seguidos. También significa que cada comisión, cada descuento y cada decisión de redondeo hereda la volatilidad del mercado de divisas; por eso, algunas empresas prefieren precios fijados por mercado y revisados periódicamente antes que recalcularlos en cada carga de página. El tipo de cambio orienta esa decisión. No la toma solo, en producción, en cada petición.

Si te suena abstracto, piensa en la conversión dinámica de divisa (DCC), esa pantalla del datáfono que te ofrece cobrarte en tu propia divisa "para tu comodidad" con un tipo peor que el de tu banco. La DCC es un mecanismo distinto, sujeto a sus propias condiciones, en el que el comercio ofrece cobrar en la divisa del titular; no es idéntica a la tarificación multidivisa de un ecommerce, pero comparte el mismo problema de fondo: dejar que el tipo de cambio decida el precio en el momento del cobro. La distinción pesa sobre todo en el desarrollo de ecommerce a medida, donde un cliente que compara tu precio con el de la competencia necesita que se quede quieto, y donde las pasarelas de pago liquidan en divisas concretas con sus propias reglas sobre lo que aceptan.

Almacena el dinero como enteros, nunca como decimales de coma flotante

Un error multidivisa muy común no tiene nada que ver con las divisas. Es guardar el dinero como decimal de coma flotante, lo que introduce errores de redondeo que se acumulan a lo largo de un carrito, un cálculo de impuestos y una pasarela de pago que no tolera que aparezca un céntimo fraccionario donde no debe. En una integración como la API de Stripe, los importes se expresan en la unidad menor de la moneda y las monedas sin decimales requieren un tratamiento específico; conviene adoptar una representación entera coherente en la capa de pagos y definir explícitamente las excepciones.

El remedio es una convención de hace décadas que los equipos nuevos en el tema siguen saltándose: almacena cada importe como entero en la unidad más pequeña de la divisa, los céntimos para el euro, y convierte a valor decimal de visualización solo al pintar la pantalla. La propia API de Stripe funciona así por exactamente este motivo: los importes se representan en la unidad más pequeña de la divisa, en entero, nunca en coma flotante (Monedas aceptadas). Acierta esto una vez, en la capa de base de datos y API, y toda una categoría de fallos de un céntimo arriba o abajo deja de existir. Lo mismo vale aguas abajo, en el software de facturación a medida para pymes: una factura que no cuadra con el cobro por un céntimo es una llamada a tu gestoría.

Las unidades menores no siempre son dos decimales

"Redondear a dos decimales" es correcto para el dólar estadounidense y el euro, y falso para una parte significativa de las divisas del mundo. El número de decimales, formalmente la unidad menor, se define por divisa en la norma ISO 4217, y varía más de lo que la mayoría de los ingenieros imagina (ISO 4217): la norma relaciona cada moneda con su unidad menor cuando existe, por lo que el número de decimales debe modelarse por moneda y no fijarse globalmente en dos.

• Cero decimales: el yen japonés (JPY) y el won coreano (KRW) no tienen subdivisión en la práctica. Un precio de 1.000,50 ¥ no es un importe real; es un fallo.
• Dos decimales: la mayoría de las divisas, entre ellas USD, EUR y GBP.
• Tres decimales: el dinar bahreiní, el dinar kuwaití, el rial omaní y el dinar jordano se subdividen todos en milésimas, no en centésimas.

Un motor de precios fijado en dos decimales corrompe en silencio cada precio en yenes que toca y trunca cada precio en dinares. El redondeo ajustado a cada divisa, guiado por la tabla de unidades menores de ISO 4217 en lugar de por una constante global, no es un caso límite. Es la base para cubrir bien más de un puñado de mercados.

Las reglas de redondeo varían según el mercado, no solo según la divisa

Incluso dentro de una misma divisa, las convenciones de redondeo cambian según el mercado y el medio de pago. Suiza suele citarse como ejemplo: el franco suizo se subdivide en 100 céntimos sobre el papel, y en determinadas operaciones en efectivo se puede redondear al múltiplo de 0,05 CHF más cercano, una convención a menudo llamada redondeo suizo o Rappenrundung, porque la moneda de cinco céntimos es la más pequeña que sigue en circulación; la aplicación concreta depende del contexto y de la normativa o práctica aplicable, así que conviene verificarlo antes de tratarlo como regla general. Una caja que muestra un precio de 19,98 CHF y luego cobra exactamente eso en efectivo podría no coincidir con lo que un mercado que redondea el efectivo espera pagar.

La lección va más allá de este ejemplo: el redondeo es una regla de negocio propia de cada mercado, no una función matemática universal. Un sistema multidivisa necesita una política de redondeo por mercado, no un único .toFixed(2) global, so pena de producir precios numéricamente próximos y localmente erróneos.

Cobros e IVA cuando vendes desde España

El multidivisa se cruza con dos asuntos muy españoles en cuanto sales del prototipo: cómo cobras y cómo declaras.

Del lado del cobro, los medios que tus clientes usan de verdad no son los de un manual estadounidense. En España, muchas tiendas integran pasarelas y TPV virtuales como Redsys, aunque la disponibilidad y la divisa de liquidación dependen del proveedor, del contrato y de la configuración del comercio. En los pagos electrónicos iniciados por el ordenante, la autenticación reforzada de cliente (SCA) se rige por los requisitos europeos de la PSD2 y su Reglamento Delegado; en los pagos remotos, la operación debe vincularse dinámicamente al importe y al beneficiario, salvo que aplique una exención, así que tu pantalla de pago tiene que sostener ese paso extra sin perder el importe por el camino. Bizum opera en euros y las transferencias SEPA se expresan en euros, así que su disponibilidad debe comprobarse antes de ofrecerlas junto a un precio mostrado en otra divisa: si tu escaparate le muestra libras a un cliente y luego le ofreces Bizum, el sistema tiene que saber qué medios existen para qué divisa antes de pintar los botones, no después.

Del lado del IVA, la divisa y el impuesto viajan juntos. Desde el 1 de julio de 2021, el umbral aplicable a las ventas a distancia intracomunitarias y a los servicios TBE es un umbral único de la UE de 10.000 € anuales, la suma de todos los Estados miembros juntos, no una cifra por país (Comisión Europea, Comisión Europea). Por debajo del umbral pueden seguir tributando en el Estado de establecimiento; superado ese límite, se aplican las reglas del lugar de destino y la ventanilla única (OSS) puede simplificar la declaración, sujeto a sus condiciones y excepciones, sin necesidad de darte de alta en cada Estado (Unión Europea). La OSS permite presentar una declaración única y efectuar un único pago a través del portal del Estado miembro de identificación; en el régimen de la Unión, la declaración es trimestral y los registros deben conservarse durante diez años (Unión Europea). La OSS exige declarar y pagar el IVA a través del Estado miembro de identificación; cuando una operación se expresa en una moneda distinta del euro, deben aplicarse las reglas oficiales de conversión y conservarse el tipo y la fecha utilizados. Traducido a arquitectura: tu sistema tiene que guardar el importe en la divisa cobrada y su contravalor en euros con el tipo y la fecha que aplicó, o cada trimestre alguien lo reconstruye a mano en una hoja de cálculo.

Y hay una regla de visualización que puede cambiar según a quién le vendes y según la normativa aplicable en cada país y contexto de la oferta: al consumidor final suele exigirse mostrar el precio final con los impuestos ya incluidos, mientras que en B2B la convención habitual es mostrar el precio sin el impuesto, marcado como "(IVA no incluido)"; conviene confirmar la base legal correspondiente antes de tratarlo como una regla única para todos los casos. Un mismo motor de precios que sirve a los dos públicos necesita saber en qué modo está antes de formatear nada.

Mostrar la divisa como cada mercado la espera

El formato es la parte que los usuarios ven de verdad, y es la configuración regional, no solo la divisa, la que decide el resultado. El mismo importe en la misma divisa se pinta distinto por convención: 1.234,56 € en España, 1 234,56 € con un espacio como separador de miles en Francia, y $1,234.56 en Estados Unidos, con la coma y el punto intercambiados y el símbolo delante. Posición del símbolo, separador decimal y separador de grupos varían cada uno con independencia de la divisa mostrada.

Las plataformas modernas no necesitan construir esta lógica a mano. La API Intl.NumberFormat, apoyada en los mismos datos de configuración regional de CLDR que guían el buen formato de fechas y números, permite formatear un importe según la configuración regional y la moneda (por ejemplo, "123.456,79 €" para de-DE, o el yen mostrado sin unidad menor) y produce la salida correcta para un par divisa-idioma dado, sin una tabla de correspondencias que mantener. Fijar en el código un prefijo de moneda y una regla de miles con coma es la versión parche de este problema: funciona para un mercado y se rompe en silencio para todos los demás. La misma disciplina que aplicas a Unicode y la codificación de caracteres vale aquí: los datos del estándar ya existen, y reescribirlos a mano solo añade formas nuevas de equivocarse.

Preguntas frecuentes sobre el soporte multidivisa

¿Qué significa de verdad el soporte multidivisa?

Significa que los clientes ven precios en su propia divisa, calculados con una tarificación controlada por mercado en lugar de una conversión al cambio del día, almacenados sin errores de redondeo de coma flotante, y con el formato que su mercado espera.

¿Debo convertir mis precios con un tipo de cambio en directo?

No para el precio que paga el cliente. Los tipos en directo sirven para los informes internos y para orientar el precio que un mercado debería llevar, pero el precio en sí debe ser un valor controlado, fijado a conciencia por mercado, no un número que sigue al mercado de divisas en cada carga de página.

¿Por qué algunas divisas tienen tres decimales?

Divisas como el dinar bahreiní y el dinar kuwaití se subdividen en milésimas en lugar de centésimas, según la norma ISO 4217. Un software que asume dos decimales en todas partes trunca o redondea mal estas divisas.

¿Cuál es la forma más segura de guardar precios en una base de datos?

Como entero en la unidad más pequeña de la divisa: los céntimos para una divisa de dos decimales como el euro, ninguna subdivisión para una divisa de cero decimales como el yen japonés. Convierte a decimal solo al mostrar el importe, nunca para el almacenamiento ni el cálculo.

¿Cómo consigo una tarificación multidivisa bien construida para mi tienda?

Métela en el alcance desde el principio: el almacenamiento de precios, las reglas de redondeo por mercado y la visualización adaptada a la configuración regional son decisiones de arquitectura, no un plugin de caja. Pide un presupuesto cerrado y construimos la capa de divisas en el núcleo del sistema, no como parche posterior.

Una gestión de divisas que no se rompe al crecer

Cuéntanos qué mercados y qué divisas tiene que cubrir tu software. Diseñamos la tarificación, el redondeo y la visualización bien desde el primer commit, y respondemos con un precio cerrado y una fecha de entrega.

Pide un presupuesto cerrado →