Normalizar montos: por qué '1.234,56' y '1234.56' son el mismo número

Un portal puede mostrar un importe como “$ 1.234,56” y una respuesta de integración devolver 1234.56 para la misma acta. No son dos montos: son dos convenciones de escritura del mismo número. En la local, el punto agrupa de a tres cifras y la coma abre los decimales; en la de intercambio, el punto es el separador decimal y la agrupación no se escribe.

La diferencia no es estética. Una lectura tolerante que aplique a la primera cadena la regla de la segunda la deja en poco más de uno; al revés, 1234.56 tomado como si el punto agrupara miles se vuelve cien veces más grande. El factor depende de dónde caiga el separador. Rara vez se nota en una tarjeta suelta: aparece al comparar dos consultas o al sumar una flota.

Por eso normalizar un monto no es sacarle los puntos y las comas. Es declarar por fuente qué papel cumple cada separador, conservar el texto tal como llegó y poder mostrar después con qué regla se leyó.

Moneda y escala no viven en la cadena

La escala tampoco sale de la cadena: el estándar ISO 4217 asigna a cada moneda un código y una unidad menor, y ARS identifica al peso argentino. Que una pantalla escriba dos decimales, ninguno o un símbolo pegado es presentación de esa fuente, no una propiedad del monto; moneda y escala las guardamos aparte.

Los casos que el texto no resuelve solo

Cuando la cadena trae los dos separadores, la lectura es directa: el de más a la derecha abre los decimales. Con uno solo, hay tres situaciones:

• un separador seguido de una o dos cifras suele ser decimal;
• un separador seguido de más de tres cifras no puede ser agrupación;
• un separador seguido de exactamente tres cifras es ambiguo.

El último no se resuelve con intuición ni con el tamaño del número, sino con una hipótesis declarada por fuente y por campo. Mientras no la tengamos, dejamos el importe sin normalizar antes que normalizado mal.

Alrededor del separador conviven otros ruidos: símbolo de moneda pegado, espacios como agrupador, un guion final en lugar de los centavos, paréntesis para negativos. Cada uno se quita en un paso explícito; el reemplazo global que borra todo lo que no sea dígito es el que convierte cuatro cifras en seis.

Guardar el original, la regla y el valor

Guardamos por separado el texto exacto que publicó la fuente, el valor normalizado, la moneda y la versión de la regla aplicada. Para el valor conviene una escala fija —un entero en la unidad menor o una cadena decimal canónica— y no arrastrar diferencias binarias entre lenguajes.

Con esos campos aparece un control barato: volvemos a escribir el valor normalizado con la convención declarada para esa fuente y lo comparamos con la cadena original. Si no coincide, la lectura fue inconsistente y el registro va a revisión en lugar de entrar como monto. El control tiene un límite: prueba que la regla se aplicó pareja, no que sea la correcta. Una hipótesis equivocada pero uniforme reproduce la misma cadena y pasa el chequeo; los ambiguos siguen necesitando una fuente que declare el formato.

Vale la misma lógica que con el texto de la infracción: la capa normalizada compara, no reemplaza lo publicado.

Dónde se rompe el formato: CSV, JSON y planillas

El formato CSV separa los campos con comas y prevé encerrar entre comillas los valores que la contienen; sin ese entrecomillado, un importe con coma decimal parte la fila en dos columnas, y sólo se arregla citando el valor o cambiando el separador de campos. Una planilla, además, puede reinterpretar los números según la configuración regional de la máquina que la abre: el mismo archivo llega a leerse distinto en dos computadoras.

En JSON el punto es el único separador decimal y no existe la agrupación: un importe escrito a la manera local nunca es un número ahí, es una cadena. El estándar además permite que las implementaciones limiten rango y precisión, otra razón para que el monto viaje como texto.

Publicar un monto de forma reutilizable empieza por declarar el formato de cada campo —separador decimal, agrupador, moneda y escala— en vez de dejar que cada consumidor lo deduzca de los valores que le tocaron.

Qué mostrar y qué verificar

Comparamos, ordenamos y sumamos con el valor normalizado; mostramos con la convención local. Si estás revisando importes, chequeá tres cosas: abrí el CSV exportado en un editor de texto antes que en una planilla; ante una diferencia entre dos consultas, fijate si cambió el monto o sólo su escritura, según cómo se clasifica la causa; y si integrás por API, pedí el formato documentado en lugar de inferirlo.

Un monto bien leído sigue siendo el que informó una fuente en una fecha. Normalizarlo no lo convierte en deuda exigible ni reemplaza los canales del organismo: sólo busca que el número que se ve y el que se guardó sean el mismo.

Preguntas frecuentes

¿“1.234,56” y “1234.56” son realmente el mismo importe?

Sí, siempre que se sepa qué papel cumple cada separador. En la escritura local el punto agrupa de a tres cifras y la coma abre los decimales; en la escritura de intercambio de datos el punto es el separador decimal y la agrupación no se escribe. La cantidad es la misma; lo que cambia es la regla necesaria para leerla.

¿Qué pasa con un monto escrito “1.234”, sin decimales visibles?

Es ambiguo tomado en forma aislada. Un separador seguido de exactamente tres cifras puede ser agrupación de miles o parte decimal. No se resuelve por intuición ni por el tamaño del número, sino con una convención declarada para esa fuente y ese campo. Sin esa convención, es preferible dejar el importe sin normalizar antes que normalizarlo mal.

¿Un cambio de formato entre dos consultas significa que cambió el monto?

No necesariamente. Una fuente puede modificar cómo escribe el importe sin que el valor se mueva, y también puede actualizar el valor conservando la escritura. Por eso comparamos el valor normalizado y conservamos la cadena original de cada observación, con su fecha.

¿Conviene guardar el monto como número decimal y listo?

Para dinero suele ser preferible un entero en la unidad menor o una cadena decimal canónica, con la escala documentada. Así se evitan diferencias binarias entre lenguajes y queda registro de la escala publicada por la fuente, que no siempre coincide con la que muestra la interfaz.

Notas relacionadas