Por Marco Vonzodas
Quando se fala em Reforma Tributária, a maior parte do mercado volta a sua atenção quase que exclusivamente para a discussão sobre as novas alíquotas do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS). Trata-se da parte visível da mudança, porém, da menor em relação ao tamanho real do desafio. Ao olharmos os sistemas de gestão (ERPs), a maturidade técnica em relação ao tema se mostra bastante desigual. Muitas companhias continuam encarando essa transição como uma simples “atualização de versão” que será resolvida isoladamente pelo fornecedor do software.
A realidade é que o fornecedor entrega apenas a infraestrutura: novos campos na nota fiscal, novos grupos e novas regras gerais de cálculo. A responsabilidade pela exatidão dos dados continua sendo da empresa. O maior gargalo técnico identificado hoje reside na parametrização e na infraestrutura de dados. Isso envolve desde a classificação fiscal de itens (NCM e a nova classificação tributária de IBS/CBS) até o cadastro de parceiros, tipos de operação e regras de determinação de imposto.
Em diversas bases de dados, esses cadastros foram estruturados há anos, por profissionais diferentes e repletos de exceções resolvidas manualmente. Enquanto o imposto era calculado focado unicamente no cumprimento de obrigações acessórias, tais divergências passavam despercebidas. Agora, com a nota fiscal carregando IBS e CBS e com o Fisco realizando cruzamentos em tempo real, qualquer inconsistência resulta em erro de cálculo, entrave na apuração de créditos ou até na rejeição imediata do documento.
Esse cenário ganha proporções ainda maiores quando consideramos a convivência entre o modelo atual (ICMS, ISS e, até 2026, PIS/Cofins) e o novo sistema, rodando simultaneamente em um período de transição que se estenderá até 2032. O maior risco de infraestrutura nesta etapa não é a capacidade dos servidores, mas sim a integridade das informações. O mesmo documento precisará carregar dois regimes distintos, com bases, regras e lógica de créditos próprias.
Se o ERP efetuar o cálculo baseado em cadastros desconectados, um item pode estar correto para o ICMS e incorreto para o IBS sem que se perceba de imediato. O erro emergirá posteriormente na apuração, no indeferimento do crédito ou na divergência junto à base do Fisco. A isso soma-se o aumento do volume de dados processados, com mais campos por documento, mais regras por linha, mais eventos e conciliações, exigindo uma governança de dados contínua em substituição à simples ideia de um evento único de go-live.
Há dois fatores centrais de atraso nesse processo: a falta de gestão de dados e o excesso de customizações. Sem uma gestão clara, a adequação transforma-se em um trabalho de “arqueologia” para mapear itens ativos, operações praticadas e origens de exceções cadastrais. Da mesma forma, as customizações acumuladas ao longo dos anos – como rotinas próprias de cálculo, relatórios paralelos e integrações sob medida – foram programadas exclusivamente para a legislação antiga. No momento em que o fornecedor atualiza a estrutura padrão do ERP, essas rotinas personalizadas continuam calculando sob o modelo anterior ou simplesmente quebram. A recomendação é buscar a máxima aproximação do padrão do ERP, aproveitando a Reforma como oportunidade para descontinuar customizações desnecessárias, tornando a adaptação mais rápida, segura e econômica.
Paralelamente, a introdução do mecanismo de Split Payment altera a lógica financeira praticada há décadas. Historicamente, o imposto arrecadado percorre o caixa da empresa para ser recolhido posteriormente. Com a segregação automática de IBS e CBS no ato da liquidação financeira, encerra-se o capital de giro informal decorrente desse intervalo temporal. Esse fator ganha gravidade ao lembrarmos de dados observados durante a pandemia, quando um estudo indicou que as pequenas e médias empresas brasileiras possuíam, em média, apenas 28 dias de caixa para sobreviver em cenários sem entrada de receita; a perda da retenção temporária do tributo exige planejamento financeiro imediato.
Além disso, o Split Payment impacta diretamente a conciliação e a arquitetura do ERP. O valor creditado na conta bancária deixará de ser idêntico ao valor de face da nota fiscal, e o sistema precisará interpretar essa diferença como tributo segregado, evitando registros incorretos de glosa, desconto ou inadimplência. Como o direito aos créditos estará atrelado à confirmação do efetivo recolhimento, torna-se indispensável o rastreamento individualizado de cada documento até sua liquidação. Módulos fiscal, contas a pagar, contas a receber e tesouraria passam a exigir integração total documento a documento.
Esse nível de exigência estende-se à infraestrutura de integração. Soluções fiscais legadas, rotinas em lote (batch), arquivos intermediários em planilhas ou conectores antigos não suportarão o volume e a velocidade de dados requeridos pelo novo Fisco em tempo real. O risco deixa de ser a lentidão e passa a ser a divergência entre o que consta no ERP, no sistema fiscal e nos registros governamentais. ERPs de mercado, a exemplo do SAP Business One, assim como soluções de parceiros certificados, estão passando por atualizações para essa nova dinâmica; o ponto crítico está nas integrações paralelas e nas customizações mantidas internamente.
Com a janela de adaptação se encurtando, a primeira atitude das lideranças deve ser retirar a Reforma Tributária do isolamento dos departamentos Fiscal ou de TI. É imprescindível estabelecer uma governança conjunta reunindo as áreas Fiscal, Financeira, TI e Operações com responsabilidade executiva. O primeiro passo prático consiste na realização de um diagnóstico profundo da base de dados (itens, parceiros, operações, integrações e customizações). O segundo é entender que revisões manuais registro a registro não possuem escala e aumentam os riscos de erro.
Por essa razão, é fundamental direcionar a adequação do ERP por meio de uma estruturada automatizada, afastando a dependência de projetos manuais e artesanais cliente a cliente. A virada não se limita a uma data específica, mas inaugura um período prolongado de transição e convivência entre regimes. Quem iniciar a reestruturação da sua arquitetura de dados desde já atravessará essa fase com processos ajustados, enquanto quem adiar a decisão enfrentará a transição sob contínua gestão de crise.
Marco Vonzodas é Co-CEO da Okser, consultoria especializada na implementação do SAP Business One.