ERP na reforma tributária: como registrar testes e pendências

Transforme “ERP atualizado” em uma entrega verificável

O cliente informa que o sistema já recebeu a atualização de IBS e CBS. Para o escritório, falta saber quais operações foram verificadas, quais campos chegaram ao documento e o que ocorreu depois da transmissão. A mensagem do suporte pode confirmar a instalação de uma versão; o aceite da rotina exige evidências do caminho usado pela empresa.

Comece com uma unidade de trabalho delimitada: empresa e estabelecimento, regime, modelo de documento, operação, emissor e integração com os controles internos. Um teste de NF-e de venda não cobre automaticamente NFS-e, devolução, compra, emissão em outro estabelecimento ou importação para a contabilidade.

Este roteiro é uma proposta de organização dos testes pelo contador e pelos responsáveis da empresa. Não é certificação oficial de software, auditoria integral nem autorização para realizar operações reais. As decisões fiscais continuam dependendo dos fatos e das regras aplicáveis.

Leia também: Reforma tributária: como organizar as próximas ações de cada cliente

Fixe a regra e a versão antes de definir o resultado esperado

Fontes verificadas em 1º de outubro de 2026. O art. 60 da LC 214/2025 trata da emissão de documentos fiscais eletrônicos e remete a forma, o conteúdo e os prazos a ato conjunto. O Ato Conjunto RFB/CGIBS 4/2026 contém marcos e exceções por documento e situação. Por isso, a ficha de teste deve separar fundamento legal, prazo aplicável e comportamento técnico do sistema.

Na NF-e, a NT 2025.002 v1.51 consultada apresenta leiaute e regras de validação em seções distintas. Registre o campo ou a regra que o cenário verifica, além da versão da nota técnica. Se a análise depende de uma tabela de classificação, guarde também a versão dessa tabela. O número da versão do ERP não substitui nenhum desses registros.

Na NFS-e, o portal oficial mantém documentação própria para Produção Restrita, destinada a homologação e testes, além das informações de Produção. Confira o ambiente e os arquivos aplicáveis ao caminho de emissão do cliente. Não transporte para a NFS-e uma regra da NF-e apenas porque ambas informam IBS e CBS.

Quando uma norma ou versão mudar, identifique quais cenários precisam ser revistos. Preserve a referência usada no teste anterior e abra uma nova execução para o que foi afetado. Uma data de publicação de manual não deve virar, sem análise, data única de obrigação para toda a carteira.

Referência: LC 214/2025 consolidada, art. 60. Consultada em 01/10/2026. ↗

Referência: SVRS: NT 2025.002 v1.51, leiaute e regras da NF-e/NFC-e. Consultada em 01/10/2026. ↗

Referência: Portal NFS-e: documentação de homologação e testes. Consultada em 01/10/2026. ↗

Referência: Ato Conjunto RFB/CGIBS 4/2026: marcos por documento e situação. Consultado em 01/10/2026. ↗

Leia também: CST e cClassTrib: como revisar o cadastro antes de emitir a NF-e

Leia também: NFS-e e IBS/CBS: prazos e conferência por cliente

Descreva o que precisa acontecer em cada etapa

Antes de executar, escreva o resultado esperado em termos que outra pessoa possa conferir. “Emitir sem erro” é insuficiente quando o objetivo inclui classificação, valores, referências, armazenamento e envio à contabilidade. A aprovação deve responder à tarefa definida, não apenas à ausência de uma mensagem na tela.

Em 6 de agosto de 2026, Receita Federal e CGIBS esclareceram que o adiamento de determinadas validações automáticas não suspendeu as obrigações de informação segundo o cronograma aplicável. Essa distinção muda o desenho do teste: o autorizador pode aceitar um documento que ainda precisa de revisão do conteúdo.

Inclua uma condição de rejeição somente quando houver regra ativa e aplicável ao cenário e ao ambiente escolhidos. Se a validação ainda não estiver habilitada, registre essa limitação. Não classifique como falha do ERP a ausência de uma rejeição que o ambiente não está programado para executar.

