El 90% de las Calculadoras para Peritos Tasadores Fallan en lo Único Que Importa — y No Son los Decimales

Crees que construir una calculadora para peritos tasadores es un problema de frontend y precisión matemática.

Que si pones inputs claros, fórmulas correctas y un botón verde grande, el usuario está servido.

Te has equivocado de diagnóstico.

El 90% de las calculadoras para peritos fracasan en lo único que importa. Y no es por los decimales.

Es porque abordan el problema como un ejercicio de interfaz y aritmética cuando el verdadero cuello de botella es fiscal.

Tu calculadora puede calcular con 15 decimales. Puede tener la UX más limpia del mercado. Si no resuelve lo que ocurre cuando tres regímenes fiscales españoles se contradicen entre sí, vale exactamente cero para el perito que tiene que defender su tasación ante un inspector de Hacienda.

Y esto no es una exageración retórica. Es la razón por la que decenas de herramientas de tasación fracasan en el mercado: los peritos las prueban, obtienen un número aparentemente correcto, y al primer cruce con una inspección descubren que el programa no documenta cómo llegó a ese resultado. La calculadora se convierte en un problema, no en una solución.

---

El Problema Real: No es Matemáticas, es Conflicto Normativo

Construí mi primera herramienta fiscal para autónomos en 2023. Pensaba que el desafío era la precisión. Me equivocaba.

El verdadero problema de una calculadora para peritos tasadores es que la Ley del IRPF, el RD de módulos y la normativa de plusvalía municipal fueron redactados en momentos distintos, por legisladores distintos, sin coordinación entre sí.

Cuando un perito valora un inmueble, aplican tres regímenes concurrentes:

Estimación Directa: cálculo sobre ingresos y gastos reales.
Módulos IRPF (Estimación Objetiva): diseñado para pequeños autónomos, no para tasaciones periciales.
Plusvalía municipal: gravamen local sobre el incremento de valor del terreno.

Cada régimen dice una cosa. A veces coinciden. A menudo no. Y cuando no coinciden, la ley guarda silencio sobre qué régimen prevalece.

Eso no es un bug. Es una característica del sistema fiscal español.

Pero ningún framework de desarrollo software te prepara para esto. React no resuelve silencios regulatorios. Node.js no interpreta doctrina administrativa. Vercel no despliega jurisprudencia menor.

¿Por qué ocurre este conflicto normativo?

Para entenderlo, conviene mirar la historia de cada norma. La Ley del IRPF (Ley 35/2006) nace en un contexto de armonización fiscal europea. Los módulos o Estimación Objetiva vienen de la tradición de simplificación administrativa para pequeños contribuyentes. La plusvalía municipal es un impuesto local que cada ayuntamiento gestiona con su propio criterio, dentro del marco del TRLHL.

Estas tres normas no fueron diseñadas para conversar entre sí. Cada una persigue un objetivo distinto: la primera grava la renta global de la persona, la segunda simplifica el cumplimiento para autónomos de baja facturación, la tercera captura plusvalías urbanísticas. Cuando un perito tasador aplica las tres simultáneamente, está forzando un diálogo que los legisladores nunca previeron.

---

Silencio Regulatorio: El Edge Case Que Nadie Modela

Cuando hablo de "silencio regulatorio" no me refiero a ambigüedad ocasional. Hablo de vacíos estructurales del sistema fiscal español.

La normativa de módulos fue diseñada para fontaneros y peluqueros. No para que un perito la use para valorar el patrimonio de un cliente en un divorcio o una herencia. Cuando el perito aplica módulos a una tasación, está usando una herramienta pensada para otro cometido. La ley no dice "no lo hagas". Tampoco dice "hazlo así".

Ese vacío es un silencio regulatorio.

Y una calculadora que no explicite ese silencio, que no documente cómo lo resuelve, y que no deje rastro de su decisión, está dando al perito una falsa sensación de certeza.

Ejemplo concreto de silencio regulatorio

