RFC en México: Formato, estructura y validación para desarrolladores

El RFC (Registro Federal de Contribuyentes) es el número de identificación tributaria de México y uno de los identificadores más importantes en el ecosistema empresarial del país. Si estás construyendo software que maneja facturación, procesamiento de pagos o compliance en México, vas a necesitar trabajar con RFCs constantemente. Cada factura electrónica (CFDI) emitida en México requiere que tanto el RFC del emisor como el del receptor sean válidos. Un RFC malformado significa que el CFDI es rechazado por el SAT (la autoridad tributaria de México), el pago no se puede procesar y tus usuarios se frustran. En esta guía desglosamos la estructura del RFC para personas físicas y morales, explicamos la misteriosa homoclave, cubrimos los enfoques de validación y mostramos cómo verificar RFCs programáticamente con la API Validate de Normadata.

¿Qué es un RFC?

El RFC (Registro Federal de Contribuyentes) lo emite el Servicio de Administración Tributaria (SAT) de México a cada persona física y moral que participa en el sistema tributario del país. Pensalo como el equivalente mexicano del EIN en Estados Unidos, el CUIT en Argentina o el CPF/CNPJ en Brasil. El RFC aparece en cada factura, declaración de impuestos, cuenta bancaria, documento de nómina y formulario gubernamental. A diferencia de algunos países donde los tax IDs son puramente numéricos, el RFC es alfanumérico — combina letras derivadas del nombre de la persona o empresa con su fecha de registro y un sufijo de verificación llamado homoclave. Esta estructura hace que el RFC sea parcialmente legible: un contador experimentado a menudo puede deducir a quién pertenece un RFC y aproximadamente cuándo se registró con solo mirarlo.

RFC de persona física (13 caracteres)

Un RFC para persona física es de 13 caracteres y sigue la estructura AAAA-AAMMDD-HHH. Las primeras cuatro letras se derivan del nombre de la persona usando reglas específicas definidas por el SAT. La primera letra viene del patrón vocal-consonante del apellido paterno, la segunda de la inicial del apellido materno, y las dos restantes del nombre de pila. Los siguientes seis dígitos representan la fecha de nacimiento de la persona en formato AAMMDD. Los últimos tres caracteres son la homoclave — un sufijo de dos caracteres más un dígito verificador, ambos calculados por el SAT usando un algoritmo que considera la cadena completa del nombre. Por ejemplo, un RFC como XAXX010101000 nos dice que las iniciales del nombre siguen el patrón GARC, la persona nació el 1 de enero de 1985, y su homoclave es AB3. Las reglas de derivación del nombre tienen muchos casos especiales: nombres compuestos, nombres que empiezan con ciertas combinaciones de letras, y nombres con partículas como "de", "del", "la" todos tienen reglas de manejo específicas documentadas en la guía de cálculo de RFC del SAT.

RFC de persona moral (12 caracteres)

Un RFC para persona moral es de 12 caracteres y sigue la estructura AAA-AAMMDD-HHH. La diferencia clave con los RFCs personales es que las empresas solo tienen tres letras iniciales en lugar de cuatro. Estas tres letras se derivan de la razón social de la empresa, usando un algoritmo diferente al de las personas físicas. El SAT extrae palabras clave del nombre de la empresa, ignorando partículas comunes y sufijos legales como "S.A. de C.V." o "S. de R.L.", y calcula un código de tres letras.

La porción de seis dígitos de fecha representa la fecha de constitución de la empresa (no la fecha de registro ante el SAT). La homoclave se calcula de la misma manera que para personas físicas — dos caracteres más un dígito verificador. Por ejemplo, un RFC como XAX010101000 es el "RFC genérico" que se usa cuando una empresa factura a un cliente que no proporciona su propio RFC. Reconocer estos RFCs especiales es importante porque aparecen frecuentemente en datos de producción pero no deberían tratarse como entidades reales y validadas.

La homoclave explicada

La homoclave es el sufijo de tres caracteres al final de un RFC. Su propósito es diferenciar personas o empresas que de otra forma tendrían prefijos de RFC idénticos — por ejemplo, dos personas con las mismas iniciales nacidas en la misma fecha. La homoclave consiste en dos caracteres calculados a partir del nombre completo usando una tabla de lookup y aritmética modular, más un dígito verificador final calculado a partir de los 11 o 12 caracteres precedentes. El algoritmo de homoclave del SAT no está documentado públicamente en un formato simple y amigable para desarrolladores. Involucra mapear cada carácter del nombre completo a un código numérico de dos dígitos de una tabla de lookup de 35 filas, sumar productos adyacentes en un patrón específico, y aplicar operaciones de módulo 11. Debido a esta complejidad, la mayoría de los desarrolladores no implementan la generación de homoclave desde cero — se apoyan en los sistemas del propio SAT o en una API de validación para verificar que la homoclave coincida.

Por qué el RFC importa para la facturación electrónica

El sistema de facturación electrónica de México (CFDI — Comprobante Fiscal Digital por Internet) es uno de los más maduros de Latinoamérica. El SAT requiere que cada factura sea firmada digitalmente y timbrada con un RFC válido tanto para el emisor como para el receptor. Si cualquiera de los dos RFCs es inválido, el CFDI es rechazado. Esto tiene consecuencias reales para los negocios:

• Las facturas rechazadas retrasan pagos y crean descuadres contables.
• RFCs inválidos disparan auditorías del SAT y posibles multas.
• Las transacciones B2B requieren RFCs validados antes de emitir el CFDI.
• La nómina (CFDI de nómina) requiere el RFC de cada empleado para calcular correctamente las retenciones de impuestos.
• Las empresas extranjeras que operan en México necesitan un RFC especial (generalmente empezando con XEXX) y deben validarse de forma diferente.

Validando con la API de Normadata

La API Validate de Normadata valida RFCs mexicanos verificando el formato, el componente de fecha, el patrón de derivación del nombre y el dígito verificador. También identifica RFCs especiales como el RFC genérico de consumidor (XAXX010101000) y el RFC de entidad extranjera (XEXX010101000). Así se usa:

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"
 }

{
 "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"
 }
}

{
 "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 pasos

Entender la estructura y validación del RFC es crítico para cualquier desarrollador que trabaje con sistemas de facturación, impuestos o compliance en México. Las diferencias de formato entre RFCs personales y empresariales, la complejidad de la homoclave y los RFCs especiales usados en flujos de CFDI requieren un manejo cuidadoso. La API Validate de Normadata abstrae esta complejidad en un solo endpoint que valida formato, estructura y dígitos verificadores. Visitá la página de cobertura para la lista completa de identificadores soportados en Sudamérica, o consultá la documentación de la API para empezar a hacer requests.