Rejeição 557: faltam dados de entrada em contingência
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 557, regra B28-20, exige data/hora e justificativa da entrada em contingência para tpEmis=2, 4, 5 ou 9. Uma justificativa na tela não basta: dhCont e xJust precisam estar corretamente representados no XML do contexto real de emissão. MOC 7.0, p. 78
Quais tipos estão nesta comparação
No leiaute, 2 identifica FS-IA; 4, EPEC; 5, FS-DA; 9, contingência offline no contexto admitido. A expressão DPEC em descrição antiga não transforma 4 em um serviço atual distinto de EPEC. tpEmis=3 representa NFF, e não o antigo SCAN. NT 2021.002 v1.12, p. 7
A lista da 557 não libera qualquer tipo para qualquer modelo. A NFC-e tem restrições próprias; a NF-e com tpEmis=9 possui a condição de DANFE Simplificado Tipo 2 na B22-10. Confira modelo, tipo e serviço antes dos dados de contingência. MOC, B22-34, NT 2026.002 v1.11, p. 8
Como representar data e justificativa
Em /NFe/infNFe/ide, dhCont usa o formato AAAA-MM-DDThh:mm:ssTZD, com fuso. xJust é texto de 15 a 256 caracteres. O tamanho é um requisito estrutural, não um convite para inventar uma frase: o motivo registrado deve ser o real.
Os dois elementos compõem uma sequência opcional no XSD, mas a B28-20 a exige no contexto. Uma sequência omitida pode passar na estrutura e falhar na regra fiscal. Enviar só um elemento ou conteúdo vazio pode causar erro estrutural antes. Leiaute e B28-20, pp. 11 e 78
Exemplo de horário perdido na integração
Cenário sintético: a modalidade de contingência é cabível e o operador registrou horário e motivo, mas a integração transfere apenas xJust. Compare os dados de origem com a sequência emitida. A falha é de geração/estrutura, não de parâmetro tributário.
Se ambos estão ausentes porque a operação nunca entrou em contingência, não fabrique horário e motivo. Investigue por que tpEmis foi gerado assim. A evidência pode apontar erro no indicador, desde que comprovado pelo fluxo real. A prova exige os registros protegidos; um XML sintético não define quando a contingência começou. B28-20
Como conferir depois da correção
Revise tipo, modelo, horário com fuso e motivo. Corrija a origem demonstrada, gere pelo emissor e confira os dois elementos. Com tpEmis=1, a 556 proíbe os mesmos dados; a 558 compara o horário de contingência com a recepção.
Preserve início real, histórico e tentativas. Não altere uma data verdadeira para obter autorização. Esclareça envio anterior incerto antes de repetir; a ausência de 557 é apenas uma etapa da validação. MOC, B28-10/20/30