Soinda
Blog con novedades y tips para el día a día.
Caso real · Software financiero
El reto de los 3 decimales exactos: cómo replicamos el Excel de un cliente en un dashboard de +10.000 empresas
«Necesito que vuestra plataforma dé exactamente los mismos números que mi hoja de cálculo. Hasta el tercer decimal. En todas las empresas.» No era una broma. Era el requisito. Y lo cumplimos.
Hay requisitos que suenan triviales en una reunión y se convierten en el corazón de todo el proyecto. «Que los números cuadren» es uno de ellos. Cuando una gestora de inversiones nos pidió un dashboard que replicara al tercer decimal los cálculos de los modelos en Excel que llevaban años puliendo, supimos que el verdadero trabajo no estaba en pintar gráficos bonitos: estaba en que el 3,142 de su Excel fuera, sin excepciones, el 3,142 de nuestra plataforma.
01El requisito que parecía imposible
El cliente tenía un activo invisible pero crítico: la confianza en sus propios números. Sus analistas tomaban decisiones de inversión a partir de hojas de cálculo construidas y validadas durante años. Esos modelos eran su lenguaje. Cualquier herramienta nueva que no hablara exactamente ese mismo lenguaje sería rechazada de inmediato, por muy moderna que fuera.
Por eso el requisito no fue «que se parezca» ni «que esté dentro de un margen razonable». Fue literal:
El requisito, palabra por palabra
«Los resultados deben coincidir con mi Excel hasta el tercer decimal, para las más de 10.000 empresas cotizadas que analizamos.»
A 3 decimales, sobre 30+ métricas interdependientes, multiplicado por 10.000 empresas, en 12 divisas distintas y con datos llegando de 6 APIs externas. Cualquier desviación de una milésima en una sola celda rompía la confianza en toda la plataforma. Y «un decimal mal» no es un bug cosmético en finanzas: es la diferencia entre comprar y no comprar.
02Por qué replicar un Excel es mucho más difícil de lo que parece
La intuición dice: «son las mismas fórmulas, dará el mismo resultado». La realidad es que un número en pantalla es el final de una larga cadena de decisiones técnicas, y casi todas pueden hacer que dos sistemas que aplican «la misma fórmula» den resultados distintos.
Los ordenadores no saben sumar decimales (de verdad)
Esto sorprende a casi todo el mundo, pero es la base del problema. La mayoría de lenguajes representan los números con coma flotante (el estándar IEEE 754), que almacena los decimales en binario. Y muchos decimales sencillos en base 10 no tienen representación exacta en binario. El ejemplo canónico:
// En prácticamente cualquier lenguaje con coma flotante
0.1 + 0.2
→ 0.30000000000000004 // ...no es 0.3
Si esto pasa con una suma trivial, imagina lo que ocurre tras encadenar 30 cálculos que se alimentan unos a otros. Los errores diminutos se acumulan y, redondeados a 3 decimales al final, terminan apareciendo justo donde no debían.
Excel tampoco es «la verdad exacta»
Aquí está el giro contraintuitivo del proyecto: el propio Excel usa coma flotante por debajo y oculta sus imprecisiones mostrando solo unos cuantos dígitos. Además aplica sus propias reglas de redondeo y de precisión intermedia. Por tanto, replicar el Excel del cliente no consistía en «calcular bien»: consistía en reproducir exactamente el comportamiento de Excel, quirks incluidos. Nuestro objetivo no era la verdad matemática absoluta, sino la coincidencia perfecta con su referencia.
El orden de las operaciones importa
Cuando 30+ métricas dependen unas de otras, el orden en que se calculan y el momento exacto en que se redondea cambian el resultado final. ¿Se redondea cada paso intermedio o solo al mostrar? ¿La métrica B usa el valor completo de A o su versión redondeada? Cada una de esas decisiones, tomada de forma distinta a como la tomaba el Excel, generaba una milésima de diferencia.
Y encima, dos lenguajes calculando lo mismo
La plataforma corre sobre React en el navegador y Laravel (PHP) en el servidor. Si el frontend y el backend calculan «por su cuenta», antes o después divergen: redondean distinto, ordenan distinto, arrastran errores distintos. Dos motores de cálculo son, garantizado, dos resultados que algún día no coinciden.
En una frase
Conseguir 3 decimales idénticos no es un problema de matemáticas. Es un problema de ingeniería de la precisión: control sobre cómo se representan, ordenan, redondean y verifican los números en cada capa del sistema.
03La caza del decimal perdido
Antes de escribir una sola línea de la solución, hicimos ingeniería inversa del modelo del cliente. No bastaba con leer las fórmulas: había que entender en qué orden calculaba, dónde redondeaba y qué reglas aplicaba en los casos límite.
- Mapeamos la cascada completa de las 30+ métricas: qué alimenta a qué, y en qué secuencia. Reconstruimos el grafo de dependencias para reproducirlo idéntico.
- Identificamos cada punto de redondeo: distinguimos los redondeos intermedios (que cambian el cálculo) de los de presentación (que solo afectan a lo que se ve).
- Fijamos la regla de redondeo que usaba el cliente —redondeo al alza del 0,5 (round half up), el de Excel— frente a otras alternativas como el redondeo bancario (round half to even), que habría dado milésimas distintas.
- El caso GBX / GBP: muchas acciones británicas cotizan en peniques (GBX), no en libras (GBP), con un factor de 100 entre medias. Un descuido aquí no es una milésima: son dos órdenes de magnitud. Lo tratamos como caso especial explícito.
- Conversión entre 12 divisas: definimos cuándo y con qué precisión se convierte, para que el redondeo de la conversión no contaminara las métricas posteriores.
04La solución técnica
Aritmética decimal, no coma flotante
El primer cambio de fondo: dejar de calcular con coma flotante y pasar a aritmética decimal de precisión controlada. En el backend usamos las funciones de precisión arbitraria de PHP (BCMath), que operan sobre los números como cadenas y no arrastran el error binario. En el frontend, una librería de decimales (decimal.js) para que React calcule con las mismas garantías.
// El problema (coma flotante)
0.1 + 0.2 → 0.30000000000000004
// La solución (aritmética decimal)
new Decimal(0.1).plus(0.2).toFixed(3) → "0.300"
Un único motor de cálculo como fuente de la verdad
Para que frontend y backend nunca pudieran divergir, centralizamos toda la lógica en un único motor de cálculo con reglas idénticas en ambos lados: mismo orden de operaciones, mismos puntos de redondeo, mismo tratamiento de casos especiales. Una sola definición de «cómo se calcula», en lugar de dos implementaciones que tarde o temprano se contradicen.
Reglas de redondeo explícitas y documentadas
Nada de redondeos «por defecto del lenguaje». Cada redondeo —su modo, su número de decimales y su momento en la cadena— quedó definido de forma explícita y documentada. Si en el futuro hay que auditar por qué un número es lo que es, la respuesta está escrita.
Caché para no sacrificar velocidad
La precisión decimal es más costosa que la coma flotante. Para que procesar 10.000 empresas siguiera siendo instantáneo, añadimos una capa de caché optimizada que reutiliza cálculos y resultados intermedios. La exactitud no podía pagarse con lentitud: el procesamiento de 1.000 empresas se mantiene por debajo de los 3 segundos.
05Cómo lo verificamos: tolerancia cero
Decir «coincide al tercer decimal» es fácil; demostrarlo, no. Montamos un sistema de verificación que compara, celda a celda y métrica a métrica, los resultados de la plataforma contra el Excel de referencia del cliente.
- Batería de pruebas automatizada que contrasta miles de valores contra la hoja del cliente, con tolerancia cero a nivel de 3 decimales.
- Casos límite cubiertos a propósito: divisas raras, GBX/GBP, empresas con datos incompletos, valores negativos y ceros, donde el redondeo suele fallar.
- Pruebas de regresión: cada vez que se toca el motor, las pruebas vuelven a correr. Si una sola milésima se mueve, salta la alarma antes de llegar a producción.
El criterio de aceptación
No era «pocos errores». Era cero. Si un solo número de las 10.000 empresas no coincidía al tercer decimal, no estaba terminado.
06El resultado
El dashboard no solo igualó al Excel: lo superó en todo lo demás. Mismos números en los que el cliente ya confiaba, pero con análisis predictivo en tiempo real, 33 tipos de gráficos financieros y la capacidad de analizar miles de empresas a la vez en lugar de una hoja cada vez.
0
Errores de cálculo
75%
Menos tiempo de análisis
10x
Más empresas en paralelo
<3s
Procesar 1.000 empresas
Lo más importante no aparece en una métrica: el equipo del cliente adoptó la herramienta sin desconfianza, porque desde el primer día los números eran los suyos. Esa es la diferencia entre un software que se usa y uno que acaba arrinconado.
07Qué tiene esto que ver con tu proyecto
Quizá no necesites 3 decimales en 10.000 empresas. Pero seguramente tienes algún proceso que solo tú haces de una forma concreta: una manera de calcular comisiones, de valorar stock, de facturar, de puntuar leads. Las herramientas genéricas te obligan a adaptarte a su forma de hacer las cosas. El desarrollo a medida hace lo contrario: se adapta a la tuya, hasta el último decimal.
Ese es exactamente el tipo de problema en el que nos especializamos en Soinda: traducir tu operativa real —con sus reglas, sus excepciones y sus manías— en software que funciona desde el primer día. Y cuando hablas con nosotros, hablas con quien programa, no con un comercial.
Desarrollo a medida en A Coruña
Aplicaciones web, dashboards, integraciones y módulos hechos para tu negocio. Mira qué desarrollamos →
Si tienes un proceso que ninguna herramienta del mercado replica bien, probablemente sea candidato perfecto para una solución a medida. Cuéntanoslo y te decimos cómo lo abordaríamos, cuánto costaría y cuánto tardaría —sin compromiso.
S
Equipo Soinda · Desarrollo de software a medida en A Coruña.
Convertimos procesos reales en código que funciona. Ver servicios de desarrollo →
¿Tu negocio tiene su propio «tercer decimal»?
Cuéntanos ese proceso que solo tú haces de una forma concreta. Te respondemos en 24h con una propuesta clara, presupuesto cerrado y plazo realista.
Presupuesto cerradoCódigo documentadoSoporte incluido
Caso real · Software financiero
El reto de los 3 decimales exactos: cómo replicamos el Excel de un cliente en un dashboard de +10.000 empresas
«Necesito que vuestra plataforma dé exactamente los mismos números que mi hoja de cálculo. Hasta el tercer decimal. En todas las empresas.» No era una broma. Era el requisito. Y lo cumplimos.
Hay requisitos que suenan triviales en una reunión y se convierten en el corazón de todo el proyecto. «Que los números cuadren» es uno de ellos. Cuando una gestora de inversiones nos pidió un dashboard que replicara al tercer decimal los cálculos de los modelos en Excel que llevaban años puliendo, supimos que el verdadero trabajo no estaba en pintar gráficos bonitos: estaba en que el 3,142 de su Excel fuera, sin excepciones, el 3,142 de nuestra plataforma.
01El requisito que parecía imposible
El cliente tenía un activo invisible pero crítico: la confianza en sus propios números. Sus analistas tomaban decisiones de inversión a partir de hojas de cálculo construidas y validadas durante años. Esos modelos eran su lenguaje. Cualquier herramienta nueva que no hablara exactamente ese mismo lenguaje sería rechazada de inmediato, por muy moderna que fuera.
Por eso el requisito no fue «que se parezca» ni «que esté dentro de un margen razonable». Fue literal:
El requisito, palabra por palabra
«Los resultados deben coincidir con mi Excel hasta el tercer decimal, para las más de 10.000 empresas cotizadas que analizamos.»
A 3 decimales, sobre 30+ métricas interdependientes, multiplicado por 10.000 empresas, en 12 divisas distintas y con datos llegando de 6 APIs externas. Cualquier desviación de una milésima en una sola celda rompía la confianza en toda la plataforma. Y «un decimal mal» no es un bug cosmético en finanzas: es la diferencia entre comprar y no comprar.
02Por qué replicar un Excel es mucho más difícil de lo que parece
La intuición dice: «son las mismas fórmulas, dará el mismo resultado». La realidad es que un número en pantalla es el final de una larga cadena de decisiones técnicas, y casi todas pueden hacer que dos sistemas que aplican «la misma fórmula» den resultados distintos.
Los ordenadores no saben sumar decimales (de verdad)
Esto sorprende a casi todo el mundo, pero es la base del problema. La mayoría de lenguajes representan los números con coma flotante (el estándar IEEE 754), que almacena los decimales en binario. Y muchos decimales sencillos en base 10 no tienen representación exacta en binario. El ejemplo canónico:
// En prácticamente cualquier lenguaje con coma flotante
0.1 + 0.2
→ 0.30000000000000004 // ...no es 0.3
Si esto pasa con una suma trivial, imagina lo que ocurre tras encadenar 30 cálculos que se alimentan unos a otros. Los errores diminutos se acumulan y, redondeados a 3 decimales al final, terminan apareciendo justo donde no debían.
Excel tampoco es «la verdad exacta»
Aquí está el giro contraintuitivo del proyecto: el propio Excel usa coma flotante por debajo y oculta sus imprecisiones mostrando solo unos cuantos dígitos. Además aplica sus propias reglas de redondeo y de precisión intermedia. Por tanto, replicar el Excel del cliente no consistía en «calcular bien»: consistía en reproducir exactamente el comportamiento de Excel, quirks incluidos. Nuestro objetivo no era la verdad matemática absoluta, sino la coincidencia perfecta con su referencia.
El orden de las operaciones importa
Cuando 30+ métricas dependen unas de otras, el orden en que se calculan y el momento exacto en que se redondea cambian el resultado final. ¿Se redondea cada paso intermedio o solo al mostrar? ¿La métrica B usa el valor completo de A o su versión redondeada? Cada una de esas decisiones, tomada de forma distinta a como la tomaba el Excel, generaba una milésima de diferencia.
Y encima, dos lenguajes calculando lo mismo
La plataforma corre sobre React en el navegador y Laravel (PHP) en el servidor. Si el frontend y el backend calculan «por su cuenta», antes o después divergen: redondean distinto, ordenan distinto, arrastran errores distintos. Dos motores de cálculo son, garantizado, dos resultados que algún día no coinciden.
En una frase
Conseguir 3 decimales idénticos no es un problema de matemáticas. Es un problema de ingeniería de la precisión: control sobre cómo se representan, ordenan, redondean y verifican los números en cada capa del sistema.
03La caza del decimal perdido
Antes de escribir una sola línea de la solución, hicimos ingeniería inversa del modelo del cliente. No bastaba con leer las fórmulas: había que entender en qué orden calculaba, dónde redondeaba y qué reglas aplicaba en los casos límite.
- Mapeamos la cascada completa de las 30+ métricas: qué alimenta a qué, y en qué secuencia. Reconstruimos el grafo de dependencias para reproducirlo idéntico.
- Identificamos cada punto de redondeo: distinguimos los redondeos intermedios (que cambian el cálculo) de los de presentación (que solo afectan a lo que se ve).
- Fijamos la regla de redondeo que usaba el cliente —redondeo al alza del 0,5 (round half up), el de Excel— frente a otras alternativas como el redondeo bancario (round half to even), que habría dado milésimas distintas.
- El caso GBX / GBP: muchas acciones británicas cotizan en peniques (GBX), no en libras (GBP), con un factor de 100 entre medias. Un descuido aquí no es una milésima: son dos órdenes de magnitud. Lo tratamos como caso especial explícito.
- Conversión entre 12 divisas: definimos cuándo y con qué precisión se convierte, para que el redondeo de la conversión no contaminara las métricas posteriores.
04La solución técnica
Aritmética decimal, no coma flotante
El primer cambio de fondo: dejar de calcular con coma flotante y pasar a aritmética decimal de precisión controlada. En el backend usamos las funciones de precisión arbitraria de PHP (BCMath), que operan sobre los números como cadenas y no arrastran el error binario. En el frontend, una librería de decimales (decimal.js) para que React calcule con las mismas garantías.
// El problema (coma flotante)
0.1 + 0.2 → 0.30000000000000004
// La solución (aritmética decimal)
new Decimal(0.1).plus(0.2).toFixed(3) → "0.300"
Un único motor de cálculo como fuente de la verdad
Para que frontend y backend nunca pudieran divergir, centralizamos toda la lógica en un único motor de cálculo con reglas idénticas en ambos lados: mismo orden de operaciones, mismos puntos de redondeo, mismo tratamiento de casos especiales. Una sola definición de «cómo se calcula», en lugar de dos implementaciones que tarde o temprano se contradicen.
Reglas de redondeo explícitas y documentadas
Nada de redondeos «por defecto del lenguaje». Cada redondeo —su modo, su número de decimales y su momento en la cadena— quedó definido de forma explícita y documentada. Si en el futuro hay que auditar por qué un número es lo que es, la respuesta está escrita.
Caché para no sacrificar velocidad
La precisión decimal es más costosa que la coma flotante. Para que procesar 10.000 empresas siguiera siendo instantáneo, añadimos una capa de caché optimizada que reutiliza cálculos y resultados intermedios. La exactitud no podía pagarse con lentitud: el procesamiento de 1.000 empresas se mantiene por debajo de los 3 segundos.
05Cómo lo verificamos: tolerancia cero
Decir «coincide al tercer decimal» es fácil; demostrarlo, no. Montamos un sistema de verificación que compara, celda a celda y métrica a métrica, los resultados de la plataforma contra el Excel de referencia del cliente.
- Batería de pruebas automatizada que contrasta miles de valores contra la hoja del cliente, con tolerancia cero a nivel de 3 decimales.
- Casos límite cubiertos a propósito: divisas raras, GBX/GBP, empresas con datos incompletos, valores negativos y ceros, donde el redondeo suele fallar.
- Pruebas de regresión: cada vez que se toca el motor, las pruebas vuelven a correr. Si una sola milésima se mueve, salta la alarma antes de llegar a producción.
El criterio de aceptación
No era «pocos errores». Era cero. Si un solo número de las 10.000 empresas no coincidía al tercer decimal, no estaba terminado.
06El resultado
El dashboard no solo igualó al Excel: lo superó en todo lo demás. Mismos números en los que el cliente ya confiaba, pero con análisis predictivo en tiempo real, 33 tipos de gráficos financieros y la capacidad de analizar miles de empresas a la vez en lugar de una hoja cada vez.
0
Errores de cálculo
75%
Menos tiempo de análisis
10x
Más empresas en paralelo
<3s
Procesar 1.000 empresas
Lo más importante no aparece en una métrica: el equipo del cliente adoptó la herramienta sin desconfianza, porque desde el primer día los números eran los suyos. Esa es la diferencia entre un software que se usa y uno que acaba arrinconado.
07Qué tiene esto que ver con tu proyecto
Quizá no necesites 3 decimales en 10.000 empresas. Pero seguramente tienes algún proceso que solo tú haces de una forma concreta: una manera de calcular comisiones, de valorar stock, de facturar, de puntuar leads. Las herramientas genéricas te obligan a adaptarte a su forma de hacer las cosas. El desarrollo a medida hace lo contrario: se adapta a la tuya, hasta el último decimal.
Ese es exactamente el tipo de problema en el que nos especializamos en Soinda: traducir tu operativa real —con sus reglas, sus excepciones y sus manías— en software que funciona desde el primer día. Y cuando hablas con nosotros, hablas con quien programa, no con un comercial.
Desarrollo a medida en A Coruña
Aplicaciones web, dashboards, integraciones y módulos hechos para tu negocio. Mira qué desarrollamos →
Si tienes un proceso que ninguna herramienta del mercado replica bien, probablemente sea candidato perfecto para una solución a medida. Cuéntanoslo y te decimos cómo lo abordaríamos, cuánto costaría y cuánto tardaría —sin compromiso.
S
Equipo Soinda · Desarrollo de software a medida en A Coruña.
Convertimos procesos reales en código que funciona. Ver servicios de desarrollo →
¿Tu negocio tiene su propio «tercer decimal»?
Cuéntanos ese proceso que solo tú haces de una forma concreta. Te respondemos en 24h con una propuesta clara, presupuesto cerrado y plazo realista.
Presupuesto cerradoCódigo documentadoSoporte incluido