Panama Invoice Validation by CUFE: A Receiver's Guide

Every Panama electronic invoice carries a CUFE (Código Único de Factura Electrónica), an alphanumeric code that functions as the invoice's digital fingerprint. Generated at the moment of issuance, the CUFE uniquely identifies each document within Panama's electronic invoicing system and gives recipients a direct way to confirm that an invoice is legitimate and registered with the tax authority.

If you've received an electronic invoice from a Panama-based supplier, you can verify it immediately. The DGI (Dirección General de Ingresos) operates a public consultation portal where anyone can enter a CUFE and retrieve the invoice's registered details. No taxpayer credentials, no login, no special registration. You paste the code, and the system confirms whether the invoice exists and returns its core data.

But validation is only the first step. Panama's e-invoicing framework requires receivers to formally respond to each invoice through the manifestación del receptor system within 8 calendar days of the invoice's date of issuance. Five event types are available: confirmation of data, confirmation with differences, transaction failure, business cancellation, or lack of knowledge of the operation. Choosing the wrong event, or missing the deadline, can create compliance problems that are difficult to unwind after the fact.

---

How the DGI Public CUFE Lookup Works

The Dirección General de Ingresos (DGI) operates a public CUFE lookup function — Consultas Públicas por CUFE — through its electronic invoicing portal. This is the official, authoritative method for validating any Panama electronic invoice.

The process is straightforward:

1. Access the DGI's electronic invoicing portal (SFEP — Sistema de Facturación Electrónica de Panamá). Searching for "DGI factura electrónica consultas públicas" will take you directly to the public consultation page.
2. Navigate to the public consultation section and select the CUFE lookup option.
3. Enter the full CUFE code from the invoice you need to verify.
4. Review the returned details against the invoice your supplier provided.

A successful lookup returns the invoice's key data: the issuer's identity (RUC and business name), issuance date, line item totals, tax amounts, and the invoice's current status within the DGI system. That status field matters. It tells you whether the document is active, has been corrected, or has been subject to any receiver or issuer events since submission.

No login, taxpayer registration, or special credentials are required. The CUFE consultation is a fully public function. Any party holding the CUFE — whether the invoice recipient, an auditor, or a third-party verifier — can query it at any time.

Beyond the single-invoice CUFE check, the DGI portal offers related consultation functions worth knowing about. An issuer lookup lets you verify that a supplier is an authorized electronic invoicing participant. An issuer/receiver document consultation lets you search for invoices by the parties involved rather than by a specific CUFE, which is useful when cross-referencing multiple documents from the same supplier.

Where to find the CUFE on a received invoice: The code is embedded in the invoice's electronic XML file as a dedicated field. If you received a CAFE (the printed or PDF representation of the electronic invoice), the CUFE also appears there, typically near or alongside a QR code. Scanning that QR code generally directs you to the same DGI validation lookup, giving you a second path to the same verification result.

If the portal returns an error or fails to find a CUFE you know is valid, try again later before escalating. Government portals experience periodic downtime, and a temporary outage does not mean the invoice is fraudulent.

CUFE and CAFE: What Each Code Represents

Two acronyms appear constantly in Panama's electronic invoicing system, and mixing them up creates real problems during validation. CUFE and CAFE refer to fundamentally different things, even though they always travel together.

CUFE (Código Único de Factura Electrónica) is the unique alphanumeric identifier assigned to an electronic invoice at the moment it is generated and validated within Panama's SFEP. Every electronic invoice that passes through the system receives exactly one CUFE, and that code ties permanently to the electronic record stored by the DGI. The CUFE exists in the data layer. It is not a document you can print or hand to someone.

CAFE (Comprobante Auxiliar de Factura Electrónica) is the physical or printable auxiliary document that represents the electronic invoice in paper form. When a supplier hands you a printed invoice or emails you a PDF version, that document is the CAFE. It carries a QR code and displays the CUFE so that anyone holding the paper can trace it back to the original electronic record.

The relationship between the two runs in one direction: the CAFE contains the CUFE, not the other way around. A CAFE without a valid CUFE is just a piece of paper with no backing in the SFEP. The CUFE, meanwhile, exists independently in the electronic system whether or not a CAFE was ever printed.

How the issuance chain works. When a Panama taxpayer issues an electronic invoice, the document passes through either a PAC (Proveedor Autorizado Calificado) or the DGI's own free invoicing tool. The PAC or DGI system validates the invoice data, assigns the CUFE, and then generates the corresponding CAFE for physical distribution. To understand how Panama's facturador gratuito and PAC systems issue electronic invoices, it helps to know that both paths produce the same output: a CUFE-stamped electronic record in the SFEP and a CAFE that can be printed or shared as a PDF.

For AP teams, the practical takeaway is straightforward: whether you receive the XML or a printed CAFE, the CUFE is what you validate. The authoritative record is always the electronic invoice in the SFEP, not the paper sitting in your filing cabinet.

---

What Is the Manifestación del Receptor?

Once you have validated a Panama electronic invoice using its CUFE, the next step is registering your formal response. The manifestación del receptor is the official process through which invoice recipients record their determination about a received electronic invoice within the DGI's Sistema de Facturación Electrónica de Panamá (SFEP).

