Cómo validar el RFC sin pedir la Constancia de Situación Fiscal

Cómo validar el RFC sin pedir la Constancia de Situación Fiscal: el Comunicado SAT 04/2026 la vuelve infracción multable (CFF 83-IX)

No. No necesitas la Constancia de Situación Fiscal para validar el RFC ni para emitir un CFDI 4.0. Según el Comunicado SAT 04/2026, exigir la Constancia de Situación Fiscal (CSF) como condición para emitir una factura es infracción bajo el CFF artículo 83, fracción IX, multable en un rango de aproximadamente $21,420 a $122,440 MXN (un tramo del CFF artículo 84). Para validar el RFC y timbrar un CFDI 4.0 solo necesitas cinco datos estructurados — RFC, nombre/razón social exacto, código postal, régimen fiscal y uso CFDI — ninguno en PDF. Valida el formato y el dígito verificador del RFC localmente, captura el resto con dropdowns y deja que el timbrado detecte las discrepancias.

La Constancia de Situación Fiscal (CSF), también llamada Cédula de Identificación Fiscal (CIF), es solo un documento legible que contiene algunos de esos datos; no es en sí un campo del comprobante.

El comunicado es explícito en dos frentes que tocan tu flujo de onboarding: condicionar la emisión de la factura a que el receptor te entregue su CSF/CIF está sancionado, y un patrón tampoco puede exigir la CSF a sus empleados para la nómina (puede solicitar los datos mediante un caso de aclaración). O sea: si tu formulario de alta tiene un campo “sube tu Constancia (PDF)” y bloquea la facturación hasta que lo llenen, estás construyendo una infracción dentro de tu producto.

Esta es una guía de ingeniero, no de contador. Aquí va el flujo de validación de identidad fiscal; el monto exacto de la multa y la fracción del CFF debes confirmarlos contra el CFF/RMF vigente antes de citarlos a un cliente.

Los 4 (en realidad 5) datos que un timbrado CFDI 4.0 sí necesita

Para timbrar un CFDI 4.0 a un receptor, el SAT exige exactamente estos datos, ninguno de ellos en PDF:

• RFC del receptor.
• Nombre / razón social exactamente como está registrado ante el SAT. La versión 4.0 es estricta con el nombre: una coma, un “SA DE CV” de más o un acento mal puesto y el timbrado falla.
• Código Postal del domicilio fiscal.
• Régimen Fiscal (catálogo c_RegimenFiscal).
• Uso CFDI (catálogo c_UsoCFDI).

Son cuatro datos de identidad más el uso que el receptor elige por operación, por eso “4 en realidad 5”. Todos caben en un formulario con campos de texto y dos dropdowns. La CSF no aparece en esta lista porque no es un dato del comprobante: es un documento que contiene algunos de estos datos, y el SAT ya te dijo que no la pidas.

Si ya automatizas la emisión desde tus cobros, estos cinco campos son los mismos que alimentan la facturación CFDI automática desde Stripe/Mercado Pago. El onboarding solo los recolecta una vez y los reusa.

Valida el RFC localmente: formato por persona moral/física + el dígito verificador mod 11

Antes de tocar la red, puedes rechazar el 90% de la basura validando la estructura del RFC en tu propio servidor. El RFC tiene dos formas:

• Persona moral: 12 caracteres — 3 letras + 6 dígitos de fecha (AAMMDD) + 3 de homoclave.
• Persona física: 13 caracteres — 4 letras + 6 dígitos de fecha + 3 de homoclave.

El último carácter de la homoclave es un dígito verificador calculado con un algoritmo mod 11 sobre el resto del RFC. Eso significa que un RFC mal tecleado falla el checksum sin que el SAT participe:

import re

CHARSET = "0123456789ABCDEFGHIJKLMN&OPQRSTUVWXYZ Ñ"  # posiciones oficiales SAT

# RFCs genericos del SAT: su digito verificador esta decretado, no se calcula.
RFC_GENERICOS = {"XAXX010101000", "XEXX010101000"}

def rfc_check_digit(rfc12: str) -> str:
    """Calcula el digito verificador (mod 11) sobre los primeros 12 chars."""
    suma = 0
    for i, ch in enumerate(rfc12):
        valor = CHARSET.index(ch)
        suma += valor * (13 - i)   # factores 13..2
    resto = suma % 11
    dv = 11 - resto
    if dv == 11:
        return "0"
    if dv == 10:
        return "A"
    return str(dv)

