Publicado em 2 de abril de 2026·7 min de leitura

RFC no México: Formato, Estrutura e Validação para Desenvolvedores

Teste — valide um RFC

A validação roda no seu navegador. Nenhum dado sai do seu dispositivo.

Valida localmente — seus dados nunca saem do seu navegador. Sem tracking no input.

O RFC (Registro Federal de Contribuyentes) é o número de identificação fiscal do México e um dos identificadores mais importantes no ecossistema de negócios do país. Se você está desenvolvendo software que lida com faturamento, processamento de pagamentos ou compliance no México, vai trabalhar com RFCs constantemente. Cada fatura eletrônica (CFDI) emitida no México exige que o RFC tanto do emissor quanto do destinatário seja válido. Um RFC malformado significa que o CFDI é rejeitado pelo SAT (autoridade fiscal do México), o pagamento não pode ser processado e seus usuários ficam frustrados. Neste guia, detalhamos a estrutura do RFC para pessoas físicas e empresas, explicamos a misteriosa homoclave, abordamos abordagens de validação e mostramos como verificar RFCs programaticamente com a API Validate da Normadata.

O que é um RFC?

O RFC (Registro Federal de Contribuyentes) é emitido pelo Servicio de Administracion Tributaria (SAT) do México para cada pessoa física e entidade jurídica que participa do sistema fiscal do país. Pense nele como o equivalente mexicano ao EIN nos Estados Unidos, ao CUIT na Argentina ou ao CPF/CNPJ no Brasil. O RFC aparece em cada fatura, declaração fiscal, conta bancária, documento de folha de pagamento e formulário governamental. Ao contrário de alguns países onde os IDs fiscais são puramente numéricos, o RFC é alfanumérico — combina letras derivadas do nome da pessoa ou empresa com a data de registro e um sufixo de verificação chamado homoclave. Essa estrutura torna o RFC parcialmente legível por humanos: um contador experiente muitas vezes consegue identificar a quem pertence um RFC e quando aproximadamente se registrou apenas olhando para ele.

RFC pessoal (13 caracteres)

Um RFC para uma pessoa física tem 13 caracteres e segue a estrutura AAAA-YYMMDD-HHH. As primeiras quatro letras são derivadas do nome da pessoa usando regras específicas definidas pelo SAT. A primeira letra vem do padrão vogal-consoante do sobrenome paterno, a segunda da inicial do sobrenome materno, e as duas restantes do primeiro nome. Os próximos seis dígitos representam a data de nascimento da pessoa no formato YYMMDD. Os três últimos caracteres são a homoclave — um sufixo de dois caracteres mais um único dígito verificador, ambos calculados pelo SAT usando um algoritmo que leva em conta a string completa do nome. Por exemplo, um RFC como XAXX010101000 indica que as iniciais do nome da pessoa seguem o padrão GARC, a pessoa nasceu em 1 de janeiro de 1985, e sua homoclave é AB3. As regras de derivação do nome têm muitos casos especiais: nomes compostos, nomes que começam com certas combinações de letras e nomes com partículas como "de", "del", "la" têm regras de tratamento específicas documentadas no guia de cálculo de RFC do SAT.

RFC empresarial (12 caracteres)

Um RFC para uma entidade jurídica (persona moral) tem 12 caracteres e segue a estrutura AAA-YYMMDD-HHH. A diferença principal em relação aos RFCs pessoais é que as empresas têm apenas três letras iniciais em vez de quatro. Essas três letras são derivadas da razão social da empresa, usando um algoritmo diferente do utilizado para pessoas físicas. O SAT extrai palavras-chave da razão social, ignorando partículas comuns e sufixos legais como "S.A. de C.V." ou "S. de R.L.", e calcula um código de três letras.

A parte de seis dígitos da data representa a data de constituição da empresa (não a data de registro no SAT). A homoclave é calculada da mesma forma que para pessoas físicas — dois caracteres mais um dígito verificador. Por exemplo, um RFC como XAX010101000 é o "RFC genérico" usado quando uma empresa emite fatura para um cliente que não fornece seu próprio RFC. Reconhecer esses RFCs especiais é importante porque aparecem frequentemente em dados de produção, mas não devem ser tratados como entidades reais e validadas.

A homoclave explicada

