Datos fiscales del cliente

Casi todos los rechazos del SAT vienen de los datos del cliente: un nombre con «S.A. de C.V.», un código postal que no es el de su constancia, un régimen que no le toca. Hay dos maneras de tenerlos bien antes de timbrar.

Revisar los datos que ya tieneCopiar enlace a esta sección

POST /v1/tax_ids/validate revisa los datos sin timbrar ni gastar timbres, y le dice qué está mal y con qué valor corregirlo:

curl https://api.fiscalisto.com/v1/tax_ids/validate \
  -H "Authorization: Bearer $FISCALISTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "tax_id": "EKU9003173C9", "legal_name": "Escuela Kemper Urgate, S.A. de C.V.", "tax_system": "601", "zip": "42501", "use": "G03" }'

{
  "object": "tax_id_validation",
  "tax_id": "EKU9003173C9",
  "kind": "company",
  "valid": false,
  "checked_with_sat": false,
  "errors": [
    {
      "param": "legal_name",
      "code": "legal_name_capital_regime",
      "message": "Sin «S.A. de C.V.»: en CFDI 4.0 el nombre va sin régimen de capital, como en la constancia.",
      "suggestion": "ESCUELA KEMPER URGATE"
    }
  ],
  "warnings": [],
  "sat_record": null,
  "sat_error": null,
  "sat_lists": { "object": "sat_list_check", "listed": false, "risk": "none" }
}

Sin más, revisa lo que se puede saber sin preguntarle al SAT: el formato y la fecha del RFC, el nombre, que el régimen sea de persona moral o física según el RFC, que el código postal exista, que el uso del CFDI vaya con el régimen, los RFC genéricos y si el RFC está en las listas del SAT (eso llega en warnings). Cada problema trae param, un code estable para su código, un message para mostrarle a su usuario y, cuando se puede, suggestion con el valor correcto.

Compararlos con la constanciaCopiar enlace a esta sección

Si además manda cif_id, el idCIF que viene en la constancia de situación fiscal (arriba a la derecha, junto al código QR), Fiscalisto consulta el registro del SAT y compara nombre, código postal y régimen con lo que usted mandó. Entonces checked_with_sat es true y sat_record trae lo que dice el SAT:

"sat_record": { "legal_name": "ESCUELA KEMPER URGATE", "zip": "42501", "tax_systems": ["601"] }

Cada consulta al SAT cuenta en el límite del día; la misma constancia consultada dos veces en 24 horas cuenta una. Si el SAT tarda o no contesta, la revisión llega sin él, con el motivo en sat_error, y puede repetirla después.

Pedirle sus datos al clienteCopiar enlace a esta sección

Si no tiene los datos, o no confía en los que le dieron, pídaselos con una liga. Su cliente la abre en Fiscalisto, sube su constancia (o escribe sus datos) y antes de aceptarlos se revisan igual que arriba. A usted le llega un webhook.

curl https://api.fiscalisto.com/v1/customer_data_requests \
  -H "Authorization: Bearer $FISCALISTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "reference": "Pedido 1042", "description": "Para facturar su pedido 1042", "expires_in_days": 7 }'

{
  "id": "cdr_…",
  "object": "customer_data_request",
  "status": "open",
  "url": "https://fiscalisto.com/datos/…",
  "reference": "Pedido 1042",
  "expires_at": "2026-10-31T12:00:00-06:00",
  "submission": null
}

Mándele url a su cliente como quiera: en su correo, en su página de pedido o por WhatsApp. También puede mostrarla dentro de su página, con fiscalisto.js o @fiscalisto/react, como la autofactura. reference es su id del cliente o del pedido y description una línea de para qué son los datos; el cliente ve las dos arriba del formulario, y reference le regresa en el evento. La liga sirve 60 días si no dice otra cosa.

Cuando el cliente manda sus datos llega el evento customer_data_request.completed con la solicitud completa. En submission vienen los datos y customer, el cliente (cus_…) del emisor que ya puede usar al facturar:

"submission": {
  "tax_id": "PEPJ800101AB1",
  "legal_name": "JUAN PÉREZ LÓPEZ",
  "tax_system": "612",
  "zip": "06600",
  "use": "G03",
  "email": "juan@correo.mx",
  "source": "constancia",
  "customer": "cus_…",
  "applied": true
}

Un cliente nuevo se guarda directo en el catálogo del emisor (applied: true). Si el RFC ya era un cliente suyo y los datos cambian, no se sobrescribe solo: applied es false y usted decide si actualizarlo con POST /v1/customers/{id}. Así una liga no puede cambiar a quién se le mandan las facturas.

status es open, completed, expired o canceled; url solo viene mientras la liga está abierta.