Rejeição 1009: informe o tipo verdadeiro da nota de débito

Se a resposta trouxe “Rejeição: Não informado tipo de nota de débito”, confira dois campos distintos: a finalidade da NF-e e o tipo de débito. Selecionar a finalidade 6 informa que o documento é uma nota de débito, mas ainda falta indicar qual situação ele representa.

O preenchimento precisa seguir a operação real e a orientação fiscal. Escolher qualquer tipo disponível pode afastar a ausência do campo e produzir um documento incorreto ou novas rejeições. Se o tipo já aparece na tela, o próximo passo é verificar se ele chegou ao XML enviado.

Qual regra está sendo tratada

Este artigo aborda o cStat 1009 na autorização da NF-e modelo 55, regra B25.1-20, NT 2025.002-RTC v1.52, página 32. A condição é finNFe=6, nota de débito, sem o campo tpNFDebito. O leiaute descreve esse tipo no grupo de identificação, página 15. Nota técnica oficial.

Registre UF, autorizador, ambiente e versão do emissor. Homologação e produção são ambientes distintos, e esta revisão não demonstra a implantação de todas as regras em cada UF. A condição analisada pertence ao modelo 55; não a estenda à NFC-e modelo 65 ou a outro serviço que utilize numeração semelhante.

Atenção à mensagem histórica de crédito e débito

Materiais antigos apresentam o número 1009 acompanhado de “Não informado tipo de nota de crédito/débito”. Esse texto não deve ser usado para reunir os dois diagnósticos atuais.

Na tabela da v1.52, a falta de tipo de débito corresponde à 1009. A falta de tipo de crédito, com finNFe=5 e ausência de tpNFCredito, corresponde à regra B25.2-20 e ao código 1164. O documento também separa o tipo de débito informado numa finalidade incompatível, 1139, do tipo de crédito informado indevidamente, 1163.

Se um sistema ainda mostra o rótulo antigo, preserve a resposta original do autorizador e confira a finalidade enviada. O suporte deve identificar se a descrição foi apenas mantida no cadastro de mensagens ou se há diferença de versão no processamento. Não altere campos de crédito quando o XML realmente descreve um débito.

O tipo explica o motivo fiscal

As opções da nota técnica abrangem situações diferentes, como transferências de créditos, anulação de crédito em saídas imunes ou isentas, débitos não processados na apuração, multa e juros, sucessão, pagamento antecipado, perda de estoque e desenquadramento do Simples Nacional.

Essa lista oferece estrutura para informar o documento; não comprova que qualquer empresa pode usar qualquer opção em qualquer momento. O enquadramento, os documentos de suporte e a regulamentação aplicável precisam ser analisados pelo responsável fiscal.

Por exemplo, tipo 06 representa pagamento antecipado, enquanto tipo 07 corresponde à perda em estoque. Uma cobrança atrasada não é automaticamente pagamento antecipado; uma diferença de inventário não se torna perda fiscal apenas porque existe essa opção. Também não confunda tpNFDebito com um código de débito usado no financeiro ou na contabilidade interna.

Por que o campo pode faltar

Um operador pode selecionar a finalidade e salvar a nota sem concluir a escolha do tipo. Em outra situação, a tela oferece o campo, mas uma integração antiga não conhece a nova informação e omite a tag.

Também pode existir incompatibilidade entre nomes internos: o cadastro guarda “tipo de débito”, mas a exportação procura outro identificador. Uma rotina de cópia pode preservar a finalidade e perder o tipo; um documento preparado antes da atualização pode manter o arquivo antigo mesmo após a edição da tela.

Identificar a origem evita repetir a mesma transmissão. Reenviar o XML inalterado não acrescenta o campo ausente.

O que conferir antes da correção

1. Guarde a resposta completa, o XML transmitido, a chave e o horário.

2. Confira modelo, finalidade e ambiente no arquivo, não apenas no cadastro.

3. Localize ide/tpNFDebito e confirme se ele está ausente ou se a tela diverge do XML.

4. Reúna os documentos que justificam o débito: a origem muda conforme o tipo.

5. Peça ao fiscal a classificação cabível e ao suporte a confirmação de que o emissor gera essa informação.

Se a finalidade 6 foi selecionada por engano, o problema antecede o campo ausente. A correção deve rever o documento como um conjunto, com a finalidade verdadeira e os demais dados coerentes.

Como resolver em cada cenário

A finalidade de débito está correta e o tipo não foi selecionado. Escolha o tipo confirmado pelo responsável fiscal, salve e regenere a nota pelo emissor. Confira o XML antes do reenvio. Não use uma opção padrão para todos os casos.

O tipo está na tela, mas não aparece no XML. Encaminhe a comparação ao suporte. Corrija o mapeamento ou a versão responsável pela exportação, incluindo o processamento do documento já preparado. Evite editar manualmente o arquivo assinado: a alteração deve passar pelo fluxo de geração e assinatura do emissor.

A finalidade está incorreta. O fiscal deve definir o documento adequado à operação. Não transforme uma venda comum em débito tributário por existir saldo a receber; nem mude um débito verdadeiro para finalidade normal apenas para dispensar o tipo.

O campo foi preenchido e surge outra rejeição. Confira a nova mensagem. A nota técnica também valida operação de saída nas notas de débito e relações entre tipo, classificação tributária e grupos de impostos. Resolver a 1009 não encerra essas verificações.

Exemplo original

Uma empresa fictícia de alimentos registra produtos inutilizados após avaria comprovada. O contador orienta o tratamento da perda e a documentação aplicável. Na preparação da NF-e de débito, o operador seleciona finalidade 6, mas deixa o tipo em branco. O envio retorna 1009.

A equipe confirma que o caso realmente corresponde ao tipo 07, perda em estoque, completa a seleção e gera novo arquivo. Depois confere o tipo, os itens e os tributos definidos pelo fiscal. Ela não copia a configuração de uma nota de pagamento antecipado apenas porque essa opção já foi utilizada em outra emissão.

Como confirmar o resultado e quando escalar

Examine a resposta do documento reenviado e preserve XML e protocolo quando houver autorização. Confira a chave, o vínculo à origem do débito e os registros internos. Não marque como autorizado apenas porque a tela deixou de mostrar 1009.

Acione o suporte para campo ausente no XML, opções indisponíveis ou divergências de versão. Procure o contador quando houver dúvida sobre o motivo do débito, o tipo cabível ou a obrigação de emitir. Se XML, versão e regra coincidem e o retorno permanece, encaminhe as evidências ao autorizador.

Fontes e revisão

Revisão documental por IA em 10/10/2026. A v1.52 foi confirmada no Portal SVRS. O aviso de implantação de 05/10 não estabelece uma nova data universal de ativação da B25.1-20.

Conferência prática: Webmania, Migrate/InvoiCy e TOTVS. O material TOTVS conserva uma descrição mais ampla de crédito/débito; a orientação atual foi separada conforme a tabela oficial. Não houve teste operacional por UF nem validação fiscal humana.