Rejeição 905: complete a fatura quando o XML contém dados de cobrança

A NF-e foi preparada com dados de cobrança, mas retorna “Rejeição: Campos do grupo Fatura não informados”. No código 905 da autorização da NF-e modelo 55, a presença do grupo cobr exige número da fatura, valor original e valor líquido. A empresa precisa descobrir qual desses dados faltou no XML e completar a informação verdadeira na origem.

Isso não significa que toda nota deva ganhar uma fatura artificial. A exigência é condicionada ao grupo informado. Na base documental utilizada, vDesc não integra a lista dos três campos; não invente desconto para completar a fatura.

Quando a regra se aplica

No MOC 7.0, Anexo I, página 125, a Y01-20 trata da autorização de NF-e modelo 55. Quando cobr está informado, nFat, vOrig e vLiq devem ser informados. A linha é obrigatória, sem exceção estadual expressa; a página 152 resume a mensagem. A conferência de 15/10/2026 utiliza o MOC novamente obtido, a NT 2016.002 v1.61 e o pacote XML 010f. Manual e leiaute XML 4.00 possuem versões distintas.

Há uma diferença entre estrutura e validação. O leiaute descreve campos opcionais dentro do grupo de fatura, mas a regra de negócio estabelece condições adicionais quando a cobrança é enviada. Por isso, conseguir montar ou validar a estrutura do XML não garante que o documento cumpriu a Y01-20.

A NT 2016.002 v1.61, de setembro de 2018, página 4, retirou vDesc da Y01-20 e permitiu valores zero no schema da fatura. No pacote XML 010f, os valores da fatura usam TDec_1302 e os três campos aparecem estruturalmente opcionais; a Y01-20 estabelece a exigência de negócio. Nessa base, os três dados exigidos são número, original e líquido. Se houver desconto verdadeiro, represente-o corretamente e confira as regras próprias; a ausência de desconto não exige inventar uma dedução.

O MOC conserva a observação de produção a partir de 03/09/2018. A NT 1.61 descreve mudanças já implementadas à época. Essas referências históricas não comprovam a execução individual por UF, autorizador e ambiente. Registre esses dados do caso antes de aplicar a orientação.

Antes de completar, confira o modelo e o formato

No MOC, a NFC-e modelo 65 não admite cobr pela Y01-10. Na NT 2026.002 v1.11, página 19, essa vedação alcança a NF-e com DANFE Simplificado Tipo 2, tpImp=6, código 760. Nesses documentos, o diagnóstico não consiste em completar fatura proibida. Confira o formato permitido e a geração indevida do grupo, sem mudar fatos fiscais para obter autorização.

Para a NF-e 55 no contexto permitido de cobrança, confirme que o retorno veio do serviço de autorização e contém a mensagem de campos da fatura. Produção e homologação são independentes; um teste não regulariza uma emissão real. Se a mensagem ou o documento forem diferentes, o número isolado não basta para aplicar este procedimento.

O cronograma documental dessa NT, página 3, inclui a Y01-10 no conjunto original com testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 abrange I08-180, BA02-35 e VC02-40, sem incluir a Y01-10. São datas documentais, distintas da referência de 2018 da Y01-20; não comprovam execução individual na UF.

Como identificar o dado ausente

Peça o XML efetivamente enviado, o retorno e a identificação da nota. Dentro de cobr, procure o grupo fat e os três elementos: nFat, identificador da fatura; vOrig, valor original; e vLiq, valor líquido. A fatura e suas parcelas são partes relacionadas da cobrança, mas não são o mesmo grupo. Informar duplicatas em dup não substitui os dados de fat.

Compare o arquivo com a fatura comercial ou o registro correspondente no financeiro. Pode haver um número visível na tela e nenhum nFat transmitido. Pode haver parcelas completas, mas ausência de todo o grupo fat. Um documento criado antes de atualizar o pedido pode carregar informação incompleta mesmo após o cadastro ter sido corrigido.

Não preencha nFat com qualquer texto apenas para satisfazer a presença do campo. Use o identificador adotado para aquela cobrança, de acordo com a organização real da empresa. Não há nesta regra uma obrigação de tornar o número da fatura igual ao número da NF-e. O importante é transmitir o dado correto e manter a rastreabilidade.

