SAT lists (articles 69, 69-B and 69-B Bis of the Federal Tax Code) explained for compliance teams

Almost every customer or supplier onboarding process in Mexico includes a check against "the SAT lists". The expression is convenient, but it mixes different publications, with different legal grounds and consequences. For a compliance team, understanding what each list says is as important as querying it, because that determines how a match is interpreted. In this article we explain the three main publications, why it makes sense to query them from a system and how to handle false positives.

Three lists, three meanings

The Federal Tax Code (Código Fiscal de la Federación, CFF) empowers the SAT, Mexico's tax authority, to publish information about taxpayers in various situations. The three most frequently checked lists are:

• Article 69 (published taxpayers). It includes taxpayers in situations of non-compliance, such as final or enforceable unpaid tax debts, taxpayers who cannot be located, cancelled or forgiven tax debts, criminal convictions for tax offenses or revoked digital seal certificates, among other cases. The SAT publishes it in several files, one per case type, and the same RFC may appear in more than one.
• Article 69-B (presumably non-existent operations). This is the list of so-called EFOS: taxpayers whom the SAT presumes issued invoices without having the assets, staff or capacity to provide the services or deliver the goods they billed. The procedure has stages: taxpayers are first published as presumed, given a period to rebut the presumption, and may then be listed as definitive, rebutted or with a favorable ruling. Those who received invoices from a definitive taxpayer also face consequences, since they must prove the operations took place or correct their tax position.
• Article 69-B Bis (improper transfer of tax losses). It covers taxpayers that, in the SAT's view, improperly transferred tax losses, for example through restructurings or changes of shareholders without a business reason. It is a much shorter list, but no less relevant.

The distinction matters. A taxpayer with an enforceable tax debt on the article 69 list is not an EFOS, and treating it as one leads to disproportionate decisions. Likewise, a presumed taxpayer under 69-B is not in the same situation as a definitive one. That is why a useful result does not just say "found", but in which list, under which case type or stage and with what publication date.

Why manual checks do not scale

Checking these lists by hand means downloading files from the SAT portal, opening them in a spreadsheet and searching by RFC or by name. It works for a handful of cases a month, but it has well-known problems:

1. The lists change. The SAT updates its publications periodically, and a check made with a file from weeks ago may not reflect the current situation.
2. No structured evidence is left. A screenshot says little about which version of the list was checked and with what search criteria.
3. Name search is fragile. Accents, abbreviations such as "S.A. de C.V.", the order of surnames or typing errors cause an exact search to miss real matches.
4. Tax lists are not the only ones. A reasonable due diligence process also checks international lists, such as the SDN list of the US Treasury's Office of Foreign Assets Control (OFAC) and the UN Security Council consolidated sanctions list.

Approximate search and false positives

When the RFC is available, the check should start there: it is the most reliable identifier for the SAT lists. But it is not always available, and international lists do not use RFC. Searching by name requires techniques that tolerate differences in spelling:

• Normalization: removing accents, punctuation and common corporate suffixes before comparing.
• Order-independent comparison: "Pérez López Juan" and "Juan Pérez López" should be compared as the same name.
• String similarity: measuring how similar two names are instead of requiring an exact match.
• Phonetic search: finding names that sound the same even when spelled differently, which is common in transliterations on international lists.
• Aliases: on lists such as OFAC's, a person may appear under several names, and each one must be compared separately.

The counterpart is the false positive: a namesake or a similar name that is not the same person. Tuning the similarity threshold is a balance. Too strict, and real matches are missed; too loose, and the team is flooded with alerts. In anti-money-laundering work, missing a real match is more serious than reviewing a false positive, so the reasonable approach is for the system to propose candidates with a score and for a person to dismiss or confirm them with additional data, such as RFC, CURP, date of birth or address.

A match on a list is not a conclusion, it is the start of a review. What the system must deliver is enough context to resolve it quickly and leave a record.

Querying from a system

Integrating the check into the onboarding flow solves most of these problems: each customer or supplier is checked at the moment they are registered, the result is stored with the date of the check and the lists stay current without anyone having to download them.

That is why we built AmigoApi: a single REST endpoint that checks the SAT lists under articles 69, 69-B and 69-B Bis together with OFAC and the UN, with approximate and phonetic search, aliases and a score per result. Each match indicates its source list and, for article 69, every case type under which the taxpayer appears. Sources are updated automatically and changes are detected in each publication.

If your team checks these lists by hand and wants to integrate them into its process, Write to us.