Generic RFC: XAXX010101000 and XEXX010101000
April 6, 2026
Mexico has two RFCs (Mexico's taxpayer IDs, Registro Federal de Contribuyentes) that belong to no person or company, yet they show up on millions of invoices every month. They're called generic RFCs, and they're how the SAT (Mexico's tax authority, Servicio de Administración Tributaria) says "I don't know who the recipient is, but the invoice still has to exist." If you build invoicing systems or keep the books for a business with counter sales, these two values are part of your daily work: XAXX010101000 and XEXX010101000.
One is for when you sell to someone in Mexico who doesn't give you their RFC. The other is for when you sell to a foreigner who has no Mexican RFC. It sounds simple. But the rules for using them in version 4.0 of the CFDI (Mexico's electronic invoice) have nuances that get invoices rejected at stamping (the certification by a SAT-authorized provider that makes a CFDI valid) far more often than they should.
The SAT's two generic RFCs
The SAT defines exactly two generic RFCs. There's no third one, there are no variants, and you can't make up your own.
XAXX010101000
Generic domestic RFC: for the general public (customers who did not ask for their own CFDI).
Use it when the invoice recipient is someone in Mexico who doesn't provide their RFC. The classic case: counter sales, point of sale, stores where the customer pays and leaves without asking for an individual invoice.
- Name on the CFDI:
PUBLICO EN GENERAL - Tax regime (régimen fiscal, the SAT category a taxpayer is registered under, such as
601or626):616(Sin obligaciones fiscales, no tax obligations) - CFDI use (how the recipient will use the CFDI for tax purposes):
S01(Sin efectos fiscales, no tax effect) - Tax address (the address registered with the SAT; a CFDI 4.0 carries only its postal code): the issuer's postal code, the same value as
LugarExpedicion
XEXX010101000
Generic RFC for foreigners: foreign individuals and entities without a Mexican RFC.
Use it when you sell to a foreign customer who has no RFC in Mexico. Tourists who buy in your store, companies in other countries that hire your services, export transactions.
- Name on the CFDI: the foreigner's real name
- Tax regime:
616(Sin obligaciones fiscales, no tax obligations) - CFDI use:
S01(Sin efectos fiscales, no tax effect) - Tax address: the issuer's postal code too (
LugarExpedicion), the same as with XAXX010101000
Don't mix up XAXX and XEXX. The A is for "anónimo" (anonymous, domestic) and the E is for "extranjero" (foreign). A one-character mistake in the generic RFC completely changes the type of transaction in the SAT's eyes. I've seen databases where someone stored XEXX for Mexican counter customers and nobody noticed until the SAT cross-referenced the data. If you're not sure whether a string is a valid generic RFC or a malformed RFC, the RFC format tool confirms its structure in seconds.
When to use each generic RFC
The general rule is straightforward: if you know the recipient's RFC, use it. Generic RFCs are the last resort, not the convenient option.
| Situation | RFC to use | Reason |
|---|---|---|
| Counter sale, the customer doesn't ask for an invoice | XAXX010101000 | No tax details for the recipient |
| Global invoice (factura global, one CFDI that groups a period's sales to the general public) for a day's, week's, or month's sales | XAXX010101000 | The recipient is the "general public" |
| Sale to a foreign tourist without a Mexican RFC | XEXX010101000 | No Mexican RFC exists for the recipient |
| Export of goods or services | XEXX010101000 | The recipient is a foreign entity |
| Mexican customer who did provide their RFC | The customer's real RFC | The specific RFC always prevails |
| Foreign company with a permanent establishment in Mexico | The company's real RFC | It has a Mexican RFC, so the generic one doesn't apply |
If a Mexican customer tells you "put the generic RFC" but you already have their RFC in your system, don't do it. The SAT may read it as helping the recipient get around the rules on deducting that expense. Using the generic RFC when you know the real one does the customer no favors: it creates a tax risk for both parties.
CFDI fields with a generic RFC
When you use a generic RFC, the fields of the Receptor node in a CFDI 4.0 take specific values you can't change. If you send the wrong combination, the PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs) refuses to stamp it. More in the CFDI stamping guide.
| CFDI field | XAXX010101000 (domestic) | XEXX010101000 (foreign) |
|---|---|---|
ReceptorRfc | XAXX010101000 | XEXX010101000 |
ReceptorNombre | PUBLICO EN GENERAL | The foreigner's real name |
DomicilioFiscalReceptor | Same as LugarExpedicion | Same as LugarExpedicion |
RegimenFiscalReceptor | 616 | 616 |
UsoCFDI | S01 | S01 |
Note that tax regime 616 (Sin obligaciones fiscales, no tax obligations) is the only valid regime with a generic RFC, and CFDI use S01 (Sin efectos fiscales, no tax effect) is the use the SAT's filling guides call for. You can't set G03 as the CFDI use or 601 as the tax regime of the generic recipient. The PAC rejects both because those combinations assume an identified recipient with real tax obligations. More in the Spanish-language tax regime guide and the Spanish-language CFDI use guide.
For XAXX010101000 on a global invoice, the ReceptorNombre field must be exactly PUBLICO EN GENERAL, in uppercase, without accents. Not "Público en General", not "PUBLICO GENERAL", not "PUB. EN GRAL.". The SAT's global invoice guide requires that literal string, and the PAC uses it to require the InformacionGlobal node.
Global invoice
The global invoice is an income CFDI (type I, the regular sales invoice) that groups all of a period's sales to the general public. If you run a store, a restaurant, or any business with counter sales where customers don't ask for an individual invoice, the global invoice is how you meet your obligation to report those transactions.
Since 2022, the SAT has required every taxpayer to issue a global invoice for the sales that didn't get an individual CFDI. It isn't optional.
How the global invoice is structured
The global invoice always uses the generic domestic RFC XAXX010101000, but it also requires specific fields that a regular invoice doesn't have.
The Periodicidad field says how often you issue the global invoice. The options are 01 (daily), 02 (weekly), 03 (semi-monthly), 04 (monthly), and 05 (bimonthly, every two months). Most small businesses go with monthly. Businesses with a high volume of cash transactions tend to prefer daily or weekly.
The Meses and Año fields specify the period the invoice covers. The month goes as a two-digit code (01 to 12, plus 13 to 18 for two-month periods). The year is the tax year, in four digits.
Each line item in the global invoice corresponds to one sales receipt: the receipt's number or transaction number goes in NoIdentificacion, with ClaveProdServ 01010101, Cantidad 1, and ClaveUnidad ACT. What you can't do is add a single line with the total and call it done: the SAT expects one line item per sales receipt, and one per rate when a receipt mixes IVA (Mexico's value-added tax, VAT) rates. The exception is individuals under RESICO (Régimen Simplificado de Confianza, Mexico's simplified tax regime for small taxpayers) or the RIF (Régimen de Incorporación Fiscal, a small-taxpayer regime closed to new taxpayers since 2022): under Rule 2.7.1.21 of the Resolución Miscelánea Fiscal (RMF, the SAT's annual tax rules), their global invoice includes only the total amount of the period's sales.
Stamp it with the generic data#
The global invoice goes out with RFC XAXX010101000, name PUBLICO EN GENERAL, regime 616, and use S01. The form of payment (how the customer paid: cash, bank transfer, card; the FormaPago key) must be the one used to pay the largest sales receipt in the global invoice (usually 01, cash, or 03, bank transfer). More in the CFDI form of payment guide.
| Global invoice field | Value | Description |
|---|---|---|
InformacionGlobal:Periodicidad | 01-05 | How often it's issued |
InformacionGlobal:Meses | 01-18 | Month or two-month period |
InformacionGlobal:Año | 2026 | Tax year |
TipoDeComprobante | I | Always an income CFDI |
MetodoPago | PUE | Paid in full when the CFDI is issued (Pago en una sola exhibición) |
ReceptorRfc | XAXX010101000 | Generic domestic RFC |
Common generic RFC mistakes
These are the mistakes that show up again and again in years of stamping logs.
The generic RFC for foreigners in export sales
When you sell goods or services to a foreign customer, the CFDI has extra requirements beyond the generic RFC XEXX010101000.
The Exportacion field of the Comprobante node takes an export key instead of 01 (not applicable), for example 02 (definitive, with customs key A1) or 03 (temporary), depending on the type of export. If the transaction involves moving goods, you probably need a complement (complemento, an XML extension the SAT defines for specific operations) called Carta Porte, the CFDI complement that documents the transport of goods in Mexico. And if you receive the payment in a foreign currency, the CFDI must record the day's exchange rate.
Unlike the generic domestic RFC, with XEXX010101000 you can (and should) put the foreigner's real name in the ReceptorNombre field. The SAT needs to know who you sold to, even if they don't have a Mexican RFC.
| Aspect | Domestic sale with a generic RFC | Export with a generic RFC |
|---|---|---|
| RFC | XAXX010101000 | XEXX010101000 |
| Recipient name | PUBLICO EN GENERAL | The foreigner's real name |
| Export | 01 (No aplica, not applicable) | Another key, such as 02 or 03 |
| Currency | Usually MXN | Can be USD, EUR, etc. |
| Exchange rate | Not applicable | Required if it isn't MXN |
| Additional complements | None (or Carta Porte if goods are moved) | May require Comercio Exterior (the CFDI foreign trade complement for exports) |
The Comercio Exterior complement isn't always mandatory for exports. It's required when Exportacion is 02, optional with 04, and must be omitted with 03. But when it applies, it's another full node in the XML, with data on the consignee, the goods, the fracciones arancelarias (Mexico's 8-digit tariff codes: the 6-digit Harmonized System code plus 2 Mexican digits), and the addresses. Refer to the SAT's guide for your specific case.
How to automate generic RFCs with an API
If you're building an invoicing system, the generic RFC logic belongs in your business layer, not in the user interface. When a sale is marked as "sale to the general public" or "foreign customer without an RFC," your system should automatically apply all the right values: RFC, name, regime, CFDI use, and tax address.
Don't make anyone type XAXX010101000 by hand into a text field. That's asking for typos in a 13-character alphanumeric value that the PAC validates character by character.
Fiscalapi enforces these rules before stamping. If you send a CFDI with a generic RFC through the Fiscalapi API, Fiscalapi validates the generic RFC rules (regime 616, a recipient postal code equal to the place of issue, and the InformacionGlobal node on a global invoice) before it sends the CFDI to the PAC, and returns a validation error that names the field to fix. You can review the SDKs on GitHub to see how to implement the logic in your stack.