Compliance resolve o sintoma. Arquitetura resolve o problema.

O LAUDO × reforma-tributária × arquitetura × business-capability

Toda empresa que diz estar "resolvendo a reforma tributária" está resolvendo a parte errada.

Compliance é necessário. Emitir nota com os campos certos, calcular IBS e CBS, entregar as obrigações acessórias no prazo — tudo isso tem que acontecer. Mas se for só isso, a empresa está comprando metade de uma solução e pagando o preço inteiro. A outra metade vai cobrar a conta em 2027, quando CBS estiver em vigor pleno e IFRS 18 entrar em operação ao mesmo tempo. Não como surpresa — como consequência de uma decisão tomada agora, implicitamente, ao escolher correr atrás do prazo em vez de entender o problema.

A pergunta certa não é "o que precisamos atualizar?" A pergunta certa é: o que nossa empresa precisa ser capaz de fazer?

São perguntas diferentes. A primeira leva a um projeto de patch. A segunda leva a um projeto de arquitetura. E é o segundo que decide se a empresa gasta uma vez ou duas.

A abordagem compliance tem uma lógica impecável no curto prazo: identifica o que o regulador exige, mapeia o que o sistema atual não entrega, corrige o gap. Deadline 2026, projeto fechado.

O problema é que essa lógica pressupõe que o impacto da reforma está contido no sistema fiscal. Não está.

A lógica tributária da reforma — princípio do destino, não cumulatividade plena, cálculo dual durante a transição até 2033 — atravessa a empresa inteira. Pricing que não considera a alíquota do estado do comprador vai errar a margem. Contratos com cláusula de reajuste indexada a tributos precisam ser revisados porque a estrutura dos tributos mudou. Logística que otimizava rota por carga fiscal vai precisar recalcular as premissas. Decisões de M&A que não avaliem o estoque de créditos de ICMS da empresa-alvo estão ignorando um ativo que pode ser relevante — ou um passivo disfarçado.

Nenhum desses itens mora no departamento fiscal. O fiscal enxerga a ponta — nota emitida, obrigação entregue. A causa fica espalhada por dentro da operação.

Quando a abordagem é só compliance, o que acontece é o seguinte: o sistema emite a nota certa. Mas o preço estava errado quando foi calculado, o contrato vai gerar litígio quando o cliente interpretar a cláusula de forma diferente, e a logística continua otimizando uma variável que mudou de sinal. Compliance em dia, operação desalinhada.

A consequência prática é gastar duas vezes. O patch de 2026 custa X. A refatoração de 2028, quando a pressão de CBS plena + IFRS 18 tornar insustentável ignorar o resto, vai custar mais do que X — com o agravante de ser feita em urgência, sem o prazo que existe agora para fazer com cuidado. Urgência tem preço específico: decisões arquiteturais tomadas com deadline na nuca costumam ser decisões de que a empresa vai se arrepender por cinco anos.

Quem paga essa conta não é o vendor. É a empresa.

Se a pergunta errada é "o que precisamos atualizar?", a pergunta certa precisa de uma ferramenta diferente para ser respondida. Essa ferramenta existe e tem nome: business capability map.

Não é metodologia nova. Arquitetura corporativa usa o conceito há décadas. O que a reforma faz é torná-lo urgente para quem nunca precisou dele antes.

O que é uma capability

Capability é o que a empresa precisa conseguir fazer — independente de qual sistema faz isso, de qual processo executa, ou de quem é responsável operacionalmente.

A distinção é mais importante do que parece. Um processo é como a empresa faz algo hoje. Um sistema é a ferramenta que suporta esse processo. Uma capability é a capacidade em si — existe em abstrato, antes de qualquer decisão de implementação.

"Calcular tributo por destino" é uma capability. O IBS e o CBS exigem que o tributo seja calculado com base no destino da operação, não na origem. Isso é uma exigência da reforma — e é válida independentemente de como a empresa decide atendê-la. SAP com módulo atualizado é uma implementação dessa capability. Motor fiscal externo integrado ao ERP é outra. Planilha gerenciada pelo fiscal é uma terceira — ruim, mas é uma implementação.

A reforma não dita a implementação. Ela exige a capability. E é exatamente essa separação que a abordagem compliance ignora: vai direto para a implementação sem passar pela pergunta de qual capability está sendo endereçada.

Como mapear o que a reforma afeta

