Rejeição 556: dados de contingência em uma emissão normal

A rejeição 556 aparece quando a nota informa emissão normal, mas leva dados de entrada em contingência no XML. Se a operação realmente deve seguir pelo fluxo normal, a correção é retirar os campos próprios de contingência da geração do documento. Antes, confirme como aquela nota nasceu: uma nota já emitida em contingência não deve ser convertida automaticamente só porque a conexão voltou.

Para a empresa, o risco é uma fila de vendas permanecer parada por uma configuração que não foi encerrada corretamente. O problema também pode ocorrer em apenas uma nota, quando o emissor reaproveita informações de um documento anterior. O diagnóstico começa pelo arquivo transmitido, não apenas pela opção exibida na tela.

O que a SEFAZ está comparando

A regra B28-10 do MOC 7.0, Anexo I, página 78 relaciona três campos do grupo ide:

• tpEmis identifica o tipo de emissão; o valor 1 corresponde à emissão normal;

• dhCont registra a data e a hora de entrada em contingência;

• xJust contém a justificativa dessa entrada.

Quando tpEmis=1, dhCont e xJust não devem ser informados. Embora a mensagem destaque a justificativa, confira os dois campos. Remover somente o texto e manter a data não deixa o documento coerente com a regra.

A validação está documentada como obrigatória para NF-e, modelo 55, e NFC-e, modelo 65, no serviço de autorização. Isso não significa que todas as modalidades de contingência sejam permitidas nos dois modelos. Também não é uma regra sobre justificativas de cancelamento ou outros eventos, que possuem campos e condições próprios.

Por que isso acontece depois de uma indisponibilidade

Imagine uma loja fictícia que enfrentou uma falha de comunicação. Após a recuperação, o sistema voltou a preparar novas notas como emissão normal. Entretanto, continuou preenchendo, nessas novas notas, a justificativa e o horário da falha anterior.

A venda atual pode estar correta, mas sua identificação mistura dois estados incompatíveis. Esse tipo de resíduo é descrito na documentação da TecnoSpeed. O fornecedor chama atenção para integrações que mantêm os campos no arquivo de entrada mesmo depois de voltar ao modo normal.

Outra hipótese é a nota ter sido efetivamente emitida em contingência, e um processo de retransmissão ter trocado seu tpEmis para 1. Nesse caso, apagar dhCont e xJust pode esconder o erro de origem. É necessário recuperar a modalidade correta, os registros da ocorrência e o tratamento previsto para aquele documento.

Um roteiro seguro para corrigir

1. Localize o retorno completo da nota e confirme cStat 556, modelo, estabelecimento, série, número e ambiente.

2. Consulte a situação da chave e reconcilie tentativas anteriores que ficaram sem resposta. Guarde XML, recibos e protocolos já existentes.

3. Compare o XML enviado com os dados atuais da tela. Veja se tpEmis=1 e se dhCont ou xJust continuam presentes.

4. Identifique se a nota é uma nova emissão normal ou um documento pendente de contingência.

5. Sendo realmente normal e ainda rejeitada, corrija o cadastro temporário, o mapeamento ou a regra que alimenta esses campos. Gere o XML novamente pelo emissor.

6. Valide e assine o arquivo pelo fluxo habitual, transmita ao autorizador correto e confira o retorno individual.

A remoção deve ocorrer na origem da geração. Editar manualmente um XML já assinado altera o conteúdo protegido pela assinatura e pode criar outro problema. Tags vazias também não são uma solução: o emissor deve omitir os campos quando eles não cabem.

O que conferir na integração

A Berga aponta configurações persistentes e retorno incompleto ao modo normal entre as causas práticas. Use isso como orientação de investigação, sem presumir que uma troca automática sempre resolve.

Peça ao suporte para conferir valores padrão por empresa, parâmetros compartilhados entre filiais, filas salvas antes da normalização e transformações entre o ERP e o componente fiscal. Uma tela pode mostrar “normal”, enquanto o componente usa uma configuração antiga. Um teste útil compara uma nota rejeitada com uma nova nota de teste no ambiente apropriado, preservando os documentos reais.

Na ajuda da Omie, a análise é encaminhada ao suporte por envolver pontos técnicos. Para tornar esse atendimento objetivo, envie o retorno e os campos envolvidos, sem compartilhar senha, arquivo de certificado ou chave privada.

Contingência não é uma opção para liberar qualquer nota

Não mude tpEmis só para fazer os campos serem aceitos. A modalidade precisa corresponder ao procedimento realmente adotado, ao modelo e às condições da UF. A indisponibilidade local de internet, por exemplo, não prova que a SVC esteja habilitada pela administração tributária.

Há ainda documentação antiga que chama tpEmis=3 de SCAN. Essa modalidade foi desativada; a NT 2021.002 passou a utilizar 3 para o regime especial Nota Fiscal Fácil. Não selecione esse valor como saída genérica para a rejeição.

Também mudou o alcance do off-line. A NT 2026.002 v1.11, páginas 3, 7 e 8 contempla tpEmis=9 na NFC-e e na NF-e com DANFE Simplificado Tipo 2, dentro das condições previstas. Isso não libera off-line para qualquer NF-e. Cronograma documental e aceitação pelo autorizador da UF precisam ser conferidos separadamente.

Como saber que a correção terminou

A nota precisa ter resposta de autorização compatível com sua chave e ambiente, e o XML autorizado deve ser arquivado com o protocolo. Uma impressão de DANFE ou a ausência de novo alerta na tela não substitui essa verificação.

Não cancele, inutilize ou crie outro número apenas por causa do 556. Primeiro determine a situação fiscal do documento e resolva eventuais tentativas anteriores. Para prevenir recorrências, separe a configuração das próximas notas do tratamento da fila que nasceu durante a contingência. Encerrar uma ocorrência não deve reescrever o histórico dos documentos pendentes.

Revisão documental por IA: 9 de outubro de 2026. Escopo: autorização de NF-e e NFC-e; disponibilidade e procedimentos dependem da UF, do modelo e do ambiente.