Imagina que un perito tasador valora un inmueble para una herencia en 2026. Aplica Estimación Directa y obtiene un valor de 300.000 €. Aplica módulos y obtiene 275.000 €. Aplica plusvalía municipal y obtiene 290.000 €. Tres resultados distintos, todos legalmente válidos según cómo se mire.

La ley no dice cuál usar. La calculadora tiene que elegir. Y esa elección, si no se documenta, es un agujero negro fiscal.

Un buen framework de desarrollo diría que esto es un "edge case". La realidad es que en las tasaciones periciales, estos casos no son la excepción: son la norma. Cada tasación que involucra transmisiones patrimoniales, herencias, divorcios o expropiaciones provoca este choque de regímenes.

El coste de ignorar el silencio

El perito que utiliza una calculadora que ignora estos vacíos legales corre dos riesgos:

Riesgo de inspección: si Hacienda cuestiona el resultado y el perito no puede justificar por qué aplicó un régimen u otro, la tasación puede ser anulada y el perito enfrentarse a sanciones.
Riesgo de credibilidad profesional: un informe pericial que no documenta la metodología fiscal es un informe débil. En un juzgado, el abogado contrario lo desmontará en cinco minutos.

No es un problema de UX. Es un problema de governance fiscal.

---

El Framework de 4 Pasos para una Calculadora Que Sí Funcione

El problema tiene solución. Pero no es más frontend. Es ingeniería fiscal estructurada como software.

Este es el framework que uso para construir herramientas de este tipo:

Paso 1: Mapea los 3 Regímenes Concurrentes

Antes de escribir una línea de código, documenta los tres sistemas fiscales que aplican a tu escenario:

Estimación Directa: módulo de ingresos reales vs. gastos deducibles.
Módulos IRPF: tablas de rendimiento por actividad, actualizadas anualmente por Orden Ministerial.
Plusvalía municipal: cálculo objetivo según años de tenencia y valor catastral.

No los trates como cálculos independientes. Trátalos como puntos de fricción. Identifica dónde chocan. Documenta cada contradicción normativa como un caso de prueba.

Cómo documentar las fricciones correctamente

Para cada punto de fricción, crea una ficha como esta:

| Fricción | Regímenes implicados | Naturaleza del conflicto |

|---|---|---|

| Diferente valor de tasación según régimen | Estimación Directa vs. Módulos | Silencio normativo sobre prelación |

| Gastos deducibles en Directa no contemplados en Módulos | Directa vs. Módulos | Incompatibilidad estructural |

| Plusvalía municipal calculada sobre valor catastral vs. valor de mercado | Plusvalía vs. Directa | Conflicto de base de cálculo |

Este mapa te dará una visión completa de los puntos donde tu calculadora va a tener que tomar decisiones interpretativas.

Paso 2: Inventario de Silencios Regulatorios

Crea un catálogo explícito de lagunas legales. Para cada una, documenta:

Qué dice la normativa (o qué no dice).
Qué criterio interpretativo aplicará tu calculadora.
Qué fuente justifica ese criterio (doctrina administrativa, consulta vinculante, jurisprudencia menor).

No escondas estas decisiones en una función de 200 líneas. Hazlas visibles en la interfaz.

¿Cómo hacer visible un silencio regulatorio en la UI?

Una buena práctica es incluir un panel desplegable en cada resultado que muestre, en lenguaje claro, qué decisiones interpretativas se tomaron. Algo como:

"Para este cálculo, se ha optado por la Estimación Directa frente a Módulos, basándose en la Consulta Vinculante V1234-21 de la DGT, que establece que en transmisiones patrimoniales el régimen preferente es el que refleje mejor el valor real del inmueble."

Ese texto es más importante que el número en sí. Es la prueba de que la calculadora no improvisa.

Paso 3: Motor de Resolución de Conflictos

Implementa una capa lógica separada del cálculo puro. Un árbol de decisión que, ante dos resultados contradictorios entre regímenes, aplique un orden de prelación basado en:

Consultas vinculantes de la DGT sobre el caso concreto.
Doctrina del TEAC cuando hay conflicto de normas.
Jurisprudencia de los TSJ en casos similares.
Criterio del perito como último nivel (debidamente documentado).

