Lista 69-B: check suppliers against SAT's list

If you buy from suppliers in Mexico, keep an eye on Lista 69-B (the SAT list of taxpayers presumed to issue invoices for nonexistent transactions, under Article 69-B of the Federal Tax Code). Its risk lies less in the invoice you receive tomorrow than in the one you paid two years ago. The SAT (Mexico's tax authority, Servicio de Administración Tributaria) publishes it, so you'll also see it called the SAT 69-B list.

That's the part almost nobody explains well. When the SAT publishes an issuer on the definitive list under Article 69-B, its CFDIs (Mexico's electronic invoices) "no producen ni produjeron efecto fiscal alguno": they don't produce, and never produced, any tax effect. The past tense isn't a drafting slip. A transaction you recorded, paid, and deducted in 2024 can lose its tax support in 2026, when the supplier shows up in the DOF (Diario Oficial de la Federación, Mexico's official gazette).

If your group operates in Mexico through a subsidiary, that subsidiary is the one that recorded and deducted those CFDIs. And it usually finds out because someone in accounting checked the list. Or because a request from the SAT arrived.

What is the SAT 69-B list

Lista 69-B is the list the SAT publishes of taxpayers that issued CFDIs without the assets, staff, infrastructure, or material capacity to provide the services or produce the goods those CFDIs cover. It also includes taxpayers the SAT couldn't locate. It's published in the DOF and on the SAT website.

In everyday language, these taxpayers are called EFOS (Empresas que Facturan Operaciones Simuladas, taxpayers that issue invoices for simulated transactions), which is why you'll also hear Lista 69-B called the EFOS list. The taxpayer on the other side of the transaction, the one that deducted those invoices, is called an EDOS. Neither term appears in the Código Fiscal de la Federación (Mexico's Federal Tax Code), but you'll read both in any official notice from the SAT.

The SAT presumes that the transactions didn't exist. The technical validity of the CFDI is a separate question. A CFDI from an EFOS is perfectly stamped (stamping: the certification by a SAT-authorized provider that makes a CFDI valid). It has a UUID (folio fiscal, the unique ID the PAC assigns when it stamps a CFDI) and a SAT seal (the seal inside the digital tax stamp that certifies the CFDI). Its status is active (vigente: not canceled with the SAT). It passes every cryptographic check. And you still can't deduct it.

The four stages of the 69-B listing

