The SAT key comes first
In a SAT rejection, message starts with the key: «CFDI40143 - Este RFC del receptor no existe…». code carries 400, the same HTTP status as the response.
CFDI 4.0 recipient errors, what they mean and what to do
When your customer's RFC, name or postal code doesn't match the SAT's records, the API responds HTTP 400 with the error key. Here is every recipient key, how to read it from your system and how to fix it or stamp with the generic RFC.
What you need to read a rejection
What the response carries and what to do with it.
702, with per-field detail
If a value doesn't have the shape the SAT schema requires, code is 702 and errors carries the field and the value. That CFDI never reaches the SAT.
The full recipient list
CFDI40143 to CFDI40161, plus the keys tied to the generic RFC, with the wording of the SAT error matrix from July 2026.
A rejection uses no folio
A folio is deducted only when the SAT stamps. With Folio AUTO, the rejected CFDI's folio goes back to the counter.
Generic RFC fallback
The five fields to stamp to XAXX010101000 when your customer can't confirm their data, and what the SAT responds if one is off.
Try it in the sandbox
The test PAC checks the recipient against the SAT's list just like production, so you test your fallback with real rejections.
A recipient rejection, exactly as you get it
The stamping request is the usual one. What changes is the response: HTTP 400 with the cause in the body, so your system can decide whether to fix the value or stamp with the fallback.
Endpoints
- POST /invoice/create
- CFDI as JSON. A recipient rejection responds HTTP 400 with code 400 (SAT validation) or 702 (schema).
- POST /invoice/stampxml
- Already-sealed XML in Base64. SAT rejections arrive with the same key at the start of message.
- GET /validator/cfdi
- After stamping or cancelling: status with the SAT and, if you cancelled through the API, the cancellation dates.
- SAT validation: HTTP 400, code 400 and the key at the start of message (CFDI followed by five digits).
- Schema: HTTP 400, code 702, errorType cfdi_schema_validation and the errors list.
- The SAT text may be followed by « - Detalle: …»: match on the key.
- Retry 5037 (nothing was sent to the PAC) as is; with 5034, first look the CFDI up by its series and folio.
- Production
- https://app.facturadigital.com.mx/api/v5
- Sandbox
- https://sandbox-app.facturadigital.com.mx/api/v5
# FD_API=https://sandbox-app.facturadigital.com.mx/api/v5
curl -X POST "$FD_API/invoice/create" \
-H "X-Api-Key: $FD_API_KEY" \
--data-urlencode "json@factura.json"{
"message": "CFDI40143 - Este RFC del receptor no existe en la lista de RFC inscritos no cancelados del SAT.",
"code": 400
}{
"message": "El CFDI no cumple con el esquema del SAT. Se encontró 1 error de validación. Revisa el campo 'errors' para el detalle.",
"code": 702,
"errorType": "cfdi_schema_validation",
"docs": "https://docs.facturadigital.com.mx/errores/702",
"errors": [
{
"severity": "error",
"libxmlCode": 1839,
"message": "Elemento 'Receptor', campo 'Rfc': [faceta 'patrón'] El valor 'ZKA010101JWY' no está aceptado por el validador del SAT regex '[A-Z&Ñ]{3,4}[0-9]{2}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])[A-Z0-9]{2}[0-9A]'.",
"rawMessage": "Element '{http://www.sat.gob.mx/cfd/4}Receptor', attribute 'Rfc': [facet 'pattern'] The value 'ZKA010101JWY' is not accepted by the pattern '[A-Z&Ñ]{3,4}[0-9]{2}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])[A-Z0-9]{2}[0-9A]'.",
"element": "Receptor",
"namespace": "http://www.sat.gob.mx/cfd/4",
"field": "Rfc",
"value": "ZKA010101JWY",
"line": 4
}
]
}Your fallback in 4 steps
From the response to a stamped CFDI.
- 01
Read code
702: the value doesn't have the SAT's shape and errors says which one. 400: the SAT key is the first nine characters of message, such as CFDI40143.
- 02
Fix it or fall back
With the same value, the SAT gives the same answer. If you have the right value, fix it; if your customer can't confirm it, switch to the generic RFC.
- 03
Build the generic recipient
Rfc XAXX010101000, your customer's name, DomicilioFiscalReceptor equal to LugarExpedicion, RegimenFiscalReceptor 616 and UsoCFDI S01.
- 04
Ask for the certificate
Store the rejection key with your customer's data. Their Constancia de Situación Fiscal has the exact RFC, name, postal code and tax regime.
Recipient keys and how to fix them
Wording from the SAT's CFDI 4.0 error matrix (July 2026), plus the 702 from our schema check. The SAT tweaks the wording now and then; the key is what stays the same.
KeyWhen it happensWhat to do
702The value doesn't have the shape the SAT schema requires: an RFC structure the SAT doesn't accept, an empty Nombre or one with «|», a postal code that isn't five digits, or a regime, use or country outside its catalog.errors[].field names the field and errors[].value the value. Check the RFC against the SAT pattern before sending it; if it doesn't match, use the generic RFC.
CFDI40143The RFC isn't on the SAT's list of registered, active taxpayers: it doesn't exist, it was deregistered or a character is off.Confirm it with your customer's Constancia de Situación Fiscal. If they can't confirm it, use the generic RFC.
CFDI40144The Nombre isn't on the SAT's list of registered, active taxpayers.Use the legal name exactly as the certificate shows it, without the capital regime (S.A. de C.V.), which the certificate lists separately.
CFDI40145The Nombre doesn't belong to the RFC: the SAT has a different name on file for that RFC.Copy it letter by letter from the certificate, without the capital regime.
CFDI40146The Nombre is «PUBLICO EN GENERAL» and the RFC isn't XAXX010101000.That name only goes with the generic RFC XAXX010101000.
CFDI40147The DomicilioFiscalReceptor isn't on the SAT's list of registered, active taxpayers.Use the postal code of the tax address on your customer's certificate.
CFDI40148The postal code doesn't belong to the RFC. It arrives with the text «El campo Codigo Postal (DomicilioFiscalReceptor) no coincide con los registros del SAT».The right postal code is on your customer's certificate.
CFDI40149With a generic RFC (XAXX010101000 or XEXX010101000), DomicilioFiscalReceptor isn't equal to LugarExpedicion.With a generic RFC, the recipient's postal code is the same as LugarExpedicion.
CFDI40150ResidenciaFiscal isn't in the c_Pais catalog. You almost always see it as 702, because the schema catches it first.Use the three-letter c_Pais key.
CFDI40151ResidenciaFiscal is present with a registered RFC or with XAXX010101000.Remove ResidenciaFiscal: it only goes with the foreign generic RFC XEXX010101000.
CFDI40152ResidenciaFiscal is MEX.ResidenciaFiscal isn't used for a recipient in Mexico.
CFDI40153ResidenciaFiscal is missing with XEXX010101000 and the foreign trade complement, or with NumRegIdTrib.Add the recipient's country with its c_Pais key.
CFDI40154NumRegIdTrib is present with a registered RFC or with XAXX010101000.Remove NumRegIdTrib.
CFDI40155NumRegIdTrib is present without the foreign trade complement or without XEXX010101000.NumRegIdTrib goes with XEXX010101000 and the foreign trade complement; in that case it's required.
CFDI40156NumRegIdTrib doesn't follow the format c_Pais publishes for that country.Check the country's tax ID format in c_Pais.
CFDI40157RegimenFiscalReceptor isn't in c_RegimenFiscal. You almost always see it as 702.Use the three-digit regime key from the certificate.
CFDI40158The regime doesn't match the type of taxpayer: a 12-character RFC is a company and a 13-character one is an individual.Use a regime from the certificate that c_RegimenFiscal allows for that type of taxpayer.
CFDI40159With a generic RFC, RegimenFiscalReceptor isn't 616.With XAXX010101000 or XEXX010101000, the regime is 616.
CFDI40160UsoCFDI isn't in c_UsoCFDI. You almost always see it as 702.Use a current c_UsoCFDI key.
CFDI40161The UsoCFDI doesn't apply to the recipient's type of taxpayer or regime.In c_UsoCFDI each use lists the regimes that allow it. With regime 616, use S01.
CFDI40130An income invoice to XAXX010101000 with Nombre «PUBLICO EN GENERAL» and no InformacionGlobal node.If it's a global invoice, add InformacionGlobal. If it's an invoice for one customer, put their name in Nombre.
The fallback recipient
The five recipient fields with the generic RFC. With Nombre «PUBLICO EN GENERAL», the SAT treats it as a global invoice and requires InformacionGlobal (CFDI40130); for an invoice to one customer, use their name.
{
"LugarExpedicion": "64000",
"Receptor": {
"Rfc": "XAXX010101000",
"Nombre": "YOUR CUSTOMER NAME",
"DomicilioFiscalReceptor": "64000",
"RegimenFiscalReceptor": "616",
"UsoCFDI": "S01"
}
}Keep going
Cancellation
Cancel with reasons 01 to 04 and check the cancellation status with the SAT.
Sandbox
Test your rejections and your fallback for free, with the same API v5 as production.
API v5
Authentication, endpoints and the three ways to stamp: JSON, XML in Base64 or an XML file.
Questions about recipient errors
Something missing? Write to us or check the full reference.
How do I tell a recipient error apart in my code?
Both arrive with HTTP 400. If code is 702, the value doesn't have the SAT schema's shape and errors gives you the field and the value. If code is 400 and message starts with CFDI followed by five digits, it's a SAT validation and that's the key, for example CFDI40143. Match on the key, not on the text, which the SAT tweaks now and then.
Where is the official list of these errors?
On the SAT portal, in the Anexo 20 documentation: «Matriz de errores CFDI versión 4.0». The table on this page has every Receptor key from the July 2026 version and the keys tied to the generic RFC.
Does retrying with the same RFC help?
No: as long as the value doesn't change, the SAT gives the same answer. Fix the value or stamp with the generic RFC. The one to retry as is is 5037, when the PAC couldn't be reached and nothing was sent. With 5034 the outcome is uncertain: first look the CFDI up by its series and folio.
Can I check the RFC before stamping?
Its shape, yes, at no cost: the SAT accepts an RFC that matches the pattern [A-Z&Ñ]{3,4}[0-9]{2}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])[A-Z0-9]{2}[0-9A]. If it doesn't match, the response is 702 and you can go straight to the generic RFC. Whether the RFC is registered, with that name and that postal code, is confirmed by the SAT when stamping; your customer's Constancia de Situación Fiscal has the exact data.
Why is fecha_cancelacion null in /validator/cfdi?
The SAT's status service doesn't return the cancellation date. We take it from the acknowledgment the SAT issues when you cancel through the API. If the SAT cancelled on receiving the request (estatuscancelacion «Cancelado sin aceptación»), that's the date and it comes in fecha_cancelacion. If it was cancelled later, because your customer accepted («Cancelado con aceptación») or because their time to respond ran out («Plazo vencido»), the SAT doesn't publish that moment: fecha_cancelacion is null and fecha_solicitud_cancelacion holds when you requested it. While your customer hasn't answered («En proceso») you also get only the request date. Both are null if the CFDI was cancelled outside Factura Digital, and in the sandbox, because the SAT doesn't know test CFDIs. Dates are in central Mexico time.
Can I test these rejections in the sandbox?
Yes. The test PAC checks the recipient against the SAT's list, so an unregistered RFC, or a name or postal code that doesn't match, responds with the same keys as in production. It's free and your sandbox account is separate from production.
Test your fallback in the sandbox
The test PAC checks the recipient just like production. It's free and a rejection uses no folio.