Como funciona legislação do IRPJ e da CSLL no SAP?

Veja, a fonte é, o risco que já vi é o lançamento em moeda local ser recalculado num relatório à parte, sem reconciliação. Para complementar o que a Sandra Pereira colocou, a camada de relatório precisa usar a mesma taxa do fechamento, senão o cálculo da base diverge. Um ponto novo e útil é guardar a taxa usada em cada lançamento, para o teste de auditoria refazer a conta sem depender de memória. Assim você separa erro de data de erro de conversão.

Concordo em parte com o Wagner Correia: a data certa é o ponto de partida. Discordo que isso resolva tudo: quando as companhias do grupo operam em moedas diferentes, cada compensação de prejuízo muda o resultado. Na homologação, tá, a dúvida é esta: a taxa fixada vale para todas as compensações do período ou só para o saldo final? Preciso dessa resposta para montar o teste com um caso de cada moeda.

Será que dá para resolver sem mexer na moeda? A dúvida é, ó, se o caminho certo é conversão na origem ou na camada de relatório, mas os sistemas autorizados pela área fiscal mudam a resposta. Nossa equipe mantém o lançamento em moeda local e aplica a regra só no relatório, o que facilita a auditoria. Esse caminho vale quando o beneficiário dos benefícios não depende do valor convertido. Quando o incentivo sai da receita em moeda forte, vale a conversão na origem, mesmo com mais trabalho.

Na minha rotina de farma, o IRPJ só fecha quando a conversão usa a mesma data nos dois lados, e foi isso que me travou com a moeda estrangeira. Olha, vale registrar: a regra pode estar certa e mesmo assim o saldo chegar diferente, porque a parte fiscal lê a data do documento e a contábil lê a data do pagamento. Os valores apurados só batem quando as duas leituras seguem o mesmo critério. Por isso, fixamos a taxa de fechamento e registramos a diferença na mesma data de apuração.