CPF válido não é CPF existente: dígito verificador, situação cadastral e o que a consulta confirma

Um validador de CPF responde a uma pergunta de aritmética: os dois últimos dígitos batem com a conta feita sobre os nove primeiros? Ele não responde — e não tem como responder — se existe alguém por trás daquele número. São perguntas diferentes, resolvidas em camadas diferentes do sistema, e confundir uma com a outra produz desde bugs bobos de cadastro até decisões de produto que não se sustentam.

Três níveis de verificação: formato, dígito e existência

Todo documento brasileiro com dígito verificador admite três perguntas empilhadas, cada uma mais cara e mais lenta que a anterior:

O nível de formato é sintático: onze algarismos para o CPF, catorze posições para o CNPJ — que desde 2026 aceita letras nas doze primeiras, conforme explicado no guia do CNPJ alfanumérico. O nível do dígito verificador é aritmético: aplica o módulo 11 sobre a base e compara com o que veio na entrada. Os dois rodam dentro do seu processo, sem rede, e nessa ordem — não faz sentido gastar uma chamada externa com uma string que nem tem o tamanho certo.

O terceiro nível é de outra natureza. Não é cálculo: é consulta a um cadastro mantido pela Receita Federal, que só ela pode responder. Nenhuma biblioteca de validação chega lá offline.

Por que um gerador produz números válidos que não existem

O dígito verificador é uma função da base. Para cada conjunto de nove algarismos existe exatamente um par de verificadores correto, o que significa que há cerca de um bilhão de CPFs bem formados dentro de um universo de cem bilhões de sequências de onze algarismos. Um número escolhido ao acaso tem por volta de 1% de chance de passar na conferência — e é exatamente por isso que o DV serve ao que foi criado: pegar erro de digitação, não atestar identidade.

Gerar um documento fictício é percorrer esse caminho na ordem inversa: sorteia-se a base e calcula-se o par de verificadores. No exemplo didático mais conhecido, a base 123456789 produz soma 210 no primeiro dígito (resto 1, menor que 2, então o dígito é 0) e soma 255 no segundo (resto 2, então o dígito é 11 − 2 = 9), resultando em 123.456.789-09. O número passa em qualquer validador do mercado e ninguém em sã consciência diria que ele identifica uma pessoa.

Vale ser exato sobre o que isso quer dizer. O gerador de CPF e o gerador de CNPJ daqui não consultam cadastro nenhum: eles sorteiam e calculam. Como o espaço de números bem formados é finito, um número gerado pode, por coincidência aritmética, coincidir com uma inscrição que já existe. O que o gerador jamais faz é associar esse número a um nome, a uma data de nascimento ou a um endereço de alguém real — e é a associação, não o número solto, que transforma uma sequência de algarismos em dado pessoal. As fichas do gerador de pessoas seguem a mesma lógica: campos sorteados que combinam entre si e não correspondem a ninguém.

As situações cadastrais do CPF

Existir no cadastro é só metade da resposta. Uma inscrição ativa carrega um estado, e esse estado muda ao longo da vida do titular. A consulta pública da Receita Federal devolve a situação em que o CPF se encontra:

Duas observações importam para quem escreve código. A primeira: a consulta pública é um formulário web que exige o número do CPF mais a data de nascimento do titular, além de verificação anti-robô. Não existe uma API aberta e gratuita da Receita para isso, raspar o formulário quebra a cada mudança de layout, e a exigência da data já denuncia o desenho: a consulta pressupõe que quem pergunta tem algum vínculo com a pessoa, não que vai varrer uma lista.

A segunda: “Regular” não é prova de identidade. A situação diz que aquela inscrição não tem pendência, não que a pessoa do outro lado da tela é o titular. Autenticação de identidade é um problema separado, resolvido por outros meios, e nenhuma consulta cadastral substitui isso.

As situações cadastrais do CNPJ

No cadastro de pessoa jurídica o vocabulário é diferente e a leitura tem consequências operacionais mais imediatas, porque sistemas costumam decidir se emitem nota, se liberam crédito ou se aceitam um fornecedor com base nesse campo.