def validar_rfc(rfc: str) -> bool:
    rfc = rfc.strip().upper()
    if rfc in RFC_GENERICOS:   # whitelist: su DV esta decretado, no calculado
        return True
    moral = re.fullmatch(r"[A-ZÑ&]{3}\d{6}[A-Z0-9]{3}", rfc)
    fisica = re.fullmatch(r"[A-ZÑ&]{4}\d{6}[A-Z0-9]{3}", rfc)
    if not (moral or fisica):
        return False
    cuerpo = rfc[:-1]
    # el cuerpo se rellena a 12 con espacio inicial si es persona moral
    cuerpo12 = cuerpo.rjust(12, " ")
    return rfc_check_digit(cuerpo12) == rfc[-1]

Esto te da una comprobación barata y offline: formato correcto, longitud correcta según el tipo y dígito verificador consistente. Ojo con los RFCs genéricos: XAXX010101000 (público en general) no satisface el mod 11 calculado, así que se incluyen en una whitelist en lugar de pasar por el algoritmo. Lo que no te dice ninguna de estas comprobaciones es si ese RFC existe y está activo ante el SAT — para eso hace falta otra cosa. El mismo razonamiento de checksum local aplica a CURP y CLABE si necesitas ocultar PII mexicano antes de mandarlo a un LLM.

La verdad incómoda: el SAT no tiene API en tiempo real — solo el validador masivo .txt

Aquí es donde casi todos los tutoriales mienten por omisión. El SAT ofrece un validador oficial y gratuito (“Validación de la clave en el RFC”) que comprueba RFC, nombre, régimen fiscal y código postal. Lo puedes usar uno por uno, o masivo hasta 5,000 registros subiendo un archivo .txt delimitado por pipe (UTF-8, sin encabezado) con columnas consecutivo|RFC|nombre|CP:

1|EKU9003173C9|ESCUELA KEMPER URGATE SA DE CV|26015
2|XAXX010101000|PUBLICO EN GENERAL|64000

El detalle crítico: es una herramienta web / carga de archivo, NO una API REST en tiempo real. A día de hoy no existe una API oficial del SAT para validar por petición de forma automatizada en tu backend. Si tu onboarding necesita un “verificar” síncrono mientras el usuario teclea, el validador masivo no te sirve: está pensado para conciliar tu padrón completo en batch, no para responder en 200 ms.

Trátalo como lo que es: un job nocturno que pasa tu lista de clientes contra el SAT y te marca discrepancias, no un endpoint que llamas en el onChange del formulario.

Validar en tiempo real significa un web service de PAC (SW, Facturapi, Facturoporti)

Si de verdad quieres validación síncrona en el alta, la única vía es un web service de un PAC que envuelve la validación del SAT y te la expone como API. Proveedores como SW (Smarter Web), Facturapi o Facturoporti ofrecen un endpoint que recibe RFC + nombre + CP y te responde si el trío coincide con los registros del SAT.

// Validacion sincrona via web service de un PAC (pseudo-cliente)
async function validarReceptorPAC(receptor: {
  rfc: string; nombre: string; cp: string;
}) {
  const res = await fetch("https://api.tu-pac.com/v1/rfc/validate", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.PAC_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(receptor),
  });
  if (!res.ok) throw new Error(`PAC ${res.status}`);
  const data = await res.json();
  return data.valido as boolean; // coincide RFC + nombre + CP en el SAT
}

Decisión de arquitectura honesta: esto cuesta una llamada de red (y a veces dinero) por verificación. No la pongas en cada tecla. Llámala una vez, al final del formulario, con debounce, o difiérela hasta el primer timbrado real. Y guarda el resultado para no revalidar en cada factura.

Compatibilidad Régimen y Uso con c_RegimenFiscal y c_UsoCFDI

Aunque RFC, nombre y CP sean correctos, el timbrado todavía puede fallar por una combinación inválida: el Uso CFDI que elige el receptor debe ser compatible con su Régimen Fiscal. El SAT publica esa matriz de compatibilidad en los catálogos c_RegimenFiscal y c_UsoCFDI, y un par incompatible se rechaza en el timbrado.

Por ejemplo, un receptor en régimen 605 (Sueldos y salarios) no puede usar un uso CFDI reservado para actividad empresarial. Si tu dropdown de “Uso” muestra todas las opciones sin filtrar por el régimen elegido, vas a generar timbrados fallidos en producción.

