What is the CUFE and why is it the heart of SFEP?

The CUFE (Unique Electronic Invoice Code) is the fiscal identifier that turns an XML into a valid invoice. Without a CUFE, the document does not exist for the DGI. With a CUFE, it becomes queryable, auditable and traceable for 5 years. This post explains what it is, how it’s generated and how to use it well.

Anatomy of the CUFE

A CUFE is an alphanumeric string of 40+ characters that encodes, via a hash, the document’s essential information:

Issuer and recipient RUC.
Document type (01 invoice, 02 receipt, 03 credit note, 04 debit note).
Series and sequential number.
Issue date and time.
Total amount and ITBMS breakdown.
Digest of the digitally signed XML.

Any alteration of any of those fields, no matter how small, invalidates the CUFE — that is precisely what gives it probative value.

Who generates it?

The CUFE is generated by the DGI, not by the issuer or the software. When your PAC submits the XML:

The DGI validates the structure and fiscal data.
If everything is correct, the DGI generates the CUFE.
The PAC returns it to the issuer as part of the successful response.
The PAC signs the final XML and archives it.

That’s why you cannot “pre-calculate” a CUFE offline: it requires online DGI validation. Contingency mode is a controlled exception, explained below.

Where does the CUFE appear?

In three mandatory places:

In the signed XML, inside the fiscal information node.
In the PDF representation the customer receives, usually in the header and next to a QR code.
In the DGI query portal, where anyone can verify the document exists by entering the CUFE.

The attached QR code

Every invoice prints a QR code containing the CUFE and the DGI’s query URL. A skeptical customer can scan the QR with any reader and confirm, in real time, that the invoice is real and registered. That has two implications:

Increases trust in B2B transactions.
Reduces fraud: printing an official-looking PDF is no longer enough to defraud.

CUFE in contingency (72 hours)

When the DGI or the PAC channel is down, regulation allows continuing to issue for up to 72 hours using a provisional CUFE calculated locally by the PAC with the same hash formula. Once the connection is back, the PAC retransmits the documents and the DGI confirms the definitive CUFEs. Nothing changes from the customer’s perspective because the QR and the code stay consistent.

Querying the CUFE

Anyone can verify a CUFE on the DGI’s public portal. It’s useful when:

You receive an invoice from a new supplier and want to confirm it’s properly issued.
You audit deductible expenses before filing.
You book invoices that the supplier voided after issuing them.

Voiding a CUFE

An invoice with a CUFE is not “deleted”. If there’s an error (amount, customer, product), a credit note is issued that references the original CUFE. That note also has its own CUFE and leaves a clear audit trail. Trying to fix errors “on paper” without credit notes is fiscally risky.

Common CUFE mistakes

Confusing CUFE with invoice number. The sequential number is internal to the business; the CUFE is assigned by the DGI.
Forgetting the CUFE on the printed representation. A PDF without CUFE and QR is not valid deductible evidence.
Reusing sequentials after voiding an invoice. Each issuance attempt consumes a sequential, even if it fails before receiving the CUFE.
Issuing in contingency mode when connectivity actually exists. Poorly configured systems fall into contingency carelessly — abuse is detectable at audit.

What FacturaHQ does with the CUFE

We store it with the signed XML in our Azure vault for the mandatory 5 years.
We expose it over API so you can query it from your ERP or accounting system.
We print it on the PDF and generate the QR automatically.
We link it to every credit or debit note that references it.

The CUFE is simultaneously the seal and the memory of your document. Understanding it well is the first step to operating SFEP without surprises.