Folio fiscal: the UUID of a CFDI explained

If you've ever tried to cancel an invoice, link a payment complement (the complement that records each payment received against a PPD invoice; the type P CFDI that carries it is also called REP), or answer a request from the SAT (Mexico's tax authority, Servicio de Administración Tributaria), the first thing you were asked for was the folio fiscal. It's the identifier the SAT uses to recognize your CFDI (Mexico's electronic invoice), and yet almost nobody explains what it is, how it's built, or why it's sometimes missing. After years of issuing and validating invoices in production, I can tell you that most folio fiscal problems come from confusing it with the internal folio number (the issuer's own sequential number for the CFDI; not the UUID), not from the SAT. Let's take the concept apart.

What is the folio fiscal?

The folio fiscal is a unique 36-character identifier in UUID format that a PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs) assigns to each CFDI during stamping (the certification by a SAT-authorized provider that makes a CFDI valid). It's the CFDI UUID, and it guarantees that the invoice officially exists with the SAT. Without a folio fiscal, an invoice isn't a valid CFDI.

What matters is who assigns it. Your invoicing system doesn't generate it. Neither does the SAT, at least not directly. The PAC assigns it at the exact moment of stamping, and from that instant the folio is recorded in the SAT's database with all the invoice data tied to it.

Where does the folio fiscal appear on an invoice?

It depends on which form of the CFDI you're looking at. The folio fiscal lives in three places:

On the printed representation (the PDF of a CFDI; the XML is the legal document): it usually appears at the bottom, next to the SAT seal (the seal inside the digital tax stamp that certifies the CFDI). Most issuers label it "Folio Fiscal" or "Folio Fiscal UUID". Some systems, especially older ones, only print "UUID". It's the same data.

In the XML: it sits inside the digital tax stamp (Timbre Fiscal Digital, the SAT seal the PAC adds to a CFDI). If you open the XML in any text editor, look for this fragment:

<cfdi:Complemento>
  <tfd:TimbreFiscalDigital
    UUID="A1B2C3D4-1234-5678-9ABC-DEF012345678"
    FechaTimbrado="2026-05-20T10:15:30"
    .../>
</cfdi:Complemento>

The UUID attribute of the TimbreFiscalDigital node is the folio fiscal. Period.

On the SAT portal: in the Verificación de CFDI (CFDI verification) tool, the field is called "Folio fiscal", and it's the first thing the tool asks for when you look up an invoice's status.

Folio fiscal and the CFDI UUID: are they the same?

Yes. UUID stands for "Universally Unique Identifier", an international standard defined in IETF RFC 4122. The SAT adopted this format to identify each CFDI and gave it a friendlier name: folio fiscal. In the official documentation of Anexo 20 (the SAT technical standard that defines the CFDI: its XML structure, catalogs, and validation rules) you'll see "UUID". On electricity bills you'll see "Folio Fiscal". In the SAT's API you'll see "UUID". On the SAT portal you'll see "Folio fiscal". They're synonyms, so if you need the folio fiscal in English, it's the UUID.

The practical rule: if the value has 36 characters and hyphens at positions 9, 14, 19, and 24, it's a folio fiscal.

Folio fiscal structure: how it's built

Every invoice UUID in Mexico follows the standard format of 32 hexadecimal digits, grouped in five blocks separated by hyphens: 8-4-4-4-12.

An example:

A1B2C3D4-1234-5678-9ABC-DEF012345678

The valid characters are the digits 0 to 9 and the letters A to F (hexadecimal). No ñ, no accents, no spaces. The total is always 36 characters: 32 hexadecimal digits plus 4 hyphens.

The PAC uses an algorithm that combines invoice data, a timestamp, and a random component to make sure the folio is globally unique. The chance of a collision is so low that in practice it's treated as impossible. That matters for a concrete reason: you can use the folio fiscal as the primary key in your database without worrying about duplicates, which saves you a lot of defensive logic in integrations.

How the folio fiscal is generated: the role of the PAC and the SAT

The folio fiscal appears only when stamping happens. Before stamping, your CFDI is an XML with no folio fiscal, no SAT seal, and no legal validity. After stamping, it has all three.

