Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Identificação

refCTe na NF-e: conferir a chave do CT-e e diagnosticar rejeições

<refCTe>ide › NFref › refCTe

Revisão editorial em 27 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

refCTe identifica um Conhecimento de Transporte Eletrônico anteriormente emitido, relacionado à NF-e atual. A informação é a chave de acesso do CT-e, com 44 posições, dentro de uma ocorrência de ide/NFref. Ela não é o número do conhecimento, o protocolo de autorização ou a chave da própria NF-e. MOC, BA19, p. 12

O XPath completo é /nfeProc/NFe/infNFe/ide/NFref/refCTe, no namespace http://www.portalfiscal.inf.br/nfe. A referência documenta um vínculo; não comprova pagamento do frete nem estabelece crédito ou responsabilidade tributária.

Nesta página: origem, composição, modelo, rejeições, XML e conferência.

A origem é o CT-e do transporte

A fonte preferencial de conferência é o XML autorizado do CT-e ou a consulta oficial do conhecimento identificado. O DACTE, documento auxiliar do CT-e, também apresenta a chave, mas a cópia digitada precisa ser comparada com o documento eletrônico para evitar troca ou perda de caracteres.

Confira se o transporte corresponde à operação da NF-e que está sendo emitida: documento e emitente do CT-e, partes envolvidas e vínculo com a mercadoria. A presença de uma transportadora no cadastro ou na nota não permite deduzir uma chave de CT-e. Um documento de transporte ainda não emitido não fornece uma chave anterior a ser inventada.

A definição de quando a operação exige essa referência, como a prestação é documentada e quem suporta o frete depende dos documentos e parâmetros da operação. O artigo explica a identificação técnica depois de confirmado esse vínculo.

Leia a chave por partes

A chave de acesso tem esta composição, da esquerda para a direita:

Posições Informação Tamanho
1–2 Código da UF do emitente do CT-e 2
3–6 Ano e mês de emissão, AAMM 4
7–20 Identificação do emitente na área de CNPJ 14
21–22 Modelo documental 2
23–25 Série 3
26–34 Número do documento 9
35 Forma de emissão 1
36–43 Código numérico 8
44 Dígito verificador da chave 1

Essa composição é documentada na NT Conjunta DFe 2025.001, seção 5. A chave deve ser tratada como texto: a conversão para número pode perder zeros e precisão. Não coloque espaços, pontuação, o prefixo de um atributo Id ou apenas a parte numérica do conhecimento. NT Conjunta, pp. 8–9

O tipo compartilhado TChNFe aceita o padrão [0-9]{6}[0-9A-Z]{12}[0-9]{26}. As letras maiúsculas são admitidas nas primeiras 12 posições da área do CNPJ; os dígitos verificadores do CNPJ e as outras partes continuam numéricos. A NT 2026.004 mudou BA19 de numérico para caracteres e registra o cronograma de produção do schema em 01/07/2026. Não aplique um filtro que remova letras de uma chave alfanumérica verdadeira. NT 2026.004, pp. 3 e 5 Schema, TChNFe

Exemplo de leitura e DV

Considere esta chave sintética, sem documento real ou autorização:

35 | 2508 | 12345678000195 | 57 | 001 | 000001234 | 1 | 87654321 | 3

Ela representa UF 35, agosto de 2025, identificador sintético do emitente, modelo 57, série 1 e número 1234. A série e o número têm preenchimento posicional na chave: 001 e 000001234. Isso é diferente de campos individuais que podem ter outra representação.

Para conferir o último dígito, o módulo 11 usa as 43 posições anteriores, com pesos de 2 a 9 repetidos da direita para a esquerda. No exemplo numérico, a soma é 789, o resto da divisão por 11 é 8, e o DV é 11 − 8 = 3. Restos 0 ou 1 resultam em DV 0. No cálculo alfanumérico, cada caractere usa seu código ASCII menos 48, mantendo os pesos por posição. NT Conjunta, seção 5 e Anexo II

Um DV coerente demonstra uma conferência matemática da chave. Não demonstra que o CT-e existe, está autorizado ou corresponde ao transporte da nota.

O nome do tipo não muda o modelo do documento

Embora o XSD chame o tipo de TChNFe, o campo estudado é refCTe. O MOC, BA19-34, verifica modelo 57 e prevê 679 quando o modelo da chave é diferente. Não conclua que uma chave de NF-e 55 serve nesse campo por compartilhar o mesmo tamanho.