• Dados de entrada: operação, partes, itens ou serviço, condições e parâmetro fiscal previamente analisado.
• Documento gerado: campos, referências e valores comparados com o resultado esperado, mantendo IBS e CBS separados.
• Retorno técnico: protocolo ou código e mensagem de resposta, com data, ambiente e relação com o arquivo enviado.
• Registro posterior: documento final recuperável e informação recebida pelo controle ou integração incluídos no escopo.
• Conclusão: comportamento encontrado, diferença observada, evidência, responsável pela correção e condição para repetir o teste.

Referência: Receita Federal e CGIBS: esclarecimento sobre validações, 06/08/2026. Consultado em 01/10/2026. ↗

Leia também: IBS e CBS em 2026: o que conferir na NF-e antes do fechamento

Exemplo: seis cenários, quatro executados e duas pendências

Considere um exemplo hipotético de uma empresa comercial. O escritório e o responsável pelo ERP selecionaram seis cenários de NF-e, incluindo o recebimento do documento no controle interno. Eles definiram os dados e resultados esperados antes de executar em homologação. Não houve emissão real nem cálculo de tributo de um cliente neste exemplo.

Os seis casos abaixo representam um recorte didático, não uma lista universal de homologação. A operação efetiva, o enquadramento e as regras disponíveis determinam quais testes fazem sentido para cada empresa.

• T01, venda do cenário de referência: documento, resposta e importação conferidos; teste aprovado no escopo descrito.
• T02, venda com desconto incondicional documentado e previamente analisado pelo escritório: dados, documento e retorno conferidos; teste aprovado nesse cenário.
• T03, arquivo propositalmente incompatível com uma regra ativa do ambiente: rejeição esperada recebida e registrada; o controle foi aprovado, embora não tenha ocorrido autorização.
• T04, documento tecnicamente aceito, mas com divergência no registro importado pelo controle interno: teste reprovado; guardar os dois arquivos e identificar o campo divergente.
• T05, cenário de devolução selecionado para teste: ainda não executado porque falta a referência necessária da operação de origem.
• T06, venda com entrega parcial selecionada na matriz: cenário independente ainda não executado porque depende de uma nova versão do ERP. O reteste da falha de T04 será registrado como outra tentativa de T04, sem criar um sétimo cenário.

Leia a cobertura sem transformar o recorte em precisão

Na primeira rodada do exemplo, quatro dos seis cenários foram executados. Três dos quatro atenderam aos critérios combinados, um apresentou falha e dois permaneceram não executados. A cobertura de execução é 4 dividido por 6, aproximadamente 66,7%. A proporção de aprovação entre os executados é 3 dividido por 4, ou 75%.

Esses percentuais descrevem somente a matriz escolhida. Não medem precisão tributária do ERP, conformidade geral da empresa, redução de risco ou prontidão de toda a operação. Informar apenas “75% aprovado” esconderia dois cenários que nem chegaram a produzir evidência.

T03 mostra por que contar notas autorizadas distorce o aceite. Uma rejeição pode ser o resultado correto de um teste de controle. T04 mostra a situação inversa: o documento foi aceito, mas o fluxo contratado continua com falha. O critério deve existir antes do resultado para evitar que qualquer retorno seja interpretado como sucesso.

Após a correção de T04, execute novamente o caso e os cenários que possam ter sido afetados pelo mesmo ajuste. Acrescente o resultado à sequência de tentativas. Não substitua o arquivo antigo por outro com o mesmo nome nem apague a primeira falha do relatório.

Leia também: Como melhorar a precisão da revisão sem esconder as pendências

Guarde uma ficha curta e os arquivos que sustentam a conclusão

Uma ficha útil permite reconstruir o teste sem depender da memória de quem estava na reunião. Use um identificador estável por cenário e numere as execuções. O relatório deve apontar para os arquivos originais e preservar a diferença entre resultado esperado e observado.

