Cuando un auditor, la asesoría o un inspector de Hacienda pregunta por qué una cifra cambió, la respuesta no puede ser «alguien lo corrigió». La trazabilidad de cambios es la capacidad de reconstruir quién registró, modificó o anuló cada asiento, cuándo y con qué motivo. No es un lujo de empresas grandes: es lo que permite fiarse de la contabilidad.
Lo que exige la ley
El Código de Comercio establece que los libros y documentos contables se lleven con claridad, por orden de fechas, sin espacios en blanco, interpolaciones, tachaduras ni raspaduras, y que los errores se salven en cuanto se adviertan (artículo 29). En una contabilidad informatizada, el equivalente de una tachadura es editar un asiento antiguo sin dejar rastro. La forma correcta de corregir es un nuevo asiento.
Además, los libros, la correspondencia y los justificantes deben conservarse seis años desde el último asiento, y la Ley General Tributaria permite a Hacienda comprobar los ejercicios no prescritos, normalmente los últimos cuatro, plazo que se amplía cuando hay bases negativas o deducciones pendientes de aplicar. En facturación, la exigencia es aún más estricta: los sistemas sujetos a VERI*FACTU no permiten modificar registros y llevan un registro de eventos propio.
Qué debe guardar la pista de auditoría
| Dato | Para qué sirve |
|---|---|
| Usuario que crea el asiento | saber a quién preguntar |
| Fecha y hora de creación, distinta de la fecha contable | detectar asientos registrados con fecha atrasada |
| Usuario y fecha de cada modificación | reconstruir el historial |
| Valor anterior y valor nuevo | ver exactamente qué cambió |
| Motivo de la modificación | entender la decisión |
| Documento soporte enlazado | comprobar que el asiento tiene base |
| Bloqueos y reaperturas de periodo | saber cuándo se tocó un periodo cerrado |
La segunda fila es la que más destapa: un asiento con fecha contable de marzo creado en septiembre no es necesariamente un error, pero merece una explicación si marzo ya estaba declarado. Para que el registro sirva, cada usuario debe ser nominativo, como se explica en permisos de usuario en software contable.
Corregir sin borrar: un ejemplo
En abril se contabilizó una factura de 800 € de alquiler de una nave en la 629 Otros servicios, cuando correspondía a la 621 Arrendamientos y cánones. El mes está cerrado. En lugar de editar el asiento original, se registra una reclasificación en el periodo abierto:
| Cuenta | Debe | Haber |
|---|---|---|
| 621 Arrendamientos y cánones | 800,00 | |
| 629 Otros servicios | 800,00 |
Con un concepto que diga qué se corrige y por qué: «Reclasificación factura 118 del proveedor X, contabilizada en abril en 629 por error». El IVA no cambia, así que no afecta al 303 ya presentado. Si el error hubiera afectado a la cuota, habría que valorar una declaración complementaria o una rectificación.
Cuándo hacerlo así y cuándo con un extorno completo, que anula el asiento original con signo contrario y lo vuelve a registrar bien, se trata en el control de ajustes de cierre.
Periodos cerrados
La trazabilidad se apoya en el bloqueo de periodos: una vez conciliado y declarado un mes, nadie lo modifica sin reabrirlo, y la reapertura queda registrada con usuario, fecha y motivo. Si las reaperturas son frecuentes, el problema no es el bloqueo, sino que se cierra antes de que esté todo registrado.
Control de versiones en exportaciones contables
Gran parte de la información contable sale del programa: el balance que se envía al banco, el libro diario que pide el auditor, el fichero con el que la asesoría prepara el 303 o las cuentas anuales. Si después se cambia algo en la contabilidad, la exportación ya entregada queda desfasada y nadie lo sabe.
Ejemplo: la asesoría prepara el 303 del segundo trimestre con un listado de facturas exportado el 10 de julio. El 14 llega una factura de junio que se contabiliza en el trimestre, que aún no estaba bloqueado. El 303 se presenta el 20 con los datos del día 10. En el cierre anual, el IVA de la contabilidad no coincide con las declaraciones y hay que rastrear la diferencia factura a factura.
Un sistema sencillo de versiones evita esta situación:
- Nombre normalizado para cada fichero: sociedad, periodo, contenido, versión y fecha, por ejemplo «SLNorte_T2_libro-IVA_v2» seguido de la fecha de exportación.
- Registro de entregas: qué fichero se envió, a quién, cuándo y para qué.
- Huella del fichero: calcular un hash SHA-256 de cada exportación y anotarlo en el registro permite demostrar después que el fichero no se ha modificado.
- Exportar después de bloquear: lo que se envía para presentar un modelo debe salir de un periodo cerrado.
- Nueva versión si se reabre: si un periodo se reabre después de exportar, se genera una nueva versión y se avisa a quien recibió la anterior.
- No reimportar hojas editadas: si el auditor devuelve un Excel con ajustes, los ajustes se registran como asientos en el programa, no se reimporta la hoja.
Este registro forma parte del soporte que se entrega en una auditoría, tal como se describe en preparar la documentación para auditoría.
Un programa contable que registre por sí mismo usuarios, cambios y bloqueos te ahorra mantener todo esto a mano. Al comparar programas, pide que te enseñen ese registro con un caso real.