Is the Constancia de Situación Fiscal required to issue an invoice in Mexico?

No. Under the reform to the Federal Tax Code in force since November 7, 2025, conditioning the issuance of a CFDI on the customer handing over their tax ID card or tax status certificate is an infraction punishable by a fine. To issue the invoice you only need the recipient's tax data: RFC, legal name and the postal code of the tax address, plus the tax regime and the CFDI use.

What does the SAT validate to stamp a CFDI 4.0?

The SAT validates that the recipient's RFC exists and is active, and that the legal name and the postal code of the tax address match exactly what it has on record in its registry. Any mismatch causes the invoice to be rejected.

How do I validate an RFC in real time without asking for the certificate?

With Tlaloc's RFC validation API you query the SAT registry in real time: you send the RFC and receive whether it is valid and whether it can receive invoices, without asking for, transcribing or storing the tax status certificate. You can call it as many times as you need, once per RFC.

Stop Asking for the Tax Status Certificate: Validate the RFC in Real Time

June 4, 2026 RFC CFDI 4.0 SAT Invoicing

It is one of the most common scenes in Mexican commerce: you ask for an invoice and, before handing it over, the merchant asks you to send your Constancia de Situación Fiscal (tax status certificate, or CSF). You upload it to a portal, forward it over WhatsApp, leave it printed on the counter — a document with your RFC, your name, your tax regime and, in the full version, your tax address, circulating with no control.

Here is what almost nobody tells you: they can no longer require it, and it was never needed to issue the invoice in the first place. All the SAT needs to stamp a CFDI is a handful of the recipient's tax data, and those can be validated in real time — without asking for the PDF, transcribing it by hand, or storing it in your database.

The SAT put it in writing: requiring the certificate is now an infraction

The reform to Mexico's Federal Tax Code (Código Fiscal de la Federación) that took effect on November 7, 2025 added a specific clause to Article 83: it is now an infraction to condition the issuance of a CFDI on showing the Tax ID Card (Cédula de Identificación Fiscal) or the Constancia de Situación Fiscal. The corresponding penalty lives in Article 84.

The head of the SAT himself, Antonio Martínez Dagnino, put it bluntly (translated):

“To issue the invoice you need the RFC, the name, the postal code and the address. (…) In fact, in this amendment we even added a fine.”

The fines are not symbolic. Under the reform, requiring the certificate in order to invoice can be penalized with amounts ranging from roughly $21,000 to over $122,000 pesos for most businesses (with a reduced bracket for small taxpayers), and repeat offenses can lead to a 3-to-15-day shutdown of the establishment. Asking for the CSF stopped being a harmless habit — today it is a regulatory risk.

PRODECON (the taxpayer ombudsman) backs the same criterion: a taxpayer is not obligated to hand over their certificate to be invoiced, and should periodically review the CFDIs issued under their name to catch operations they do not recognize.

What do you actually need to issue a CFDI 4.0?

Article 29-A of the Federal Tax Code and the CFDI 4.0 technical standard (Anexo 20) are clear about the recipient's data. To stamp an invoice you only need:

RFC of the recipient — valid and active in the registry.
Legal name — exactly as registered, in uppercase and, for legal entities, without the corporate suffix (no “S.A. de C.V.”).
Postal code of the tax address — the DomicilioFiscalReceptor field.
Tax regime and CFDI use — which depend on the transaction, not on any document.

The certificate does not appear on that list because it is not a requirement: it is merely a document that contains those data points. And here is the part that changed everything in CFDI 4.0: the SAT validates that the RFC, the legal name and the postal code match its registry exactly. A single difference — one extra accent, a leftover “S.A. de C.V.”, an outdated postal code — and the invoice is rejected and never gets stamped.

That is why asking for the certificate feels safe: people use it to copy those three fields by hand. But manual copying is exactly where the errors that later kill your stamping are born.

The cost of asking for (and re-typing) the certificate

Leaning on the CSF to invoice carries three costs that rarely get counted:

