CFDI 4.0 XML Viewer
Open a CFDI 4.0 invoice XML and read it in plain language: issuer, recipient, line items, taxes and tax stamp, with SAT codes translated and the arithmetic checked.
What this tool does
You open a CFDI 4.0 invoice XML — by dragging it in or pasting it — and read it in plain language: issuer, recipient, line items, taxes and tax stamp, with the SAT catalogue codes already translated and the figures checked.
The XML is never uploaded anywhere. It is processed with the browser’s own parser, so you can go offline and the tool keeps working. That matters: an invoice carries your customers’ tax IDs, tax addresses and amounts.
Why raw CFDI XML is so hard to read
Because almost everything is a code. A CFDI says UsoCFDI="G03", RegimenFiscal="601", MetodoPago="PUE", ObjetoImp="02", and to know what those mean you have to go to the SAT catalogue. This tool does the translation for you:
| In the XML | What it means |
|---|---|
TipoDeComprobante="I" | Income |
MetodoPago="PUE" | Payment in a single instalment |
MetodoPago="PPD" | Instalment or deferred payment |
FormaPago="03" | Electronic funds transfer |
RegimenFiscal="601" | General Law for Legal Entities |
RegimenFiscal="626" | Simplified Trust Regime |
UsoCFDI="G03" | General expenses |
ObjetoImp="02" | Subject to tax |
Impuesto="002" | VAT |
The two checks it performs
It does not validate the seal — that requires cryptography and a SAT lookup — but it does catch the two errors that show up most often when integrating invoicing:
1. The RFC check digits. Both the issuer’s and the recipient’s are validated with the SAT’s modulo 11 algorithm. That is where data-entry typos surface, typically an O where a zero belongs.
2. The invoice arithmetic. It verifies that:
Total = SubTotal − Discount + TotalTransferredTaxes − TotalWithheldTaxes
with a one-cent tolerance for the rounding certification providers apply. If it does not add up, it tells you which two numbers disagree. A mismatch here almost always means your system is computing VAT on the wrong base.
What this tool does not do
- It does not validate the digital seal. That requires verifying the signature against the issuer’s certificate and the SAT’s.
- It does not check current status. To know whether an invoice is valid or cancelled you must query the SAT verification service with the UUID.
- It does not issue or stamp invoices. It only reads.
About versions
It targets CFDI 4.0, the version currently in force. The reader locates nodes by their local name without depending on the namespace prefix, so a 3.3 document opens and largely displays; the fields that only exist in 4.0 will simply appear empty — the recipient’s tax regime, their tax address or the per-item tax object.
If the invoice carries no TimbreFiscalDigital node, you get a notice. That is not always an error: an XML freshly generated by your system and not yet stamped will not have one. But on an invoice that is supposed to be stamped, a missing UUID means it has no tax effect.
Related tools
- Mexican ID validator — RFC, CURP, CLABE, NSS — to check a standalone RFC outside the invoice context.
- Mexican test data generator — fictitious RFCs and CLABEs for your test invoices.
- JSON validator — the equivalent for the APIs that usually accompany invoicing.
Frequently asked questions
Is my invoice uploaded to a server?
No. The XML is read with the browser's own parser and all processing happens on your machine; there is no file upload and no network request. You can go offline and the tool keeps working. That is an important difference from online viewers that do upload the invoice, because an invoice carries your customers' tax IDs, tax addresses and amounts.
Does it validate the SAT digital signature?
No. Checking the seal requires cryptographically verifying the signature against the issuer's certificate and the SAT's, and confirming the invoice status against the official validation service. This tool stays at the data layer: it reads the XML, translates the catalogue codes and checks that the figures add up. To confirm an invoice is valid and not cancelled, use the SAT verification service with the UUID.
What checks does it perform, then?
Two that catch most integration errors. First, it validates the check digit of both the issuer's and the recipient's RFC, which is where data-entry typos usually surface. Second, it verifies the invoice arithmetic: that the declared total equals subtotal minus discount, plus transferred taxes and minus withheld ones, with a one-cent tolerance for the rounding certification providers apply. If something is off, it tells you exactly which numbers disagree.
What do codes like G03, 601 or PUE mean?
They are SAT catalogue codes and the tool translates them automatically. G03 is the CFDI use "General expenses"; 601 is the tax regime "General Law for Legal Entities"; PUE is the payment method "Payment in a single instalment", as opposed to PPD for instalment or deferred payments. Payment form, invoice type and each line item's tax object are translated too — in the raw XML they are just numbers.
Does it work with CFDI 3.3 or only 4.0?
It targets version 4.0, the one currently in force. The reader locates nodes by their local name without depending on the namespace prefix, so a 3.3 document will open and largely display, but fields that only exist in 4.0 — such as the recipient's tax regime, their tax address or the per-item tax object — will show up empty, simply because that XML does not carry them.
My XML has no tax stamp, is something wrong?
Not necessarily. The digital tax stamp is added by the certification provider at stamping time, so an XML freshly generated by your system and not yet submitted will not have one, and that is normal. What is a red flag is it missing from an invoice that is supposed to be stamped already: with no TimbreFiscalDigital node there is no UUID, and the invoice has no tax effect.
Reviews & ratings
No reviews yet. Be the first to leave one!
Related tools
Others from the catalogue that pair well with this one.