Quem deve ser o responsável por ferramentas fiscais dentro da empresa?

Eu entendo o raciocínio sobre a separação entre análise e execução, mas acho que simplificar demais a cadeia de custódia gera vulnerabilidades. Se a operação apenas executa o que foi parametrizado, e há um erro de concepção no favor, quem assume o risco tributário? Como se diz, pois é, a responsabilidade final é sempre de quem chancela a aplicação da regra, mesmo que seja o time que fez o lançamento no sistema.

Nós mapeamos um protocolo distinto para esses momentos. Se a variação documental for decorrente da interpretação da norma, cabe à área técnica revisar a aplicação do conceito legal. Todavia, se o erro estiver na parametrização ou na entrada dos dados no sistema, o time que operou o lançamento assume a responsabilidade imediata pela correção. Agora, aqui na empresa, equilibramos isso: a análise tributária chancela a regra, e a operação garante a fiel execução dessa regra no software.

Carolina, pensando na sua questão sobre a correção de inconsistências após a aplicação de um favor, eu gostaria de complementar. Quando o sistema aponta um erro, precisamos definir quem é o guardião da informação. Se o favor concede condições individuais, como prazos e garantias, qualquer divergência precisa voltar ao ponto de origem. Então, sem rodeio, o responsável pela informação contida no favor, seja a análise tributária ou a parametrização, deve ser o primeiro a endereçar a falha antes de qualquer lançamento ser considerado definitivo.

Bianca, sua menção à validação fiscal dos pontos sensíveis é muito coerente com nossa vivência. Dado que lidamos com o GUEPARDO Tax e a dinâmica de um favor individual, onde há tributos a que se aplica e condições da concessão, surge minha dúvida. Quando o sistema apresenta um log indicando uma inconsistência após a aplicação de um favor, o plano é, né, quem assume a correção nesse cenário?

Olhando o XML, viu, kleber, sua questão sobre a formalização da alocação diante de variações tributárias é muito pertinente. No nosso cenário, ao tentarmos conciliar o que está estabelecido em lei com a execução no sistema, surge a necessidade de um ponto de controle robusto. Olhando o XML, vimos que a documentação precisa ser muito clara sobre os tributos a que se aplica e as condições da concessão, especialmente quando há um favor individual por trás.

Paulo, sua observação sobre o mapeamento do conhecimento técnico para a aplicação tributária é pertinente. Seguindo sua linha de raciocínio, e aí, a dúvida é: como vocês formalizaram essa alocação de responsabilidades no dia a dia, quando surgem variações inesperadas sobre os tributos ou as condições dessa concessão, sem que isso gere retrabalho ou insegurança jurídica para a operação?

A responsabilidade pelas ferramentas fiscais deve ser estruturada de acordo com o escopo operacional e o conhecimento técnico necessário para cada aplicação. Eu, com minha vivência em fiscalização e migrando para o ECC 6.0, vejo que a gestão desses detalhes é complexa. É preciso mapear precisamente quais tributos se aplicam e quais são as condições da concessão, como se trata de um favor concedido. E aí, olhando o número, a documentação e o acesso precisam estar alinhados ao contribuinte.

Na minha experiência com S/4HANA 2023, chegamos a um ponto em que a dispersão de tarefas era o gargalo. Para mitigar isso, criamos um fluxo onde o time fiscal se torna o ponto focal para validações de maior risco, enquanto a área de negócio executa a operação rotineira. Isso funciona melhor quando as questões são muito específicas, como o prazo de duração de um favor ou os tributos que estão sendo considerados. Já adianto, tá, que essa divisão depende muito da maturidade interna.