Data-entry errors. Someone reads a PDF or a photo and types the RFC, name and postal code into your system. One wrong digit, a missing uppercase, the corporate suffix left in by mistake — and the PAC rejects the stamp. The customer gets annoyed, the cashier retries, the line grows.
Tax identity-theft exposure. The full certificate reveals the tax address and the detail of one's tax obligations. When that document circulates uncontrolled, it fuels tax identity theft: third parties using an RFC to issue fake invoices, creating “phantom income” that later shows up in the victim's annual return. This is not theory — it is among the fastest-growing complaints before the SAT and PRODECON.
A custody duty you never wanted. The moment you store a customer's certificate, you become the keeper of sensitive personal data, with all the data-protection obligations that entails. That is liability and exposure you do not need to take on.

It is no accident that the SAT itself enabled a version of the certificate without the address: it acknowledges that circulating the full document is a risk. But the best certificate is the one you do not ask for.

The alternative: validate in real time against the SAT registry

Instead of asking for a document, validate the data. Tlaloc's RFC validation API queries the SAT registry in real time and answers two things that matter before you issue any invoice:

valid — whether the RFC exists and is well-formed in the SAT's records.
accept_cfdi — whether that RFC can receive invoices. This is the gold field: some RFCs exist but, given their status, cannot receive a CFDI. Knowing it before you stamp saves you the rejection.

This is not a format check or a client-side checksum: it is a real query against the SAT's own RFC Validation service. You capture the legal name and the postal code straight from your customer — they go on the invoice anyway — and the field you actually confirm against the registry is the one that causes the most stamping rejections: an RFC that does not exist or cannot receive invoices.

How to use it

It is a single HTTP call per RFC. You pass the RFC and it tells you whether it is good to invoice:

curl -X GET "https://api.tlaloc.sh/mx/v1/rfc?rfc=TWS241119PK0" \
  -H "Authorization: Bearer tlmx_YOUR_API_KEY"

The response:

{
  "valid": true,
  "accept_cfdi": true,
  "reason": "RFC válido, y susceptible de recibir facturas"
}

The reason field always returns the SAT's own message, so you can show it to the user or log it. When an RFC exists but cannot receive invoices, you see it immediately:

{
  "valid": true,
  "accept_cfdi": false,
  "reason": "RFC válido, pero no susceptible de recibir facturas"
}

Call it as many times as you need — once per RFC: at every checkout, at every customer onboarding, or sweeping your whole catalog. And because the validation is cached, if the same RFC is queried again the response is instant and not billed a second time: re-validating your entire recipient base is practically free from the second pass on.

Where it fits in your product

Real-time validation turns a counter ritual into an API call that fits into any flow:

Checkout and automatic invoicing. The customer enters their RFC, name and postal code in your form. You validate the RFC inline, before stamping. If the RFC doesn't exist or can't receive invoices, you tell them right there — not after the PAC rejected the invoice.
Customer and vendor onboarding. Confirm that every RFC is active and able to receive invoices before adding it to your catalog. You avoid registering counterparties with dead tax data.
Cleaning up your recipient catalog. Inherited a customer base copied from certificates over the years? Re-validate the RFCs to catch the ones that no longer work, before one kills a stamp mid-operation.
Point of sale and registers. Instead of asking “send me your certificate,” ask for the three fields and validate them in seconds. The line moves and nobody exposes their tax address.
Platforms and marketplaces. If you issue CFDIs on behalf of your sellers, validate their tax data at onboarding and keep your stamping rate clean.

What you stop carrying

The benefit is not only conversion — it is also compliance and peace of mind:

You stop asking for a document you can no longer require. You align with the Federal Tax Code reform and remove the risk of a fine for conditioning the invoice on the certificate.
You transcribe nothing by hand. Goodbye to rejections over an accent, an extra “S.A. de C.V.,” or an outdated postal code.
You store no certificates. You validate the data and move on. You never become the keeper of anyone's tax address, nor feed identity theft.

Get started today

The RFC validation API is available to all users. If you do not have an API key yet, you can sign up and get one in minutes — you can run your first test with your own RFC. Stop asking for the certificate: validate in real time.

Official and reference sources: Federal Tax Code art. 29-A (CFDI data) · SAT statement on the fine for requiring the certificate (Expansión) · SAT: generate your Constancia de Situación Fiscal. This article is informational and does not constitute tax or legal advice; consult your accountant for your specific case.