A cobrança tem parcelas, mas não tem fatura

Se dup foi montado e fat ficou ausente, confira o processo que gerou o XML. Complete os dados da fatura correspondente e revise a relação com as parcelas. Quando a origem estiver correta, o suporte deve ajustar o mapeamento ou a montagem do arquivo, preservando o registro anterior para comparação.

Faltou original ou líquido

Recupere a composição comercial e envie os dois valores verdadeiros. Quando original e líquido estão informados, a Y06-10, código 902, compara líquido com original menos desconto. Essa conta é distinta da presença dos campos da 905. Não copie automaticamente o total da nota para ambos sem confirmar que representam a fatura.

O grupo foi incluído sem corresponder à operação

Investigue por que uma configuração ou integração gerou cobr. Sua retirada somente é adequada se a análise confirmar que o grupo não corresponde ao documento e à cobrança que devem ser informados. Excluir informações reais para desaparecer o 905 não é correção. Havendo dúvida, envolva o responsável fiscal antes de regenerar a nota.

A nota não tem desconto

Não crie desconto fictício. A ausência de vDesc não integra a lista da Y01-20 na regra consultada. Zero numérico permitido no tipo da fatura não substitui campo ausente nem autoriza alterar valor comercial. Confira o schema aplicável e a operação. Se os três dados estão presentes e a rejeição persiste, preserve o arquivo e peça análise técnica.

Atenção a guias de versões anteriores

Alguns tutoriais ainda exigem vDesc mesmo sem desconto ou indicam desativar a geração de cobrança. A lista da Y01-20 no MOC e a alteração expressa da NT 2016.002 v1.61 exigem número, original e líquido. Não transforme comentários antigos de suporte em uma exigência atual por UF. Se o retorno divergir dessa regra, envie as evidências ao suporte, em vez de inventar desconto ou excluir dados comerciais verdadeiros.

Exemplo de diagnóstico

Uma oficina fictícia fatura R$ 760,00, sem desconto, com cobrança em duas parcelas de R$ 380,00. A integração envia as parcelas, mas omite o número da fatura e o valor líquido. O financeiro preserva a fatura OF-2026-184 com os dados completos; o problema está na transformação para XML.

A equipe corrige essa transformação, enviando nFat correspondente à fatura, vOrig de R$ 760,00 e vLiq de R$ 760,00. Confere as duas parcelas e seus vencimentos reais. Não muda cliente, tributos ou condições negociadas. Esse exemplo não estabelece um padrão universal de número da fatura nem de parcelamento.

Verifique o resultado antes de encerrar

Gere novamente o XML pelo emissor, incluindo assinatura nova quando houver alteração de conteúdo. Confira os três campos no arquivo final, a conta do líquido e a soma das parcelas quando existentes. Não edite manualmente XML já assinado nem considere uma tela preenchida suficiente para comprovar o envio.

Depois de retransmitir, examine o retorno da chave correta. Uma nova rejeição precisa de diagnóstico próprio; a ausência do 905 não significa autorização. Quando houver autorização, preserve XML e protocolo e confira o vínculo com a venda e com a cobrança interna.

Escalone ao suporte se houver perda de campos, origem divergente ou retorno incompatível com o arquivo enviado. Envolva o responsável fiscal quando não estiver claro se cobr deve existir ou como a fatura representa a operação. Para investigação com o autorizador, reúna XML, mensagem, horário, UF, ambiente e versão do emissor. Evite reenvios sucessivos de um arquivo ainda incompleto.

Fontes

Conferência documental em 15/10/2026. Sem emissão de teste ou validação operacional do ALRA.

• MOC 7.0, Anexo I, páginas 61 e 125: campos e regras de cobrança. NT 2016.002 v1.61, páginas 4–5 e 64: alterações e comparação histórica.

• Esquemas XML do Portal Nacional, pacote 010f: estrutura de fat e tipos monetários.

• NT 2026.002 v1.11, páginas 3 e 19: calendário e Y01-10/760.

• Apoios específicos: Oobj, TecnoSpeed, TOTVS Protheus. Menus, componentes e exemplos desses produtos não representam procedimentos comprovados do ALRA.