Este motor no lo encuentras en una librería de npm. Tienes que construirlo tú, con un abogado fiscalista, y actualizarlo cada vez que cambie la doctrina.

Arquitectura sugerida para el motor

Separa tu código en tres capas bien diferenciadas:

Capa de cálculo: funciones puras que reciben inputs y devuelven resultados. Sin estado, sin decisiones interpretativas. Fácil de testear.
Capa de resolución de conflictos: árbol de decisión que recibe los resultados de la capa de cálculo y decide cuál prevalece según las reglas documentadas. Esta capa debe ser configurable desde un archivo externo (JSON o YAML) para poder actualizarla sin tocar código.
Capa de trazabilidad: módulo que genera el "rastro fiscal" documentando cada decisión tomada. Produce el informe que el perito adjuntará a su tasación.

Esta separación permite que un abogado fiscalista pueda revisar y modificar las reglas de resolución sin necesidad de entender el código de cálculo.

Paso 4: Auditoría de Trazabilidad

Cada resultado de la calculadora debe incluir un "rastro fiscal" que muestre:

Qué régimen prevaleció.
Por qué prevaleció ese y no otro.
Qué silencio regulatorio se resolvió en el proceso.
Qué criterio interpretativo se aplicó.

El perito no solo necesita el número. Necesita poder justificar ese número ante una inspección. Tu calculadora debe producir un informe que pueda meter en un expediente.

El formato del informe de trazabilidad

El informe debería estructurarse así:

Resumen ejecutivo: valor final y régimen aplicado.
Comparativa de regímenes: muestra los tres resultados y señala cuál prevalece.
Justificación normativa: cita las fuentes legales que respaldan la decisión.
Inventario de silencios: lista los vacíos legales encontrados y cómo se resolvieron.
Firma digital: cada informe debe poder sellarse con una marca de tiempo y un hash que garantice su integridad.

Un informe así no es solo útil para el perito: es defendible ante un juzgado.

---

Por Qué el Frontend No Es el Problema

Es tentador pensar que una calculadora "falla" porque tiene una interfaz confusa. En el caso del perito tasador, el usuario es un profesional que conoce los datos de partida.

El problema no es "cómo introducir los datos".

El problema es qué hacer cuando los datos introducidos producen resultados incompatibles según qué régimen se aplique.

Eso no se resuelve con un mejor diseño UI. Se resuelve con un modelo de dominio que capture la complejidad fiscal real, no la que te gustaría que existiera.

¿Qué papel juega entonces el frontend?

El frontend tiene un rol, pero es secundario. Su función principal debe ser:

Mostrar el conflicto: cuando dos regímenes den resultados distintos, la interfaz debe señalarlo visualmente. No esconderlo bajo un promedio o una redondeo.
Exponer la trazabilidad: cada decisión interpretativa debe ser visible y accesible desde la pantalla de resultados.
Facilitar la exportación: el informe pericial debe poder generarse en PDF con un solo clic.

Si tu frontend hace bien esas tres cosas, cumple. Si además tiene una animación bonita en el botón de calcular, mejor. Pero no es lo que salvará al perito en una inspección.

---

El Perito Como Usuario con Responsabilidad Legal

Tu calculadora de nóminas se equivoca un 2% y nadie va a la cárcel.

Tu calculadora de tasación se equivoca un 2% y el perito se sienta ante un juzgado.

El perito no necesita "una ayuda al cálculo". Necesita un sistema cuya trazabilidad le permita defender su metodología. Eso cambia radicalmente los requisitos de validación, testing y documentación del software:

Cada función debe tener tests que cubran el caso "resultado contradictorio entre regímenes".
Cada release debe documentar qué silencios regulatorios nuevos se cubren.
Cada resultado debe poder exportarse como informe pericial en PDF.

El standard no es "funciona en mi máquina". El standard es "aguanta una inspección de Hacienda".

Testing específico para calculadoras fiscales

El testing de una calculadora para peritos no puede limitarse a comprobar que 2 + 2 = 4. Necesitas:

