xJust na NF-e: justificativa da contingência e rejeições 556/557

xJust registra o motivo da entrada em contingência. Na identificação da NF-e ou NFC-e, ela acompanha dhCont, a data e hora dessa entrada. É um texto de 15 a 256 caracteres, localizado em /nfeProc/NFe/infNFe/ide/xJust.

A justificativa explica a ocorrência real; não concede, por si só, permissão para usar uma modalidade de contingência. Também não é a justificativa de um evento de cancelamento ou de outro procedimento.

Quando o par dhCont e xJust aparece

No XSD, dhCont e xJust formam uma sequência opcional dentro de ide. Quando a sequência está presente, ambos são obrigatórios, nessa ordem, uma vez cada. Assim, a indicação “1–1” de xJust não significa que todas as notas precisem da justificativa: ela vale dentro da sequência.

As regras B28-10 e B28-20 do MOC 7.0, Anexo I, p. 78 definem:

Não converta essa lista em “qualquer tipo diferente de 1 exige justificativa”. As regras têm gatilhos específicos. A escolha e disponibilidade da modalidade precisam ser verificadas no procedimento fiscal aplicável.

A NT 2026.002 v1.10a, pp. 7–8 descreve tpEmis=9 para NFC-e e NF-e com DANFE Simplificado Tipo 2. Para modelo 55 em contingência off-line, B22-10 exige tpImp=6, retorno 711; essa alteração tem produção prevista em 03/08/2026. Um texto válido em xJust não transforma qualquer NF-e modelo 55 em operação autorizada nessa modalidade.

Texto da causa real, com 15 a 256 caracteres

A origem é o registro do problema que motivou a entrada em contingência: a ocorrência identificada pelo emissor e seu momento. Convém que o texto permita reconhecer essa causa sem expor senhas, tokens ou detalhes pessoais desnecessários. Não use uma descrição de falha que não ocorreu.

O tipo TString preserva espaços e restringe os caracteres. Além do tamanho, o padrão não admite espaços nas extremidades ou caracteres de controle como tabulação/quebra de linha. Espaços entre palavras pertencem ao texto; preencher o mínimo com espaços não resolve uma justificativa curta.

Por exemplo, “Sem internet” tem 12 caracteres e não atinge 15. Se o fato real tiver sido uma indisponibilidade de conexão, a descrição deve ser desenvolvida de forma fiel à ocorrência. Não se deve inventar uma falha ou copiar indiscriminadamente uma mensagem de exemplo para atingir o tamanho.

Fragmento sintético e parcial, assumindo uma ocorrência de contingência previamente caracterizada:

<ide xmlns="http://www.portalfiscal.inf.br/nfe">
  <!-- Demais campos e sequência da identificação omitidos -->
  <dhCont>2026-09-26T10:00:00-03:00</dhCont>
  <xJust>Indisponibilidade de conexão registrada no início da contingência</xJust>
</ide>

O exemplo mostra o par e a data/hora com fuso. A descrição possui tamanho compatível com o intervalo e deve corresponder a um fato real quando usada em documento efetivo. O tipo de emissão e os demais elementos estão omitidos; não é uma nota pronta para transmissão nem instrução para emitir em contingência.

Para conferir o XML, leia o valor efetivamente serializado entre as tags. Compare-o com o registro da ocorrência e conte caracteres do texto resultante, sem contar <xJust> ou o nome das tags. Se houver & no conteúdo, sua representação XML exige escape &; isso é codificação do mesmo texto, não uma mudança de causa.

Diagnóstico pela presença e pelo conteúdo

Uma falha de schema por comprimento ou sequência não é o mesmo diagnóstico de uma rejeição de regra:

1. 556: confira se tpEmis=1 e o emissor deixou dhCont ou xJust de uma configuração anterior. Verifique a modalidade realmente documentada e a origem da geração dos campos. Não mude o tipo de emissão só para manter a justificativa.
2. 557: confira tpEmis=2,4,5,9 e os dois campos. A presença apenas de texto ou apenas de data não completa o par. Compare o registro da ocorrência com os dados que o emissor recebeu.
3. Falha estrutural: verifique tamanho, caracteres de controle, sequência e namespace http://www.portalfiscal.inf.br/nfe. Uma justificativa visível na tela pode não ter sido incluída no XML ou pode ter sido serializada em outro lugar.
4. 558: o problema é a data/hora de dhCont, posterior à recepção pela SEFAZ na regra B28-30. O MOC prevê tolerância de até cinco minutos por sincronismo de relógios, numa validação facultativa. Isso não é um prazo para emitir nem uma autorização para alterar a hora real.

A correção deve ocorrer na origem comprovadamente divergente: registro da ocorrência, estado do emissor, mapeamento ou serialização. Depois, confira o XML novamente antes da etapa operacional cabível. Não edite documento assinado, não fabrique uma data e não use uma justificativa para contornar um retorno sem saber se a nota já foi autorizada.

A decisão de usar contingência exige o procedimento e as condições da modalidade para a empresa e a UF. Para a conferência técnica, reúna tipo de emissão, modelo, registro da falha, horário real, XML gerado e mensagem integral. Esses dados permitem separar ausência de campo, texto inválido e problema temporal.

Veja também dhCont — data e hora de entrada em contingência.