CPF ou CNPJ "válido" pode não existir na Receita: validação de formato vs. validação real

Um CPF que passa no cálculo do dígito verificador prova uma coisa e uma só: que os 11 dígitos são internamente consistentes entre si. Não prova que aquele número foi emitido pela Receita Federal, que pertence a alguém vivo, ou que consta em qualquer cadastro real. É uma distinção que parece óbvia quando explicada, mas que se perde constantemente na hora de escrever um caso de teste, porque o termo "CPF válido" é usado, sem querer, para descrever duas coisas bem diferentes.

O que o dígito verificador prova, e o que ele não prova

O algoritmo de módulo 11 usado tanto no CPF quanto no CNPJ existe para detectar erro de digitação e transcrição, não para confirmar existência. Ele responde a uma pergunta estritamente matemática: dados os primeiros dígitos, os últimos dois (ou o par de dígitos verificadores) são o resultado esperado do cálculo? Se a resposta é sim, o número é estruturalmente válido. Se um número existe de fato no cadastro da Receita, com uma pessoa física ou jurídica associada, ele é real. Um documento estruturalmente válido pode não ser real; um documento real é sempre estruturalmente válido, porque a Receita não emite números que reprovariam no próprio algoritmo que ela define.

Essa assimetria é a origem de boa parte da confusão: como todo documento real passa na validação de formato, é fácil assumir o caminho inverso — que todo documento que passa na validação de formato é real. Não é, e o espaço de números estruturalmente válidos é ordens de grandeza maior do que o espaço de números efetivamente emitidos.

Onde essa confusão aparece em produção

Em um cadastro simples, sem integração externa, a distinção não costuma importar: valida-se o formato, aceita-se o documento, ponto final. O problema surge quando o sistema depende de outro serviço para confirmar existência — uma consulta à Receita, uma API de terceiro que retorna dados cadastrais, uma integração de KYC (know your customer) — e alguém, em algum ponto da cadeia, decide que a validação de dígito verificador já é suficiente e pula a consulta real por questão de custo, latência ou simplicidade.

O resultado costuma aparecer meses depois, quando um usuário cadastra um CPF gerado por engano ou mal-intencionado que nunca existiu, e o sistema aceita porque nunca chegou a perguntar à fonte de verdade. Ou o inverso: um fluxo de teste automatizado gera CPFs válidos em massa e, sem querer, algum deles bate por coincidência com um CPF real de terceiro, e a consulta externa retorna dados de uma pessoa que nada tem a ver com o teste.

O CNPJ tem o mesmo problema, com uma camada a mais

No CNPJ a distinção fica ainda mais evidente porque o cadastro carrega informação de negócio: situação cadastral (ativa, baixada, suspensa, inapta), razão social, natureza jurídica, endereço. Um CNPJ pode ser estruturalmente válido, pertencer a uma empresa real, e ainda assim estar baixado — e um sistema que só confere o dígito verificador aceita normalmente uma empresa que juridicamente não pode mais operar. Com a migração para o formato alfanumérico, esse cuidado fica mais importante ainda: a mudança altera como o dígito verificador é calculado, mas não altera o fato de que o cálculo, sozinho, nunca vai dizer se aquele CNPJ está ativo, apto e correspondendo à razão social que o formulário também coletou.

Como decidir o nível de validação certo para cada caso

• Formulário de front-end. Validar formato e dígito verificador no cliente é suficiente e correto — o objetivo ali é dar feedback rápido de erro de digitação, não confirmar existência.
• Cadastro que vira massa de teste ou dado de demonstração. Só precisa de validade estrutural. Não há motivo para consultar uma fonte real, e fazer isso é até contraproducente: pode gerar ruído em serviço de terceiro ou, pior, expor coincidência com dado real.
• Fluxo com implicação financeira, fiscal ou de compliance. Emissão de nota fiscal, abertura de conta, aprovação de crédito, KYC — nesses casos a validação de dígito verificador é apenas o primeiro filtro. É preciso consultar a fonte de verdade (ou um provedor que a espelhe) antes de tratar o documento como confirmado.

O erro mais comum não é escolher o nível errado de validação — é misturar os dois sem perceber, aplicando a lógica do primeiro caso (documento estruturalmente válido é suficiente) em um contexto que exigia a lógica do terceiro (documento precisa ser confirmado como real e apto).

Casos de teste que expõem essa confusão

• CPF/CNPJ estruturalmente válido, mas fora da faixa plausível de emissão. Testar se o sistema trata esse caso da mesma forma que trataria um documento real, quando deveria — ou não — diferenciar os dois, dependendo do requisito.
• CNPJ real, porém baixado ou suspenso. Confirmar que o fluxo consulta a situação cadastral, e não só o dígito verificador, antes de liberar uma operação sensível.
• Dependência de serviço externo fora do ar. Se a validação de existência depende de uma API de terceiro, o teste precisa cobrir o comportamento quando esse serviço está indisponível — o sistema deve degradar de forma segura, não aceitar o documento silenciosamente como se a consulta tivesse confirmado algo que não confirmou.
• Reutilização de massa de teste estruturalmente válida em ambiente que faz consulta real. Um CPF gerado para teste, usado sem querer em um ambiente que dispara uma consulta real à Receita ou a um provedor de dados, pode gerar custo, ruído ou, em casos raros, coincidir com um documento de terceiro — vale isolar claramente os ambientes onde isso pode acontecer.

O Validador de CPF e o Validador de CNPJ deste site conferem exatamente a validade estrutural — dígito verificador e formato — que é o primeiro filtro em qualquer fluxo, mas não substituem uma consulta à fonte de verdade quando o caso de uso exige confirmação real. Para gerar massa de teste com essa mesma validade estrutural, sem risco de colidir com documento real de terceiro, o Gerador de CPF e o Gerador de CNPJ produzem números prontos para popular ambiente de teste sem essa ambiguidade.