Rejeição 760: separe o financeiro do grupo de cobrança no XML

Se a nota voltou com a rejeição 760, confira o grupo cobr no XML transmitido. Na NT 2026.002 v1.11, ele é incompatível com NFC-e 65 ou NF-e 55 com DANFE Simplificado Tipo 2 (tpImp=6). A correção começa identificando o modelo e o formato de DANFE realmente enviados. A existência de parcelas no financeiro da empresa, por si só, não explica o erro nem autoriza apagar contas a receber.

Este artigo trata do cStat 760 nas validações de NFeAutorizacao, indicadas na página 8 da NT. Confira cStat e xMotivo no retorno. Ele não é um aviso sobre inadimplência, valor recebido ou validade de um boleto. O problema está na estrutura fiscal transmitida, que precisa corresponder à operação e às regras do documento utilizado.

Mensagem e documentos abrangidos

A NT 2026.002 v1.11, regra Y01-10, página 19, apresenta a mensagem: “Rejeição: NFC-e ou NF-e com DANFE Simplificado Tipo 2 com dados de cobrança (Fatura, Duplicata)”. A validação verifica a presença do grupo cobr em NFC-e modelo 65 ou em NF-e modelo 55 com DANFE Simplificado Tipo 2, identificado por tpImp=6. A linha permanece íntegra na página, com aplicação obrigatória e efeito de rejeição, sem exceção particular. NT 2026.002 v1.11.

O MOC 7.0, página 125, registra Y01-10 apenas para modelo 65. A NT amplia o recorte à NF-e 55 com tpImp=6; não proíbe o grupo em toda NF-e 55. Esse DANFE não muda o modelo 55 para 65 e não se confunde com o DANFE Simplificado de tpImp=3.

O índice SVRS consultado em 15/10/2026 lista a v1.11, com rótulo de publicação de 01/10/2026 e ressalva sobre possíveis mudanças de datas. Na página 3 da NT, Y01-10 integra o conjunto previsto para testes em 01/07/2026 e produção em 03/08/2026.

O adiamento para 14/12/2026 enumera I08-180, BA02-35 e VC02-40; não inclui Y01-10. Não transfira o prazo de outra regra para essa rejeição.

A pesquisa sustenta o alcance documental, sem certificar a implantação individual por UF/autorizador. Registre o autorizador acessado, a UF emitente e o ambiente: tpAmb=1 é produção; tpAmb=2, homologação. Confira comunicados e o retorno no ambiente correto. Homologação não documenta uma venda real.

Por que a cobrança aparece onde não deveria

Uma causa possível é o reaproveitamento de uma configuração de NF-e em uma venda de balcão. O financeiro gera os vencimentos e a integração envia esses mesmos dados como fatura fiscal, sem distinguir o documento. Também pode haver cópia de uma nota anterior, importação de parcelas ou um perfil de emissão que sempre monta cobr.

O grupo pode existir mesmo quando a tela parece vazia. O operador apaga os valores, mas o gerador conserva a estrutura. Outra possibilidade é a alteração valer apenas para documentos novos, enquanto a nota rejeitada mantém o XML preparado anteriormente. Essas são hipóteses para investigação; o arquivo efetivamente enviado é que permite confirmá-las.

Separe três coisas: contas a receber no ERP, o grupo fiscal de cobrança cobr e as informações de pagamento do documento. Fatura e duplicata no XML não são sinônimos de qualquer pagamento. Retirar o grupo indevido não significa zerar o total, declarar recebimento em dinheiro ou eliminar os dados de pagamento que continuam exigidos no cenário.

O que conferir antes de alterar

Guarde o XML transmitido e a resposta completa da SEFAZ. Anote chave, número, série, horário, ambiente e versão do emissor. Confira o mod e o tpImp dentro da identificação da nota; o papel impresso ou o nome do botão podem não refletir o arquivo enviado.

Peça ao suporte que localize cobr dentro de infNFe. No MOC, páginas 61–62, e no esquema XML, fat é o grupo de fatura e dup, o de parcelas, ambos filhos de cobr. pag/detPag pertence a outro grupo. A estrutura opcional no esquema não libera seu uso quando a regra fiscal o veda. Compare com a configuração de cobrança e com a origem da venda. Não edite manualmente o XML já assinado: o emissor deve gerar e assinar novamente o conteúdo corrigido.

Antes de qualquer nova tentativa, confirme que o documento continua rejeitado. Se houver incerteza sobre um envio anterior, consulte a situação da chave. A correção de uma rejeição não justifica criar outra nota para a mesma operação sem conciliar o histórico.

Como corrigir em cada cenário

NFC-e com grupo de cobrança herdado

