Enero de 2027 es la fecha que importa para el sistema de tu empresa. Es cuando Brasil empieza a cobrar de verdad la CBS (la nueva contribución federal sobre bienes y servicios) y el PIS y la Cofins dejan de existir, según la Enmienda Constitucional 132/2023. En 2026 los nuevos tributos ya aparecen en la factura a modo de prueba, y la Ley Complementaria 214/2025 detalla cómo funciona todo: alícuotas, créditos, documentos fiscales y la recaudación en la liquidación financiera, el llamado split payment.
Para quien opera un ERP propio, un sistema en Delphi hecho hace muchos años o un conjunto de planillas e integraciones que solo un empleado entiende, la pregunta de la dirección es directa: ¿nuestro sistema aguanta? Y, si no aguanta, ¿lo parchamos, ponemos algo al lado o cambiamos todo?
Este artículo responde en lenguaje de directorio. Explica qué exige la reforma del software, las señales de que el legado llegó a su límite, una matriz de decisión entre tres caminos (adaptar, integrar por fuera, reescribir) y cómo migrar sin frenar la facturación. En Reiko mantenemos sistemas en funcionamiento desde hace más de 20 años, y la lección es simple: el buen software es el que sigue funcionando años después de la entrega, incluso cuando cambia la ley.
Qué exige la reforma del software
La reforma reemplaza cinco tributos (PIS, Cofins, IPI, ICMS e ISS) por tres: la CBS (federal), el IBS (estadual y municipal, administrado por un Comité Gestor) y el Impuesto Selectivo. Para el sistema, el problema no es solo cambiar una alícuota. Durante años los dos modelos conviven, y el software tiene que calcular, emitir, liquidar y conciliar ambos al mismo tiempo.
El cronograma que el sistema tiene que seguir
- 2026 (año de prueba): CBS del 0,9% e IBS del 0,1% informados en el documento fiscal. El monto se compensa con PIS y Cofins, y la Ley Complementaria 214/2025 dispensa el pago a quien cumpla las obligaciones formales. El dinero casi no cambia, pero la factura tiene que salir bien.
- 2027: la CBS empieza a cobrarse, PIS y Cofins se extinguen y el IPI pasa a alícuota cero (salvo productos con industrialización incentivada en la Zona Franca de Manaos). En 2027 y 2028 el IBS sigue en prueba, con 0,05% estadual y 0,05% municipal. Según la Receita Federal, las obligaciones de CBS e IBS rigen para las empresas del Simples Nacional (el régimen simplificado brasileño para pequeñas empresas) desde el 1 de enero de 2027.
- 2029 a 2032: el ICMS (impuesto estadual al consumo) y el ISS (impuesto municipal sobre servicios) bajan un escalón por año (9/10, 8/10, 7/10 y 6/10 de las alícuotas actuales) mientras el IBS sube para compensar. Son cuatro años en que la misma venta lleva los tributos antiguos reducidos y los nuevos en alza.
- 2033: ICMS e ISS se extinguen y el modelo nuevo queda solo.
Qué cambia dentro del sistema
- Catálogo de productos y servicios: cada ítem necesita clasificación para IBS y CBS. En la NF-e (factura electrónica de bienes de Brasil), la Nota Técnica 2025.002-RTC creó un grupo de campos por ítem con CST, código de clasificación tributaria (cClassTrib), base de cálculo y alícuotas separadas de IBS estadual, IBS municipal y CBS.
- Cálculo en paralelo: hasta 2032 el motor fiscal calcula ICMS, ISS y los tributos nuevos en la misma operación, cada uno con su regla, su reducción y su excepción.
- Documentos fiscales: NF-e, NFC-e (factura al consumidor) y NFS-e (factura de servicios) con diseño nuevo, que cambia por nota técnica. Para servicios, la Receita Federal informó que la NFS-e de estándar nacional pasa a ser obligatoria para micro y pequeñas empresas del Simples Nacional desde el 1 de noviembre de 2026.
- Split payment: en la liquidación del pago, la institución de pago separa el IBS y la CBS y los ingresa directamente al fisco. Para eso, el pago tiene que estar vinculado al documento fiscal. Un sistema que emite la factura en un lugar y registra el cobro en otro, sin vínculo entre ambos, va a sufrir.
- Conciliación: con el split payment, lo que llega a la cuenta tiende a ser el monto sin el tributo segregado. Finanzas tiene que conciliar factura, pago, monto retenido y crédito, y cuentas por cobrar tiene que entender por qué el depósito es menor que la factura.
- Crédito y liquidación: en el modelo nuevo, la regla general de la Ley Complementaria 214/2025 vincula el crédito del comprador a la extinción del débito en la etapa anterior. El sistema tiene que guardar el vínculo entre compra, factura de entrada y pago.
- Auditoría: cada valor calculado tiene que ser explicable: qué regla, qué versión de la tabla, qué fecha. Ante una fiscalización, "el sistema lo calculó así" no es respuesta.
El detalle de la factura de servicios está en nuestro artículo sobre NFS-e con IBS y CBS. Aquí el foco es la decisión mayor: qué hacer con el sistema completo.
Señales de que el legado no aguanta
No todo sistema antiguo necesita ser reemplazado. Muchos funcionan bien desde hace décadas y solo necesitan ajustes. Las señales siguientes indican que el ajuste será más riesgoso de lo que parece:
- Regla fiscal dispersa en el código: alícuota fija en pantallas, informes, procedures de la base de datos y planillas de apoyo. Cambiar en un lugar y olvidar otro genera facturas erróneas.
- Nadie sabe exactamente cómo funciona el cálculo: quien lo escribió dejó la empresa, no hay documentación y el proveedor original ya no existe.
- Código fuente incompleto o inaccesible: componentes de terceros sin fuente, versión antigua de Delphi, Clipper, VB6 o Access que solo corre en una máquina nueva con parches.
- Emisión de facturas atada a un componente sin actualizaciones: el diseño cambia por nota técnica, varias veces a lo largo de la transición.
- No hay ambiente de prueba: todo cambio va directo a producción, y el error de cálculo solo aparece cuando el cliente reclama.
- Integración por archivo manual: se exporta un TXT, alguien lo importa en la base, otra persona registra el cobro. El split payment exige un vínculo automático entre factura y pago.
Si aparecen tres o más de estas señales, la pregunta deja de ser "¿se puede adaptar?" y pasa a ser "¿vale la pena adaptar?".
Tres caminos: adaptar, integrar por fuera, reescribir
No existe una respuesta única. Existe la combinación entre el estado del sistema, el tamaño del riesgo fiscal y cuánto depende el negocio de reglas que solo existen en ese código. Los tres caminos:
Camino 1: adaptar el legado
Modificar el propio sistema para incluir los campos nuevos, el cálculo paralelo y la emisión con el diseño actualizado. Tiene sentido cuando el código fuente es accesible, alguien lo conoce y la regla fiscal está concentrada en pocos puntos. El riesgo: de 2026 a 2033 no hay un cambio, hay varios. Adaptar una vez es viable; adaptar cada año un código frágil, en general, no lo es.
Camino 2: integrar por fuera (patrón strangler fig)
El nombre viene de la higuera estranguladora, que crece alrededor de un árbol viejo hasta reemplazarlo. El patrón, descrito por Martin Fowler, cambia el sistema de a poco: construyes al lado del legado una capa nueva (una API, un servicio de cálculo fiscal, un módulo de emisión) y le desvías una función por vez. El legado sigue haciendo lo que hace bien, como inventario y registros, y la parte fiscal nueva nace fuera de él.
En la reforma, eso suele significar un servicio que recibe los datos de la venta del sistema antiguo, calcula ICMS, ISS, IBS y CBS con reglas versionadas, emite la factura, registra el vínculo con el pago y devuelve el resultado. Cuando el motor nuevo está estable, la siguiente función sale del legado. En ningún momento la empresa deja de facturar.
Camino 3: reescribir (o cambiar por un ERP listo)
Construir un sistema nuevo o implantar un ERP de mercado. Tiene sentido cuando el legado ya frena al negocio en otros puntos (nube, celular, integración bancaria), cuando no hay código fuente o cuando el mantenimiento quedó rehén de una sola persona. El riesgo es el clásico: reglas de negocio olvidadas en el camino y la tentación de cambiar todo en un solo día, en plena transición tributaria.
Matriz de decisión
| Criterio | Adaptar el legado | Integrar por fuera | Reescribir o reemplazar |
|---|---|---|---|
| Cuándo es la mejor opción | Código accesible, bien conocido y con regla fiscal concentrada | Legado estable en la operación, pero frágil en lo fiscal o sin integración | Legado sin fuente, sin soporte o frenando al negocio en varios frentes |
| Riesgo para la facturación | Medio: cada cambio toca el sistema que emite la factura | Bajo: el cambio es por función, con vuelta rápida al camino anterior | Alto si el cambio es de una vez; menor si se hace por módulos |
| Esfuerzo con cada nueva nota técnica | Repetido en el código antiguo, con el mismo riesgo cada vez | Concentrado en la capa nueva, hecha para cambiar | Concentrado en el sistema nuevo o en el proveedor del ERP |
| Dependencia de quien conoce el código antiguo | Total | Parcial: solo para leer y entregar los datos del legado | Alta durante el relevamiento, baja después de la migración |
| Reglas de negocio propias | Preservadas: ya están ahí | Preservadas: el legado sigue funcionando | Solo las que se releven y se vuelvan a implementar |
| Historial de datos | Queda donde está | Queda en el legado y la capa nueva lo consulta | Exige migración planificada y verificada |
| Auditoría del cálculo fiscal | Difícil si la regla está dispersa | Buena: regla versionada y registrada en un solo lugar | Buena, si el sistema nuevo registra la regla aplicada |
Para muchas empresas con sistema propio que funciona bien en el día a día, el camino 2 suele ser el de menor riesgo durante la transición: protege la facturación, aísla la parte que más va a cambiar hasta 2033 y deja la decisión sobre el resto del sistema para después, con calma. La comparación más amplia está en el artículo sistema a medida vs listo, y los factores que pesan en la inversión están en cuánto cuesta un sistema web.
El error más común: esperar a que rechacen la factura
Descubrir el problema cuando la administración tributaria estadual rechaza la factura, o cuando el depósito del cliente llega menor, es la forma más cara de empezar. Relevar lo que el sistema hace hoy (dónde calcula, dónde emite, dónde registra el cobro) no depende de elegir el camino y puede empezar ahora.
Migrar sin frenar la facturación
Sea cual sea el camino, la regla de oro es la misma: la empresa no puede quedarse un día sin emitir facturas. Prácticas que reducen el riesgo:
- Correr en paralelo antes de cambiar: el cálculo nuevo corre al lado del antiguo, con las mismas ventas, y las diferencias se analizan antes de que lleguen al cliente.
- Cambiar por función, no por fecha: primero la emisión, después la conciliación, después cuentas por cobrar. Cada etapa con criterio de terminado y camino de vuelta.
- Migrar datos en olas: registros maestros primero, después documentos abiertos, y el historial cerrado al final. El historial puede quedar consultable en el legado en modo lectura, sin convertirlo entero.
- Verificar por totales: facturación por mes, saldo por cliente, stock por ítem. Si los totales no coinciden entre el sistema viejo y el nuevo, la migración no terminó.
- Evitar ventanas críticas: cierre de mes, fin de año y fechas de cambio de regla (cada 1 de enero de la transición) no son días para cambiar de sistema.
- Involucrar al contador desde el inicio: clasificación de ítems, régimen y beneficios son decisiones fiscales, no de TI. El sistema ejecuta; quien define es el área fiscal.
El razonamiento es el mismo de cualquier cambio de plataforma bien hecho, como mostramos al hablar de salir de WordPress hacia un sistema a medida: primero entender todo lo que hace la plataforma antigua, después mover una parte por vez.
IA para mapear reglas de negocio escondidas en el código antiguo
El mayor riesgo de una migración está en lo que el sistema antiguo hace sin que nadie lo recuerde: el descuento especial de un cliente, el redondeo que pidió el contador, la excepción para un producto. Esas reglas están en el código, no en la documentación.
Aquí la IA ayuda de verdad. Los modelos de lenguaje actuales leen código Delphi, VB, Clipper, PL/SQL y procedures de base de datos, y pueden:
- Resumir qué hace cada rutina, en lenguaje simple, para quien no programa.
- Listar los puntos del código donde aparece cálculo de impuestos, alícuota fija o regla por cliente.
- Redactar borradores de la documentación de reglas de negocio y casos de prueba con entradas y salidas esperadas.
El cuidado: la IA lee y redacta, las personas validan. Puede interpretar mal una regla o inventar una explicación plausible. Toda regla relevada tiene que ser confirmada por quien conoce el negocio y por el contador, y probada con datos reales. Y el código de la empresa solo debe ir a herramientas cuyo contrato prohíba usar los datos para entrenamiento.
Checklist para la reunión con la dirección
Antes de decidir entre adaptar, integrar o reescribir, lleva estas respuestas a la mesa:
- ¿Qué sistemas emiten documentos fiscales hoy (NF-e, NFC-e, NFS-e) y quién mantiene cada uno?
- ¿Tenemos el código fuente y alguien que lo conozca? ¿El proveedor original todavía existe?
- ¿Dónde está la regla fiscal: concentrada en un lugar o dispersa por el sistema?
- ¿El catálogo de productos y servicios está listo para recibir la clasificación de IBS y CBS? ¿Quién lo va a revisar?
- ¿Cómo se vincula hoy el pago a la factura? ¿Boleto bancario, Pix (el sistema de pagos instantáneos de Brasil) y tarjeta llegan con referencia al documento fiscal?
- ¿Finanzas está preparada para recibir montos con el tributo ya segregado y conciliarlos?
- ¿Existe ambiente de prueba? ¿Se puede emitir en homologación sin afectar producción?
- ¿Cuál es el régimen tributario de la empresa y qué recomienda el contador para 2027?
- ¿Quién decide, quién acompaña y cuál es el criterio para decir que la transición está lista?
Con estas respuestas, la elección del camino suele quedar clara. Relevar este escenario y ejecutar el camino elegido es lo que hacemos en nuestro trabajo con sistemas web a medida.
¿Tu sistema está listo para IBS, CBS y split payment?
Conversamos sobre tu sistema actual (dónde calcula, emite y concilia) e indicamos cuál de los tres caminos tiene más sentido para tu empresa. Conversación directa, sin compromiso.
Hablar por WhatsAppConclusión
La reforma tributaria es un proyecto de años, no un evento de enero. De 2026 a 2033 el sistema de la empresa va a convivir con dos modelos, varios cambios de proporción y una forma nueva de recibir el dinero de las ventas. El sistema legado no es un problema en sí: el problema es no saber qué hace ni cuánto aguanta.
Adaptar, integrar por fuera o reescribir son caminos legítimos. Lo que decide es el estado del código, el riesgo para la facturación y lo que el negocio necesita para los próximos años. Si quieres discutir tu caso, habla con Reiko.
Preguntas frecuentes
¿El split payment es obligatorio en 2027?
La Ley Complementaria 214/2025 prevé el split payment y deja a un acto conjunto de la Receita Federal y del Comité Gestor del IBS su implementación gradual, incluidos casos en que será opcional. En septiembre de 2026, según la prensa especializada, la Receita Federal informó que el mecanismo empieza de forma opcional a partir del segundo semestre de 2027, solo en operaciones entre empresas, sin fecha definida para volverse obligatorio. Las pruebas con las instituciones de pago empiezan el 15 de octubre de 2026. Aunque sea opcional, conviene preparar el vínculo entre factura y pago: es lo que se va a exigir cuando llegue la obligatoriedad.
¿Mi sistema en Delphi puede emitir con IBS y CBS?
Puede. El lenguaje no es el problema: Delphi genera XML y consume servicios web como cualquier otro. Lo que decide es si existe el código fuente, si el componente de emisión recibe actualizaciones para las notas técnicas de la reforma y si la regla fiscal está concentrada. Con eso en orden, adaptar es viable. Sin eso, una capa de cálculo y emisión al lado del sistema resuelve sin reescribir el resto.
¿Vale la pena cambiar por un ERP listo?
Vale cuando los procesos de la empresa caben en el ERP sin mucha personalización y el sistema actual ya frena al negocio en otros puntos. El riesgo está en las reglas propias que hacía el sistema antiguo y el ERP no hace: relévalas antes de firmar. Y cambiar de sistema en plena transición tributaria suma dos proyectos grandes al mismo tiempo.
¿Cómo migrar los datos sin perder el historial?
Migra en olas (registros maestros, documentos abiertos, historial cerrado), verifica por totales (facturación por mes, saldo por cliente) y guarda en cada registro el identificador de origen. El historial antiguo no necesita convertirse entero: puede quedar consultable en modo lectura, siempre que siga accesible durante el plazo en que la ley exige guardar los documentos fiscales.
¿Las empresas del Simples Nacional también deben preocuparse?
Sí, con otro calendario. Según la Receita Federal, las obligaciones de CBS e IBS rigen para las empresas del Simples Nacional desde el 1 de enero de 2027, y la NFS-e de estándar nacional pasa a ser obligatoria para micro y pequeñas empresas del Simples desde el 1 de noviembre de 2026. También existe la opción de pagar IBS y CBS por el régimen regular, que es decisión del contador, pero el sistema tiene que soportar esa elección.