Junto da situação vem a data da situação cadastral e um motivo — e é o motivo que costuma ser ignorado. Uma inscrição baixada por encerramento voluntário e outra baixada de ofício contam histórias distintas sobre o mesmo CNPJ.

Outro equívoco frequente: tratar Ativacomo sinônimo de "pode emitir nota fiscal". O CNPJ é o cadastro federal. A habilitação para circular mercadoria ou prestar serviço depende de inscrição estadual e municipal, que são cadastros à parte, com situações próprias — o guia sobre CPF, CNPJ, inscrição estadual e MEI detalha essa separação. E há o caso do MEI e do empresário individual, em que os dados do CNPJ se confundem com os de uma pessoa física: tratar "dado de empresa" como automaticamente impessoal, nesses casos, é um atalho perigoso.

Quando o seu sistema realmente precisa consultar a Receita

A regra que funciona bem na prática: consulte quando a decisão depende do estado da inscrição, não quando você só quer garantir que o usuário digitou certo. Situações em que a consulta se justifica:

• Abertura de conta, contratação de crédito e outros fluxos regulatórios em que a empresa tem obrigação legal de conhecer a contraparte.
• Cadastro de fornecedor ou parceiro, onde uma inscrição inapta ou baixada muda a decisão de contratar.
• Emissão de documento fiscal, em que os dados cadastrais do destinatário precisam bater com o cadastro oficial.
• Cobrança recorrente de longo prazo, em que a situação registrada há dois anos pode não valer mais hoje.

E a lista do que nãojustifica consulta: formulário de newsletter, cadastro de conta gratuita, CPF usado apenas como chave de deduplicação interna, tela de teste. Nesses casos o módulo 11 basta. Muita integração cara existe porque alguém confundiu "quero evitar erro de digitação" com "preciso saber quem é essa pessoa".

O custo escondido de consultar: latência, disponibilidade e finalidade do tratamento

Colocar uma chamada externa no caminho síncrono de um cadastro muda o perfil de falha da aplicação. A validação local nunca fica fora do ar; um serviço externo fica. Formulário que devolve erro 500 porque o provedor caiu trocou um problema de qualidade de dado por um de disponibilidade — e barrou justamente quem estava com tudo certo.

O desenho que costuma resolver: aceitar o cadastro com a validação local, marcar o registro como pendente de verificação cadastral e rodar a consulta de forma assíncrona, com fila e repetição. A decisão que depende da situação (liberar limite, emitir documento, habilitar o fornecedor) espera; o cadastro, não.

Do lado dos dados, consultar a situação de um documento de terceiro é tratamento de dado pessoal quando o documento é de pessoa física. Isso puxa as perguntas que a LGPD organiza em torno de finalidade e necessidade: para que serve a consulta neste fluxo, qual base legal a sustenta, o que você guarda do retorno e por quanto tempo. Persistir o nome e a data de nascimento devolvidos quando a regra só precisava do campo de situação é coleta acima do necessário. O guia sobre LGPD e dados de teste cobre o lado do ambiente de desenvolvimento; aqui a pergunta é de produção.

Três práticas de implementação que evitam retrabalho:

• Guarde a resposta com carimbo de data."Regular" sem a data da consulta é um dado sem validade. Defina um TTL explícito e reconsulte quando expirar.
• Persista o mínimo. Situação, data da consulta e um identificador da requisição costumam bastar. O payload completo raramente precisa ir para o banco.
• Não jogue o retorno no log. Log de aplicação é replicado, indexado e visto por muita gente. Registre o resultado, não o documento nem os dados do titular.

Como testar uma integração de consulta sem usar documento real

Nenhum teste automatizado deveria bater no serviço oficial, e nenhum deveria usar o CPF de um colega de equipe como fixture. O caminho é isolar a consulta atrás de uma interface e testar contra um dublê determinístico, alimentado por documentos fictícios gerados.

Primeiro, a verificação em camadas, com a consulta como dependência opcional:

type Nivel = "formato" | "digito" | "cadastro";

