Qué revisamos en un sistema de facturación antes de decir que aguanta la Ley Antifraude

Resumen:

• Cuatro de las ocho comprobaciones las puede hacer cualquiera usando el programa como usuario normal.
• Poder editar una factura emitida es el defecto descalificante: invalida el sistema entero.
• Una declaración del fabricante es un indicio, no una prueba.
• La revisión hay que repetirla tras cada actualización mayor, no solo una vez.

Después de auditar varios sistemas de facturación acabamos escribiendo una lista. No por orden burocrático, sino porque los mismos defectos aparecían una y otra vez en programas muy distintos entre sí.

Esta es esa lista. Está pensada para que la puedas usar sobre tu propio sistema sin contratar a nadie.

Las cuatro que puedes comprobar tú mismo

Uno: intenta modificar una factura emitida

Abre una factura de hace tres meses e intenta cambiar algo. El nombre del cliente, un importe, la fecha. Si el programa te deja y guarda el cambio sin generar ningún registro adicional, has terminado la auditoría: el sistema no cumple.

Esta es, con diferencia, la carencia más común. Y casi nunca es malicia: alguien pidió poder corregir erratas y un desarrollador lo implementó de la manera obvia.

Dos: intenta borrar una factura

Lo mismo. Un sistema conforme no ofrece la operación de borrar. Ofrece anular, que es distinto: genera un registro nuevo que deja constancia de que aquella factura queda sin efecto, conservando la original.

Tres: revisa la numeración

Lista las facturas de un mes cualquiera ordenadas por número. ¿Hay huecos? Si los hay, pregunta a quién factura si sabe explicarlos. Un hueco justificado por una anulación es correcto; un hueco inexplicable es un hallazgo de inspección esperando a ocurrir.

Cuatro: busca el rastro de quién hizo qué

¿Puede el sistema decirte quién emitió una factura concreta y a qué hora? Si la respuesta es que todos usan el mismo usuario, o que esa información no se guarda, falta trazabilidad.

Las cuatro que requieren perfil técnico

Cómo se prioriza lo que sale

Ningún sistema pasa las ocho a la primera. Lo importante es el orden de ataque.

Primero, todo lo que permita alterar el pasado: edición, borrado, acceso directo a la base de datos. Estos defectos invalidan el sistema y además son los más rápidos de corregir, porque suele bastar con eliminar una funcionalidad.

Segundo, lo que falta y hay que construir: encadenamiento y registro de eventos. Requiere desarrollo, pero es trabajo acotado si la emisión de facturas está centralizada en el código.

Tercero, lo que afecta a la forma y no al fondo: formato de exportación, campos incompletos. Importa, pero no impide seguir facturando mientras se resuelve.

Preguntas frecuentes

¿Puedo hacer esta revisión yo mismo sin ser técnico?

Las cuatro primeras preguntas sí: se responden usando el programa como usuario normal e intentando modificar una factura ya emitida. Las cuatro últimas requieren acceso a la base de datos o a la documentación técnica, y ahí sí conviene que alguien con perfil técnico las verifique.

¿Qué hago si mi software falla en varios puntos?

Ordénalos por gravedad. La posibilidad de editar una factura emitida es descalificante y hay que atacarla primero. La ausencia de registro de eventos es grave pero se puede añadir. Un formato de exportación incompleto es lo menos urgente porque no invalida la emisión.

¿Sirve que el proveedor me diga por correo que ya cumple?

Sirve como indicio, no como prueba. La norma exige una declaración responsable del fabricante sobre el producto. Pide ese documento formal y, aun teniéndolo, verifica al menos las cuatro comprobaciones que puedes hacer tú: hemos visto sistemas declarados conformes que permitían editar facturas.

¿Los huecos en la numeración son siempre un problema?

No siempre, pero siempre hay que poder explicarlos. Un hueco justificado por una anulación registrada es correcto. Un hueco que aparece porque el sistema consume el número al abrir la pantalla y no lo libera al cancelar es un defecto que hay que corregir.

¿Con qué frecuencia conviene repetir la revisión?

Una vez al año y siempre después de una actualización mayor del sistema. Hemos visto cumplimientos que se rompen al instalar una versión nueva porque alguien reintrodujo una función de edición que había sido eliminada.

El informe que entregamos

Cuando hacemos esto para un cliente, el entregable no es una lista de fallos. Es una tabla con tres columnas: hallazgo, gravedad y esfuerzo estimado de corrección. Con eso la dirección puede decidir qué se arregla ya, qué entra en el plan del trimestre y qué se asume conscientemente.

Esa última categoría existe y conviene nombrarla. Hay defectos menores que una empresa puede decidir no corregir de inmediato, siempre que sea una decisión informada y no un descuido. La diferencia entre las dos cosas es exactamente lo que un inspector va a querer saber.

Los tres defectos que más se repiten

De todas las revisiones que llevamos hechas, tres hallazgos aparecen en la mayoría de los sistemas, independientemente de quién los construyera.

La pantalla de corrección. Casi todos los programas antiguos tienen una. Nació de una petición razonable —«necesitamos poder arreglar una errata»— y se implementó de la forma directa: actualizar la fila. Sustituirla por un flujo de rectificativas es el cambio que más cumplimiento aporta por unidad de esfuerzo.

El usuario compartido. Una sola cuenta que usa todo el departamento porque «es más cómodo». Destruye la trazabilidad de golpe: el sistema puede registrar perfectamente quién hizo cada cosa y esa información no sirve de nada si todos son la misma persona.

El acceso directo a la base de datos. Alguien de informática, o el propio proveedor, con credenciales que permiten modificar cualquier tabla. Puede que nunca lo haya usado para tocar una factura, pero la posibilidad existe y es difícil de descartar ante un tercero.

Los tres son problemas de proceso disfrazados de problemas técnicos. Se corrigen con decisiones, no solo con código.