RFC in Mexico: tax ID number format and examples

Any company operating in Mexico, paying Mexican vendors, or invoicing Mexican customers eventually runs into the RFC (Mexico's taxpayer ID, Registro Federal de Contribuyentes). Without a valid RFC on both sides of a transaction, no invoice can be issued, no expense can be deducted, and no payment can be properly documented for tax purposes. For foreign businesses, the RFC is the single most important identifier to understand before opening operations in Mexico or sourcing from Mexican suppliers.

This guide covers what the RFC in Mexico is, how its format works, who needs one, how foreign companies and individuals fit into the system, and how the RFC connects to the CFDI (Mexico's electronic invoice), the core of Mexico's e-invoicing regime.

What is the RFC

The RFC is Mexico's federal taxpayer registry number and the official Mexico tax ID. It is the unique tax identification code that the SAT (Mexico's tax authority, Servicio de Administración Tributaria) assigns to every individual and entity with tax obligations in the country.

Functionally, the RFC plays the same role as the EIN in the United States, the VAT number in the European Union, or the CNPJ in Brazil. Every fiscal interaction in Mexico runs on RFCs: invoices, payroll, withholdings (retención), tax returns, customs declarations, and bank reporting.

RFC format and structure

The RFC follows a deterministic format based on the taxpayer's legal name and date of inception. There are two variants depending on whether the holder is an individual (persona física) or a legal entity (persona moral).

RFC for individuals (personas físicas)

Thirteen characters, structured as four letters, six digits, and three alphanumeric characters.

A full example: MERC850315H38.

RFC for companies (personas morales)

Twelve characters, structured as three letters, six digits, and three alphanumeric characters.

A full example: FAP200115XYZ.

The homoclave is the part that frequently causes integration errors. It is not derived algorithmically from public data; SAT assigns it. Any system that attempts to "compute" a full RFC without the homoclave will produce invalid codes. The complete RFC must always be obtained from the SAT or from the taxpayer directly.

Who needs an RFC

The RFC is required in three primary scenarios:

• Mexican residents (individuals). Anyone earning income in Mexico, whether as an employee, self-employed professional, or business owner, must register and obtain an RFC.
• Mexican companies. Any legal entity incorporated in Mexico is automatically required to register upon incorporation.
• Non-residents with Mexican income. Foreign individuals or entities receiving income from Mexican sources may need to register, depending on the type of income and applicable tax treaties.

For foreign companies that do not have a Mexican subsidiary but interact with Mexican counterparties, two situations are common: receiving an invoice from a Mexican vendor (no foreign RFC needed) and being invoiced by a Mexican customer (no foreign RFC needed for the customer either, since the issuer's RFC is what matters). The complication appears when a foreign company has employees or a permanent establishment in Mexico; in that case, registration becomes mandatory.

Generic RFCs for foreign parties

Mexico's tax code provides two reserved generic RFC codes for transactions where the counterparty does not have a Mexican RFC. These are critical for cross-border operations.

The detailed rules for each generic RFC are covered in the generic RFC guide. Two operational notes that matter for foreign companies:

• When a Mexican company invoices a foreign customer, the CFDI is issued to XEXX010101000. The foreign customer's actual tax ID and country are recorded in dedicated XML fields (NumRegIdTrib and ResidenciaFiscal), not in the RFC field.
• Those fields become mandatory when the CFDI carries Comercio Exterior (the CFDI foreign trade complement for exports), and the PAC checks the tax ID against the format set for the customer's country. Missing them causes the stamping (the certification by a SAT-authorized provider that makes a CFDI valid) to fail.

How a foreign company obtains an RFC

A foreign entity that needs an actual RFC (not a generic one) must go through SAT registration. This applies when the company has a permanent establishment, hires local employees, or generates Mexican-source income subject to direct taxation.

For individuals (foreign residents working in Mexico, expats with local income, freelancers invoicing Mexican companies), the process is simpler and can be initiated online if the person has a CURP (Mexico's population registry ID, Clave Única de Registro de Población). Without a CURP, an in-person appointment is required.

RFC validation

Before issuing or accepting an invoice, the RFC must be validated. There are three levels of validation, each with different reliability.

Format validation

Confirms the RFC follows the expected structure (13 characters for individuals, 12 for companies, with the correct letter and digit positions). Format validation catches typos but does not confirm the RFC exists.

SAT validation service

The SAT exposes a free validation service that confirms whether an RFC is registered, active, and whether the associated tax regime (régimen fiscal, the SAT category a taxpayer is registered under, such as 601 or 626) matches what is being declared. This is the only authoritative validation method.

The service accepts a list of RFCs and returns, for each one, the registration status, the registered name or business name (when public), the tax regime, and whether the taxpayer is eligible to issue CFDIs.

Real-time validation in invoicing

When a CFDI is stamped, the PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs) performs an automatic SAT validation of both the issuer and the recipient. Recipient data that doesn't match the SAT registry causes stamping to fail with specific error codes: CFDI40143 when the RFC isn't registered, CFDI40145 when the name doesn't match, and CFDI40147 when the postal code doesn't match. Issuing systems must handle these failures gracefully and surface them to the user before the transaction is committed.

How the RFC affects e-invoicing

The RFC is embedded in every CFDI as both the issuer (Emisor) and recipient (Receptor) identifier. Five fields make the connection between the RFC and the broader CFDI compliance system.

The last three fields are why CFDI 4.0 increased the integration burden. Before 4.0, only the RFC was required. Today, the recipient's tax regime and postal code must be obtained, validated, and submitted with every invoice. For Mexican companies invoicing Mexican customers, this means requesting a Constancia de Situación Fiscal (the SAT tax status certificate) before issuing the first invoice. For cross-border invoicing using the generic RFC XEXX010101000, the equivalent foreign-jurisdiction data is captured in specific XML fields instead.

Common scenarios for foreign businesses

The following situations cover most cases foreign companies encounter when interacting with Mexico's invoicing system.

Invoicing a Mexican customer from abroad

A foreign company sells software, services, or goods to a Mexican company. Two paths exist:

• The foreign company has no Mexican RFC. The Mexican customer cannot deduct the expense through a CFDI process. Some Mexican companies accept foreign invoices as deductible expenses under the rules for foreign payments, but this requires additional documentation and withholding compliance. The Mexican counterparty's tax advisor should confirm whether the foreign invoice is acceptable.
• The foreign company has a Mexican subsidiary or permanent establishment. The subsidiary issues the CFDI to the Mexican customer using its own RFC, while the inter-company arrangement handles the rest internally.

Receiving an invoice from a Mexican vendor

A foreign company purchases services from a Mexican supplier. The Mexican vendor issues a CFDI to XEXX010101000 (the generic foreign-resident RFC), including the foreign company's actual tax ID and country in the CFDI's dedicated foreign-party fields. The foreign company can use this CFDI as documentary support, though deductibility in the foreign country follows that country's own rules.

Paying Mexican contractors or freelancers

A foreign company hires a Mexican freelancer or consultant. The freelancer needs an active RFC and a registered tax regime. They issue a CFDI to the foreign company's XEXX010101000. Whether the foreign company must withhold Mexican taxes depends on the type of service, the freelancer's regime, and applicable tax treaties.

Operating a Mexican subsidiary

A foreign parent incorporates a Mexican subsidiary, which obtains its own RFC, e.firma, and CSD certificates. From that point forward, the subsidiary operates as a Mexican taxpayer with full obligations: monthly tax returns, the DIOT (Mexico's monthly informative return on transactions with suppliers and the VAT they charged, Declaración Informativa de Operaciones con Terceros), withholdings, the Opinión de Cumplimiento (the SAT's opinion on whether a taxpayer is current with its tax obligations), and CFDI issuance for every transaction.

How Fiscalapi handles RFC validation and CFDI

For foreign companies building systems that interact with Mexican invoicing, RFC validation is the first integration point. Fiscalapi exposes endpoints to check an RFC against the SAT's Article 69-B lists of taxpayers presumed to invoice nonexistent transactions or to have improperly transferred tax losses, and to generate CFDIs with the correct issuer and recipient information for both Mexican-resident and foreign-resident scenarios. When Fiscalapi sends the CFDI to its PAC for stamping, the PAC checks the recipient's RFC, name, and postal code against the SAT registry. The Fiscalapi documentation describes the validation and stamping flows, and the SDKs cover .NET, Node.js, PHP, Python, and Java for direct integration into ERP, invoicing, or marketplace platforms.

Frequently asked questions

The operational view

For foreign companies, the RFC is the gating mechanism for every invoicing, payment, and deduction process in Mexico. Systems that integrate with Mexican counterparties (ERPs, accounting platforms, marketplaces, payment processors) must treat the RFC as a validated, structured identifier from day one. The cost of treating it as free-text is paid in rejected invoices, blocked deductions, and reconciliation problems that surface months later during audits.