En desarrollo Electron JavaScript VeriFactu

Veridico

Infraestructura de facturación construida para VeriFactu, no adaptada a él.

Autónomos y pequeñas empresas en España enfrentan un plazo regulatorio duro: VeriFactu exige que los sistemas de facturación garanticen integridad de datos, trazabilidad y auditabilidad, con sanciones reales en caso de incumplimiento. La mayoría de herramientas existentes se adaptaron a posteriori — Veridico se diseñó alrededor del requisito desde la primera línea.

VeriFactu no es una función, es una restricción que da forma a toda la capa de datos: cada registro de factura necesita una cadena verificable (sin ediciones silenciosas, sin borrados, con exportación auditable), y el sistema tiene que funcionar para autónomos sin perfil técnico, no solo para asesorías.

La corrección regulatoria no admite término medio — un sistema de facturación cumple el requisito de trazabilidad o es un pasivo legal. Se construyó como aplicación desktop-first (Electron) para dar fiabilidad offline y propiedad local de los datos, lo que introdujo sus propias decisiones de arquitectura de sincronización.

El libro de facturas se trata como un log de solo-adición, no una tabla editable — las correcciones se hacen mediante asientos compensatorios, nunca ediciones, lo que hace que el rastro de auditoría sea real y no cosmético.

Diagrama de arquitectura de Veridico Cliente Electron Libro de facturas solo-adición Exportación auditoría / informes Sync previsto

Cliente (Electron) → libro de facturación de solo-adición → capa de exportación/auditoría → servicio de sincronización multi-dispositivo (previsto).

Electron (shell de escritorio + fiabilidad offline-first), JavaScript/HTML/CSS para la capa de interfaz, con la capa de datos diseñada para poder migrar hacia un backend alojado según el producto evolucione de herramienta local a SaaS.

El descubrimiento partió del texto normativo, no de una lista de funciones — cada requisito de VeriFactu se mapeó a una garantía concreta de integridad de datos antes de tocar la interfaz. El prototipo validó el modelo de libro de registro antes de cualquier trabajo visual.

Libro de solo-adición vs. registros editables

Más difícil de construir, pero el único modelo que sobrevive a una auditoría.

Desktop-first vs. web-first

Priorizar la propiedad del dato y la fiabilidad offline para autónomos sobre la comodidad de una app alojada, con sincronización en la nube prevista como capa adicional, no como sustituto.

Subestimé cuánto trabajo de UX necesita el software de cumplimiento "aburrido" — un sistema puede ser perfectamente correcto y aun así fallar si un usuario sin perfil técnico no puede confiar en lo que ve. Se replanteó la capa de interfaz a mitad de construcción priorizando claridad sobre amplitud de funciones.

Los productos guiados por cumplimiento normativo premian acertar primero el modelo de datos — toda función posterior depende de si el diseño del libro de registro es fiable.

En desarrollo

Primera empresa piloto, primera factura real emitida por el sistema y primera exportación completa de rastro de auditoría VeriFactu: se añadirán aquí en cuanto estén disponibles. No hay métricas que mostrar todavía — y prefiero decir eso antes que inventar una.

Versión alojada/SaaS con sincronización multi-dispositivo, herramientas de exportación para asesorías, ampliación más allá de la facturación hacia el registro fiscal integral de pequeñas empresas.