En 2026 la reforma tributaria brasileña entra en fase de prueba: los dos nuevos impuestos al consumo aparecen destacados en los documentos fiscales, con alícuotas simbólicas, y no se recaudan. El año es informativo.

Eso suena a holgura, y es lo contrario. Lo que la empresa declara sin pagar es exactamente lo que queda registrado sin el filtro de alguien revisando un valor a pagar. Es el material que se va a leer después — cuando la discusión ya no sea una prueba.

Y «después» no es una figura retórica. Una divergencia sobre un documento de 2026 puede juzgarse en 2031, con el proceso tramitando años. La pregunta que llega en esa fecha no es cuál es la regla hoy. Es: ¿qué aplicó su sistema aquel día, y por qué?

La prueba exige tres cosas, y nadie guarda las tres juntas

Para demostrar cómo salió un número hace falta tener, al mismo tiempo:

El documento. Ese lo guarda todo el mundo. Es la parte fácil, y es la que da falsa sensación de cobertura.

La regla vigente en aquella fecha. Esa vive fuera del sistema — en la legislación, en notas técnicas, en el entendimiento del equipo fiscal. Rara vez hay un vínculo entre «este documento» y «la versión de la regla que valía cuando se emitió».

La versión del parámetro que produjo el número. Esa es la que se pierde. Tablas de alícuota, reglas de decisión, código propio, motor fiscal externo — todo eso cambia con los años, y buena parte cambia por encima, sin dejar el estado anterior.

Guardar el documento sin los otros dos permite mostrar el resultado. No permite mostrar la derivación — y la derivación es lo que se discute en un contencioso.

La trampa del parámetro sobrescrito

Los sistemas fiscales suelen tener validez por fecha en las tablas de alícuota — y eso crea la impresión de que el histórico está resuelto. No lo está, porque el cálculo rara vez sale solo de ahí.

Pasa también por reglas de decisión, por código propio escrito para tratar excepciones del negocio, por el maestro — la clasificación del producto, el régimen del cliente, la naturaleza de la operación — y, en muchas empresas, por un motor fiscal externo con base de conocimiento propia, actualizada por el proveedor.

Ninguna de esas capas guarda versión por defecto. El resultado práctico es conocido: usted logra reproducir el cálculo de hoy, y no el de hace dos años. Cuando alguien pregunta por qué aquel ítem fue tributado de aquella manera en 2026, la respuesta honesta suele ser «porque el sistema estaba configurado así» — y eso no es una respuesta.

Conviene recordar que en volumen el origen del número casi nunca es el cálculo: es el maestro. Un error de clasificación se repite en todos los documentos de ese producto, en silencio, hasta la determinación — es el mecanismo descrito en clasificación fiscal errada en el maestro de producto.

La convivencia duplica todo, y por varios años

Hasta la extinción completa del sistema anterior, ambos regímenes coexisten. En la práctica, para TI, eso significa tres cosas que se acumulan:

Cada documento carga las dos determinaciones. Lo que ya era complejo pasa a existir en dos versiones simultáneas, con reglas que evolucionan a ritmos distintos.

Cada cambio necesita fecha. No basta con alterar: hay que saber desde cuándo pasó a valer, y qué valía antes. Cambio sin fecha es histórico perdido.

La ventana de retención pasa a ser mayor que la vida del sistema. El ambiente que hizo la cuenta puede haber sido actualizado, migrado o reemplazado antes de que llegue la discusión. Por eso el archivado con regla de retención deja de ser asunto de espacio en disco y se vuelve requisito de defensa — lo tratamos en archiving SAP.

Lo que sale mal, con nombre

Apagar el legado demasiado pronto. Es la tentación después de una migración exitosa: el ambiente viejo cuesta caro y nadie lo usa. Dejó de ser sistema y pasó a ser prueba — y su plazo no es el del proyecto.

Migrar sin traer el histórico calculable. Traer los documentos es el mínimo. Si la plataforma nueva no logra reconstruir cómo salió el número en la anterior, el histórico se volvió archivo muerto legible, no evidencia.

Tratar la captura de pantalla como prueba. Una imagen muestra el resultado y no sostiene ninguna pregunta sobre derivación.

Creer que el archivo del documento alcanza. Registra lo que se declaró, no cómo se llegó ahí. Es el resultado, no el camino.

Dejar el código propio sin versionar. Es la capa que más se olvida y la que más decide el número en empresas con operación específica.

Lo que esto no es

Vale ser explícito: nada de esto es orientación tributaria. La lectura de la regla, el encuadre y la estrategia de defensa son del equipo fiscal y del jurídico, y ahí es donde empieza esta conversación.

El trabajo de TI es otro, y es complementario: garantizar que el sistema logre demostrar lo que hizo. Cuando el fiscal necesite sostener un entendimiento, va a necesitar la evidencia — y ella existe desde la emisión, o no se fabrica después.

El límite honesto

Poder probar el cálculo no gana la discusión. Gana la posibilidad de tenerla con dato en lugar de con memoria — que es distinto, y es bastante menos de lo que nos gustaría prometer.

Tampoco es gratis. Versionar parámetros, fechar cambios y retener ambientes con regla cuesta disco, licencias y disciplina, y ese costo aparece antes que el beneficio — que puede no cobrarse nunca, si la discusión no llega. Es una póliza, y una póliza se evalúa por el tamaño del riesgo, no por la prima.

Y hay un límite de alcance: esto trata de lo que la empresa logra mostrar. No corrige lo que se calculó mal. Si el maestro estaba equivocado, guardar bien la evidencia solo documenta mejor el error — por eso el orden es hallar primero, guardar después.

Si el punto de partida es entender qué hace el ambiente hoy antes de cambiar nada, empiece por el diagnóstico de TI. Para el panorama de lo que la reforma exige de TI, vea Reforma Tributaria y SAP. Y si la emisión todavía depende de la plataforma anterior, el camino es la migración de SAP NFE a DRC.

Preguntas frecuentes