Mexican RFC Validator (SAT)
Validate RFC tax IDs in bulk — structure, date, and the SAT check digit.
RFCs are validated in your browser — never sent anywhereCheck the structure, date and SAT check digit — one RFC or a whole list
What this validator checks — and what it cannot confirm
The RFC — Registro Federal de Contribuyentes — is the tax ID Mexico's SAT assigns to every person and company, and getting it wrong has a real cost: an electronic invoice (CFDI) with a bad receiver RFC will not stamp, and a customer table full of invalid RFCs breaks reconciliation. This validator checks one RFC or hundreds at a time — paste them one per line — and tells you exactly what is wrong with each: length, format, date, or check digit.
The structure is fixed. An individual (persona física) has 13 characters: 4 letters derived from the surnames and given name, 6 digits with the birth date (YYMMDD), and a 3-character homoclave assigned by the SAT. A company (persona moral) has 12: 3 letters from the legal name, the incorporation date, and the homoclave. In both cases the last homoclave character is a check digit — 0–9 or the letter A — computed with a mod-11 algorithm over the rest of the key, just like the final digit of a bank card number.
That is what this validator genuinely verifies, in three layers: the structure (letters where letters belong — including Ñ and & — and digits where digits belong), the calendar validity of the date (a month 13 or a February 30 betrays an invented or mistyped RFC), and whether the check digit matches what the SAT algorithm produces — the test that catches the vast majority of typos, because changing a single character almost always breaks the digit.
What no outside tool can confirm is that the RFC is actually registered with the SAT: a structurally perfect RFC can still be absent from the registry, or cancelled. That is what the SAT's own lookup is for (the situación fiscal check on its portal). Treat this validator as the cheap, bulk first filter — clean the data before invoicing or loading a table — and the SAT as the final source of truth.
One detail many validators get wrong: the generic RFCs XAXX010101000 (general public) and XEXX010101000 (foreign residents) are official keys used every day in invoicing — and they do not satisfy the check-digit algorithm. A naive validator rejects them; this one recognizes them and labels them for what they are. Everything runs in your browser: the RFCs you paste — real tax data — are never sent to any server.
The RFC structure, piece by piece
| Type | Length | Composition | Example |
|---|---|---|---|
| Individual (persona física) | 13 | 4 letters (from surnames and given name) + YYMMDD birth date + 3-character homoclave (the SAT assigns the first 2; the 3rd is the check digit) | GODE561231GR8 |
| Company (persona moral) | 12 | 3 letters from the legal name + YYMMDD incorporation date + 3-character homoclave | EKU9003173C9 |
| Generic — general public | 13 | Fixed official key for sales to the public without an RFC | XAXX010101000 |
| Generic — foreign residents | 13 | Fixed official key for foreign residents | XEXX010101000 |
The letters may include Ñ and the & sign (common in legal names like "AT&T"). The date carries no century — 561231 can be 1956 — so a validator can only require that the month and day exist on the calendar, and February 29 is accepted because some century makes it a leap year. EKU9003173C9 is, incidentally, the official test RFC the SAT itself uses in its invoicing documentation.
The check digit, explained with a worked example
The last character of an RFC is not random: it is computed from the previous 12 (11 for companies, padded with a leading space). Each character takes a value from an official table (0–9 are worth their digit; A=10 … N=23, &=24, O=25 … Z=36, space=37, Ñ=38), each value is multiplied by a descending weight from 13 to 2, the products are summed, and the remainder mod 11 decides the digit: remainder 0 gives 0; otherwise the digit is 11 minus the remainder, and when that subtraction yields 10 the digit is written as the letter A.
RFC: GODE561231GR + digit
G=16×13 O=25×12 D=13×11 E=14×10
5=5×9 6=6×8 1=1×7 2=2×6
3=3×5 1=1×4 G=16×3 R=28×2
Sum = 1026
1026 mod 11 = 3
11 − 3 = 8 → GODE561231GR8That is why the check digit is such a good typo detector: change a single letter or number and the sum changes, so the expected digit almost always stops matching. It is also why the generic RFCs are the exception worth knowing: XAXX010101000 computes a 4 under this formula, not a 0 — the SAT defined them as fixed keys, not algorithm outputs, and a correct validator accepts them as special cases.
Validating RFCs in Excel, Google Sheets, and SQL
To clean an RFC column in your own tools, the format regular expression is the first filter. It does not replace the check digit — that needs the full algorithm, which this page runs in bulk — but it instantly discards anything that is not even RFC-shaped.
Google Sheets (A2 = RFC):
=REGEXMATCH(A2, "^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$")
Excel 365 (2024 and later):
=REGEXTEST(A2, "^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$")
Normalize before validating (uppercase, no spaces):
=UPPER(SUBSTITUTE(A2, " ", ""))-- PostgreSQL
SELECT rfc FROM customers
WHERE rfc !~ '^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$';
-- MySQL 8
SELECT rfc FROM customers
WHERE rfc NOT REGEXP '^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$';
-- SQL Server: no native regex — filter by length as a first pass
SELECT rfc FROM customers
WHERE LEN(rfc) NOT IN (12, 13);FAQ
Does this validator confirm the RFC is registered with the SAT?
No — and no outside tool can. This checks structure, date, and the check digit, which is enough to catch typos and invented keys. To confirm an RFC is actually enrolled and active, use the SAT's own lookup on its portal (the situación fiscal check). The efficient workflow is to bulk-clean here first, then query the SAT only for the entries that passed.
Why does XAXX010101000 show as valid if it fails the algorithm?
Because it is an official generic RFC: XAXX010101000 is used to invoice the general public and XEXX010101000 for foreign residents, and neither satisfies the check-digit algorithm. They are exceptions defined by the SAT itself, so this validator recognizes them as special cases and labels them as generic instead of rejecting them the way a formula-only validator would.
Is it safe to paste my customers' real RFCs?
Yes. Validation runs entirely in your browser with JavaScript: the RFCs are never sent to any server, there are no accounts or logging, and you can prove it by disconnecting from the internet after the page loads — the tool keeps working. For third-party tax data, that is exactly the guarantee you want before using an online tool.