An RFC (Mexico's taxpayer ID, Registro Federal de Contribuyentes) isn't either "on the list" or "off the list." It's at a stage, and each stage has a different effect:

The difference between presumed and definitive is the one that causes the most trouble in practice. I've seen accounts payable teams block payments to a supplier because it showed up as presumed, when at that point the issuer still has the right to rebut and its CFDIs still have tax effect. Blocking there is a legitimate business decision, but it has no tax basis. Mixing up the two ends in an awkward call with the supplier.

The deadlines in the procedure

Months go by between the SAT's notice and the publication of the definitive list, and each step has its own deadline in Article 69-B of the Código Fiscal de la Federación:

Within the first 20 days of that 50-day period, the authority can request additional information. The taxpayer has 10 days to respond, and the review period is suspended in the meantime. It's the kind of detail that doesn't change your integration, but it explains why an RFC can stay presumed for months with nothing visible happening.

What happens if your supplier is on the definitive list

From here on, the problem is yours more than the supplier's.

Article 69-B gives whoever gave tax effect to those CFDIs 30 business days, counted from the publication of the definitive list in the DOF, to do one of two things: prove to the authority that it did in fact acquire the goods or receive the services, or correct its tax situation by filing an amended return.

Proving the transaction took place takes more than showing the invoice. The invoice is exactly what's in doubt. You show contracts, proof of delivery, warehouse receipts, logs, emails, payment records, service reports. Anything that proves the transaction existed in the physical world. If that evidence wasn't created at the time, you can't manufacture it later.

The deadline is the same for every recipient in the country and can't be extended. That's why monitoring the list matters more than validating on receipt: a supplier that's clean today can be published six months from now, and the clock starts with the publication, not with your quarterly review.

Lista 69-B Bis isn't the same as 69-B

This mix-up keeps showing up in forums, at accounting firms, and in more than one top-ranking article on the Mexico SAT blacklist.

Lista 69-B Bis (the SAT list of taxpayers involved in a presumed improper transfer of the right to offset tax losses, under Article 69-B Bis of the Federal Tax Code) works differently. The SAT can presume that improper transfer when a taxpayer with losses takes part in a restructuring, spin-off, merger, or change of shareholders, stops being part of the group it belonged to when it generated the loss, and meets one of the conditions that article lists. The notified taxpayer has 20 days to respond.

The effect is different: the tax loss can't be offset. The issuer's CFDIs keep their tax effect as usual. If one of your suppliers appears on Lista 69-B Bis, your deductions don't fall apart because of it.

So why check it? Because it's a risk signal about the counterparty, not about the CFDI. If you're evaluating a supplier for a multi-year contract, financing a transaction, or reviewing related parties in a restructuring, that publication is relevant information. Treating it as if it invalidated invoices is wrong. Ignoring it is a mistake too.

How to look up a supplier on Lista 69-B

There are three ways, and they aren't equivalent.

If you go with the file, get ready for what nobody documents. The encoding isn't always UTF-8, so names with accents arrive garbled if you open the file assuming it is. Some RFCs have trailing spaces. The date format has changed between publications. And the same RFC shows up once for every stage it has gone through, with no column that tells you which one is current: you work that out yourself, sorting by publication date.

None of that is hard. The hard part is when it breaks silently six months later, when a column changes and your month-end close keeps running green on a file it no longer parses correctly.

Common mistakes when screening suppliers against Lista 69-B

Checking only once, when you onboard the supplier. It's the most expensive mistake. By design, the publication comes after the transaction. A supplier vetted at onboarding protects you from nothing if it gets published two years later.

Not saving the cutoff date of the list. When your validation result says "not listed," that statement is true for a list with a specific date. Without that date, the record doesn't work as evidence of due diligence. Save the verdict together with the cutoff.

Searching by name or legal name (as registered with the SAT). Names have variants, abbreviations, "S.A. de C.V." with and without periods. The RFC is the only reliable identifier.

Treating presumed as definitive. I mentioned it already, and I'm repeating it because it keeps happening. They're two stages with different effects.

Validating only new CFDIs. Your historical supplier base is where the accumulated risk lives.

Automating 69-B screening

In Fiscalapi, checking Lista 69-B and Lista 69-B Bis covers two of the seven criteria in the CFDI validation API, and they're the only ones that run without an XML: you send the issuer's RFC and get its current status and the cutoff date of the list. That date is what works as evidence, and it's exactly what gets lost when someone checks by hand.

Nobody maintains files, nobody parses the DOF, nobody finds out in December that the format changed in August.

CFDI validation API

Check Lista 69-B and Lista 69-B Bis by RFC, or validate the full CFDI against the SAT's seven official criteria in a single call. A free test environment account and SDKs for .NET, TypeScript, Python, PHP, and Java.

See the seven criteria

If you already use bulk download (the SAT service that delivers the CFDIs a taxpayer issued and received), you have the input ready: pull the unique issuer RFCs from the CFDIs you received and run them against the list in one pass. It's the fastest way to put a number on your historical exposure.

The response contract and the official SDKs are in the documentation. To try it before you integrate, signing up for the test environment is free, and in production each validated criterion costs $0.50 MXN, IVA (Mexico's value-added tax, VAT) included. Validation plans start with a minimum purchase of 200 validations.

Frequently asked questions about Lista 69-B

If you've never run your historical supplier base against the definitive list, that's the first job. Before daily monitoring, before validation on receipt. First find out how much risk is already recorded in your books, because that number exists today, whether or not it's on your dashboard.