01
Contexto
Resumen de lo que cambia desde 2026 y cómo el período de prueba/adaptación afecta contratos de aplicación, persistencia de datos y conciliación.
Resumen técnico
- • Los documentos fiscales se convierten en fuente operativa de datos: CBS/IBS/IS entran en el XML, el DPS, los eventos y la liquidación asistida.
- • Fiscal y financiero quedan acoplados: El Split Payment conecta factura, pago, baja, reversión y flujo de caja.
- • Los maestros dejan de ser soporte: cClassTrib, CST, destino, beneficio y régimen pasan a determinar el comportamiento transaccional.
Línea de tiempo que los sistemas deben soportar
| Fase | Tema | Qué cambia | Impacto en la aplicación |
|---|---|---|---|
| 2026 H1 | Inventario y diseño de arquitectura | Mapear los puntos que calculan precio, impuesto, factura, cobros, créditos y liquidación. | Crear backlog por dominio: ERP, fiscal, pricing, checkout, pagos, finanzas, data/BI e integraciones. |
| 2026 | Año de prueba y adaptación CBS/IBS | Los documentos fiscales (DF-e) deben destacar CBS e IBS según notas técnicas; el foco oficial es validar modelos digitales y obligaciones accesorias. | Los sistemas deben generar nuevos XML/JSON, persistir bases/valores y reconciliar lo emitido con la liquidación asistida. |
| 2027 | CBS pleno y fases del Split Payment | CBS reemplaza PIS/Cofins; el Split Payment avanza gradualmente según reglamentación, acuerdos de pago y capacidad técnica. | Checkout, cuentas por cobrar, conciliación bancaria y ledger deben manejar valor bruto, impuesto segregado y valor neto recibido. |
| 2029-2032 | Transición gradual del IBS | ICMS/ISS conviven con IBS en porcentajes progresivos, exigiendo dos modelos en paralelo. | El motor fiscal y la contabilidad deben soportar coexistencia, distribución por destino, créditos e informes comparativos. |
| 2033 | Nuevo modelo pleno | IBS reemplaza totalmente a ICMS/ISS y el legado deja de ser la ruta principal. | Desactivación controlada de reglas antiguas, limpieza de maestros y consolidación del modelo operativo definitivo. |
| Fuente | Tema | Uso en el playbook |
|---|---|---|
| Receita Federal | Orientações para 2026 | Obrigações acessórias, DF-e com CBS/IBS, DeRE, plataformas digitais e ano de teste. |
| Receita Federal | Período de adaptação e multas | Evita tom alarmista: 2026 é período de teste/adaptação e orientação antes de punição. |
| Ministério da Fazenda | Regulamento CBS/IBS | Apuração assistida, documentos padronizados, regras uniformes e centralização da apuração. |
| Avalara Brasil | Descomplica Reforma Tributária | Benchmark editorial sobre cálculo de tributos, Split Payment, GTIN e TCO de conformidade. |
| NT 2025.002 / NF-e | Grupos UB, W03, CST e cClassTrib | Base técnica para impactos em NF-e/NFC-e e contratos de documento fiscal. |
En 2026, los campos pueden no bloquear técnicamente todas las emisiones al inicio, pero la obligación legal y la necesidad de persistir los datos ya afectan contratos de aplicación y conciliación.
02
Aplicaciones impactadas
Dominios de sistema que deben inventariarse antes de cambiar schemas o reglas: fiscal, finanzas, datos maestros, pricing, checkout, integraciones y datos.
Aplicaciones que generalmente fallan primero
| Área | Estado habitual hoy | Qué cambia | Riesgo | Modernización recomendada |
|---|---|---|---|---|
| Motor tributario / Tax Engine | Reglas dispersas en ERP, módulo fiscal, pricing, NCM, CFOP y configuraciones por estado/municipio. | CBS, IBS e IS exigen cálculo ítem a ítem, base sin impuesto incluido, créditos amplios, regímenes específicos y clasificación tributaria dinámica. | Riesgo de inconsistencia entre pedido, factura, finanzas y liquidación asistida. | Centralizar reglas en un servicio versionado con parámetros por fecha de vigencia y explicabilidad por ítem. |
| Emisor fiscal / DF-e | Layouts existentes para NF-e, NFC-e, CT-e, NFS-e y documentos sectoriales. | Nuevos grupos IBS/CBS/IS, nuevos totalizadores, eventos e información de reparto/créditos. | Un documento técnicamente autorizado puede ser aún inconsistente con la obligación accesoria o la liquidación. | Separar generación fiscal de regla tributaria; versionar schemas y aceptar convivencia de layouts. |
| Maestro de productos, servicios y clientes | NCM, código de servicio, CFOP, CST y beneficios fiscales mantenidos como maestro operativo. | GTIN donde aplique, cClassTrib, CST CBS/IBS, indicadores ZFM/ALC, beneficios, destino y tipo de consumidor adquieren centralidad. | Riesgo de clasificación fiscal incorrecta a escala, especialmente en e-commerce, marketplace y PDV. | Crear gobernanza de catálogo fiscal con vigencia, origen de la regla, flujo de aprobación y auditoría. |
| Pricing, cotización y checkout | Precio generalmente tratado como valor final con impuestos incluidos y poca separación fiscal en tiempo real. | Base sin impuesto incluido, desglose individualizado y Split Payment cambian lo que el cliente ve, paga y lo que ingresa neto a la caja. | Margen, descuento, flete, cupón e instalamentos calculados sobre bases incorrectas. | Exponer precio bruto, impuestos, valor neto y efectos de crédito/beneficio en el mismo contrato de cálculo. |
| Pagos y cuentas por cobrar | Pago, factura y conciliación frecuentemente resueltos en batch. | El Split Payment vincula el documento fiscal a la transacción financiera cuando aplique; parte del impuesto puede segregarse en la liquidación. | Riesgo de divergencia entre liquidación, baja, reversión, devolución y liquidación tributaria. | Modelo de conciliación event-driven con idempotencia, estado por transacción y trazabilidad completa. |
| Contabilidad, ledger y liquidación | Cierre mensual con conciliaciones manuales y ajustes por planillas o reportes de ERP. | La liquidación asistida consolida débitos y créditos a partir de documentos y registros fiscales. | El ledger interno no coincide con la liquidación preliminar del fisco; los ajustes manuales se vuelven rutina. | Crear sub-ledger fiscal por ítem/documento, conciliación automática y divergencia explicable. |
| Integraciones B2B, marketplace y plataformas digitales | Contratos legados EDI/API intercambian XMLs, pedidos y pagos sin los nuevos campos fiscales. | Las plataformas digitales tendrán obligaciones específicas cuando se publiquen los layouts; marketplaces, sellers y PSPs deben preparar contratos. | Riesgo de incompatibilidad entre seller, marketplace, ERP, gateway y fiscos. | Versionar APIs externas, crear schema registry fiscal y estrategia de compatibilidad por socio. |
| Datos, BI y auditoría | El dato fiscal se usa más para obligaciones accesorias que para operaciones en tiempo real. | Los datos fiscales ahora alimentan la liquidación asistida, el control de créditos, la caja y la auditoría operacional. | Indicadores de ingresos, margen y caja inconsistentes entre finanzas, fiscal y BI. | Modelo analítico con granularidad por ítem, documento, pago, crédito y evento. |
Punto de control recomendado: registrar, por dominio, qué sistema calcula, transforma o persiste valores fiscales.
Evidencia esperada: inventario con responsable, contrato de datos, campos obligatorios, sistemas consumidores y fecha de vigencia de la regla.
03
Arquitectura de referencia
Flujo recomendado para mantener pedido, cálculo, documento fiscal, pago, ledger y determinación consistentes durante la transición.
Flujos que cambian de forma estructural
| Flujo | Antes | Después | Sistemas involucrados |
|---|---|---|---|
| Pedido -> precio -> factura -> pago | Flujo lineal con impuestos incluidos, baja financiera posterior y liquidación en batch. | Flujo fiscal-financiero acoplado: cálculo CBS/IBS/IS, documento con desglose, pago con posible split y conciliación por evento. | E-commerce, ERP, motor fiscal, emisor fiscal, gateway/PSP, cuentas por cobrar. |
| Servicio -> DPS/NFS-e -> municipio/entorno nacional | Municipios con estándares distintos e integraciones específicas por ayuntamiento. | Estándar nacional NFS-e/DPS con grupos IBS/CBS e integración al entorno nacional. | Sistema de servicios, billing, NFS-e, municipio/entorno nacional, contabilidad. |
| Compra -> crédito -> liquidación | El crédito tributario depende de reglas PIS/Cofins/ICMS/ISS y conciliación manual. | El crédito amplio CBS/IBS exige trazabilidad por documento, ítem, proveedor y pago. | Procurement, fiscal inbound, cuentas por pagar, ledger, data lake fiscal. |
| Cancelación/devolución -> reversión fiscal/financiera | Eventos fiscales y reversiones financieras procesados por rutinas separadas. | El evento fiscal debe reconciliar impuesto desglosado, crédito, split y valor neto. | OMS, ERP, emisor fiscal, PSP, finanzas y atención al cliente. |
Arquitectura objetivo para convivencia 2026-2033
+-------------+ +-------------+ +---------------+
| Pedido/Cart | ---> | Tax Engine | ---> | Emissor DF-e |
+-------------+ +-------------+ +---------------+
| | |
v v v
+-------------+ +-------------+ +---------------+
| PSP/Gateway | ---> | AR/Ledger | ---> | Apuracao/Fisco|
+-------------+ +-------------+ +---------------+
| | |
+--------------------+--------------------+
v
Data Lake fiscal auditavel
Decisión de arquitectura
- • Centralice el contrato de cálculo: precio, descuento, flete, destino e impuestos deben tener una única respuesta explicable.
- • Versione por vigencia: la regla tributaria no es un deploy único; es un dato regulatorio con fecha de inicio y fin.
- • Diseñe para la convivencia: el legado y el nuevo modelo correrán juntos durante años.
04
Cálculo tributario
Cambios de cálculo que afectan tax engine, pricing, vista previa de factura, contratos de API y persistencia por ítem.
Qué cambia en el cálculo de la aplicación
| Dimensión | Qué cambia | Impacto en la aplicación |
|---|---|---|
| Base sin impuesto incluido | El impuesto deja de componer su propia base como en el modelo actual en varias situaciones. | Pricing e invoice preview deben recalcular bruto, neto, descuento, flete e impuestos en el mismo contrato. |
| Tributación en destino | El IBS depende del lugar de destino/consumo y del reparto entre entes. | Dirección, municipio, estado, consumidor final y tipo de operación se convierten en inputs obligatorios del cálculo. |
| Crédito amplio | El crédito tiende a ser financiero y más amplio, pero depende de documentos y pagos trazables. | Cuentas por pagar, fiscal inbound y ledger deben exponer crédito por ítem/documento/proveedor. |
| Regímenes especiales | Finanzas, salud, seguros, hotelería, combustibles, monofásicos y otros tienen reglas propias. | El motor fiscal debe soportar plugins/reglas por sector, no solo una tabla simple por NCM/servicio. |
| Impuesto Selectivo (IS) | El IS recae sobre bienes/servicios específicos y agrega otra capa de clasificación. | El catálogo de producto debe indicar sujeción al IS, vigencia, base y excepciones. |
El contrato de cálculo debe devolver valores por ítem, regla aplicada, vigencia de la regla y explicación suficiente para auditoría y atención al cliente.
05
Documentos fiscales electrónicos
DF-e listados por Receita Federal y layouts que pasan a transportar CBS/IBS según notas técnicas. El punto es preparar contratos de datos, no solo pantallas de emisión.
Documentos y contratos fiscales impactados
| Documento | Nuevos campos | Cambio en la aplicación | Responsable |
|---|---|---|---|
| NF-e / NFC-e | Grupo UB (IBS/CBS/IS por ítem), totalizadores W03 y tablas CST/cClassTrib según NT 2025.002. | Actualizar emisor, validadores, almacenamiento XML, DANFE/representación e integraciones downstream. | ERP / Fiscal / PDV |
| NFS-e / DPS nacional | Grupo IBS/CBS, códigos nacionales, indicadores como ZFM/ALC y reglas del entorno nacional cuando aplique. | Soportar emisor propio o entorno nacional, APIs Sefin/ADN y convivencia municipal. | Billing / Servicios / Fiscal |
| CT-e / CT-e OS | Desglose CBS/IBS en transporte y ajustes de totalizacion. | Actualizar TMS, cálculo de flete, documentos vinculados e integraciones con embarcadores. | Logística / TMS |
| NFCom / NF3e / BP-e | Campos CBS/IBS y reglas por sector regulado. | Adaptar plataformas sectoriales y contratos con reguladores/operadoras. | Telecom / Energía / Transporte |
| DeRE y declaraciones de regímenes especiales | Layouts específicos para sectores financiero, salud, seguros, consorcios y otros. | Crear nueva capa declaratoria y reconciliar con operaciones sin documento fiscal tradicional. | Fiscal / Cumplimiento / Producto |
Documento autorizado no significa sistema correcto
La flexibilización inicial de validaciones técnicas no elimina la obligación legal. Esto crea un riesgo nuevo: los documentos pueden pasar por el autorizador, pero aún así generar incumplimiento, divergencia de liquidación y retrabajo operacional.
06
Datos maestros y tablas fiscales
Campos maestros que pasan a influir directamente en la operación: producto, servicio, cliente, proveedor y tablas regulatorias.
Maestros que ahora gobiernan el comportamiento transaccional
| Dato | Campos críticos | Falla típica |
|---|---|---|
| Producto / SKU | GTIN donde aplique, NCM, cClassTrib, sujeción al IS, beneficio fiscal, monofásico, cBenef. | Un SKU nuevo sin clasificación correcta puede generar divergencia de impuesto, rechazo o ajuste posterior. |
| Servicio | Código nacional, DPS, municipio de incidencia, prestador/tomador, régimen especial. | NFS-e emitida con municipio o código incorrecto rompe la liquidación asistida. |
| Cliente / tomador | CNPJ/CPF, inscripciones, dirección destino, contribuyente, consumidor final, ZFM/ALC. | Regla de destino y beneficio aplicada incorrectamente en checkout o factura. |
| Proveedor | Régimen tributario, regularidad, documentos recibidos, pago confirmado. | Crédito tributario no aprovechado o bloqueado por falta de trazabilidad. |
| Tabla fiscal | CST CBS/IBS, alícuotas, reducciones, diferimientos, vigencia, fuente normativa. | Actualización de tabla sin versionado genera comportamiento diferente entre ambientes. |
Punto de control recomendado: simular jornadas con variación de clasificación fiscal, destino, beneficio y régimen.
Evidencia esperada: el mismo ítem produce resultado consistente en pricing, documento fiscal, pago, ledger y liquidación asistida.
07
Pagos y Split Payment
Split Payment debe tratarse como integración fiscal-financiera por fases, no como obligación universal instantánea para todos los flujos.
Cómo el Split Payment cambia producto y finanzas
| Área | Impacto | Arquitectura necesaria |
|---|---|---|
| Checkout y pedido | El pedido debe guardar bruto, impuesto estimado, neto, medio de pago y documento fiscal vinculado para escenarios con segregación. | Contrato único entre pricing, motor fiscal y pago. |
| Gateway / PSP | La transacción debe estar preparada para llevar identificadores fiscales y recibir respuesta de segregación cuando el modelo aplique. | Callbacks idempotentes, reintento, estado granular y firma/verificación. |
| Cuentas por cobrar | La baja financiera puede dejar de ser igual al valor total de la factura cuando haya segregación del impuesto en la liquidación. | Ledger con bruto, impuesto retenido, neto, tarifas y divergencias. |
| Tesorería | El capital de trabajo puede cambiar porque parte del impuesto deja de estar temporalmente disponible en caja. | Forecast de caja con escenarios de split, cuotas y reversión. |
| Atención al cliente y reembolso | Las cancelaciones y devoluciones deben revertir fiscal y financiero de forma sincronizada. | Orquestador de devolución con compensación fiscal y conciliación automática. |
Impacto real: caja y conciliación
- • El monto que ingresa a caja puede ser menor que el total de la factura.
- • Cuotas, devoluciones parciales, cancelaciones y chargebacks deben llevar el efecto fiscal.
- • Cada transacción debe ser conciliable por documento, cuota, impuesto, tarifa y valor neto.
08
Integraciones y contratos de API
Contratos internos y externos que necesitan nuevos campos fiscales, eventos e identificadores conciliables.
Contratos de integración que deben cambiar
| Contrato | Campos / eventos nuevos | Versionado recomendado |
|---|---|---|
| ERP -> emisor fiscal | item.cClassTrib, item.CST, base IBS/CBS, alícuota, valor, IS, destino. | Versionar por NT y fecha de vigencia; aceptar campos opcionales/obligatorios por fase. |
| E-commerce -> motor fiscal | sku, consumidor, dirección destino, cupón, flete, canal, marketplace, fecha de operación. | Respuesta explicable con bruto/neto/impuestos por ítem y regla aplicada. |
| ERP -> PSP/gateway | id documento fiscal, valor CBS, valor IBS, valor IS, valor neto, transacción original. | Idempotencia y callbacks de confirmación/error/reversión. |
| ERP -> data warehouse | documento, ítem, impuesto, crédito, pago, reversión, evento, divergencia. | Modelo analítico append-only para auditoría y reprocesamiento. |
| Marketplace -> seller | responsable tributario, seller, documento, split, comisión, transferencia, devolución. | Contrato por seller y por régimen, con convivencia legado/nuevo. |
Los sistemas que ya tienen APIs versionadas y un schema registry fiscal sufrirán menos. Quienes intercambian XML y CSV sin contrato formal descubrirán el impacto cuando los socios empiecen a enviar nuevos campos.
09
Operación en producción
Señales concretas de divergencia para operación: pedido vs documento, documento vs pago, datos maestros vs cálculo, documento vs determinación asistida.
Señales operativas que deben convertirse en paneles
| Señal | Por qué importa | Responsable |
|---|---|---|
| Documentos sin campos CBS/IBS | La obligación legal puede existir aunque no haya rechazo técnico inmediato. | Fiscal Platform |
| Divergencia pedido vs factura | Pricing y motor fiscal pueden aplicar reglas distintas. | Commerce Platform |
| Divergencia factura vs pago | El Split Payment modifica la baja y el valor neto recibido. | Payments / AR |
| Divergencia factura vs liquidación asistida | El fisco consolida débitos/créditos a partir de los documentos. | Fiscal / Accounting |
| Maestros fiscales vencidos | La tabla cClassTrib/CST/beneficios cambia por vigencia. | Master Data |
| Colas de contingencia fiscal | SEFAZ, NFS-e nacional o PSPs pueden fallar e impactar emisión, recepción o conciliación. | SRE / Fiscal Ops |
Punto de control recomendado: comparar continuamente pedido, documento fiscal, pago, maestros y liquidación.
Evidencia esperada: divergencias abiertas por tipo (cálculo, maestro, documento, split, baja, liquidación) con payloads y eventos trazables.
10
Roadmap de adaptación
Secuencia práctica para preparar sistemas existentes: inventario, cálculo central, documentos, Split Payment, convivencia y operación.
Roadmap de modernización por fases
| Fase | Ventana típica | Entregable |
|---|---|---|
| 1. Inventariar flujos | 2-4 semanas | Mapa de aplicaciones, contratos, responsables y jornadas fiscales críticas. |
| 2. Separar motor fiscal | 4-8 semanas | Contrato único de cálculo tributario con explicabilidad y versionado. |
| 3. Actualizar documentos y schemas | 4-10 semanas | Nuevos DF-e/NFS-e validados en homologación con los nuevos campos persistidos. |
| 4. Conectar fiscal y financiero | 6-12 semanas | Split Payment modelado en pedido, pago, cuentas por cobrar y conciliación. |
| 5. Operar convivencia | 2026-2033 | Dos modelos corriendo con monitoreo, auditoría y feature flags por dominio. |
Discovery
Inventario inicial
0/4
Arquitectura
Contratos y datos
0/5
Operación
Producción y sustentación
0/4
Priorice flujos que combinan alto volumen, impacto en caja y dependencia de múltiples integraciones: checkout, facturación, Split Payment, devoluciones/cancelaciones y liquidación.
El objetivo es reducir la divergencia entre sistemas, no solo actualizar campos fiscales. Cada etapa debe producir evidencia trazable de cálculo, emisión, pago y conciliación.