Por qué tu ERP genera facturas, no evidencia
El software ERP y de contabilidad es notablemente bueno en la tarea para la que fue diseñado: procesar transacciones a escala, imponer flujos de aprobación y producir una salida estructurada que otros sistemas pueden consumir. Así se generan millones de facturas cada día sin incidentes.
Pero hay otra tarea para la que el software ERP nunca fue diseñado, y esa distinción importa cuando una autoridad fiscal, un tribunal o un organismo regulador hace una pregunta más difícil que “enséñame la factura”.
La pregunta que la mayoría del software no puede responder
Cuando se discute una factura rutinaria, presentar el PDF suele bastar. El comprador la reconoce, el vendedor la confirma y el asunto queda resuelto. Ese es el flujo para el que está optimizado el software ERP.
Una pregunta más difícil suena así: “Demuestra que esta factura existía exactamente en esta forma en esta fecha, que no se ha alterado desde entonces y que la persona que afirma haberla enviado la envió realmente a través de tu sistema”.
Esa no es una pregunta sobre documentos. Es una pregunta sobre evidencia. Y la evidencia tiene requisitos distintos de los de los documentos.
Un documento es un registro de una transacción. La evidencia es un registro verificable que puede resistir un escrutinio independiente, incluido el de alguien que intenta activamente impugnarlo.
Lo que sí proporciona el software ERP
Para ser precisos sobre la brecha, conviene tener claro lo que el software ERP hace bien.
La mayoría de los sistemas ERP modernos proporcionan:
Datos de factura estructurados. Las facturas se almacenan en una base de datos con relaciones claras entre compradores, vendedores, líneas, totales y fechas. Eso las hace consultables, auditables a través de la propia interfaz del ERP y exportables en formatos estandarizados como XML UBL o CII.
Registros de aprobación y de auditoría. La mayoría de los sistemas ERP registran quién aprobó qué y cuándo. Estos registros son útiles para las revisiones de control interno y pueden demostrar que se siguió el proceso adecuado.
Cumplimiento de formato. Para la salida en Factur-X, ZUGFeRD, XRechnung y Peppol, el software ERP moderno genera XML que se valida contra el esquema correspondiente. Eso cubre el requisito de formato de las obligaciones de facturación electrónica de la UE.
Exportación y portabilidad. Las facturas suelen poder exportarse en bloque, como XML, PDF o ambos. Eso cubre el caso de uso de la portabilidad de datos.
Nada de esto es trivial. El cumplimiento de formato es un verdadero problema de ingeniería en el que los proveedores de ERP han invertido un esfuerzo considerable. La cuestión no es que el software ERP sea deficiente. La cuestión es que el cumplimiento de formato es necesario, pero no suficiente, para la evidencia legal.
Lo que el software ERP no proporciona
La brecha aparece cuando pides una verificación independiente de tres cosas que los procedimientos judiciales suelen exigir.
Prueba de existencia en un momento concreto. Una marca de tiempo almacenada dentro de tu propio sistema es tan fiable como tu sistema. Si controlas el sistema, la parte contraria puede alegar que también controlabas la marca de tiempo. Un sello de tiempo RFC 3161 de una Autoridad de Sellado de Tiempo independiente está firmado criptográficamente por un tercero y no puede falsificarse con carácter retroactivo sin invalidar la firma. La mayoría de los sistemas ERP no emiten ni almacenan sellos de tiempo RFC 3161.
Prueba de integridad desde ese momento. Un archivo PDF o XML almacenado en una base de datos puede modificarse. Un registro de una base de datos puede actualizarse. Sin un compromiso de hash independiente (una huella criptográfica creada en el momento de la creación y almacenada en algún lugar fuera de tu control), no puedes demostrar que el documento no se ha alterado desde entonces. La mayoría de los sistemas ERP no producen ni almacenan compromisos de hash criptográficos vinculados a sus registros.
Una cadena de custodia independiente. Saber que un documento existe hoy en un estado concreto es distinto de saber cómo llegó a ese estado. Una cadena de custodia registra cada acción realizada sobre un documento (quién accedió a él, qué se hizo y en qué orden) en un registro resistente a manipulaciones. Esto es habitual en los procedimientos judiciales y regulatorios, pero no suele ser la forma en que se implementan los registros de auditoría de un ERP.
Cuándo importa esto en la práctica
La brecha entre documento y evidencia no es académica. Estos son los contextos en los que sale a la luz.
Investigaciones de la autoridad fiscal. En varias jurisdicciones de la UE, las autoridades fiscales tienen la facultad de exigir a las empresas que demuestren la integridad de sus registros de facturación electrónica. Una empresa que puede presentar facturas pero no puede demostrar que no se han alterado desde su emisión está en una posición más débil que una que puede presentar una prueba criptográfica de integridad junto con la factura.
Disputas comerciales. Cuando un comprador impugna una factura (alegando que se modificó a posteriori, o que los importes no coinciden con lo acordado), el vendedor necesita demostrar que el documento es auténtico y no ha cambiado. Un sello de tiempo RFC 3161 y una cadena de hashes proporcionan esa demostración. Un PDF de un sistema ERP sin verificación independiente, no.
Auditorías regulatorias en servicios financieros. Las empresas sujetas a MiFID II, Solvencia II o marcos equivalentes deben mantener sus registros de forma que se demuestre su integridad y autenticidad. Los requisitos concretos varían, pero la expectativa general es que los registros no puedan alterarse sin que se detecte. Es un listón más alto que el del almacenamiento habitual de un ERP.
Disputas contractuales con largos períodos de retención. Los requisitos de retención de facturas en la UE van desde 7 años (el estándar habitual para las facturas con IVA) hasta 20 años para determinados registros del sector público según el derecho neerlandés. En un margen de 7 años pueden cambiar muchas cosas: el sistema ERP puede sustituirse, la base de datos puede migrarse, los archivos PDF pueden volver a exportarse. Sin un sello de tiempo y una cadena de hashes anclados en el momento de la creación, demostrar que una factura con 7 años de antigüedad no se ha modificado se vuelve difícil.
El malentendido del cumplimiento de formato
Una suposición habitual es que, si una factura cumple con Factur-X o Peppol, es admisible como prueba. El cumplimiento de formato significa que la factura se valida contra el esquema y contiene los campos obligatorios. No dice nada sobre cuándo se creó el documento, si se ha modificado o si el registro puede verificarse de forma independiente.
Factur-X es un formato de archivo. RFC 3161 es un protocolo de evidencia. Operan en capas distintas de la pila de cumplimiento, y uno no sustituye al otro.
Por usar una analogía física: un documento con fe notarial y un documento impreso son ambos documentos. La fe notarial añade una capa de verificación independiente: un tercero de confianza que da fe de cuándo y por quién se firmó el documento. El cumplimiento de formato se parece más a la impresión que a la fe notarial.
Lo que exige realmente la capa de evidencia
Producir evidencia verificable de un documento digital exige, como mínimo, tres cosas.
Un sello de tiempo de confianza. Un sello de tiempo RFC 3161 de una Autoridad de Sellado de Tiempo proporciona una prueba criptográfica de existencia en un momento concreto. La TSA es una parte independiente cuya firma puede verificar cualquiera con herramientas estándar. El sello de tiempo no puede falsificarse a posteriori sin invalidar la cadena de firmas.
Un compromiso de hash. Antes de sellar el documento, se calcula el hash de su contenido. SealDoc calcula tanto un resumen SHA-256, que es el valor con el que la solicitud RFC 3161 compromete a la Autoridad de Sellado de Tiempo, como un resumen SHA-384, que identifica el registro en el ledger de evidencias. El hash es una huella del contenido. Si cambia un solo byte del documento después de calcular el hash, la huella deja de coincidir. El hash se almacena de forma independiente del documento, de modo que el documento y la huella pueden contrastarse entre sí en cualquier momento futuro.
Un registro de la cadena de custodia. Cada acción realizada sobre el documento tras su creación (acceso, conversión, archivo, recuperación) se registra con la identidad del actor, la marca de tiempo y la dirección IP, en un registro de auditoría resistente a manipulaciones.
Juntos, estos tres elementos responden a las preguntas que plantean los procedimientos judiciales: si este documento existía en esta forma en este momento, si ha cambiado desde entonces y quién lo ha manejado.
La cuestión práctica
La cuestión importa sobre todo en estas circunstancias: sectores regulados, transacciones de alto valor, largos márgenes de retención, facturas impugnadas o cualquier contexto en el que la otra parte pueda tener un incentivo para cuestionar la integridad de tus registros.
Para esos casos de uso, la brecha entre “tenemos la factura” y “podemos demostrar que la factura es auténtica” es real, y el cumplimiento de formato por sí solo no la cierra.
El enfoque más práctico es incorporar la capa de evidencia en el momento de crear el documento, y no con carácter retroactivo. Un sello de tiempo RFC 3161 y una cadena de hashes añadidos en el momento de la generación no cuestan nada en el momento de la auditoría. Añadirlos retroactivamente, o intentar argumentar que los registros existentes bastan sin ellos, es más difícil.
SealDoc añade la capa de evidencia a cada documento que pasa por el pipeline: un sello de tiempo RFC 3161 solicitado por defecto a una Autoridad de Sellado de Tiempo independiente de la UE, una cadena de custodia SHA-256 sobre los pasos de procesamiento, un ledger de evidencias SHA-384 sobre el registro y un Paquete de Evidencia Legal, a petición, que reúne ambos en un único archivo auditable.