Rejeição 263: como corrigir o CPF usado na consulta cadastral

A rejeição 263, “CPF da consulta inválido”, pede a conferência do CPF enviado como argumento de uma pesquisa cadastral. Antes de alterar a nota fiscal, identifique a rotina que retornou a mensagem. O problema pode estar na digitação, na importação de uma planilha ou na montagem do pedido de consulta, mesmo que o cadastro exibido na tela pareça correto.

O código não significa, por si só, que a pessoa esteja sem inscrição estadual ou irregular perante a Receita Federal. A validação descrita para essa rejeição é sobre o identificador apresentado à SEFAZ. Separar essas situações evita encaminhar o cliente para uma regularização que talvez nem seja necessária.

A regra e o campo envolvidos

No MOC 7.0, página 90, a regra K08 do NfeConsultaCadastro determina a verificação do dígito de controle ou de zeros quando é informado CPF. O resultado de falha é o código 263.

O CPF tratado aqui está dentro do pedido ConsCad, no grupo infCons. Não é automaticamente o CPF do emitente, do destinatário da nota nem do titular do certificado digital. Essas pessoas podem coincidir em determinada operação, mas o diagnóstico precisa acompanhar o campo que realmente foi transmitido.

A mesma seção descreve outros resultados próximos: 262 quando a UF não oferece consulta por CPF e 264 quando o contribuinte não é encontrado pela pesquisa por CPF. Cada retorno exige uma investigação própria. Depois de corrigir o CPF, examine a nova resposta sem presumir que a modalidade esteja disponível ou que o contribuinte será encontrado. Validar o número, oferecer a pesquisa e localizar uma inscrição são verificações diferentes.

Compare três versões do dado

O procedimento mais eficiente é comparar o CPF comprovado pela pessoa, o que está armazenado no cadastro e o que aparece no pedido transmitido. Se as três versões não coincidem, já existe um ponto concreto para investigar.

Em uma importação, por exemplo, uma coluna tratada como número pode perder zeros iniciais. Outra possibilidade é o sistema usar um registro antigo do parceiro, enquanto o atendente está olhando uma ficha atualizada. Essas são hipóteses de diagnóstico, não conclusões extraídas apenas do código 263.

O suporte também deve verificar se a rotina selecionou o tipo de documento correto. CPF e CNPJ possuem campos próprios. Não cabe completar um CPF com caracteres arbitrários, usar o documento de outra pessoa ou substituir a identificação só para fazer o teste passar.

Roteiro de correção

1. Separe o retorno completo, com cStat, xMotivo, data, horário e UF consultada. Identifique a operação como consulta cadastral.

2. Confira o documento com uma fonte legítima e atual. Faça isso por um canal adequado ao tratamento de dados pessoais.

3. Peça ao suporte a conferência do CPF existente no XML de consulta. Evite confiar apenas na mensagem resumida da tela.

4. Verifique zeros iniciais, caracteres indevidos, espaços e trocas de dígitos. A formatação aceita na tela e a representação enviada pelo programa podem ser diferentes.

5. Corrija a origem confirmada do erro. Se a falha estiver na importação ou integração, corrigir somente uma ficha pode deixar o problema ativo para outros registros.

6. Refaça a consulta depois do ajuste e examine a nova resposta. Guarde o resultado como evidência do que foi efetivamente resolvido.

A base prática da Berga recomenda conferir o documento e o tipo de consulta. O benefício dessa abordagem é localizar o dado que originou o pedido antes de modificar informações fiscais da operação.

Quando o CPF correto continua gerando 263

Nesse cenário, peça uma comparação controlada entre entrada, cadastro salvo e mensagem enviada. A documentação da TecnoSpeed apresenta parâmetros separados para documento, tipo e UF. Um erro na ligação entre esses parâmetros pode passar despercebido para quem apenas preenche a ficha.

A documentação do NFePHP informa que sua função não verifica a validade do conteúdo dos campos. Portanto, a existência de uma biblioteca de integração não garante que o número tenha sido conferido antes da transmissão. O comportamento específico depende da ferramenta usada pela empresa.

Se o suporte confirmar que o pedido corresponde ao documento legítimo e ao leiaute exigido, reúna os registros para atendimento da SEFAZ. Não faça uma sequência de testes com CPFs aleatórios: um número que passa no cálculo pode pertencer a outra pessoa e não resolve a identificação do parceiro correto.

CPF válido e situação fiscal são verificações diferentes

Um dígito de controle consistente não comprova inscrição estadual, habilitação ou credenciamento para emitir NF-e. Da mesma forma, a situação federal do CPF não substitui a consulta ao cadastro estadual de contribuintes do ICMS.

A habilitação do solicitante pelo certificado também tem tratamento próprio. A NT 2018.001 v1.10 prevê verificações para e-CNPJ e e-CPF no CCC. Isso não converte a rejeição 263 em problema do certificado, e não justifica trocar seu titular sem evidência de que a configuração esteja errada.

O leiaute ConsCad não apresenta mod nem tpAmb. Anote o ambiente configurado no programa quando isso ajudar o suporte, mas não crie esses campos no XML por analogia com a autorização de notas. O serviço e a versão da consulta precisam ser respeitados.

Um cuidado atual com os validadores

A NT 2026.004 v1.01 altera campos de CNPJ da consulta cadastral para comportar caracteres alfanuméricos. Essa mudança não transforma o CPF em um identificador alfanumérico nem autoriza aplicar a ele a validação de CNPJ.

Para empresas que usam um campo genérico de “documento”, vale verificar se a atualização preservou as regras de cada identificador. Ao final, o objetivo é consultar a pessoa correta com seu documento verdadeiro. Uma resposta cadastral bem-sucedida deve ser interpretada separadamente do protocolo de autorização da nota fiscal.

Base documental conferida em 9 de outubro de 2026. A solução deve respeitar a implementação e as condições atuais da SEFAZ consultada.