TL;DR — Quick Summary

CFDI rejected because recipient RFC is on the SAT blacklist (Art. 69-B). Check EFOS status, validate customers before invoicing, and document the business relationship.

Diagram

When stamping a CFDI 4.0, your PAC or ERP may reject the invoice because the recipient RFC appears on the SAT blacklist — formally, the list of taxpayers flagged for allegedly nonexistent operations under Article 69-B of Mexico’s Federal Tax Code. This is not an XML or certificate error: it is a fiscal validation meant to protect the issuer from associating with EFOS (companies that invoice simulated operations) or recipients in serious noncompliance.

In accounting and accounts receivable, the message often surfaces at month-end, when a new client is loaded from an outdated catalog, or when the SAT publishes an updated roster your system has not synced yet. One blacklisted RFC can halt bulk invoicing if the ERP validates each recipient before stamping.

The Error

During stamping, the PAC or e-invoicing module may return:

“Recipient RFC is on the SAT blacklist”

“Recipient with Article 69-B noncompliance status — stamping not allowed”

“Presumed or definitive recipient RFC — operation blocked”

“EFOS validation: client RFC cannot receive CFDI”

The XML remains without a UUID and the internal folio stays pending. In API integrations, the HTTP response usually includes a PAC validation code referencing SAT lists or an RFC verification service.

Cause of the Problem

The SAT periodically publishes taxpayer lists at different 69-B procedure stages:

  1. Presumed: the SAT presumes nonexistent operations; the taxpayer may disprove the presumption.
  2. Definitive: presumption was not disproved in time; stronger fiscal consequences apply.
  3. Disproved: removed from the list after proving real operations.

Billing systems compare the recipient RFC in the CFDI Receptor node against:

  • SAT files or web services updated by the PAC.
  • Local databases downloaded by the ERP (Aspel, CONTPAQi, etc.).
  • Internal PAC rules that preventively block stamping.

Incorrect RFC capture

Sometimes the block does not match the real client:

  • Generic RFC XAXX010101000 or XEXX010101000 misused where an identified RFC is required.
  • Transposed digits when migrating catalogs from Excel.
  • Correct legal name but RFC from another company in the same corporate group.

Client newly added to blacklist

A client with a clean history may appear in a new Official Gazette publication. Your customer master did not update and next month’s invoice fails without any process change on your side.

Outdated catalog in ERP or PAC

If validation uses a local list copy not updated for weeks, you may get false negatives (allow stamping to EFOS) or false positives (block an already disproved RFC). Last sync date is the first field to review.

Real operation with noncompliant recipient

Even when the sale is legitimate, stamping to a Definitive RFC exposes the issuer to deductibility scrutiny, withholdings, and possible audits. That is why many PACs block preventively.

Step-by-Step Solution

1. Document the rejection

Save a screenshot of the error, recipient RFC, amount, line items, and attempt timestamp. For batch stamping, identify which invoices share the problematic RFC.

2. Check official status on SAT

Using the issuer’s e.firma or available public queries:

  1. Tax compliance opinion for the recipient RFC (if permitted or shared by the client).
  2. Article 69-B listing on the SAT portal.
  3. Tax situation certificate to confirm the active RFC matches your catalog.

Note whether status is Presumed, Definitive, or Disproved and the publication date.

3. Fix customer master data

In your ERP, open the customer catalog and verify:

  • 12- or 13-character RFC for legal entity or individual.
  • Name aligned with SAT certificate (CFDI 4.0 is strict).
  • Tax regime and recipient postal code matching fiscal address.

If RFC was wrong, correct and retry stamping. If correct and still blacklisted, proceed to step 4.

4. Assess risk with accounting

For Presumed clients, many firms suspend new invoices until the client shares disproof documentation. For Definitive clients, avoid additional CFDIs without fiscal counsel and documentary evidence (contract, delivery notes, SPEI transfers, acceptance minutes).

If service was already rendered and stamping is mandatory, your accountant will decide whether to invoice with documented reservations or issue a credit note and renegotiate.

5. Update PAC and ERP validations

In the PAC panel, review blacklist validation settings and force download of the updated roster. In Aspel SAE, CONTPAQi, or other ERP, run SAT catalog update utilities and enable pre-stamping alerts on sales orders if available.

6. Test stamp or release folio

After RFC correction or catalog update, issue a minimal test CFDI. Confirm UUID and original string. If the client remains blocked by internal policy, cancel the internal folio or hold it with an AR comment.

Prevention

  • Validate RFC on customer onboarding: check compliance opinion before opening commercial credit.
  • Weekly sync: schedule Article 69-B list updates in PAC or ERP.
  • Order alerts: block shipment if RFC falls on blacklist between order and invoice.
  • Quarterly audit: export active customers and cross-check against SAT list.
  • Sales training: blacklisted RFC is a fiscal issue, not only IT.

Summary

  • The error means the recipient RFC is in Article 69-B noncompliance or EFOS SAT validation.
  • Confirm official status, fix wrong RFC, and update PAC/ERP catalogs.
  • Do not ignore the block: document the operation and coordinate with accounting before stamping to Definitive recipients.
  • Prevention is RFC validation at onboarding and weekly list synchronization.