"Es solo una web app con algunos campos más"
Escuchamos una versión de esto en casi todas las primeras llamadas sobre un sistema financiero o de cumplimiento normativo — una cadena minorista que quiere un libro contable real en lugar de una hoja de cálculo, una constructora que necesita facturación por avance de obra, una clínica que necesita reclamaciones y nómina en un solo lugar, un colegio que necesita contabilidad de subvenciones y matrículas capaz de resistir una auditoría. El instinto es dimensionarlo como la última app CRUD: algunas tablas, algunos formularios, un panel, listo en unos pocos sprints.
No es el mismo tipo de proyecto. No porque la interfaz sea más difícil — la mayoría del software financiero tiene pantallas más simples y en menor número que una app de consumo. Es diferente porque hay cinco cosas que no son negociables en el software financiero y que en cualquier otro contexto son opcionales. Sáltate cualquiera de ellas y el sistema no falla de forma ruidosa. Falla en silencio, meses después, frente a un auditor o a un cliente muy enfadado.
1. El dinero no es un float
Una app normal puede redondear un número en pantalla y seguir adelante. Un libro contable no puede. Si guardas la moneda como punto flotante, pequeños errores de redondeo se acumulan a lo largo de miles de transacciones hasta que las cuentas no cuadran — y "las cuentas no cuadran" no es un ticket de bug, es una emergencia del negocio.
La solución es aburrida y obligatoria: centavos como enteros o un tipo decimal adecuado, nunca floats de JavaScript, y que cada cálculo — impuestos, descuentos, repartos, retenciones — pase por la misma regla de redondeo en todo el código base. Tratamos esto como una regla de linting, no como un detalle menor de code review.
2. Nada se elimina
Las apps normales hacen soft-delete o hard-delete de registros constantemente. Los sistemas financieros no eliminan — corrigen, y conservan el original. Un libro contable de solo inserción (append-only) significa que cada entrada es inmutable una vez registrada; un error se revierte con una nueva entrada vinculada, no se edita ni se borra. Esto es lo que hace que un sistema esté listo para auditoría: un auditor puede recorrer el historial completo de cualquier dólar, no solo el estado actual.
Esta única decisión rediseña todo tu modelo de datos. Las tablas necesitan posted_at, reversed_by y created_by en cada fila financiera desde el primer día — añadir inmutabilidad más adelante a un esquema construido para permitir ediciones es una reconstrucción, no una migración.
3. Toda acción de alto riesgo necesita una segunda mirada
El modelo de permisos de una app normal suele ser "¿puede este rol ver esta página?". El software financiero necesita permisos a nivel de cada acción individual, y para todo lo que implique dinero real o riesgo real — anular una factura, aprobar una transferencia, revertir el rechazo de una reclamación, condonar un recargo por mora — una segunda persona tiene que aprobarlo antes de que se ejecute. Eso es maker-checker: una persona propone la acción, otra con el rol adecuado la confirma, y el sistema registra ambas cosas.
Añadir esto más tarde es doloroso porque no es solo una tabla de permisos — cambia la forma de tu API. Las acciones pasan de un solo paso a dos pasos (propose y luego approve), y ese patrón hay que diseñarlo desde el principio, no acoplarlo a un flujo existente de "un clic para enviar".
4. Los reintentos crean dinero duplicado si se lo permites
Las pasarelas de pago, los archivos bancarios y las cámaras de compensación de seguros reintentan constantemente. Una app normal reintenta una solicitud fallida y no pasa nada malo. Un sistema financiero que reintenta una llamada de pago sin una clave de idempotencia puede cobrarle dos veces a un cliente, registrar una transacción dos veces o duplicar el pago a un subcontratista. Cada escritura externa necesita una clave de idempotencia única, y cada proceso nocturno necesita un paso de conciliación que compare lo que realmente ocurrió con lo que el libro contable cree que ocurrió, y que marque la diferencia en lugar de asumir que todo salió bien.
Este es un vacío habitual en sistemas que no se diseñaron pensando en la idempotencia: la integración funciona bien en pruebas, y meses después, ya en producción, la liquidación de un proveedor no cuadra y nadie sabe por qué — porque nada marcó el reintento que lo causó.
5. Las reglas de retención y disponibilidad no las decides tú
Una app normal puede elegir su propia política de copias de seguridad. El software financiero y de cumplimiento hereda reglas desde afuera: aproximadamente siete años de conservación de registros contables para la mayoría de autoridades fiscales, la propia regla de retención de seis años de HIPAA para documentación de cumplimiento como políticas y autorizaciones (la retención real de historiales médicos la fija la ley estatal, que varía y no queda anulada por HIPAA), y las reglas de alcance de PCI DSS en el momento en que los datos de tarjeta tocan tu sistema, incluso en tránsito. Si te saltas esto, el costo no es un arreglo de bug — es un hallazgo en la auditoría del próximo año, o una multa.
Las expectativas de disponibilidad también cambian. Que un sitio de marketing se caiga durante una hora es vergonzoso. Que la nómina no se procese el día que corresponde, o que el sistema de facturación de un hospital quede inalcanzable durante el ingreso de pacientes, es un tipo de problema distinto — y eso cambia cuánto presupuestas para monitoreo, failover y cobertura de guardia.
Cómo se ve esto sector por sector
Minorista — el punto de dolor suele ser la conciliación: las ventas del POS, las liquidaciones del procesador de tarjetas y los pagos a proveedores tienen que cuadrar entre docenas de locales, todos los días, de forma automática.
Construcción — la facturación por avance de obra estilo AIA y el seguimiento de retenciones significan que la "factura" no es definitiva hasta que se verifica un hito del proyecto; el libro contable tiene que modelar pagos parciales y condicionales, no solo pagado/no pagado. Construimos exactamente esto para una constructora especializada en proyectos multifamiliares y comerciales — mira el caso de estudio.
Salud — los flujos de reclamaciones, la adjudicación de seguros y la nómina clínica tocan información de salud protegida, así que el manejo consciente de HIPAA (registro de accesos, acceso mínimo necesario, cifrado en reposo) es una restricción de diseño, no una casilla que se marca al final.
Institucional — los libros contables de subvenciones, las restricciones de donantes y los presupuestos departamentales necesitan contabilidad a nivel de fondo: el dinero etiquetado para un propósito no puede cubrir otro en silencio, y cada dólar necesita un rastro reportable hasta su origen.
Lo que esto realmente te cuesta
Nada de esto es ingeniería exótica — son patrones disciplinados y bien entendidos aplicados con consistencia. Pero sí significa que un módulo financiero tarda más que una funcionalidad CRUD comparable y cuesta más por pantalla. Según nuestra experiencia, un módulo único y bien acotado — costeo de obra, ingesta de reclamaciones, un panel de conciliación — toma entre 10 y 16 semanas. Una suite financiera multimódulo que toque varios de estos puntos a la vez suele tomar entre 5 y 9 meses, con una primera versión utilizable en producción dentro de las primeras 12 semanas.
Si un proveedor cotiza software financiero o de cumplimiento a la misma tarifa que tu sitio de marketing, pregúntale directamente cómo manejan los rastros de auditoría inmutables, la doble aprobación y la conciliación. Si la respuesta es vaga, el número equivocado es ese, no el esfuerzo que esperabas pagar.
En resumen
El software financiero no es más difícil porque las pantallas sean complicadas. Es más difícil porque las restricciones son externas — normas contables, HIPAA, PCI, tus propios auditores — y ninguna de ellas perdona los atajos tomados para cumplir un plazo. Incorpora la disciplina del libro contable desde el primer esquema, no después de la primera auditoría. Nuestro equipo de software financiero y empresarial dimensiona exactamente este tipo de proyecto — minorista, construcción, salud e instituciones — y puede decirte en una semana cuáles de los patrones anteriores necesita realmente tu sistema.
