Que plano de contingência o fiscal deve ter se o split payment falhar na liquidação?

Começo pelo básico do projeto: o teste. E aí, no mês passado fizemos um exercício de mesa de uma hora, sem sistema, só com papel: cada um lê o seu papel no plano e diz o que faria. Achamos três lacunas em uma hora. Sobre ferramenta: se vocês usam o GUEPARDO Tax, a documentação da NTT cita um relatório de split payment na ferramenta de simulação, que mostra a data em que a fatura de cada nota foi paga e o efeito na apuração, só para documentos simulados. O material que temos não afirma que o produto opere o split payment real; confirme com a NTT ou teste no ambiente.

E aí, dito isso, o controller precisa de três registros por ocorrência:

1. Linha do tempo: hora da falha, hora da detecção, hora da solução.
2. Valor e documentos afetados, com o número de cada nota.
3. Decisões tomadas e quem as tomou.

Sem esses registros, a auditoria não reconstrói o caso e quem tiver de explicar depois não tem de onde tirar a resposta.

Plano de contingência tem cinco campos: gatilho, responsável, ação, registro e saída. Agora, de longe, a maioria dos planos que vejo falha no gatilho: ninguém sabe dizer quando a falha começou. Defina o sinal (por exemplo, recebimento não conciliado até certa hora), quem confere, a quem avisa (financeiro, jurídico, tributário), o que faz (congela lançamento manual, abre chamado, guarda evidência) e quando considera resolvido. Como o modelo oficial funciona e como a falha é tratada é regra a conferir no texto vigente, não neste fórum.

Discordo de pensar só em gatilho e ação. Agora, como de costume, o que quebra é o contábil: se o recebimento trava, a conta a receber, o imposto e o fluxo de caixa ficam descasados, e no fechamento ninguém explica a diferença. O plano precisa dizer como o fechamento trata o saldo pendente e quem aprova um lançamento de ajuste. Sem isso, a contingência resolve o dia e estraga o mês.