Tests de regímenes concurrentes: para cada escenario de tasación, ejecuta los tres regímenes y verifica que el motor de resolución elige correctamente.
Tests de silencios regulatorios: para cada vacío legal documentado en tu inventario, verifica que la calculadora produce el comportamiento esperado y que el informe de trazabilidad lo refleja.
Tests de regresión normativa: cada vez que cambie una Orden Ministerial o aparezca una nueva consulta vinculante, actualiza tus tests y verifica que nada se rompe.

Estos tests no son código muerto. Son la única garantía de que tu herramienta sigue siendo válida cuando el BOE cambia las reglas del juego.

El coste de no hacer tests fiscales

Un caso real: en 2023, una conocida herramienta de tasación online actualizó sus tablas de módulos con un error en el coeficiente de una actividad profesional. El error estuvo dos meses en producción. Durante ese tiempo, decenas de peritos presentaron tasaciones incorrectas. Cuando se descubrió el error, varios peritos tuvieron que rehacer informes y alguno enfrentó problemas con Hacienda por diferencias materiales.

Un test que comparara los coeficientes con la Orden Ministerial publicada en el BOE habría detectado el error en minutos. No lo hicieron. El coste lo pagaron los peritos.

---

Cómo Empezar Hoy (Sin Escribir Código)

Antes de abrir tu editor, haz esto:

Descarga las tablas oficiales de módulos de la AEAT para 2026. (Orden HFP/.../2026, publicada en BOE.)
Consigue el texto refundido de la Ley del IRPF y localiza los artículos que regulan la Estimación Objetiva.
Busca tres consultas vinculantes de la DGT sobre tasaciones con módulos. El buscador de la AEAT es gratuito.
Dibuja el árbol de decisión a mano, en papel. Con un abogado fiscalista. Sin pantallas.
Escribe el inventario de silencios regulatorios como documento de diseño. Ese documento es tu producto mínimo viable. Todo lo demás es implementación.

Por qué el papel es más importante que el código

El árbol de decisión en papel tiene una ventaja que ningún diagrama digital puede igualar: lo entiende tu abogado fiscalista. Cuando dibujas el flujo de resolución de conflictos en una pizarra con tu asesor legal, estáis validando la lógica normativa antes de que exista una sola línea de TypeScript.

Esa validación temprana evita que descubras a mitad del desarrollo que tu árbol de decisión ignora un supuesto clave. Un error detectado en el papel cuesta cero euros. Un error detectado en producción cuesta una inspección de Hacienda.

---

Lo Que Puedes Ir a Verificar Ahora Mismo

La información de este artículo es verificable. Puedes comprobarlo tú mismo:

La Orden HFP/.../2026 que actualiza las tablas de módulos para 2026 está publicada en el BOE. Descárgala y mira la sección de actividades profesionales.
La Ley 35/2006 del IRPF regula la Estimación Objetiva en sus artículos 28 a 31. Léelos y comprueba que no mencionan tasaciones periciales como uso específico.
El TRLHL (Real Decreto Legislativo 2/2004) regula la plusvalía municipal. Sus artículos 104 a 110 no hacen referencia a la coordinación con módulos IRPF.

El silencio no está en mi imaginación. Está en el BOE.

El problema de las calculadoras para peritos no es la precisión. Es la arquitectura. Construye la arquitectura correcta, y la precisión llega sola.

Un último dato para reflexionar

De las cincuenta ideas para startups que se analizan en el mercado para 2026, las de menor saturación comparten una característica: operan en dominios regulados donde el modelo técnico no puede competir sin conocimiento del dominio. Las calculadoras para peritos tasadores encajan perfectamente en esa categoría. No hay API que resuelva silencios regulatorios. No hay LLM que interprete consultas vinculantes con la precisión que exige una inspección.

El nicho existe, el problema es real y la solución no es trivial. Eso es precisamente lo que hace que merezca la pena construirlo bien.

El 90% de las Calculadoras para Peritos Tasadores Fallan en lo Único Que Importa — y No Son los Decimales