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.
Okser
Nenhum comentário:
Postar um comentário