{
  "regimen_to_usos": {
    "605": ["CP01", "S01"],
    "612": ["G01", "G03", "I01", "D01", "P01", "S01", "CP01"],
    "601": ["G01", "G03", "I01", "CP01", "S01"]
  }
}

Carga la matriz oficial del SAT, no esta muestra recortada, y filtra el segundo dropdown según el primero. Así el usuario solo ve usos válidos para su régimen y el timbrado no se cae por una combinación imposible.

El árbol de decisión del onboarding: dropdowns, verificación opcional y dejar que el timbrado detecte discrepancias

El flujo correcto no tiene ningún upload de PDF. Se ve así:

1. Valida el RFC localmente — formato + dígito verificador, en el servidor, sin red.
2. Recolecta CP, Régimen (c_RegimenFiscal) y Uso (c_UsoCFDI) con dropdowns, nunca con un PDF. El uso se filtra por el régimen.
3. Verifica opcionalmente RFC + nombre + CP contra el validador del SAT (batch) o un web service de PAC (en vivo).
4. Timbra. Recuerda que el timbrado de CFDI 4.0 falla por sí solo si RFC + nombre + CP + régimen no coinciden con los registros del SAT. La discrepancia se atrapa en el timbrado, con o sin tu verificación previa.

El punto 4 es liberador: el SAT ya es tu validador de última línea. No necesitas reconstruir su padrón ni exigir la CSF “por si acaso” — si los datos están mal, el PAC rechaza el comprobante y tú capturas ese error. Por eso conviene tener un outbox con idempotencia para tolerar fallas del PAC: el rechazo por datos del receptor es solo otro estado que tu pipeline maneja y reintenta tras corregir.

Este mismo patrón de “deja que el timbrado valide” sirve para todos tus comprobantes: la factura global de 24h, el complemento de pago (REP) y el CFDI de egreso para reembolsos heredan los mismos datos de receptor que validaste una sola vez en el alta.

Lo que NO debes hacer: guardar el PDF de la Constancia de Situación Fiscal y condicionar la factura a ella

Dos antipatrones que el Comunicado SAT 04/2026 vuelve directamente riesgosos:

• No condiciones la emisión de la factura a recibir la CSF/CIF. Eso es la infracción del CFF 83-IX, en el rango de ~$21,420 a $122,440 MXN. Tu botón de “Facturar” no debe estar bloqueado por un campo “Constancia”. El SAT también prohíbe exigir la Constancia de Situación Fiscal a los empleados para la nómina.
• No guardes el PDF de la CSF como requisito. Es PII fiscal que no necesitas: ya tienes RFC, nombre, CP, régimen y uso en campos estructurados. Almacenar el documento solo te agrega superficie de fuga y de cumplimiento sin ningún beneficio de timbrado.

Si hoy tienes ese upload en tu producto, el fix es directo: cámbialo por los dropdowns de régimen/uso, mueve la verificación a opcional/batch y deja que el timbrado sea tu validador final. Si vienes del hub de facturación CFDI, este flujo es el mismo que alimenta el CFDI de Nómina por API, donde el SAT además prohíbe pedir la Constancia de Situación Fiscal al empleado.

Ingeniero, no contador: confirma la multa y la fracción contra el CFF/RMF vigente

Para cerrar con honestidad: esto es sobre el flujo de alta y validación y sobre la ley tal como la fija el Comunicado SAT 04/2026, no es asesoría fiscal. El monto de la multa (~$21,420 a $122,440 MXN) y la fracción exacta (CFF 83-IX) debes confirmarlos contra el CFF/RMF vigente antes de citarlos en producción o a un cliente — los tramos del artículo 84 se actualizan. Para el patrón completo, revisa la guía hermana de validar el RFC sin la Constancia de Situación Fiscal.

La parte de ingeniería es estable y accionable hoy: valida el RFC localmente con el dígito verificador, captura los cinco datos con dropdowns filtrados por régimen, verifica en batch o vía PAC si lo necesitas, y deja que el timbrado de CFDI 4.0 atrape cualquier discrepancia. Nunca pidas la Constancia.

Fuentes:

• SAT — Comunicado y prensa (gob.mx/sat)
• SAT — Validación de la clave en el RFC (sat.gob.mx)
• Código Fiscal de la Federación, artículos 83 y 84 (Cámara de Diputados)