RFC in Mexico: The Tax ID Foreign Companies Need to Know

Any company operating in Mexico, paying Mexican vendors, or invoicing Mexican customers eventually runs into the RFC. 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 Mexico's electronic invoicing (CFDI) regime.

What is the RFC

The RFC (Registro Federal de Contribuyentes) is Mexico's federal taxpayer registry number and the official Mexico tax ID. It is the unique tax identification code that the Servicio de Administración Tributaria (SAT), Mexico's tax authority, 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, 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 or a legal entity.

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 RFC genérico 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, address, and country are recorded in dedicated XML fields, not in the RFC field.
• The CFDI 4.0 specification requires additional fields when using XEXX010101000, including the foreign tax ID format and country code. Missing those fields causes the stamping 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 Mexican CURP. 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 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 performs an automatic SAT validation of both the issuer and the recipient. Invalid RFCs cause stamping to fail with specific error codes (most commonly CFDI40147, CFDI40151, or CFDI40152). 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 ZIP 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 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, country, and address 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, DIOT, withholdings, opinion of compliance, 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 validate RFCs against the SAT registry, retrieve the associated tax regime data, and generate CFDIs with the correct issuer and recipient information for both Mexican-resident and foreign-resident scenarios. 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, billing, or marketplace platforms.

Frequently asked questions

The operational view

For foreign companies, the RFC is not just a number; it 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.