A captura de tela pode ajudar a explicar uma ocorrência, mas não substitui o documento eletrônico e a resposta que sustentam a conclusão. Se a integração transforma o arquivo recebido, conserve a entrada e a saída para localizar onde a diferença surgiu.

Mantenha o material acessível somente às pessoas autorizadas para aquela empresa. Use dados de teste conforme as regras do ambiente e não inclua senhas, certificados privados ou credenciais no relatório enviado ao suporte. A necessidade de investigar um erro não justifica compartilhar a base inteira do cliente.

• Identificação: empresa, estabelecimento, responsável, cenário e tentativa.
• Configuração: ambiente, versão do ERP, parametrização relevante, modelo e versão dos arquivos técnicos utilizados.
• Critério: fundamento, regra ou campo examinado e resultado esperado para aquela operação.
• Evidência: arquivo enviado, documento e retorno obtidos, registro de importação quando incluído no teste, data e horário.
• Decisão: aprovado, reprovado, não executado ou bloqueado por dependência, com motivo e próxima ação.
• Revisão: quem conferiu o conteúdo fiscal e quem confirmou o funcionamento técnico, sem presumir que sejam a mesma pessoa.

Leia também: Auditabilidade: como explicar uma decisão contábil meses depois

Trate indisponibilidade, dependências e produção como situações próprias

Se o serviço de homologação estiver indisponível, conserve a resposta e registre a dependência. Isso demonstra uma tentativa, mas não permite concluir que a rotina passou ou que o software está errado. Defina quem repetirá o caso quando houver condição de execução.

Se a operação depender de evento, referência ou documento ainda ausente, não fabrique a evidência. Identifique a origem que falta e mantenha o cenário fora da lista de aprovados. O mesmo cuidado vale para uma regra cuja aplicação técnica depende de implementação futura.

Antes de qualquer liberação em produção, os responsáveis devem revisar o escopo testado, as falhas abertas e o procedimento para interromper ou corrigir uma execução problemática. Essa decisão interna não dispensa uma obrigação legal nem autoriza operar com informação incorreta. Pendência relevante exige solução ou encaminhamento profissional adequado.

Acompanhe as primeiras operações reais autorizadas no escopo aprovado e confira os efeitos no destino. Um teste em homologação não comprova emissão em produção, baixa financeira, apropriação de crédito ou recolhimento. Testar o vínculo com um pagamento também não comprova a liquidação ou a disponibilidade efetiva do split payment.

Referência: Portal NFS-e: documentação de homologação e testes. Consultada em 01/10/2026. ↗

Leia também: Split payment: vínculo na NF-e não confirma pagamento

Entregue ao cliente a decisão, a pendência e o próximo passo

A comunicação final pode ser objetiva: “Executamos quatro dos seis cenários definidos. Três atenderam aos critérios, um exige correção na importação e dois não foram executados. O responsável pelo ERP entregará a correção; o escritório revisará o novo documento; a empresa confirmará o registro final.” Acrescente as datas acordadas e os links das evidências.

Divida as responsabilidades conforme o trabalho: a empresa confirma os fatos da operação; o escritório analisa o tratamento fiscal; o responsável pelo sistema demonstra a implementação; quem tem alçada decide a liberação interna. Uma troca de mensagens sem responsável e prova de conclusão mantém a pendência aberta.

A my selene pode apoiar a conversa a partir da base fiscal e analítica disponível ao contador, dentro da cobertura efetivamente habilitada. Este roteiro não comprova homologação automática de ERPs, execução de testes em sistemas de terceiros ou aprovação de enquadramento tributário pela plataforma. Confirme o escopo antes de combinar uma entrega.

Acompanhe quantidade de cenários necessários, executados, aceitos e ainda pendentes, além do esforço observado de correção e revisão. Não converta uma aprovação técnica em economia de caixa ou resultado comercial sem medir o que mudou na operação.