Se o documento é corretamente uma NFC-e e cobr foi incluído indevidamente, ajuste a origem desse grupo e regenere a nota sem ele. Preserve os registros financeiros verdadeiros da venda. Confira se a integração deixou de transportar automaticamente parcelas para fatura/duplicata fiscal e se o grupo desapareceu integralmente no novo XML.

Peça ao suporte que identifique a configuração que gera o grupo na versão instalada. A documentação fiscal não comprova uma sequência de telas ou preservação automática do financeiro no ALRA.

NF-e com DANFE Simplificado Tipo 2

Se o XML contém mod=55 e tpImp=6, não descarte o diagnóstico apenas porque a tela diz NF-e. Verifique se o grupo surgiu por herança ou se a operação realmente exige informações fiscais de fatura. No primeiro caso, corrija a geração indevida. No segundo, o responsável fiscal deve avaliar o documento e a representação cabíveis à operação real antes de autorizar qualquer mudança.

Não troque tpImp somente para fazer a validação desaparecer. Uma alteração de formato precisa ser permitida e coerente com as condições de emissão, impressão e uso daquele documento.

NF-e modelo 55 sem tpImp=6

Esse cenário não corresponde ao predicado de Y01-10 na nota técnica consultada. Confira se a resposta pertence à mesma chave e se o XML analisado é o que foi enviado. O suporte deve investigar eventual transformação posterior ou associação incorreta de retorno. Não remova cobrança legítima de todas as NF-e por causa de um código visto em outro documento.

Exemplo original e confirmação

Uma loja fictícia vende R$ 480 em três vencimentos registrados no financeiro. O caixa emite NFC-e, mas um perfil compartilhado gera cobr com fatura e duplicatas. A autorização retorna 760. A equipe confirma que a operação permanece corretamente documentada por NFC-e, corrige o perfil e gera outro XML sem o grupo indevido. Nesta ilustração, os três vencimentos permanecem no financeiro. Em um caso real, confira se a correção fiscal preservou os registros e a integração do sistema.

Depois do reenvio, leia o resultado do documento, não apenas o status do lote. Se houver autorização, confira chave, protocolo e XML correspondente. Uma nova rejeição exige seu próprio diagnóstico; eliminar 760 não garante aprovação das demais regras.

Acione o suporte se cobr reaparecer, se não houver campo editável ou se tela e XML divergem. Leve ao contador dúvidas sobre modelo, formato e necessidade fiscal de fatura. O caso estará encerrado quando o retorno oficial, o XML preservado e os registros da venda estiverem coerentes, sem duplicação de emissão ou perda do financeiro.

Fontes e limites

Pesquisa e revisão textual em 15/10/2026, horário de Brasília. Capturas oficiais desse dia e inspeções documentais anteriores desta sessão foram reutilizadas por hash. Três corpos práticos específicos foram lidos agora. Não houve teste no ALRA ou certificação individual de implantação estadual.

• MOC 7.0, Anexo I: páginas 61, 62 e 125, hierarquia de cobrança e pagamento, Y01-10 original e regras vizinhas distintas.

• NT 2026.002 v1.11: páginas 3, 7, 8 e 19. A inspeção pessoal do PNG existente da página 19, feita na revisão da 755 nesta sessão, confirma Y01-10 íntegra, 55/65 e Tipo 2; riscos de outras linhas não foram transportados. O cronograma reutiliza também inspeção anterior do PNG da página 3.

• Documentos SVRS e pacote de esquemas 010f do Portal NF-e: disponibilidade da versão, declaração completa de cobr e estrutura inicial de pag. Busca focal em seis caches de NTs: a NT 2026.010 trata de representação do DANFE e cita fatura/duplicatas; esse contexto de impressão não substitui Y01-10. Ausência literal em outros caches não prova ausência universal de alterações.

• Oobj: corpo completo HTTP 200 e WEB, datado de 19/09/2024. A presença de cobr e a retirada do grupo indevido são pertinentes. Imagens de exemplo não foram inspecionadas ou validadas.

• TecnoSpeed: corpo completo WEB, de 20/05/2025, separado da tentativa direta HTTP 403. A frase que inverte a hierarquia dos grupos foi confrontada com MOC e esquema. Campos de TX2/JSON pertencem à integração do fornecedor; o exemplo JSON chamado pagamentos não justifica apagar pag/detPag nem contas a receber. XML e valores externos não foram reutilizados ou validados.

• Webmania: corpo completo HTTP 200 e WEB, ambos com data de 28/10/2025. Orienta desativar a cobrança no produto do fornecedor; telas e parâmetros ilustrados não foram convertidos em instruções do ALRA.

Os três guias abordam NFC-e; a extensão ao modelo 55 Tipo 2 deriva da NT. Leituras atuais não autenticam consultas ou revisões antigas. Históricos preservados, revisão cruzada independente pendente e publicação não realizada.