A homoclave é o sufixo de três caracteres no final de um RFC. Seu propósito é diferenciar pessoas ou empresas que, de outra forma, teriam prefixos RFC idênticos — por exemplo, duas pessoas com as mesmas iniciais de nome nascidas na mesma data. A homoclave consiste em dois caracteres calculados a partir do nome completo usando uma tabela de consulta e aritmética modular, mais um dígito verificador final calculado a partir de todos os 11 ou 12 caracteres precedentes. O algoritmo de homoclave do SAT não está documentado publicamente em um formato simples e acessível a desenvolvedores. Ele envolve mapear cada caractere do nome completo para um código numérico de dois dígitos a partir de uma tabela de consulta de 35 linhas, somar produtos adjacentes em um padrão específico e aplicar operações de módulo 11. Por causa dessa complexidade, a maioria dos desenvolvedores não implementa a geração de homoclave do zero — eles dependem dos próprios sistemas do SAT ou de uma API de validação para verificar se a homoclave corresponde.

Por que o RFC é importante para o faturamento eletrônico

O sistema de faturamento eletrônico do México (CFDI — Comprobante Fiscal Digital por Internet) é um dos mais maduros na América Latina. O SAT exige que cada fatura seja assinada digitalmente e carimbada com um RFC válido tanto do emissor quanto do destinatário. Se qualquer RFC for inválido, o CFDI é rejeitado. Isso tem consequências reais para as empresas:

  • Faturas rejeitadas atrasam pagamentos e geram inconsistências contábeis.
  • RFCs inválidos acionam auditorias do SAT e possíveis multas.
  • Transações B2B exigem RFCs validados antes de emitir o CFDI.
  • A folha de pagamento (nomina CFDI) exige o RFC de cada funcionário para calcular corretamente as retenções de impostos.
  • Empresas estrangeiras que operam no México precisam de um RFC especial (geralmente começando com XEXX) e devem ser validadas de forma diferente.

Validando com a API da Normadata

A API Validate da Normadata valida RFCs mexicanos verificando o formato, o componente de data, o padrão de derivação do nome e o dígito verificador. Ela também identifica RFCs especiais como o RFC genérico do consumidor (XAXX010101000) e o RFC de entidade estrangeira (XEXX010101000). Veja como usá-la:

cURL
curl -X POST https://api.normadata.io/v1/validate/tax-ids \
 -H "X-API-Key: nd_your_key_here" \
 -H "Content-Type: application/json" \
 -d {
 "value": "XAXX010101000",
 "country": "MX",
 "type": "rfc"
 }
Resposta — RFC pessoal válido
{
 "valid": true,
 "country": "MX",
 "type": "rfc",
 "value": {
 "raw": "XAXX010101000",
 "formatted": "XAXX010101000"
 },
 "metadata": {
 "entity_type": "persona_fisica",
 "date": "1985-01-01",
 "homoclave": "AB3",
 "check_digit": "3"
 }
}
Resposta — RFC genérico do consumidor
{
 "valid": true,
 "country": "MX",
 "type": "rfc",
 "value": {
 "raw": "XAXX010101000",
 "formatted": "XAXX010101000"
 },
 "metadata": {
 "entity_type": "persona_fisica",
 "special_rfc": "generic_consumer",
 "date": "2001-01-01",
 "homoclave": "000",
 "check_digit": "0"
 }
}

Próximos passos

Entender a estrutura e a validação do RFC é fundamental para qualquer desenvolvedor que trabalha com sistemas de faturamento, tributação ou compliance mexicanos. As diferenças de formato entre RFCs pessoais e empresariais, a complexidade da homoclave e os RFCs especiais usados nos fluxos de CFDI exigem tratamento cuidadoso. A API Validate da Normadata abstrai essa complexidade em um único endpoint que valida formato, estrutura e dígitos verificadores. Acesse a página de cobertura para a lista completa de identificadores suportados na América do Sul, ou consulte a documentação da API para começar a fazer requisições.

Pronto para começar a desenvolver?

Solicitar acessoLer documentação

Artigos relacionados

5 de maio de 2026IDs Fiscais Latino-Americanos: Um Guia para Desenvolvedores5 de maio de 2026Validando o CUIT Argentino: Algoritmo, Formato e API5 de maio de 2026Validação de CPF: Algoritmo, Exemplos e API REST5 de maio de 2026RFC vs CURP no México: Quando Usar Cada Um15 de março de 2026Como Validar um Número de CUIT com uma API1 de abril de 2026Validação de CPF: Formato, Algoritmo e Integração com API para o Brasil10 de março de 2026O Guia Completo de IDs Fiscais na América Latina1 de março de 2026Boas Práticas para Integrar APIs de Terceiros em Aplicações LATAM11 de maio de 2026Quanto orçamento KYC você desperdiça com dados malformados (e como medir)16 de maio de 2026Como validar todos os tax IDs da LATAM com uma única API16 de maio de 2026Por que pré-validar dados antes do KYC economiza dinheiro — com números16 de maio de 2026Construindo um formulário de checkout consciente da LATAM16 de maio de 2026O custo oculto dos erros de mod-11 no seu onboarding LATAM