Three things in this flow are worth pointing out. First, the PAC assigns the folio before it registers the invoice with the SAT, not after. That means the UUID exists from the exact moment the PAC generates it, and it becomes final once the SAT confirms the registration. Second, the folio is tied to the invoice for good: any later change to the XML invalidates it, because the PAC's seal is calculated over the content of the CFDI. Third, the folio can never repeat, not even across different PACs, because the SAT rejects a registration with a duplicate UUID.

If you want to go deeper into how the PAC validates each field before it assigns the folio, we cover it in detail in the CFDI stamping guide.

How to verify a folio fiscal with the SAT

The SAT's official tool lets you confirm whether a folio fiscal belongs to a CFDI that is active (vigente: not canceled with the SAT), canceled, or nonexistent. It doesn't require an e.firma (the SAT advanced electronic signature that identifies a taxpayer, formerly FIEL) or an account; anyone can look up any folio if they have the basic data.

For programmatic validation or large batches, the manual process doesn't scale. The guide to verifying a CFDI covers the automated options.

Common folio fiscal errors

These are the three cases you see all the time in production, and they fill support queues with tickets that could have been avoided.

"El folio fiscal no es válido por el siguiente motivo" (The folio fiscal isn't valid for the following reason): the SAT returns this message when one of the fields in the verifier doesn't match the registered invoice. It's almost always a copy-paste error: the UUID is missing a character or the recipient's RFC is misspelled. Before you assume the invoice is broken, take the data again straight from the XML, not from the printed representation.

"My invoice has no folio fiscal": if the PDF you received shows no UUID anywhere, the invoice was most likely never stamped. An invoice without a folio fiscal is a draft, not a CFDI. It isn't valid for tax purposes, you can't deduct it, and the SAT doesn't recognize it. Ask the issuer for the XML; if it doesn't have the TimbreFiscalDigital node either, you've confirmed the problem. Without a folio fiscal, the invoice doesn't exist for the SAT.

Duplicate UUID: it shouldn't happen, but if you see it, it means two PACs tried to stamp the same invoice because of an integration error. In that case, the SAT rejected one of the two stampings and only one was registered. Check each folio on the SAT portal to find out which one is active, and report the incident to the PAC.

Folio fiscal vs. internal folio number: the mix-up behind support tickets

This is the number one cause of problems in integrations. The CFDI has two different fields that people often call "folio", and they get mixed up.

The internal folio number is optional, and it's your own counter. It lets your system tell which invoice is which. Two different issuers can each have a CFDI with internal folio number 001 on the same day, because each one counts its own invoices. The folio fiscal, on the other hand, is assigned by the PAC and never repeats across invoices, not even across different issuers. To send your own internal folio number with each invoice, see custom folio numbers for your CFDIs in Fiscalapi.

The rule for any integration: use the folio fiscal as the unique identifier in your database, as the idempotency key when you link payment complements, and as the reference when you interact with SAT APIs. The internal folio number is for human-readable reports and reconciliation inside your company. Mixing them up can lead you to duplicate payments, cancel the wrong invoice, or link a complement to the wrong CFDI.

How to find an invoice using the folio fiscal

If you have the folio fiscal and need to retrieve the full invoice, there are several paths, depending on who issued it and where you need it.

On the recipient's side, the fastest option is the SAT's bulk download (the SAT service that delivers the CFDIs a taxpayer issued and received): with your e.firma you can request a package with every CFDI issued to you in a period, then filter by UUID once you receive it. The tax mailbox (Buzón Tributario) also lets you look up specific invoices.

On the issuer's side, it depends on the system you invoice with. If you issue through an API, the stamping response returns the folio fiscal, and you should save it to your database the moment you receive it. If you stored it, you can retrieve it at any time. If you didn't, you can't rebuild it.

At Fiscalapi we expose endpoints to check a CFDI's status with its folio fiscal and to download the XML of the CFDIs you stamp with us, straight from the API, without going through the SAT portal. To see how the integration works, read the official documentation or the SDKs for your preferred language.

Frequently asked questions

The folio fiscal is one of those concepts that seem minor until you have to explain why your integration broke. Treat it from day one as an immutable key, assigned by a third party and separate from the internal folio number, and you avoid most of the problems you see in production.