Hay una escena que se repite en los tribunales administrativos de México con una frecuencia que debería indignar a cualquier contribuyente. El fiscalista presenta ante el magistrado una carpeta — física o digital — con decenas de archivos XML que comprueban que su cliente emitió o recibió facturas electrónicas por operaciones reales, con montos reales, con timbrado del PAC, con folio fiscal del SAT. Todo en orden. Todo verificable.
Y la autoridad fiscal, sentada del otro lado, dice: «Esos archivos no son confiables.»
Así. Sin más. Sin un peritaje que demuestre la alteración. Sin un análisis técnico que cuestione la integridad. Sin un contra-dictamen. Solo la afirmación desnuda de que los archivos que presenta el contribuyente — archivos que fueron generados, timbrados y registrados dentro del propio ecosistema digital del SAT — «no son confiables.»
Y en muchas ocasiones, el magistrado lo acepta. Porque la autoridad tiene presunción de legalidad. Porque el contribuyente no certificó forense los archivos. Porque nadie le explicó al fiscalista que un XML sin cadena de custodia documentada es un XML impugnable, por más auténtico que sea.
Este artículo existe para cerrar esa brecha. Para explicar, con la precisión técnica de 17 años de informática forense, qué es realmente un archivo XML fiscal, por qué es mucho más que un recibo, cómo se certifica su integridad para que sea inimpugnable ante un tribunal, y por qué la cadena de custodia digital que aplica el SAT a sus propios registros tiene huecos que un perito forense puede exponer.
Fiscalista que lleva archivos XML a juicio y los trata como si fueran PDFs: lo que viene a continuación va a cambiar la forma en que presenta evidencia digital ante el tribunal. Un XML no es un PDF bonito. Es un archivo de datos con firma criptográfica, metadatos de emisión, sello del PAC y timbre fiscal. Y la forma en que lo presente ante el magistrado determina si es prueba irrefutable o papel mojado.
Empresario que no sabe qué es un XML y solo le importa que le paguen sus facturas: entiéndalo así — ese archivo XML que su contador le dice que «ya está timbrado» es la prueba digital más poderosa que tiene su empresa de que una operación existió. Es más poderoso que el contrato. Es más poderoso que la orden de compra. Es más poderoso que el estado de cuenta. Porque tiene firma criptográfica. Y la criptografía no miente.
Abogado tributario que está en juicio contencioso y necesita que sus XMLs tengan valor probatorio pleno: necesita un peritaje informático. No porque sus XMLs sean falsos. Porque sin certificación forense, la contraparte los puede impugnar. Y la impugnación, por injusta que sea, funciona si usted no tiene la prueba pericial que la neutralice.
Contador que maneja miles de XMLs y nunca ha pensado en ellos como evidencia legal: empiece a pensarlo. Porque el día que el SAT cuestione una operación, la primera línea de defensa no van a ser sus hojas de cálculo. Van a ser esos XMLs. Y la forma en que los almacenó, los preservó y los puede presentar ante un tribunal va a determinar si son su salvación o su frustración.
El XML fiscal: anatomía de un archivo que casi nadie entiende
Para la inmensa mayoría de los contribuyentes en México, el XML de una factura electrónica es «ese archivo que le llega junto con el PDF» y que el contador le pide que guarde. La mayoría no lo abre. Los que lo abren ven un texto que parece código de computadora y lo cierran inmediatamente. Y los que lo guardan, lo guardan en una carpeta de Windows junto con el PDF y se olvidan de él.
Esa ignorancia generalizada sobre lo que es un XML es una de las razones por las que tantos contribuyentes pierden juicios fiscales. Porque si supieran lo que tienen en ese archivo, lo tratarían con el mismo cuidado con el que tratan una escritura pública.
Un archivo XML de un CFDI — Comprobante Fiscal Digital por Internet — contiene, en su estructura de datos, la siguiente información:
Datos de la operación. RFC del emisor, RFC del receptor, razón social de ambos, domicilio fiscal, régimen fiscal, monto total, subtotal, impuestos trasladados, impuestos retenidos, moneda, forma de pago, método de pago, uso del CFDI, conceptos facturados con descripción, cantidad, valor unitario e importe.
Sello digital del emisor. Una firma criptográfica generada con la llave privada del Certificado de Sello Digital (CSD) del emisor. Esta firma es una operación matemática que vincula el contenido del XML con la identidad del emisor de forma irrefutable. Si se modifica un solo carácter del contenido del XML después de firmado, la verificación del sello falla. Es como un sello de cera en un documento medieval: si alguien abre el sobre, el sello se rompe. Solo que en el mundo digital, el sello no se puede falsificar.
Certificado del emisor. El número del certificado de sello digital utilizado para firmar, verificable contra los registros del SAT. Cada CSD tiene una fecha de emisión, una fecha de vigencia y un número de serie único. Si el certificado estaba vigente al momento de la emisión del CFDI, la factura fue emitida con credenciales válidas autorizadas por el SAT.
Cadena original. Una secuencia de texto que concatena los datos fiscales más relevantes del comprobante en un orden específico definido por el SAT. La cadena original es el «resumen» sobre el cual se calcula el sello digital. Funciona como una huella dactilar del contenido: si el contenido cambia, la huella cambia. Si la huella coincide con el sello, el contenido no fue alterado.
Timbre Fiscal Digital (TFD). Este es el sello que pone el Proveedor Autorizado de Certificación (PAC) después de validar y registrar el CFDI. El TFD contiene: el folio fiscal UUID (un identificador único universal asignado a esa factura específica), la fecha de timbrado (con precisión de segundos), el sello del SAT (otra firma criptográfica, esta vez del propio SAT), el número de certificado del SAT utilizado para el timbrado, y la versión del TFD.
Léalo otra vez: el propio SAT firma criptográficamente cada CFDI timbrado. Es decir, el SAT certifica con su propia firma digital que esa factura fue registrada en su sistema, en esa fecha, con esos datos. Y después, en juicio, dice que «no es confiable.»
La ironía sería cómica si no destruyera empresas.
El XML no es un recibo: es un contenedor de prueba matemática
Hay una distinción fundamental que el sistema judicial mexicano — magistrados incluidos — no ha terminado de asimilar: un archivo XML fiscal no es un documento. Es un contenedor de datos con múltiples capas de verificación criptográfica.
Un documento — un contrato en PDF, una carta en Word, una imagen JPG — puede ser alterado sin dejar rastro visible. Se cambia el texto, se guarda, se presenta. A simple vista, nadie nota la diferencia. Se necesita un perito forense para verificar los metadatos y determinar si hubo alteración.
Un archivo XML fiscal es diferente. Tiene verificación integrada. El sello digital del emisor, la cadena original, el sello del SAT y el timbre fiscal crean un sistema de verificación cruzada que hace que cualquier alteración sea matemáticamente detectable.
Si alguien cambia el monto de una factura en el XML — de $500,000 a $300,000, por ejemplo — y no recalcula el sello digital con la llave privada del emisor (que solo el emisor tiene), la verificación del sello falla. La factura se detecta como alterada. Automáticamente. Sin necesidad de un perito. Cualquier sistema de validación de CFDI — incluyendo el del propio SAT — detecta la discrepancia.
Y si alguien intenta recalcular el sello digital para que coincida con el monto alterado, necesita la llave privada del certificado de sello digital del emisor. Una llave que solo el emisor posee (o debería poseer). Sin esa llave, el nuevo sello no coincide con el certificado registrado ante el SAT, y la alteración se detecta de todas formas.
Es un sistema de seguridad de múltiples capas diseñado por el propio SAT. Y funciona. El problema no es la seguridad del XML. El problema es que casi nadie — ni los contribuyentes, ni los fiscalistas, ni muchos magistrados — entiende cómo funciona. Y lo que no se entiende, no se valora.
Fiscalista que presenta XMLs en juicio: no los presente como si fueran documentos genéricos. Presente el análisis de su estructura criptográfica. Que el magistrado entienda que ese archivo tiene firma digital verificable, que fue timbrado por un PAC autorizado, que el SAT lo selló con su propia firma, que cualquier alteración es matemáticamente detectable. Eso transforma la percepción de la prueba. Ya no es «un archivo que trajo el contribuyente.» Es un archivo con integridad criptográfica certificada por el propio ecosistema del SAT.
Y si la autoridad fiscal dice «no es confiable,» la pregunta es obvia: ¿está diciendo que su propio sistema de timbrado no es confiable? Porque el sello del SAT está ahí. En el archivo. Verificable.
La cadena de custodia digital: el concepto que el SAT viola sistemáticamente
La cadena de custodia es un concepto que viene del mundo jurídico físico: la documentación continua de quién tiene un objeto de evidencia, desde que se recolecta hasta que se presenta ante el juez. Si la cadena se rompe — si alguien tuvo acceso al objeto sin documentación de que lo tocó, cuándo lo tocó y qué le hizo — la integridad de la evidencia se cuestiona.
En el mundo digital, la cadena de custodia aplica con la misma lógica pero con herramientas diferentes. La integridad de un archivo digital se verifica con valor hash: una función matemática que genera una «huella dactilar» única del archivo. Si el hash del archivo al momento de la recolección coincide con el hash al momento de la presentación ante el tribunal, el archivo no fue alterado. Si no coincide, fue alterado. Es binario. No hay ambigüedad.
Ahora. Cuando Duriva o cualquier laboratorio de informática forense serio recolecta evidencia digital, documenta la cadena de custodia con rigor absoluto: quién recolectó el archivo, cuándo, desde qué sistema, con qué herramienta, qué hash arrojó al momento de la recolección, dónde se almacenó, quién tuvo acceso al almacenamiento, qué hash arroja al momento de la presentación. Todo documentado. Todo verificable. Todo auditable.
Cuando el SAT presenta sus «constancias de sistema» como prueba en un juicio fiscal, ¿qué cadena de custodia digital presenta?
En la experiencia de Duriva: ninguna.
El SAT presenta impresiones de pantalla de sus sistemas internos. Presenta «constancias» firmadas por un funcionario que dice «esto es lo que consta en nuestros registros.» Presenta copias de su base de datos que nadie puede verificar porque nadie tiene acceso a sus sistemas. Y lo presenta sin hash, sin cadena de custodia documentada, sin certificación forense de la integridad de los datos.
Y el tribunal lo acepta. Porque viene de la autoridad. Porque tiene presunción de legalidad. Porque nadie lo impugna técnicamente.
Pero un perito forense sí puede impugnarlo.
Fiscalista que nunca ha cuestionado la cadena de custodia de la evidencia del SAT: empiece a hacerlo. Pida la cadena de custodia de los archivos que presenta la autoridad. Pregunte: ¿cuál es el hash de la constancia que presenta? ¿Quién la extrajo del sistema? ¿Con qué herramienta? ¿Cuándo? ¿Dónde está la documentación de la cadena de custodia? Si la autoridad no puede responder esas preguntas, su evidencia digital no tiene mayor rigor que un pantallazo.
Y si su cliente presenta un dictamen pericial con cadena de custodia completa, con hashes documentados, con metodología certificada bajo NOM-151, y la autoridad presenta un pantallazo sin hash ni custodia, la asimetría probatoria se invierte. Ahora es la evidencia del contribuyente la que tiene rigor técnico, y la de la autoridad la que se queda corta.
Certificar la integridad de archivos XML: el proceso forense
El proceso de certificación forense de archivos XML fiscales es meticuloso, pero no es complicado de entender. Lo que sí es, es técnico. Y esa tecnicidad es la que le da valor probatorio.
Paso 1: Recolección con cadena de custodia
El perito recolecta los archivos XML directamente del sistema donde están almacenados — el servidor de la empresa, el sistema de facturación, la carpeta de respaldos. No del correo electrónico. No de una carpeta que el contador pasó por USB. De la fuente primaria.
Al momento de la recolección, se calcula el hash SHA-256 de cada archivo XML. Ese hash es la primera marca en la cadena de custodia. Es la prueba de que, en el momento de la recolección, el archivo tenía un contenido específico e íntegro.
La recolección se documenta: fecha, hora, sistema de origen, ruta del archivo, herramienta utilizada, nombre del perito, hash resultante. Todo en un acta de recolección que forma parte del dictamen pericial.
Paso 2: Verificación de la estructura criptográfica
Para cada archivo XML, el perito verifica:
Que el sello digital del emisor sea válido. Se toma la cadena original del CFDI, se aplica la función de verificación con la llave pública del certificado del emisor, y se compara con el sello registrado en el XML. Si coinciden, el CFDI fue firmado con el certificado correcto y no fue alterado después de la firma.
Que el certificado del emisor estuviera vigente al momento de la emisión. Se verifica la fecha de vigencia del certificado contra la fecha de emisión del CFDI. Un CFDI firmado con un certificado vencido es una anomalía que el perito documenta.
Que el timbre fiscal digital del PAC sea válido. Se verifica el sello del SAT contenido en el TFD usando la llave pública del certificado del SAT. Si la verificación es exitosa, el SAT efectivamente timbró esa factura. Es la confirmación de que el SAT registró la operación en su propio sistema.
Que el folio fiscal UUID sea consultable en el portal del SAT. Se verifica que el UUID del CFDI existe en la base de datos pública del SAT y que su estatus sea vigente (o cancelado, según el caso). Esta verificación cruza los datos del XML contra los registros públicos del SAT.
Paso 3: Análisis de metadatos del archivo
Más allá de la estructura interna del XML, el archivo como objeto digital tiene sus propios metadatos: fecha de creación en el sistema de archivos, fecha de última modificación, fecha de último acceso, tamaño en bytes. El perito documenta estos metadatos y verifica que sean consistentes con la fecha de emisión del CFDI.
Si un XML que dice haber sido emitido el 15 de marzo de 2024 tiene una fecha de creación en el sistema de archivos del 15 de marzo de 2024 y una fecha de última modificación del 15 de marzo de 2024, los metadatos son consistentes. El archivo fue creado el día que se emitió y no fue modificado después.
Si en cambio el archivo tiene una fecha de creación del 20 de noviembre de 2025 — casi dos años después de su supuesta emisión — hay una anomalía que puede explicarse (se descargó del portal del SAT en esa fecha, se restauró de un respaldo, se migró a un nuevo servidor) o que puede indicar un problema. El perito investiga la explicación y la documenta.
Paso 4: Emisión del dictamen pericial
El dictamen integra los resultados de los tres pasos anteriores: recolección documentada con hash, verificación criptográfica de cada XML, análisis de metadatos. El dictamen se emite bajo los requisitos del artículo 210-A del Código Federal de Procedimientos Civiles (fiabilidad del método, atribuibilidad del contenido, accesibilidad para consulta) y con referencia a la NOM-151 para la conservación de mensajes de datos.
El resultado es un documento pericial que dice, en términos que el tribunal puede entender: estos archivos XML son íntegros, no fueron alterados, fueron emitidos con certificados válidos, fueron timbrados por el SAT, y su cadena de custodia está documentada desde la recolección hasta la presentación.
Eso convierte un XML de «archivo que trajo el contribuyente» en «evidencia digital certificada forense con cadena de custodia completa.» La diferencia ante el tribunal es enorme.
El ecosistema fiscal digital mexicano visto desde la informática forense
Para defender correctamente una empresa en un juicio fiscal, hay que entender el ecosistema completo. No solo la factura. No solo el XML. El ecosistema entero. Y ese ecosistema, visto desde la perspectiva forense, tiene fortalezas notables y debilidades que nadie quiere discutir.
Los actores del ecosistema
El contribuyente emisor. Genera el CFDI en su sistema de facturación, lo firma con su Certificado de Sello Digital, y lo envía al PAC para timbrado. Es el primer eslabón de la cadena.
El Proveedor Autorizado de Certificación (PAC). Recibe el CFDI del emisor, valida su estructura, lo timbra con el sello del SAT, le asigna el folio fiscal UUID, y lo reporta al SAT. Es el intermediario autorizado. En México hay decenas de PACs autorizados, cada uno con sus propios sistemas y servidores.
El SAT. Recibe el reporte del PAC, registra el CFDI en su base de datos central, y lo hace consultable en su portal. Es el registro final. La «verdad» oficial de que la factura existe.
El contribuyente receptor. Recibe el XML del emisor (o lo descarga del portal del SAT o del portal del PAC) y lo almacena como comprobante de la operación.
Las fortalezas del ecosistema
La criptografía. El sistema de firmas digitales — sello del emisor, sello del SAT, cadena original — es técnica y matemáticamente robusto. Un CFDI correctamente timbrado es, a efectos prácticos, inalterable sin detección. Esto es una fortaleza real del diseño del SAT. Hay que reconocerlo.
La trazabilidad. Cada CFDI tiene un folio fiscal único consultable. No hay dos facturas con el mismo UUID. Esto permite verificar la existencia de cualquier factura en cualquier momento.
La estandarización. Todos los CFDI en México siguen la misma estructura XML definida por el SAT. Esto facilita el análisis forense masivo: las mismas herramientas y metodologías aplican a cualquier factura de cualquier contribuyente.
Las debilidades que el SAT no reconoce
La cadena de custodia interna del SAT es opaca. Cuando el SAT presenta sus registros como prueba, no documenta cómo se extrajeron, quién tuvo acceso a la base de datos, qué controles de integridad se aplicaron. La presunción de legalidad sustituye a la cadena de custodia. Y eso, desde la perspectiva forense, es una debilidad probatoria.
Las fallas del sistema no se documentan públicamente. Los servidores del SAT tienen caídas, tienen errores de sincronización, tienen períodos de mantenimiento donde los datos pueden no procesarse correctamente. Cuando un CFDI no aparece en los registros del SAT, la primera asunción de la autoridad es que el contribuyente no lo emitió. Nunca es que el sistema del SAT falló al registrarlo. Y esa asunción, sin verificación técnica, genera créditos fiscales injustos.
La interoperabilidad entre PACs y SAT no es perfecta. Cada PAC es un sistema independiente que se comunica con el SAT vía interfaces electrónicas. Esa comunicación puede tener latencias, errores de transmisión, duplicados o pérdidas de registros. Si un PAC timbró un CFDI pero el reporte al SAT falló por un error de comunicación, el CFDI existe en los registros del PAC pero no en los del SAT. Para el SAT, esa factura no existe. Para el contribuyente, sí existe. Y la discrepancia genera un problema fiscal que no es culpa de nadie excepto de la tecnología.
Los certificados revocados retroactivamente. Cuando el SAT revoca un certificado de sello digital de un EFOS, la revocación puede tener efectos sobre CFDI que se emitieron cuando el certificado estaba vigente. Esto crea una situación técnica absurda: una factura que fue emitida con un certificado válido el día de su emisión puede ser cuestionada después porque el certificado fue revocado meses más tarde. Forense, la factura era válida al momento de su creación. Administrativamente, queda en entredicho.
Un peritaje informático puede documentar estas debilidades y presentarlas ante el tribunal como contexto técnico que explica las discrepancias. No para atacar al SAT — sino para demostrar que las discrepancias no necesariamente implican culpa del contribuyente.
Materialidad de operaciones a través de XMLs: la prueba cruzada
Cuando un juicio fiscal gira alrededor de la materialidad de operaciones — es decir, de demostrar que las operaciones amparadas por los CFDI realmente ocurrieron — el análisis forense de los XMLs es una de las pruebas más contundentes, pero no es la única. Su poder se multiplica cuando se cruza con otras fuentes de evidencia.
Cruce XML vs. base de datos contable
El perito toma cada XML cuestionado y cruza sus datos — monto, fecha, concepto, RFC del emisor y receptor — contra los registros de la base de datos del sistema contable de la empresa. Si el registro contable coincide con el XML en monto, fecha y concepto, la operación está documentada en dos fuentes independientes. Si además el registro contable tiene un timestamp de captura que es posterior a la fecha de emisión del CFDI pero anterior a la fecha de pago — como sería lógico en un proceso contable real — la cronología es consistente.
Cruce XML vs. registros bancarios
El monto del CFDI debe corresponder con un movimiento bancario. El perito cruza el monto y la fecha de la factura contra los estados de cuenta de la empresa. Si hay una transferencia por el monto exacto de la factura (o del monto neto después de retenciones), realizada en una fecha posterior a la emisión del CFDI y dentro de un plazo razonable de pago, el flujo de dinero documenta la materialidad.
Cruce XML vs. registros de entrega
Si la operación involucra entrega de bienes, los registros de recepción de mercancía — remisiones, bitácoras de almacén, registros del ERP — deben ser consistentes con los conceptos y cantidades del CFDI. El perito verifica que los registros de entrega existan, que sus fechas sean posteriores a la emisión de la orden de compra y anteriores o contemporáneas a la emisión de la factura, y que sus metadatos sean auténticos.
Cruce XML vs. comunicaciones electrónicas
Correos electrónicos entre la empresa y el proveedor — cotizaciones, órdenes de compra, confirmaciones de entrega, acuerdos de pago — son evidencia complementaria de que existió una relación comercial real. El perito puede extraer y certificar los encabezados de esos correos para demostrar que fueron enviados desde servidores reales, en fechas consistentes con la operación, y no fabricados después de los hechos.
Cuando el dictamen pericial presenta estos cuatro cruces — XML, contabilidad, banco, entrega — y todos cuentan la misma historia, la materialidad de la operación queda demostrada con un nivel de evidencia que es extremadamente difícil de refutar. No imposible. Pero extremadamente difícil. Porque refutarlo requeriría demostrar que cuatro sistemas independientes fueron manipulados coordinadamente, lo cual es improbable y, desde la perspectiva forense, detectable.
Fiscalista que está pensando «esto es exactamente lo que necesito»: lo es. Pero tiene que solicitarlo correctamente. No pida «un peritaje de los XMLs.» Pida un peritaje informático de certificación de integridad de CFDI con análisis cruzado de materialidad contra base contable, registros bancarios, evidencia de entrega y comunicaciones electrónicas. Ese es el alcance correcto. Y ese es el alcance que produce el dictamen que gana juicios.
Cuarta pared: lo que necesita saber cada persona que lee esto
Fiscalista con XMLs en la mano que está a punto de presentarlos como prueba: deténganlo un momento. ¿Cómo va a presentar esos XMLs? Si los va a presentar como documentales simples — una copia impresa del contenido del XML o el archivo en un USB sin certificación — está presentando la evidencia más débil posible de la prueba más fuerte que tiene. Es como tener un diamante y presentarlo envuelto en papel periódico. El XML tiene firma criptográfica del emisor y del SAT. Tiene timbre fiscal verificable. Tiene cadena original íntegra. Pero nada de eso importa si no se presenta un dictamen pericial que le explique al magistrado qué significa cada uno de esos elementos y que certifique que el archivo es íntegro. El peritaje informático no cambia el contenido del XML. Cambia su valor probatorio ante el tribunal.
Empresario que no sabe qué es un XML y está leyendo esto porque su fiscalista se lo mandó: entienda una cosa. Ese archivo que su contador le pide que guarde y que usted nunca abre es, potencialmente, la prueba más importante que tiene su empresa para defenderse ante el SAT. No lo borre. No lo guarde en una carpeta que se puede perder. Guárdelo en un servidor con respaldo. Mejor aún: pídale a su contador que implemente una política de resguardo de XMLs con respaldo automático y verificación periódica de integridad. Suena exagerado hasta que llega la auditoría del SAT. Entonces suena a previsión inteligente.
Abogado tributario que está en juicio y el SAT está impugnando sus XMLs: impugne los de ellos. Pida la cadena de custodia de las constancias de sistema que presenta la autoridad. Pregunte qué hash tienen, quién las extrajo, con qué herramienta, cuándo, dónde está la documentación de la recolección. Si la autoridad presenta una impresión de pantalla de su sistema interno como prueba de que «en nuestros registros consta que…» sin hash, sin cadena de custodia, sin certificación forense, esa prueba es técnica y jurídicamente más débil que un XML con certificación pericial. Y usted tiene derecho a señalarlo. El artículo 210-A exige fiabilidad del método para cualquier evidencia electrónica. Cualquier. Incluida la de la autoridad.
Contador que maneja los XMLs de la empresa y los tiene en una carpeta de Windows en su escritorio: esa no es una política de resguardo. Es un riesgo. Si su disco duro falla, si su equipo es formateado, si un ransomware le cifra los archivos, los XMLs de su cliente se pierden. Y cuando el SAT pida comprobantes, no va a poder decir «se me borraron.» Lo que necesita es una política de almacenamiento de XMLs que incluya respaldo automático en al menos dos ubicaciones independientes, verificación periódica de que los archivos son legibles e íntegros, y un registro de acceso que documente quién tocó esos archivos y cuándo. NOM-151 establece los requisitos para la conservación de mensajes de datos. Cumplirla no es opcional si esos archivos van a ser prueba en un juicio.
Preguntas frecuentes
Si el SAT ya tiene registro de mis CFDIs en su sistema, ¿para qué necesito guardar los XMLs?
Porque el registro del SAT es el registro del SAT. No es el suyo. Si el SAT tiene un error en su base de datos — y los tiene — usted necesita el XML original para demostrar la discrepancia. Además, el registro del SAT puede mostrar el estatus de la factura (vigente, cancelada) pero no necesariamente todos los metadatos del XML original. Su archivo XML, con su cadena de custodia documentada, es su prueba independiente. No dependa de que el sistema de la otra parte sea correcto. Tenga su propia evidencia.
¿Puedo descargar los XMLs del portal del SAT y usarlos como prueba?
Sí, pero hay matices. Un XML descargado del portal del SAT es una copia. Sus metadatos de archivo (fecha de creación, fecha de modificación) van a reflejar la fecha de descarga, no la fecha de emisión original. Un perito puede verificar que el contenido del XML descargado es íntegro — porque el sello digital y el timbre fiscal son verificables independientemente de la fuente de descarga — pero la cadena de custodia es más débil que la de un XML obtenido directamente del sistema de facturación del emisor. Siempre es preferible trabajar con la fuente primaria.
¿Qué pasa si algunos de mis XMLs están incompletos o corruptos?
Los XMLs incompletos o corruptos no pasan la verificación de sello digital. El perito lo documenta en el dictamen como una anomalía. Pero eso no significa que esas operaciones no existieron — significa que la evidencia específica del XML no es utilizable para esas operaciones específicas. El peritaje puede complementar con las otras fuentes de evidencia: registros del ERP, registros bancarios, evidencia de entrega, comunicaciones. La materialidad se puede demostrar por múltiples vías. El XML es la vía más fuerte, pero no es la única.
¿Cuánto cuesta certificar forense un lote de XMLs para un juicio fiscal?
Los peritajes informáticos en materia fiscal parten de $2,000 dólares. El costo final depende del volumen de XMLs a analizar, de la cantidad de cruces de materialidad que se requieran, y de la complejidad del caso. Un caso con 50 facturas cuestionadas no es lo mismo que uno con 500. Lo que sí se puede afirmar es que el costo del peritaje siempre es una fracción del monto en disputa. Y que un juicio perdido por falta de prueba pericial es infinitamente más caro que el peritaje que se pudo haber hecho.
¿El SAT puede presentar un contra-peritaje?
Puede. Y en ese escenario, el juicio se convierte en una confrontación técnica entre peritos, que es exactamente donde la informática forense brilla. Porque la confrontación de peritos se resuelve con argumentos técnicos, con demostraciones verificables, con hashes y sellos y metadatos. No con retórica. Y si el dictamen de Duriva tiene hashes verificables, cadena de custodia documentada, verificación criptográfica individual de cada XML y cruce de materialidad cuádruple, el contra-peritaje tiene que refutar cada uno de esos elementos con la misma precisión. No con un «nuestros sistemas dicen otra cosa.»
Qué hacer hoy para proteger sus XMLs
Primero: implemente una política de resguardo. Todo XML emitido y recibido debe almacenarse en al menos dos ubicaciones independientes. Servidor local y nube. O servidor local y disco externo. O nube primaria y nube secundaria. La redundancia no es paranoia. Es previsión.
Segundo: verifique la integridad periódicamente. Una vez al trimestre, verifique que los XMLs almacenados son legibles y que su estructura es íntegra. Herramientas gratuitas del propio SAT permiten validar la estructura básica de un CFDI. Si un archivo sale inválido, investigue por qué y reemplácelo con una copia del portal del SAT antes de que desaparezca.
Tercero: documente la cadena de custodia desde hoy. No espere al juicio para empezar a documentar. Registre dónde están almacenados los XMLs, quién tiene acceso, qué respaldos existen. Si mañana necesita un peritaje, esa documentación previa fortalece enormemente la cadena de custodia.
Cuarto: si ya está en juicio o en auditoría, contacte a un perito forense de inmediato. No después de que venza el plazo. No después de que la autoridad presente sus pruebas. Ahora. Porque la certificación forense de los XMLs toma tiempo, y el tiempo en un juicio fiscal es un recurso finito que no se recupera.
Quinto: coordine con su fiscalista la estrategia probatoria. El peritaje informático es una herramienta al servicio de la estrategia jurídica. El fiscalista define qué hay que probar. El perito define cómo probarlo. Esa coordinación, desde el inicio, es la que produce resultados.
El archivo XML de un CFDI es, probablemente, el artefacto digital más sofisticado que existe en el ecosistema fiscal de cualquier país del mundo. Tiene firma criptográfica dual — del emisor y del SAT. Tiene timbre de un tercero autorizado. Tiene folio único verificable en tiempo real. Tiene cadena original como mecanismo de integridad. Es, desde la perspectiva técnica, una pieza de ingeniería digital notable.
Y sin embargo, ese mismo artefacto se presenta en los tribunales fiscales de México como si fuera una fotocopia. Se imprime, se mete en una carpeta, se ofrece como documental. Nadie verifica el sello. Nadie verifica el timbre. Nadie calcula el hash. Nadie le explica al magistrado que ese archivo tiene más capas de seguridad que la bóveda de un banco. Y la autoridad, que fue quien diseñó el sistema criptográfico, dice ante el tribunal que «no es confiable.»
Es como si el arquitecto que diseñó la cerradura dijera en juicio que la cerradura no funciona.
La informática forense corrige esa absurdidad. Toma el XML, verifica cada capa de seguridad, documenta la cadena de custodia, cruza los datos contra fuentes independientes, y le presenta al magistrado un dictamen que no dice «créame.» Dice «verifíquelo usted mismo. Los datos están aquí. Las firmas están aquí. Los hashes están aquí. Todo es replicable, todo es verificable, todo es matemático.»
Y la matemática, a diferencia de las presunciones, no tiene sesgo. No tiene presunción de legalidad. No tiene interés en ganar o perder. Tiene resultados. Y los resultados son los que son.
Eso es lo que un peritaje informático pone sobre la mesa del magistrado. No argumentos. No interpretaciones. Resultados verificables. Y en un sistema donde la presunción juega en contra del contribuyente, los resultados verificables son la única moneda que compra justicia.