type Resultado =
  | { ok: true; nivel: Nivel }
  | { ok: false; nivel: Nivel; motivo: string };

const SITUACOES_ACEITAS = new Set(["REGULAR"]);

export async function verificarCpf(
  entrada: string,
  consulta?: ConsultaCadastral,
): Promise<Resultado> {
  const digitos = entrada.replace(/\D/g, "");

  if (digitos.length !== 11) {
    return { ok: false, nivel: "formato", motivo: "tamanho diferente de 11" };
  }
  if (!dvConfere(digitos)) {
    return { ok: false, nivel: "digito", motivo: "digito verificador invalido" };
  }

  // Sem provedor injetado, a verificação para no nível local — e isso
  // precisa ficar explícito na resposta, não implícito num booleano.
  if (!consulta) return { ok: true, nivel: "digito" };

  const { situacao } = await consulta.situacaoCpf(digitos);
  return SITUACOES_ACEITAS.has(situacao)
    ? { ok: true, nivel: "cadastro" }
    : { ok: false, nivel: "cadastro", motivo: "situacao " + situacao };
}

Depois, o dublê. A ideia é mapear a situação devolvida a partir de um pedaço do próprio documento fictício, para que cada cenário tenha um CPF de teste estável e o time consiga reproduzir o caso de "titular falecido" sem precisar de um titular falecido:

export interface ConsultaCadastral {
  situacaoCpf(cpf: string): Promise<{ situacao: string; consultadoEm: string }>;
}

const MAPA: Record<string, string> = {
  "0": "REGULAR",
  "1": "PENDENTE_DE_REGULARIZACAO",
  "2": "SUSPENSA",
  "3": "TITULAR_FALECIDO",
  "4": "CANCELADA",
  "5": "NULA",
};

export class ConsultaFake implements ConsultaCadastral {
  // Data fixa: teste com relógio real vira teste intermitente.
  static readonly MOMENTO = "2026-09-14T12:00:00Z";

  async situacaoCpf(cpf: string) {
    return {
      situacao: MAPA[cpf.slice(-1)] ?? "REGULAR",
      consultadoEm: ConsultaFake.MOMENTO,
    };
  }
}

A suíte passa a cobrir os seis ramos de situação sem rede e sem dado de ninguém. Para o adaptador real, o teste que importa é de contrato: um payload de exemplo, com os campos pessoais trocados por valores fictícios, conferindo se o código desserializa a resposta e traduz os códigos de situação. Estratégias de montagem dessa massa estão no guia de massa de dados de teste.

Erros comuns

• Ler "CPF válido" como "CPF do usuário". O módulo 11 não autentica ninguém. Se o seu fluxo trata um documento validado como identidade confirmada, o buraco está no desenho, não na biblioteca.
• Esperar que um documento gerado apareça na consulta oficial. Ele não foi inscrito em lugar nenhum. A resposta esperada para um CPF fictício é justamente a ausência de cadastro.
• Derrubar o cadastro quando a consulta externa falha. Timeout de provedor virando erro 500 na tela do usuário é falha de arquitetura. Separe o que precisa da verificação do que não precisa.
• Cachear a situação para sempre. Situação cadastral muda. Sem TTL e sem data da consulta, você toma decisões de hoje com informação de dois anos atrás.
• Guardar o retorno inteiro "porque pode ser útil". Dado de terceiro armazenado sem finalidade definida é passivo, não ativo.
• Confundir CNPJ ativo com empresa apta a operar. Situação federal regular convive com inscrição estadual bloqueada, e o erro só aparece na hora de emitir o documento fiscal.
• Validar com regex só numérica depois do CNPJ alfanumérico. Um padrão de catorze dígitos rejeita inscrições legítimas a partir de 2026; o guia de regex de documentos brasileiros traz os padrões atualizados.

Manter as camadas separadas é o que põe cada uma no lugar certo: formato e dígito verificador resolvem qualidade de entrada e podem rodar a cada tecla digitada; situação cadastral resolve decisão de negócio, custa caro e carrega responsabilidade sobre dado de gente real. Os geradores deste site vivem inteiramente no primeiro território.