Panama Invoice Validation by CUFE: A Receiver's Guide

How to validate Panama electronic invoices by CUFE. Covers the DGI public lookup, five receiver event types, and the 8-day registration window.

Published
Updated
Reading Time
12 min
Topics:
Tax & CompliancePanamaCUFEelectronic invoice validationreceiver events

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 to Validate a Panama Invoice by CUFE

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 on the receiving end, the key point is straightforward: whether you receive the electronic XML directly or a printed CAFE from your supplier, the CUFE shown on either document is what matters for verification. Enter that CUFE into the DGI's public lookup tool, and you can confirm the invoice is authentic and registered. The authoritative record is always the electronic invoice stored in the SFEP, not the printed CAFE 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).

This is not an informal back-and-forth between buyer and seller. The manifestación del receptor is a structured government mechanism built directly into the SFEP platform. When a receiver registers their response, it becomes part of the invoice's permanent official record, maintained by the DGI. The system captures exactly who responded, which event type was selected, and the precise timestamp of the filing.

The general workflow follows a clear sequence. After receiving an electronic invoice and confirming its authenticity through CUFE validation, the receiver logs into the DGI portal and selects one of five defined event types, each covered in the next section. The selected event is then permanently recorded against that invoice in the SFEP.

The rationale behind this system reflects a broader pattern across Latin America. Before formal receiver events existed, disputes between issuers and receivers had no standardized official record. A supplier could claim an invoice was delivered and accepted while the buyer maintained it was never received or contained errors. The manifestación del receptor eliminates that ambiguity by creating a timestamped, government-held audit trail of every receiver's position on every invoice they process. The compliance impact of these structured e-invoicing systems is well-documented: after Peru made e-invoicing compulsory, taxable sales reported to the tax authority increased by 7% and purchases by 5% in the first year, according to 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 introduces a second constraint that operates independently of the 8-day clock. If the issuer annuls (cancels) an invoice before you register your receiver event, the system blocks your response entirely. You cannot register a confirmation, a discrepancy, a rejection, or any other event type against an annulled invoice.

You can permanently lose your ability to register a rejection or fraud report. An issuer can annul an invoice at any point, including on day two of your 8-day window. If your AP team planned to review the invoice on day five and the supplier annulled it on day three, the annulment preempts your formal response. Your ability to register any event is gone.

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.

For finance teams operating across jurisdictions, the core discipline is the same: build invoice review and event registration into your first-touch workflow rather than treating it as a follow-up task. The 8-day window is a hard cutoff, not a suggestion.

About the author

DH

David Harding

Founder, Invoice Data Extraction

David Harding is the founder of Invoice Data Extraction and a software developer with experience building finance-related systems. He oversees the product and the site's editorial process, with a focus on practical invoice workflows, document automation, and software-specific processing guidance.

Editorial process

This page is reviewed as part of Invoice Data Extraction's editorial process.

If this page discusses tax, legal, or regulatory requirements, treat it as general information only and confirm current requirements with official guidance before acting. The updated date shown above is the latest editorial review date for this page.

Continue Reading

Invoice Data Extraction

Extract data from invoices and financial documents to structured spreadsheets. 50 free pages every month — no credit card required.

Try It Free