Como organizar a memória das decisões fiscais tomadas na implantação do GUEPARDO Tax?

Respondendo à Cristina: entram, mas com um campo a mais. Veja, digamos assim, a extensão própria em torno do fiscal é a parte que mais quebra na atualização, e a regra de decisão é parametrização antes de desenvolvimento. Registre por que não deu para resolver só com parametrização, e o que a extensão assume do produto.

É julgamento de consultoria a partir de notas de projeto, não medição. Mesmo assim, é a pergunta que mais custa depois: por que isso é Z?

Completando com um modelo que já vi funcionar. O combinado é, viu, registrar a decisão por obrigação, com três saídas possíveis: manter, substituir ou não replicar. Na migração de ECC para S/4HANA isso evita a discussão de "por que isso sumiu".

Detalhe importante: a lista oficial de obrigações encerradas eu não li, então essa coluna do registro deve citar a fonte que o cliente usou. Não tome a lista de ninguém como certa sem conferir.

Um palpite que funciona: um registro curto por decisão, com cinco campos. O que foi decidido, quem decidiu, data, a regra ou obrigação a que se liga e onde está a evidência. Agora, um palpite sobre ordem: comece pelas decisões que mais geram pergunta no fechamento, não pelas mais antigas.

O que dá sustentação é o desenho que a documentação de governança descreve: dono por regra, dossiê com data e vínculo com a regra.

Discordo de um ponto: o registro não pode ficar só com a consultoria. Então, pelo meu histórico, a decisão fiscal precisa de duas assinaturas separadas: a de quem configurou e a de quem valida. Quem valida é o cliente, e o teste técnico da consultoria não prova que a apuração do mês está certa. Se a ata mistura as duas coisas, daqui a dois anos ninguém sabe quem decidiu o quê.

No seu registro, separe o campo "configurado por" do campo "validado por".