Hay una pelea que los fiscalistas mexicanos están perdiendo. No por falta de conocimiento jurídico. No por falta de estrategia procesal. No por falta de fundamento legal. La están perdiendo porque están peleando en el campo equivocado con las armas equivocadas.
Están peleando con hojas de Excel cuando la pelea está en el código de la base de datos.
Y esa frase no es metáfora. Es diagnóstico.
Cuando el SAT emite una observación, un crédito fiscal, una liquidación, lo que está diciendo — en términos técnicos — es: «Los datos que tenemos en nuestros sistemas no coinciden con lo que usted declaró.» Y cuando el contribuyente responde, lo que presenta son sus registros contables: balanzas de comprobación, estados financieros, auxiliares, pólizas. Documentos. Papeles. Archivos de Excel que un contador llevó con disciplina durante el ejercicio fiscal.
El problema es que el SAT no hizo su determinación comparando documentos con documentos. El SAT hizo su determinación comparando bases de datos con declaraciones electrónicas. Cruzó registros en sus servidores. Procesó millones de datos con algoritmos. Identificó discrepancias mediante consultas automatizadas a tablas de datos que el contribuyente nunca ve y que, en muchos casos, ni siquiera sabe que existen.
Y cuando el contribuyente llega al tribunal con sus hojas de Excel, está respondiendo a un argumento que se generó en una base de datos con un documento que se generó en una hoja de cálculo. Es como llevar un cuchillo a un tiroteo. No es que el cuchillo sea malo. Es que no es el arma correcta para esa pelea.
La pelea correcta se da en el terreno de la integridad de datos. Se da con hashes criptográficos, con auditorías de logs, con análisis de metadatos, con verificación de cadenas de bloques de registros. Se da con informática forense. Y el gremio contable — con todo respeto y con la franqueza que caracteriza a Duriva — desconoce esa herramienta. No porque sea incompetente. Porque nadie se la enseñó.
Este artículo existe para cambiar eso.
Fiscalista que está peleando un caso contra el SAT y siente que le falta algo: lo que le falta es la prueba pericial en informática. Es el componente técnico que convierte su argumento jurídico de «los datos del SAT están mal» en una demostración forense de por qué están mal, dónde está la discrepancia, y quién — el contribuyente o la autoridad — tiene los registros correctos. Sin esa prueba, su argumento es una afirmación. Con ella, es ciencia.
Empresario con una discrepancia fiscal que no entiende cómo surgió: lo que sigue en este artículo le va a explicar, en términos que no requieren doctorado en sistemas, cómo los datos de la autoridad pueden estar incompletos, corruptos o alterados — y cómo se demuestra técnicamente.
Contador que ha llevado los registros con impecable disciplina y no entiende por qué el SAT dice otra cosa: su disciplina contable es el fundamento. Pero el tribunal necesita algo más que disciplina. Necesita prueba técnica de que sus registros son íntegros. Y la integridad de un registro digital no se demuestra con orden alfabético ni con cuadre de cifras. Se demuestra con hashes.
Abogado tributario que litiga contra el SAT sin prueba pericial en informática: Duriva entiende que la prueba pericial en informática no es parte del currículum de derecho tributario. Pero la realidad del litigio fiscal en el siglo XXI es que las discrepancias que generan créditos fiscales son discrepancias de datos digitales. Y las discrepancias de datos digitales se resuelven con informática forense, no con argumentos. Este artículo le va a mostrar la herramienta que le falta.
El problema de fondo: bases de datos vs. hojas de cálculo
Duriva lo dice de frente porque alguien tiene que decirlo: el gremio contable en México está peleando una guerra digital con herramientas analógicas.
No es una crítica. Es una observación basada en 17 años de ver cómo llegan los casos al laboratorio. El patrón es siempre el mismo:
El SAT emite una observación. El contador del contribuyente abre su sistema contable — Contpaq, Aspel, SAP, lo que sea. Genera un reporte. Lo exporta a Excel. Lo imprime. Lo entrega al fiscalista. El fiscalista lo presenta ante el tribunal como prueba de que los registros del contribuyente son correctos.
Y enfrente, la autoridad fiscal presenta una constancia de sus sistemas internos. Una impresión certificada de lo que dice su base de datos. Un documento oficial que dice, con la presunción de legalidad que ampara a los actos de autoridad: «Según nuestros registros, la cifra es esta.»
Dos documentos. Dos cifras. Dos versiones. Y el tribunal tiene que decidir cuál es la correcta.
Y aquí es donde la asimetría aplasta al contribuyente.
Porque la constancia del SAT tiene presunción de legalidad. Los actos de autoridad se presumen legales hasta que se demuestre lo contrario. Es decir: lo que dice el SAT se presume correcto. Lo que dice el contribuyente se tiene que probar.
El contribuyente tiene que probar que sus registros son correctos. Y tiene que probar que los del SAT están mal. Con una hoja de Excel. Contra una base de datos gubernamental.
Es una pelea desigual. Y es la pelea que el peritaje informático forense equilibra.
Porque lo que el peritaje hace no es presentar otra hoja de Excel más bonita. Lo que hace es entrar a la base de datos del contribuyente — la base de datos real, no el reporte que genera el contador — y demostrar, con precisión criptográfica, que esos registros son íntegros, que no fueron alterados, que la secuencia de transacciones es consistente, que los timestamps son coherentes, que los hashes de los registros no presentan anomalías.
Y simultáneamente, puede demostrar que los registros de la autoridad están incompletos, que presentan inconsistencias, que la cadena de datos entre lo que el contribuyente envió y lo que la autoridad procesó tiene brechas.
Eso ya no es una opinión contable contra una presunción de legalidad. Es una demostración matemática contra una presunción jurídica. Y la demostración matemática es más fuerte.
Auditar integridad de bases de datos: lo que el perito realmente hace
Cuando Duriva recibe un caso de discrepancia fiscal, el equipo no abre Excel. Abre la base de datos.
El sistema contable de cualquier empresa — Contpaq, Aspel, SAP, Oracle, Microsip, cualquiera — no es un archivo de Excel con columnas y filas. Es una base de datos relacional. Una estructura de tablas interconectadas donde cada transacción, cada póliza, cada movimiento contable, está registrado con un conjunto de atributos que incluyen mucho más que el monto y la fecha.
Cada registro en la base de datos tiene:
Un timestamp de creación. La fecha y hora exacta en que ese registro fue ingresado al sistema. No la fecha del movimiento contable — la fecha en que se capturó. Y la diferencia importa. Si un movimiento contable del 15 de marzo fue capturado el 15 de marzo, la secuencia es coherente. Si un movimiento contable del 15 de marzo fue capturado el 28 de diciembre — justo antes del cierre fiscal –, eso levanta una bandera.
Un ID de usuario. Quién capturó el registro. Qué usuario del sistema realizó la transacción. Esto es relevante porque si todos los registros del ejercicio fueron capturados por el mismo usuario (el contador) y de repente hay registros capturados por un usuario diferente (o por un usuario administrador que no debería estar haciendo capturas contables), eso es una anomalía.
Un log de modificaciones. Los sistemas contables profesionales registran cada modificación a un registro: qué campo se cambió, de qué valor a qué valor, cuándo, por quién. Si un monto fue modificado después de la captura original, el log lo registra. Si se modificó un mes después del cierre fiscal, el log lo registra. Si se modificó mil veces, el log registra las mil veces.
Registros de eliminación. Cuando se borra un registro de la base de datos, dependiendo del sistema, puede quedar un rastro. Registros marcados como «eliminados» pero todavía presentes en la tabla. Huecos en la numeración consecutiva de folios. Inconsistencias en la secuencia de IDs. Un perito forense sabe detectar estas huellas.
Lo que Duriva hace con la base de datos del contribuyente es una auditoría de integridad. No una auditoría contable — esa la hace el contador. Una auditoría de integridad de datos. Que responde a las preguntas que el contador no puede responder:
¿Los registros fueron alterados después de su captura original? ¿Los timestamps son consistentes con el flujo normal de operación? ¿Hay registros fantasma — registros que aparecen sin un proceso de captura documentado? ¿Hay huecos en la secuencia de transacciones que sugieran eliminación de registros? ¿La base de datos está íntegra o presenta signos de corrupción, manipulación o alteración?
Y las respuestas a esas preguntas, cuando se presentan con rigor forense, son devastadoras para quien tenga los registros incorrectos. Si los registros del contribuyente pasan la auditoría de integridad — si no hay alteraciones, si los timestamps son coherentes, si los logs no muestran modificaciones sospechosas, si los hashes son consistentes –, la conclusión técnica es que la base de datos del contribuyente es íntegra. Y si la base de datos íntegra del contribuyente dice una cifra diferente a la que dice el SAT, la pregunta cambia de dirección: ya no es «por qué el contribuyente tiene una cifra diferente» sino «por qué el SAT tiene una cifra diferente a una base de datos cuya integridad fue verificada forense.»
Cruzar hashes de registros: la prueba matemática que el SAT no puede refutar
El hash es el concepto central de toda la informática forense. Y es la herramienta que convierte una discrepancia fiscal en una demostración matemática.
Para el fiscalista y el abogado tributario que no están familiarizados con el término: un hash es una función matemática que toma cualquier conjunto de datos — un archivo, un registro, una base de datos entera — y genera una cadena única de caracteres que funciona como una huella digital de esos datos. Si cambias un solo caracter, un solo número, un solo espacio en los datos originales, el hash cambia completamente.
Duriva lo explica así en los tribunales: piense en el hash como un sello de cera en una carta. Si la carta fue abierta y vuelta a cerrar, el sello está roto. No importa qué tan cuidadosamente la hayan vuelto a sellar — el sello original está roto. El hash funciona igual: si los datos fueron modificados, el hash cambia. Y el hash original, calculado antes de la modificación, ya no coincide con el hash actual. Eso prueba alteración.
En un caso de discrepancia fiscal, el cruce de hashes funciona así:
Paso 1: El perito calcula el hash SHA-256 de cada archivo XML emitido por el contribuyente durante el ejercicio fiscal. Cada CFDI — cada factura electrónica — tiene un archivo XML con un sello digital y un timbrado del PAC. Ese archivo es una pieza de datos cuya integridad es verificable. El perito calcula su hash y lo registra.
Paso 2: El perito solicita — a través del abogado y mediante solicitud judicial si es necesario — los archivos XML que el SAT tiene registrados para el mismo contribuyente y el mismo ejercicio. Calcula los hashes de esos archivos.
Paso 3: Cruza los hashes. Si el hash del XML que tiene el contribuyente es idéntico al hash del XML que tiene el SAT, el archivo es el mismo. No fue alterado por ninguna de las partes. El dato es íntegro.
Si los hashes no coinciden, uno de los dos archivos fue modificado. Y la pregunta es cuál. Y la respuesta está en los metadatos: la fecha de creación del archivo, el sello del PAC, la cadena original del CFDI, el certificado de sello digital. Toda esa información permite determinar cuál es el archivo original y cuál fue alterado — o si el SAT tiene un archivo diferente porque su sistema procesó la información de manera incorrecta.
Paso 4: El perito totaliza los montos de todos los XMLs verificados. Si la sumatoria de los XMLs íntegros arroja $4,800,000 y el SAT dice que el contribuyente declaró $5,200,000, la discrepancia está cuantificada, documentada y demostrada con precisión matemática.
Esa es una demostración que no se refuta con «nuestro sistema dice otra cosa.» Se refuta con otra demostración matemática. Y si la autoridad no presenta su propia verificación de hashes — que en la experiencia de Duriva, rara vez presenta –, la demostración del perito del contribuyente queda como la única evidencia técnica en el expediente.
El magistrado no necesita creerle al contribuyente. Necesita creerle a la matemática. Y la matemática no miente.
Demostrar que lo que tiene la autoridad está incompleto, corrupto o alterado
Aquí es donde la informática forense entra en territorio que incomoda a la autoridad fiscal. Porque la presunción de legalidad protege los actos del SAT. Pero la presunción de legalidad no es escudo contra la ciencia.
Lo que un peritaje informático puede demostrar sobre los registros de la autoridad:
Que están incompletos. Si el contribuyente emitió 1,247 CFDIs durante el ejercicio y el SAT solo tiene registrados 1,198, hay 49 CFDIs que la autoridad no procesó. Esos 49 CFDIs tienen sello digital del PAC, tienen timbrado, tienen folio fiscal. Existen. Fueron emitidos correctamente. El PAC los certificó. Pero el sistema del SAT no los registró. Y si esos 49 CFDIs representan los $400,000 de discrepancia, el caso está resuelto: el error es del SAT, no del contribuyente.
Este escenario es más común de lo que la autoridad quisiera admitir. Los sistemas del SAT procesan millones de CFDIs diarios. Errores de procesamiento, timeouts de servidor, fallas de sincronización entre bases de datos — todo esto puede generar huecos en los registros del SAT que se convierten en créditos fiscales para el contribuyente.
Que están corruptos. La corrupción de datos en una base de datos no requiere intervención humana maliciosa. Puede ocurrir por fallas de hardware en los servidores, por interrupciones de energía durante escrituras en disco, por errores de software en los procesos de migración de datos — que el SAT realiza con cierta frecuencia cuando actualiza sus sistemas. Un registro corrupto puede mostrar un monto diferente al original, una fecha incorrecta, un RFC truncado. Y si ese registro corrupto es la base de la observación fiscal, la observación está fundamentada en datos dañados.
El perito no puede auditar directamente los servidores del SAT — la autoridad no va a darle acceso a sus sistemas internos. Pero sí puede demostrar, por comparación con los datos del contribuyente y los datos del PAC, que lo que el SAT tiene registrado no coincide con lo que debería tener. Y esa demostración por contraste es admisible y poderosa.
Que fueron procesados incorrectamente. El SAT recibe los CFDIs a través de los PACs. Los PACs timbran las facturas y envían la información al SAT. Pero el proceso entre el PAC y el SAT no es instantáneo ni infalible. Si el perito demuestra — con los registros del PAC, que son una tercera fuente independiente — que el PAC envió la información correcta y que el SAT la registró de manera diferente, la discrepancia no es culpa del contribuyente ni del PAC. Es un error de procesamiento del SAT.
Tres fuentes de datos que cuentan la misma historia: el sistema contable del contribuyente, los XMLs timbrados por el PAC, y los acuses de recepción del portal del SAT. Si las tres coinciden y la cuarta fuente — la base de datos interna del SAT — dice algo diferente, la cuarta fuente es la anómala. Y demostrar eso con rigor forense desvirtúa la presunción de legalidad. No la ataca jurídicamente. La desvirtúa científicamente.
El peritaje como «as bajo la manga» del fiscalista
Duriva trabaja con fiscalistas de todo México. Y hay un patrón que se repite en cada nuevo fiscalista que descubre la prueba pericial en informática: primero escepticismo, después asombro, después incorporación permanente a su estrategia.
El escepticismo es comprensible. El fiscalista ha litigado contra el SAT durante años — en muchos casos, décadas — con las herramientas que conoce: la argumentación jurídica, la prueba documental, el recurso de revocación, el juicio contencioso administrativo. Y esas herramientas funcionan. Nadie dice que no.
Pero funcionan hasta cierto punto. Funcionan cuando la discrepancia es claramente un error administrativo. Funcionan cuando hay un vicio de procedimiento obvio. Funcionan cuando la autoridad cometió un error de forma que permite la revocación por cuestiones procesales.
Donde dejan de funcionar es cuando la discrepancia es de datos. Cuando el SAT dice «en nuestra base dice X» y el contribuyente dice «en la mía dice Y,» y el tribunal tiene que decidir cuál base de datos tiene razón. En ese escenario, la argumentación jurídica no es suficiente porque la pregunta no es jurídica — es técnica. Y la prueba documental no es suficiente porque un reporte de Excel no demuestra la integridad de la base de datos que lo generó.
Ahí es donde la prueba pericial en informática es el as bajo la manga. Es la carta que el SAT no espera. Es la prueba que cambia el lenguaje del juicio de argumentos a datos, de opiniones a hashes, de «mi cliente tiene razón» a «aquí está la demostración criptográfica de que mi cliente tiene razón.»
Y hay algo más que el fiscalista necesita saber: el SAT, en la experiencia de Duriva, rara vez presenta prueba pericial en informática en los juicios contencioso-administrativos. Presenta sus constancias de sistema. Presenta sus impresiones certificadas. Presenta sus oficios. Pero no presenta un perito en informática que refute los hallazgos del perito del contribuyente.
Lo que significa que, en la mayoría de los casos, el dictamen del perito del contribuyente queda como la única evidencia técnica en el expediente. Sin contraparte. Sin refutación. Sin contrapericial. Y un dictamen pericial no refutado tiene un peso probatorio que el magistrado no puede ignorar.
Eso no es una ventaja táctica menor. Eso es una ventaja táctica enorme.
Onus probandi fiscal: cómo la informática forense invierte la carga
Duriva lo ha explicado en artículos anteriores y lo reitera aquí porque es el eje de toda la estrategia: en la práctica fiscal mexicana, la carga de la prueba está invertida. El SAT acusa y el contribuyente demuestra. La autoridad dice y el contribuyente prueba.
En un sistema jurídico donde la presunción de inocencia debería aplicar universalmente, el contribuyente es culpable hasta que demuestre su inocencia fiscal. Es kafkiano. Pero es la realidad operativa del sistema tributario mexicano.
Y la informática forense no cambia esa realidad sistémica. Pero le da al contribuyente la herramienta más poderosa disponible para demostrar su inocencia fiscal: datos verificables, hashes criptográficos, auditorías de integridad, demostraciones matemáticas.
Porque cuando el fiscalista llega al tribunal con un dictamen pericial que dice: «Se verificó la integridad de la base de datos contable del contribuyente mediante cálculo de hash SHA-256 de cada tabla de registros. No se detectaron alteraciones posteriores a la captura original. Los timestamps de creación son consistentes con el flujo operativo del ejercicio fiscal. La sumatoria de los CFDIs emitidos, verificados individualmente por su sello digital y timbrado del PAC, arroja un total de ingresos de $4,800,000.00 MN. Dicha cifra difiere en $400,000.00 de lo registrado por la autoridad fiscal. La discrepancia se atribuye a 49 CFDIs que obran en los registros del contribuyente y del PAC pero que no constan en los registros de la autoridad.»
Eso ya no es el contribuyente diciendo «yo tengo razón.» Eso es un perito demostrando dónde está el error. Y la diferencia entre las dos cosas, ante un magistrado, es la diferencia entre una afirmación y una prueba.
El sarcasmo fino que Duriva se reserva para el SAT
Hay algo que Duriva ha observado con consistencia a lo largo de 17 años y que merece ser dicho con la ironía que merece: el SAT exige a los contribuyentes una precisión milimétrica en sus registros digitales — que los XMLs estén correctos hasta el último centavo, que los sellos digitales sean verificables, que las declaraciones se presenten en formato electrónico con especificaciones técnicas rigurosas — pero cuando se le pide que demuestre la integridad de sus propios registros con el mismo rigor, la respuesta es el silencio institucional.
El SAT quiere que el contribuyente sea digitalmente impecable. Pero sus propios sistemas tienen fallas que no documenta, errores que no reporta, caídas de servidor que no reconoce, migraciones de datos que no audita públicamente. Y cuando esas fallas generan discrepancias que se convierten en créditos fiscales, la culpa es del contribuyente.
Es como si un profesor reprobara al alumno por un error de ortografía mientras el propio examen tiene tres preguntas ininteligibles.
Y no es que los sistemas del SAT sean malos. Son sistemas masivos que procesan millones de transacciones. Es inevitable que tengan errores. Lo que no es inevitable — lo que es una decisión institucional — es que esos errores generen consecuencias patrimoniales para el contribuyente sin que la autoridad tenga la obligación práctica de demostrar que sus propios registros son correctos.
La informática forense le da al contribuyente la herramienta para exigir esa demostración. No pidiéndola — porque el SAT no va a entregarla voluntariamente. Sino presentando una demostración propia tan sólida que la ausencia de refutación por parte de la autoridad hable por sí misma.
Para cada persona que está leyendo esto
Fiscalista que está armando una defensa contra un crédito fiscal basado en discrepancia de datos:
Incorpore la prueba pericial en informática a su estrategia. No como un complemento. Como un pilar. Porque la discrepancia que está peleando no se generó en un mundo de papel. Se generó en un mundo de bases de datos, de servidores, de procesamientos automatizados. Y la prueba que resuelve esa discrepancia vive en el mismo mundo.
El peritaje no sustituye su estrategia jurídica. La potencia. Le da el combustible técnico que convierte su argumento de «la autoridad se equivocó» en «aquí está la demostración matemática de dónde se equivocó.» Y hay una diferencia abismal entre las dos cosas.
Coordine con el perito desde el primer día del caso. No cuando ya está en el juicio contencioso. Desde el día que recibe la notificación de la auditoría. Porque la preservación de evidencia es crítica: los logs de servidor se sobreescriben, los respaldos se eliminan por rotación, los sistemas se actualizan y los datos históricos se pierden. Mientras más pronto entre el perito, más evidencia puede preservar.
Empresario con discrepancia fiscal que no sabe qué hacer:
Lo primero: no entre en pánico, pero no ignore. Ignorar una auditoría del SAT es lo peor que puede hacer. Cada día que pasa sin responder es un día donde los plazos se acortan, las multas crecen y las opciones se reducen.
Lo segundo: su contador es indispensable para identificar la discrepancia numérica. Pero la defensa ante el tribunal requiere algo más que números correctos. Requiere prueba técnica de que sus números son correctos. Y esa prueba la genera un perito en informática forense, no un contador.
Lo tercero: preserve todo. No borre logs de servidor. No formatee equipos. No reinstale el sistema contable. No «limpie» la base de datos. Todo es potencialmente evidencia forense. Y la evidencia que se destruye no se recupera.
Lo cuarto: arme un equipo de tres patas. Contador que identifique las discrepancias. Fiscalista que diseñe la estrategia legal. Perito en informática forense que genere la prueba técnica. Quitar una pata y el banco se cae.
Contador que está defendiendo a su cliente con reportes de Excel:
Con todo respeto profesional: Duriva entiende que nadie le enseñó informática forense en la carrera de contaduría. Pero la realidad del litigio fiscal en 2026 es que las discrepancias se generan en bases de datos y las defensas se presentan con hojas de cálculo. Hay una desconexión fundamental entre el problema y la herramienta con la que se intenta resolver.
Su conocimiento contable es imprescindible. Es usted quien identifica la discrepancia, quien entiende el flujo de las operaciones, quien sabe qué cifra debería ser y cuál no. Pero para probar ante un tribunal que sus cifras son las correctas, necesita al perito que demuestre la integridad de la base de datos que generó esas cifras. No es una cuestión de confianza en su trabajo. Es una cuestión de rigor probatorio.
El peritaje no lo sustituye a usted. Lo complementa. Y juntos — el conocimiento contable y la demostración forense — construyen una defensa que el SAT no puede tumbar con una constancia de sistema.
Abogado tributario que nunca ha ofrecido prueba pericial en informática:
La primera vez que un magistrado del TFJA recibe un dictamen pericial en informática forense que demuestra con hashes y timestamps que los registros del contribuyente son íntegros y que la discrepancia se origina en los sistemas de la autoridad, la dinámica del juicio cambia. Completamente. El magistrado deja de evaluar credibilidad de documentos y empieza a evaluar datos científicos. Y los datos científicos no se derrumban bajo cuestionamientos procesales. Los datos científicos son o no son.
Duriva evalúa la viabilidad técnica del peritaje antes de comprometer presupuesto. Si el caso no tiene suficiente evidencia digital para generar un dictamen útil, se dice de frente. No se cobra por un peritaje que no va a producir resultados. Esa franqueza es parte del servicio.
Preguntas frecuentes
¿Cuánto cuesta un peritaje informático en un caso de discrepancia fiscal con el SAT?
Los peritajes de esta naturaleza tienen un piso de $2,000 dólares. El costo final depende de la complejidad: cuántos ejercicios fiscales están involucrados, cuántos CFDIs hay que verificar, cuántos servidores o sistemas contables requieren auditoría. Siempre se compara contra lo que está en juego. Si el crédito fiscal es de $3 millones de pesos, el peritaje representa menos del 2% de lo que puede perder. Y si el peritaje le ahorra esos $3 millones, la inversión se justifica sola.
¿Se puede usar el peritaje tanto en recurso de revocación como en juicio contencioso?
Sí. La prueba pericial es admisible en ambos. Pero la recomendación de Duriva, basada en la experiencia, es ofrecerla en el juicio contencioso ante el TFJA. En el recurso de revocación, quien resuelve es el propio SAT — lo cual presenta un conflicto de interés estructural que no requiere explicación. En el juicio contencioso, resuelve un magistrado independiente. La probabilidad de que la prueba pericial sea valorada con imparcialidad es significativamente mayor.
¿Qué pasa si la base de datos del contribuyente sí fue alterada?
Si el perito encuentra que los registros del contribuyente fueron modificados después de la captura original, lo reporta. Duriva no altera hallazgos ni oculta evidencia desfavorable. La verdad forense no tiene lado. Si la base de datos del contribuyente fue alterada, el contribuyente necesita saberlo antes que el tribunal, para tomar decisiones informadas con su fiscalista. Un perito que oculta hallazgos no es un perito — es un riesgo.
¿Qué tipo de sistemas contables puede auditar el perito?
Cualquier sistema que utilice una base de datos. Contpaq, Aspel, SAP, Oracle, Microsip, sistemas propietarios desarrollados a medida. La metodología forense no depende del sistema específico. Depende de la estructura de la base de datos. Y todas las bases de datos — SQL Server, MySQL, Oracle, Firebird — tienen tablas, registros, timestamps y logs auditables.
¿El SAT puede pedir su propio peritaje informático para refutar el del contribuyente?
Puede. Y jurídicamente debería. Pero en la práctica, Duriva ha observado que la autoridad fiscal rara vez presenta contraprueba pericial en informática. Presenta sus constancias de sistema, sus impresiones certificadas, sus oficios. Pero no presenta un perito que diga, con el mismo rigor técnico: «El hash del archivo que presenta el contribuyente no coincide con el que tenemos» o «Los metadatos fueron alterados.» Y en ausencia de contraprueba pericial, el dictamen del contribuyente queda firme.
El SAT no es infalible. Sus sistemas tienen errores. Sus bases de datos tienen huecos. Sus procesamientos tienen fallas. Y cuando esas fallas generan créditos fiscales contra un contribuyente que operó correctamente, la carga de demostrar el error recae sobre el contribuyente.
Esa es la realidad del sistema tributario mexicano. Es injusta en su diseño. Es aplastante en sus consecuencias. Y es la realidad que la informática forense equilibra.
Porque los datos son los datos. Un hash no miente. Un timestamp no tiene sesgo. Un log de auditoría no se inventa. Y cuando esos datos demuestran que la discrepancia no es culpa del contribuyente — que sus registros son íntegros, que sus XMLs están correctos, que la cadena de datos entre su sistema contable y el PAC es consistente, y que lo único que no cuadra son los registros de la autoridad — el magistrado tiene la evidencia que necesita para resolver con justicia.
La pelea no está en las hojas de Excel. La pelea está en el código de la base de datos. Y mientras los fiscalistas sigan peleando con hojas de cálculo, van a seguir perdiendo batallas que podrían ganar.
La herramienta existe. La metodología está probada. Los resultados hablan por sí mismos.
Lo que falta es que alguien la use. Ese alguien puede ser usted.