A comparação necessária é:

  • refCTe: chave do CT-e modelo 57, sob a regra documentada.
  • refNFe: alternativa distinta de NFref, com regras próprias para documento eletrônico referenciado.
  • CT-e OS, modelo 67: é outro modelo; não satisfaz a condição de modelo 57 da BA19-34.

Não altere as posições 21–22 para fazer uma chave de outro modelo parecer um CT-e 57. O dado deve ser obtido do documento correto, preservando sua identidade. MOC, BA19-34, p. 81

O retorno indica qual parte comparar

As BA19 do MOC são indicadas como facultativas para a NF-e modelo 55; sua aplicação depende do autorizador. Essa característica não é permissão para enviar dados inválidos.

Retorno e regra Condição documentada Evidência a conferir
547 — BA19-10 DV da chave inválido Chave completa do XML original e último caractere
522 — BA19-14 UF inválida na chave Primeiras duas posições e UF do CT-e
524 — BA19-20/24 Ano menor que 06 ou maior que o ano corrente; mês fora de 01–12 Posições 3–6 e emissão do documento
552 — BA19-30 CNPJ zerado ou DV inválido Área de identificação e CNPJ original; método compatível com alfanumérico
679 — BA19-34 Modelo diferente de 57 Posições 21–22 e espécie do documento
683 — BA19-40 Número do documento zerado Posições 26–34 e número original
680 — BA19-44 Mesma chave de CT-e repetida na NF-e Todas as ocorrências NFref/refCTe

A regra de ano apresentada no MOC não é a janela de 20 anos dos antigos campos refNF/AAMM e refNFP/AAMM. Não transfira esse limite entre documentos. O marcador nOcor no retorno ajuda a identificar a ocorrência apontada; confira a ordem das referências efetivamente geradas. MOC, pp. 80–81

Se uma chave foi copiada com erro, a correção é obter novamente a chave do CT-e e corrigir a origem de geração da referência. Não recalcular um DV para legitimar uma chave digitada que pode identificar outro documento.

Um exemplo de refCTe no cabeçalho

Fragmento parcial e sintético, somente para leitura do campo, sem nota completa, assinatura ou autorização:

<NFref xmlns="http://www.portalfiscal.inf.br/nfe">
  <refCTe>35250812345678000195570010000012341876543213</refCTe>
</NFref>

O conteúdo é a chave sintética decomposta acima. NFref ocupa uma posição no cabeçalho ide. Se outro CT-e verdadeiro também precisar ser referenciado nas condições da operação, ele ocupará outra ocorrência NFref.

Repetir essa mesma chave em dois grupos não identifica dois transportes: configura o cenário de duplicidade da BA19-44. Também não se coloca refNFe junto de refCTe dentro da mesma ocorrência, pois são alternativas exclusivas no schema. Schema, NFref MOC, BA19-44

Conferência final do vínculo e do ambiente

A NFC-e e a NF-e com DANFE Simplificado Tipo 2 (tpImp=6) não podem conter NFref, pela BA01-10/708. Essa restrição do grupo pai alcança uma referência a CT-e, mesmo que a chave esteja correta. NT 2026.002, pp. 3 e 9

A NT 2026.002 prevê, para 05/10/2026 em produção, vedações específicas de refNF, refNFP e refECF. Essas mudanças não devem ser transportadas automaticamente para refCTe: cada alternativa precisa ser confrontada com sua regra. O marco é futuro na data de corte de 26/09/2026. NT 2026.002, pp. 3 e 9–11

Para concluir o diagnóstico, conserve modelo, UF, ambiente, data do retorno, chave do CT-e original, XML gerado e código/motivo exatos. Compare o documento original com a ocorrência apontada, depois valide formato, DV, modelo e ausência de duplicidade no gerador. A validade no schema é uma etapa; autorização e vínculo real são verificações diferentes.

Se faltar o CT-e correto ou houver dúvida sobre a necessidade da referência, reúna os documentos da prestação e da mercadoria para confirmar esse ponto específico com o responsável contábil. Não invente chave, não troque modelo e não edite um XML fiscal já assinado ou autorizado.

A página NFref — documentos referenciados explica as demais alternativas e as restrições do cabeçalho.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/ide/NFref/refCTe
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
TChNFe · string
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

maxLength
44
pattern
[0-9]{6}[0-9A-Z]{12}[0-9]{26}
whiteSpace
preserve