O mapeamento tem três etapas. Primeiro, identificar as capabilities que a reforma exige. Segundo, mapear onde cada uma existe hoje na empresa. Terceiro, nomear os gaps com precisão: o que não existe e vai precisar existir.

As capabilities centrais que a reforma coloca em jogo são: cálculo por destino; rastreabilidade por item (cada produto com cClassTrib vinculado a artigo da LC 214/2025); separação operacional/financeiro (que converge com IFRS 18 em 2027); gestão de crédito de ICMS acumulado; geração de obrigações acessórias nos novos formatos (campos CST-IBS e CST-CBS previstos no leiaute da NF-e); e pricing com alíquota dual durante a transição.

Para cada uma dessas capabilities, a empresa precisa responder: existe? Em qual sistema? Em qual processo? É manual ou automatizado? Pode escalar?

Quando a resposta é "não existe", o gap é explícito. Quando a resposta é "existe, mas em planilha controlada por uma pessoa do fiscal", o gap é de resiliência e escala. Quando a resposta é "existe no sistema, mas o sistema não está atualizado para os novos campos", o gap é de implementação — e esse é o único caso em que a abordagem compliance resolve por inteiro. A maioria das empresas vai descobrir uma combinação dos três.

Priorização por impacto e prazo

O mapeamento de capabilities sozinho não prioriza. O que prioriza é a interseção entre impacto financeiro, urgência regulatória e custo de refatoração posterior — nessa ordem.

2026 é o deadline de obrigações acessórias: os novos campos da NF-e são previstos no leiaute e exigidos conforme cronograma regulatório. A fase educativa de 2026 tem mecanismo de correção — mas não é impunidade. É uma janela. Capabilities de emissão e classificação fiscal têm deadline duro aqui.

2027 é o deadline de reporte financeiro: CBS entra em vigor pleno e IFRS 18 passa a ser obrigatório simultaneamente. As capabilities de separação operacional/financeiro, rastreabilidade por natureza e granularidade de crédito têm que estar funcionando antes disso.

2029–2033 é a janela de transição ICMS/ISS: prazo mais longo, mas a decisão arquitetural precisa ser tomada agora. Não porque o regulador exige em 2026 — mas porque a arquitetura que suporta oito anos de transição não se constrói em seis meses. Quem deixar para 2028 vai construir com urgência. Quem decidir agora constrói com cuidado.

O business capability map mostra o que a empresa precisa conseguir fazer. A próxima pergunta é arquitetural: quem vai fazer o cálculo? Onde vai viver a inteligência tributária da operação?

O conceito

A decisão mais importante que uma empresa pode tomar agora não é qual sistema atualizar. É onde vai morar o cálculo tributário.

O padrão de mercado é deixar no ERP. Faz sentido histórico — o ERP centraliza dados, tem módulo fiscal integrado. O problema aparece quando a regra muda. E a regra vai mudar: as regulamentações infralegais da reforma ainda estão pendentes. A alíquota de referência do IBS, por exemplo, ainda depende de resolução do Senado. Cada atualização regulatória nova significa abrir o ERP, testar, validar, reimplantar. Em ambiente legado, isso tem custo, tem risco e tem tempo.

A alternativa é desacoplar: o motor fiscal calcula, o ERP consome o resultado. O motor fica especializado em tributação — atualiza quando a regra muda, mantém histórico de versões, cobre a diversidade de tributos e regimes. O ERP faz o que faz bem: operação, logística, financeiro.

A analogia mais direta é o gateway de pagamento. A empresa não mantém o código de processamento de cartão de crédito. Mantém a integração com o gateway — e quando a bandeira muda uma regra, é o gateway que atualiza, não a empresa. A empresa continua responsável pelo resultado final, mas terceirizou a complexidade do cálculo.

Motor fiscal como serviço funciona da mesma forma. A empresa continua responsável pelo tributo — responsabilidade fiscal não se terceiriza. Mas a complexidade de acompanhar regulamentação, manter tabelas de alíquota atualizadas e calcular por destino por operação por item fica no motor, não no time interno.

Isso tem nome: arquitetura composable. A mesma lógica está por trás de sistemas de pagamento modernos, de CRM componentizado, de infraestrutura de dados — peças especializadas, interface clara, trocáveis de forma independente. O motor fiscal como serviço é a aplicação desse princípio ao problema tributário. Não é tendência. É resposta estrutural a uma regulação que vai continuar se movendo.

Quem já faz parcialmente

