Estructura y validación del RFC mexicano

Estructura del RFC

El RFC (Registro Federal de Contribuyentes) es el identificador fiscal emitido por el SAT (Servicio de Administración Tributaria), la autoridad tributaria de México. Tiene dos longitudes según el tipo de contribuyente:

• Personas físicas: 13 caracteres — 4 letras (nombre) + 6 dígitos (fecha YYMMDD) + 3 chars (homoclave)
• Personas morales: 12 caracteres — 3 letras (razón social) + 6 dígitos (fecha de constitución YYMMDD) + 3 chars (homoclave)

Las 4 letras del nombre (personas físicas) se forman así: primera letra + primera vocal interna del primer apellido, primera letra del segundo apellido, primera letra del nombre de pila. SAT aplica una tabla de palabras inconvenientes que sustituye combinaciones ofensivas por variantes neutras. La homoclave (3 chars alfanuméricos) la genera el SAT internamente — el algoritmo completo no está publicado en documentación oficial pública.

RFC genérico y para extranjeros

Ejemplo numérico paso a paso

Pseudocódigo

normalized = strip(input).toUpperCase()

if normalized in {XAXX010101000, XEXX010101000} → VALID (generic)

if length == 13 AND matches [A-Z]{4}[0-9]{6}[A-Z0-9]{3}
  extract mm = chars[6..7], dd = chars[8..9]
  if 1 ≤ mm ≤ 12 AND 1 ≤ dd ≤ 31 → VALID individual

if length == 12 AND matches [A-Z]{3}[0-9]{6}[A-Z0-9]{3}
  extract mm = chars[5..6], dd = chars[7..8]
  if 1 ≤ mm ≤ 12 AND 1 ≤ dd ≤ 31 → VALID company

→ INVALID

Edge cases que una implementación simple no maneja

• RFC genérico XAXX010101000: válido estructuralmente. Se usa en CFDIs emitidos al público general sin datos del receptor. Un sistema que solo valida el patrón regex sin whitelist de genéricos lo rechazaría incorrectamente.
• RFC para extranjeros XEXX010101000: válido estructuralmente para operaciones con personas o empresas sin RFC registrado en México. Requiere tratamiento explícito en sistemas que discriminan contribuyentes mexicanos de extranjeros.
• Homoclave no computable en cliente: el algoritmo completo de homoclave requiere tablas internas del SAT que no son públicas. Cualquier implementación que pretenda generarla desde cero está usando una aproximación, no el algoritmo oficial.
• Palabras inconvenientes: el SAT sustituye combinaciones de 4 letras ofensivas por variantes neutras. La lista exacta (aprox. 70 combinaciones) no es oficial pero está bien documentada en la práctica. Sin esta tabla, RFCs como BUCH... se generarían con combinaciones que el SAT nunca emitiría.
• RFC histórico vs actual (cambios SAT 2014 y 2022): el SAT modificó las reglas de formación del RFC en 2014 y 2022. RFCs emitidos antes de esos cambios pueden no cumplir con las reglas estructurales actuales pero siguen siendo válidos.
• Personas físicas vs morales: longitud como discriminador: 13 chars = física, 12 chars = moral. Esta distinción es crítica — un sistema que aplica el regex de persona física a un RFC de empresa (o viceversa) fallará en todas las morales.
• Fecha de nacimiento vs fecha de constitución: para personas físicas la fecha es de nacimiento; para morales es de constitución de la empresa. Un RFC de empresa con fecha "010101" (fecha placeholder del SAT) es válido estructuralmente.
• RFC en minúsculas: el SAT siempre emite en mayúsculas. Sistemas que reciben el RFC de formularios web pueden recibirlo en minúsculas o mixed case. Sin normalización a mayúsculas, el regex falla.
• RFC con guiones internos: algunos formatos impresos incluyen guiones para legibilidad (GOML-850312-AB3). El guion no es parte del RFC oficial y debe eliminarse antes de validar.
• RFC no consultado en el SAT: un RFC estructuralmente válido puede no existir en el registro del SAT, estar cancelado, o estar suspendido. La validación estructural no detecta ninguno de estos estados.
• Cambio de nombre o apellido: en México es posible cambiar el nombre legal. El SAT puede emitir un nuevo RFC con las letras del nombre actualizado. Un RFC anterior con las letras viejas puede seguir activo en sistemas legados.
• RFC de fideicomisos y asociaciones: tienen formatos especiales que pueden no seguir el patrón estándar de 12 o 13 caracteres. Validadores que solo aceptan los dos formatos estándar los rechazarán.
• Homoclave con Ñ o caracteres especiales: el SAT usa solo A-Z y 0-9 en la homoclave. Inputs que incluyen Ñ u otros chars deben normalizarse o rechazarse explícitamente con un mensaje claro.

¿Querés saltarte todo esto?

Manejar todos estos edge cases en producción cuesta semanas de testing y mantenimiento permanente conforme cambian las reglas regulatorias. La API de Normadata maneja todo lo de arriba — incluyendo los casos que ni listamos aquí — con una sola llamada REST.

Fuentes

SAT — Estructura del RFC (documentación pública disponible en sat.gob.mx). Normativa de personas físicas y morales para la formación de la clave.