DGI Panama: electronic invoicing in Odoo step by step

What DGI Panama requires in 2026

Electronic invoicing in Panama is not a signed PDF or a manual send to the customer. It is a structured XML routed through a Qualified Authorized Provider (PAC) or DGI's free invoicing portal, and only after its authorization does the document have tax validity. If your Odoo emits the invoice but the PAC rejects it, that revenue is unrecognized by the authority and the associated ITBMS is in limbo.

Panama's SFE (Sistema de Facturación Electrónica) operated by DGI works on the technical format defined by Resolución 201-9775 and its amendments. The core of the model is the assignment of a unique CUFE (Código Único de Factura Electrónica) per document, which numerically replaces the physical folio and allows DGI to trace the full operations chain.

The relevant 2026 milestones are three. First: the mandatory incorporation of new taxpayer groups per the phased calendar published by DGI, which now covers practically the entire universe of legal entities with commercial activity. Second: stricter validation on consistency between the issuer's RUC, the calculated ITBMS, and the recipient's status (resident, non-resident, exempt). Third: review of Auxiliary Electronic Invoice Documents (DAFE) delivered to the end customer as the graphical representation of the CUFE.

For an SMB invoicing from Odoo, the operational flow is:

1. Odoo generates the XML following DGI's XSD schema.
2. The XML is signed with the issuer's digital certificate and sent to the contracted PAC.
3. The PAC validates, signs with its own certificate, and forwards to DGI.
4. DGI responds with authorization (CUFE assigned) or with a rejection and an error code.
5. Only then does the DAFE PDF go out to the customer.

The operational consequence: if the PAC→DGI cycle fails, there is no invoice. No collection. No expense recognition by the buyer. For more regulatory context on the Panamanian ecosystem, see the Panama country profile.

DGI free invoicer vs Odoo: real pros and cons

DGI offers a free online invoicer aimed at micro-businesses and independent professionals. The fair question is: if DGI gives it away, why bother with Odoo?

The answer is not ideological. It is operational. The free invoicer is built to issue documents one at a time from a web form. It has no public API, no integration with your ERP, no inventory handling, no bank reconciliation, and no exportable sales ledger for the accountant. For a micro-business issuing 5–15 invoices per month, it is enough. For any operation above 30 monthly transactions or with a product catalog, it becomes a bottleneck.

The pragmatic threshold to migrate from the invoicer to Odoo sits between 30 and 50 invoices per month, or when the first need for inventory, bank reconciliation, or automated reporting appears. Before that, the free invoicer is defensible.

Configuring l10n_pa in Odoo: the honest version

Here comes the uncomfortable truth. Odoo SA does not publish an official l10n_pa in the Community version. There is an l10n_pa.gt module and other community forks that partially cover the Panamanian chart of accounts, but integration with DGI's SFE almost always depends on a module developed by the PAC or by a local partner.

What is available in community repositories (OCA Panama, Odoo Apps Store):

• Panamanian chart of accounts adapted to the Ministry of Economy and Finance.
• ITBMS calculation at 7% with exemption handling (education, health, basic basket products).
• Auxiliary reports: sales ledger, purchase ledger, withholdings.

What is not available out-of-the-box and is almost always developed in-house or bought from the PAC:

• XML→PAC connection with the exact format each PAC requires (every PAC has its own endpoint and sometimes its own XML flavor).
• Handling the CUFE returned by DGI and persisting the authorized document.
• Automated retry on temporary PAC error.
• Generating the DAFE PDF with QR code and mandatory fields per current resolution.

The realistic path: contract the PAC's connector (TheFactoryHKA, Inviu, EDISA, and similar publish certified Odoo modules bundled with their service) instead of coding the integration from scratch. If you need to evaluate whether your current installation is properly built, consider an Odoo audit before migrating PACs.

Integration with Panamanian banks and reconciliation

The second operational pain is reconciliation. Panama uses the US dollar as legal tender alongside the balboa (B/.) at a 1:1 rate, but banks export statements in heterogeneous formats. Banco General and Banistmo deliver CSV with a different structure than Multibank or Banesco, and none uses the ISO 20022 standard (MT940 or camt.053) that Odoo reads natively.

What works in practice:

• OCA account_bank_statement_import_csv module with per-bank mapping. Once configured, it becomes minimal maintenance.
• Reconciliation rules by amount + CUFE number. If the bank returns the deposit reference and it matches the CUFE, Odoo reconciles automatically. This requires a custom field on account.move.line.
• Outstanding-item report grouped by aging and customer, exportable in a format compatible with the accountant.

After implementing automated CUFE-based reconciliation at a Panamanian logistics client, monthly closing time dropped from 9 days to 2. The cost of NOT automating: 7 days per month of a junior accountant spending 100% of their time manually marking collections — roughly USD 4,200 per year in direct cost, not counting the error risk that had already produced three DGI requirements for declared inconsistencies.

Whoever starts automated reconciliation without first stabilizing the PAC→DGI flow ends up reconciling invoices that technically don't exist for the tax authority. Order matters: first ensure every invoice issued from Odoo has a valid CUFE, then concentrate on banks.

Case: Panamanian SMB exporting professional services

Anonymous client. Legal firm of 18 people in Panama City, invoicing corporate legal services to clients in Costa Rica, Colombia, and the United States. Volume: 60–80 invoices monthly, average ticket USD 4,500.

Initial problem: the team issued invoices from DGI's free invoicer, one at a time, copying client data from a master Excel. Three recurring errors:

1. Foreign client RUC mistyped — DGI rejects due to inconsistency with the format of the client's country of origin.
2. ITBMS calculation applied by mistake to exported professional services, which should carry zero rate when consumed outside Panama.
3. Inability to generate the monthly service-export report requested by the accountant.

Diagnosis: 14% of invoices required re-issuing within the first 30 days due to some error in the original document. The friction cost was double: time of the legal assistant who reissued, and above all delay in collecting from foreign clients who rejected the first document.

What was implemented:

• Odoo 17 Community with a certified PAC module.
• Customer master imported from the Excel, normalizing the "document type" field (RUC, NIT, EIN per country).
• Automated rule on the invoice: if the customer has a country other than PA → ITBMS rate = 0% with the legal justification in the document detail.
• Bilingual DAFE template for US clients (DGI legally requires Spanish, but the graphical representation delivered to the customer can be bilingual).

Result at 90 days: re-issuing rate dropped to 1.8%. Per-invoice issuing time went from 7 minutes to 90 seconds. The accountant's monthly close, which required a full day of review, shrank to 2 hours because reports come pre-balanced from Odoo. To accelerate diagnosis in similar cases, we maintain a DGI Panama 2026 checklist with the 38 points we review before approving go-live.

Preguntas frecuentes | Frequently asked questions