Unlike informal supplier correspondence, the manifestación is built into the SFEP platform itself. After CUFE validation, the receiver logs into the DGI portal and selects one of five defined event types (covered next). Each registered response becomes part of the invoice's permanent DGI record, capturing the responder's identity, event type, and timestamp — an authoritative audit trail neither party can later dispute. Structured e-invoicing audit trails like Panama's measurably lift reported tax bases: Peru's rollout produced a 7% increase in reported taxable sales and 5% in purchases in the first year, per research by CIAT and the Inter-American Development Bank.

Within Panama's broader electronic invoicing requirements under the SFEP, issuers carry the obligation to generate compliant electronic invoices, transmit them to the DGI, and deliver them to buyers. The manifestación del receptor is the receiver-side complement to those issuer obligations. Where the issuer's duties end at delivery, the receiver's formal role begins with validation and response. Together, these two sides form a complete audit chain that the DGI can reference for tax compliance, dispute resolution, and fiscal oversight.

The Five Receiver Event Types

Panama's manifestación del receptor system defines exactly five event types that a receiver can register against an electronic invoice. Each serves a distinct purpose, and selecting the right one matters because only one event type can be registered per invoice. Once submitted, the selection is definitive and becomes part of the permanent fiscal record.

Below is a structured reference for all five Panama receiver events for electronic invoices.

1. Confirmación de datos (Confirmation of data)

This is the straightforward acceptance event. The receiver confirms that the invoice data matches the transaction as originally agreed. Select this when the invoice accurately reflects the goods or services delivered, the amounts are correct, and no discrepancies exist between the invoice and the underlying purchase order or contract.

2. Confirmación con diferencias (Confirmation with differences)

The receiver accepts the invoice but formally notes discrepancies in amounts, quantities, descriptions, or other details compared to what was agreed. Use this when the underlying transaction itself is valid and the receiver does not dispute that business occurred, but the invoice contains errors or differences that need to be on record. This event acknowledges the transaction while preserving a documented trail of the inconsistencies.

3. Confirmación de fallo de transacción (Confirmation of transaction failure)

This event reports that the underlying transaction failed. The invoice may have been issued, but the goods were never delivered, the services were never rendered, or the transaction did not complete as described. Select this when the business activity the invoice claims to represent simply did not happen as invoiced.

4. Cancelación de negocio (Business cancellation)

This indicates the business transaction has been canceled by mutual agreement. Unlike event type 3, which addresses a failed transaction, this event applies when both parties have agreed to void the deal entirely. It covers situations such as contract rescissions, returned orders accepted by the supplier, or jointly agreed cancellations.

5. Desconocimiento de la operación (Lack of knowledge of the operation)

The receiver formally declares they have no knowledge of the invoiced transaction. This is the Panama electronic invoice rejection mechanism for cases where the receiver did not participate in, authorize, or even recognize the transaction described in the invoice.

This fifth event type functions as a critical anti-fraud safeguard. It allows businesses to flag invoices that were issued against them without their knowledge or consent, creating an official government record of the disputed transaction. For AP teams, registering a desconocimiento promptly is essential when an unfamiliar invoice appears, as it establishes the receiver's formal position and protects the company from liability tied to unauthorized invoicing.

Given that each invoice permits only a single event registration, AP staff should verify the situation thoroughly before submitting. Choosing confirmación con diferencias when desconocimiento de la operación is warranted, for example, would acknowledge a transaction the company never authorized, with no ability to correct the record afterward.

---

The 8-Day Window and Annulment Rules

Panama's manifestación del receptor system operates under strict time constraints that directly affect your ability to formally respond to an electronic invoice. Understanding these deadlines is essential for setting internal AP workflows that protect your organization's position.

The registration deadline is 8 days from the date of issuance. Once an invoice is generated and transmitted through the SFEP, the receiver has exactly 8 calendar days (including weekends and holidays) to register any manifestación del receptor event against that invoice's CUFE. After this window closes, the DGI system will no longer accept receiver events for that document, regardless of the event type.

Missing this deadline has real consequences. Without a registered event, you lose the ability to formally document your position through Panama's electronic invoicing infrastructure. This matters most in two scenarios: when you need evidence of a reported discrepancy during a DGI audit, and when a commercial dispute escalates and you need proof that you raised objections within the system. An informal email to your supplier is not a substitute for a registered event in the SFEP.

Annulment is a second, independent constraint. If the issuer annuls (cancels) the invoice before you register your event, the system blocks any receiver response — confirmation, discrepancy, rejection, or fraud report. The issuer can annul on day two of your 8-day window, preempting an AP team that planned a day-five review. You permanently lose the ability to register anything.

Do not treat the 8-day window as a comfortable buffer. Receivers who identify issues with an invoice should register their event as early as possible. Internal deadlines of two to three business days after receipt give your team adequate review time while leaving margin against unexpected annulments.

One important asymmetry works in the receiver's favor. If you have already registered an event and the issuer subsequently annuls the invoice, your previously recorded event remains on file in the SFEP. The system preserves the receiver's registered position regardless of later issuer actions. This is another reason to act early rather than late.

Panama's approach parallels frameworks elsewhere in the region. Costa Rica's similar 8-day invoice acceptance and rejection process follows a comparable structure, giving receivers a fixed window to confirm or dispute electronic tax documents before forfeiting the right to a formal system-level response.