CUFE: What It Is and Why Your Electronic Invoice in Panama Needs It

The CUFE (Código Único de Factura Electrónica — Unique Electronic Invoice Code) is probably the most frequently mentioned technical concept in Panamanian electronic invoicing — and also one of the least understood. If your company issues invoices with a CUFE but nobody on the team knows exactly what it is, this article explains it clearly: what data it encodes, how it is generated, how it is validated, and what happens when something goes wrong.

Important: this article is educational. The technical format of the CUFE may be updated by DGI resolutions. Always verify current requirements with your PAC or tax advisor.

What Is the CUFE?

The CUFE is a unique, non-repeatable alphanumeric code that identifies each electronic invoice issued in Panama under the Law 256 of 2021 regime. It serves three critical functions:

1. Unique identification: like a "national ID" for each invoice. No two invoices ever share the same CUFE.
2. DGI traceability: with the CUFE, anyone (customer, auditor, DGI) can verify that the invoice exists in the system.
3. Integrity: the CUFE is generated from the key data of the invoice. If any data changes, the CUFE becomes invalid.

Conceptually it is similar to the Colombian CUFE or the Mexican digital stamp (TFD) — but with its own format and rules established by Panama's DGI.

Who Generates the CUFE?

The CUFE is not generated by the issuer. It is generated by the PAC (Authorized Qualified Provider — Proveedor Autorizado Calificado). This is a fundamental control: only PACs certified under Resolution 201-7136 are authorized to generate valid CUFEs.

The flow:

1. The issuer prepares the invoice data in their ERP/system.
2. The issuer digitally signs the invoice with their certificate.
3. The invoice is sent to the PAC.
4. The PAC validates the data and the issuer's signature.
5. The PAC calculates and applies the CUFE according to the algorithm defined by the DGI.
6. The PAC transmits to the DGI and returns the CUFE to the issuer.
7. The issuer delivers the invoice to the customer with the CUFE included.

If your system "generates a CUFE" without going through a PAC, it is not a valid CUFE — it is a local code with no legal recognition, and the invoice does not comply with Law 256.

What Data Does the CUFE Encode?

The CUFE is calculated as a cryptographic hash over a set of key invoice data. Although the exact format may vary by resolution, it typically includes:

• Issuer's RUC (tax ID).
• Invoice number (the issuer's sequential numbering).
• Date and time of issuance.
• Recipient's RUC (if applicable).
• Total amount of the invoice.
• ITBMS (VAT) charged.
• PAC data that processed it.

Since it is a hash, changing any of these data points produces a different CUFE. This guarantees integrity: if someone tried to modify an invoice after it was issued, the original CUFE would be inconsistent with the modified data.

Typical Format

The CUFE is a long alphanumeric string (typically 40–60 characters) that combines:

• A prefix or PAC identifier.
• An encoded date.
• A hash of the invoice content.
• A check digit.

Conceptual example (do not use as real):

FE0202604280123456789ABCDEF...XYZ987

The exact format is governed by Resolution 201-7136 of the DGI and its updates.

How Is a CUFE Validated?

There are several ways to validate that a CUFE is legitimate:

1. DGI Portal

The DGI offers a query portal where anyone can enter a CUFE and verify:

• That the invoice exists in the system.
• The key invoice data (issuer, recipient, date, amount).
• The status (accepted, voided).

This is useful for customers who receive an invoice and want to verify its authenticity before processing it.

2. Automatic Validation in the Recipient ERP

Modern systems like cifraHQ can automatically query the DGI when they receive an electronic invoice to confirm the CUFE. This prevents accidentally accepting invoices with an invalid CUFE.

3. Manual XML Inspection

The electronic invoice XML contains the CUFE in a specific tag (<CUFE> or equivalent). The XML also includes the PAC's digital signature, which can be cryptographically validated with the PAC's public certificate to verify that the invoice has not been altered.

CUFE on Sales Invoices vs. Credit Notes

Both sales invoices and credit notes and debit notes carry a CUFE — each document type has its own unique CUFE.

When you issue a credit note that voids a previous invoice:

• The credit note has its own new CUFE.
• In the XML, it must reference the CUFE of the original invoice that it is voiding or adjusting.
• The DGI reconciles the adjustment and reflects the net transaction.

What Happens If the CUFE Is Invalid?

Possible scenarios and consequences:

Provisional CUFE (Contingency)

When the PAC is down or there are connectivity issues with the DGI, the regulations provide for a provisional CUFE (specific contingency format) that allows invoicing to continue. When connectivity is restored:

• The PAC retransmits the pending invoices.
• The definitive CUFE is confirmed (which typically replaces the provisional one).

The issuer's system must handle this flow automatically. Manual contingency operations are a source of errors.

CUFE on Form 430 and Tax Credits

For a recipient to claim an ITBMS (VAT) tax credit from a received invoice, that invoice must:

• Be validly issued (with a CUFE registered in the DGI system).
• Have the CUFE recorded in the recipient's accounting books and reports.
• Be a deductible expense linked to taxable operations.

Without a valid CUFE, the invoice is inadmissible as a basis for a tax credit — even if the issuer has already declared the ITBMS on their side.

Common Errors with the CUFE

1. Not storing the CUFE in the accounting system: the CUFE must be archived alongside each invoice for audit and traceability purposes.
2. Accepting invoices without verifying the CUFE: the recipient assumes the risk of claiming a tax credit on an invalid invoice.
3. Confusing the invoice number with the CUFE: they are different things — the invoice has its own sequential number from the issuer AND the CUFE generated by the PAC.
4. Voiding invoices without issuing a credit note: in electronic invoicing, "cancellation" is done with a credit note that references the original CUFE. Destroying the document is not sufficient.
5. Using the CUFE instead of the XML for digital archiving: the digital archive must include the full XML signed by the PAC, not just the CUFE.

How cifraHQ Handles the CUFE

cifraHQ automatically retrieves the CUFE for each issued invoice from the integrated PAC, records it in the invoicing module alongside the signed XML, automatically validates the CUFE of supplier invoices received before accepting them as a tax credit, digitally archives all invoices with their CUFE for the legally required 5-year retention period, and produces accounting and tax reports with full CUFE → invoice → journal entry → Form 430 traceability.

Ready to implement electronic invoicing with CUFE in your company? Request a demo or learn more about Law 256 of 2021.

Official Resources

• Dirección General de Ingresos (DGI) — CUFE query portal
• Resolution 201-7136 — CUFE technical format
• Authorized PACs compared — who can generate a valid CUFE

This article is educational. The technical format of the CUFE and related procedures may be updated by DGI resolution; always verify with your PAC or tax advisor.