Ferramentas especializadas de motor fiscal existem no mercado brasileiro. Não é categoria nova — o mercado de automação fiscal brasileiro tem décadas, e a reforma acelerou o desenvolvimento de soluções específicas para IBS/CBS.

A categoria existe. O que varia entre as ferramentas é o que importa para a decisão arquitetural: cobertura de tributos, velocidade de atualização quando nova regulamentação sai (o SLA entre "Senado aprova resolução" e "ferramenta calcula corretamente" é um dado crítico), capacidade de integração com ERPs legados e histórico de versões de cálculo — essencial para auditoria posterior.

O critério de avaliação não é o nome do produto. É a capacidade de resposta a mudança regulatória no tempo certo. A reforma vai continuar se movendo — regulamentações infralegais ainda pendentes, controvérsias de interpretação entre estados em aberto, mecanismos como o split payment ainda em revisão. A ferramenta que vai servir bem é a que trata atualização como produto, não como serviço adicional.

Tem um problema estrutural que o business capability map não resolve, e que nenhuma ferramenta de motor fiscal resolve: o projeto que a reforma exige não tem dono corporativo.

O CFO aprova o projeto de adequação fiscal. O CTO aprova o projeto de atualização de ERP e arquitetura. São projetos diferentes, com budgets diferentes, com KPIs diferentes, com consultores diferentes. E ninguém aprova o projeto que é os dois juntos — que é exatamente o projeto que a reforma exige.

Quando o projeto fiscal termina, o fiscal declara sucesso: sistema emite, obrigação entregue, alíquota calculada. Quando o projeto de ERP termina, o CTO declara sucesso: sistema atualizado, módulo novo funcionando. O problema da empresa — pricing desalinhado, contratos com cláusula obsoleta, logística calculando premissa errada — continua existindo, porque ele morava na intersecção, e a intersecção não tinha dono.

Isso não é falha de gestão. É estrutura. Organizações grandes são otimizadas para resolver problemas dentro de silos, não entre eles. A reforma é um problema de fronteira — e problemas de fronteira ficam no limbo organizacional por design.

O mercado de consultoria agrava o problema. A consultoria tributária especializada em reforma vende adequação fiscal. A de ERP vende transformação de sistemas. A de arquitetura corporativa vende framework. Ninguém vende a intersecção — porque ela requer expertise nas três áreas ao mesmo tempo e é mais difícil de precificar e de vender.

O incentivo é claro: quanto mais fragmentado o projeto, mais escopo para cada consultoria. A empresa tem incentivo para integrar — gasta menos e resolve de vez. O mercado tem incentivo para fragmentar — mais projetos, mais horas. Não é conspiração. É modelo de negócio.

A consequência prática é que a empresa que não nomear um dono explícito para a intersecção — alguém com mandato sobre o projeto fiscal e o projeto de arquitetura ao mesmo tempo — vai descobrir, em 2027, que cada silo entregou o seu e o problema continua inteiro.

A janela para fazer isso bem está aberta. A transição dura até 2033. Isso não é tempo de sobra — mas é tempo suficiente para tomar decisões de arquitetura com cuidado, se a decisão for tomada agora.

O que fecha a janela não é o prazo regulatório. É a convergência de 2027: CBS plena + IFRS 18 entrando ao mesmo tempo. Quem chegar em 2027 sem as capabilities de separação operacional/financeiro e granularidade de crédito funcionando vai tomar decisões sob pressão — e decisões de arquitetura sob pressão costumam produzir mais dívida técnica, não menos.

A implicação prática é direta: o projeto que a reforma exige é um projeto de arquitetura com deadline regulatório. Não é projeto fiscal com componente de TI. Essa distinção decide quem tem mandato, quem aprova o orçamento, e o que entra no escopo. Empresas que tratarem como compliance vão sair de 2033 com sistemas atualizados e arquitetura remendada. Empresas que tratarem como arquitetura vão sair com fundação melhor do que tinham antes — e a reforma terá sido a melhor desculpa que tinham para arrumar a casa.

Dossiê × A reforma tributária é um projeto de tecnologia

Compliance garante que você passa. Arquitetura garante que você não volta.

Fontes: LC 214/2025 — IBS, CBS, IS e regras de transição  ·  LC 227/2026 — CGIBS e regime de penalidades  ·  NT 2025.002 — Nota Técnica NF-e v1.34  ·  EC 132/2023 — Base constitucional da reforma  ·  CVM — CPC 51 / IFRS 18 (2025)