Quem deve ser o responsável por divergência Fiscal × TI dentro da empresa?

Adriana Marques, concordo profundamente com sua visão sobre a fronteira entre o que é tributário e o que é técnico. No entanto, eu gostaria de adicionar que, mesmo com o negócio fornecendo o conhecimento mais apurado, a documentação do requisito tributário precisa ser funcionalmente executável pela TI. Se a regra fiscal é extremamente granular, mas não mapeada em um fluxo computacional claro, o sistema dificilmente conseguirá replicá-la sem um intermediário que traduza essa complexidade em passos lógicos para o software. Então, a sacada é garantir que o aceite do escopo não seja apenas um acordo verbal, mas sim um comprovante de que o modelo de dados suporta a regra.

Meu contraponto, como coordenador tributário, observou que a atribuição de erro se torna quase um jogo de empurra, e isso não avança o projeto. Na minha vivência com o novo ERP, percebemos que a raiz da questão reside na maturidade do projeto. Veja, segundo o que li, se o conhecimento fiscal é o mais avançado, a TI deve atuar como um executor fiel desse conhecimento, não como um criador dele. O caminho eficiente é definir claramente a fronteira: o negócio fornece o "o quê" tributário, e o sistema entrega o "como" funcional.

Leonardo, sua questão sobre a tradução do conhecimento tributário ressoa muito com minha experiência. Quando o negócio possui uma camada de detalhe que o sistema não traduz de imediato, a responsabilidade da ponte entre os dois é gigantesca. Então, por via das dúvidas, sugiro que os requisitos funcionais detalhados, cobrindo essa camada fiscal, sejam revisados e assinados por ambos os líderes de área , Fiscal e TI , antes mesmo de o desenvolvimento começar. Isso força um alinhamento profundo no escopo inicial.

No meu papel como consultor de MM, vivenciei essa tensão entre o que o negócio exige e o que o sistema comporta. Muitas vezes, a causa raiz não é um erro de digitação, mas sim uma premissa incorreta no desenho inicial do processo. Quando isso ocorre, a equipe de TI precisa aceitar que o conhecimento do negócio, neste caso, o tributário, é o padrão ouro. Então, um adendo, sugiro que os testes de aceitação do usuário passem a incluir cenários fiscais extremos, extrapolando o cenário "feliz" mapeado inicialmente, para validar a robustez do fluxo antes da homologação final.

Vanessa, sua menção ao fluxo de trabalho desenhado me fez refletir sobre o ponto de partida. Se o processo não considerou a tributação desde o início, isso sugere uma falha mais estrutural do que mero ajuste. Na homologação, pois é, como garantimos que o conhecimento fiscal complexo, que já existe, seja completamente traduzido em regras que o sistema possa executar sem margem para interpretação dúbia?

A responsabilidade pela divergência fiscal, quando instalada no ERP, é inerentemente compartilhada, mas a origem da inconsistência deve ser mapeada. Colocando no papel, ó, a área fiscal detém o conhecimento a fundo sobre o correto tributo a recolher, e cabe a TI garantir que o sistema espelhe esse entendimento. Se o sistema não reflete o conhecimento tributário vigente, o fluxo de dados necessita de correção na parametrização. A transição para novas funcionalidades exige essa simbiose entre o negócio e a tecnologia para que o resultado apurado seja o esperado.

Vanessa Barbosa: Renata e Patrícia tocam em pontos cruciais sobre a simbiose entre as áreas. Minha vivência na indústria química com o GUEPARDO Tax reforça que, embora o conhecimento tributário seja da fiscal, cabe à TI entregar o ambiente correto para que esse conhecimento seja processado. Se o fluxo de trabalho não foi desenhado considerando o básico, ó, qualquer ajuste fino posterior será paliativo. A documentação do processo como ele deveria rodar no sistema precisa ser conjunta e não apenas uma entrega unilateral de cada setor.