Panama e-invoicing from SAP Business One: NUC-JSON field mapping and DGI rejections

To issue a Panama electronic invoice (Factura Electrónica, FE) from SAP Business One through the Digifact PAC, you send one NUC-JSON document per invoice or credit memo. Most of the data already sits in OINV, INV1, OCRD and OITM. What SAP B1 does not have out of the box is the receiver type, the RUC check digit (DV), the location code (CodUbi) and the CPBS item code, so those become user fields. The PAC answers with a CUFE, an authorisation protocol and a QR URL, which you write back to the document.

This guide is the mapping I use in my SAP Business One add-on for Panama. It was tested on 27 October 2026 in an SAP B1 10 company on SQL Server against the Digifact sandbox: 34 scenarios, from a 7 % consumer invoice to a 105-line invoice, exports, zona franca, credit notes and cancellations. For the commercial overview, see Panama e-invoicing for SAP Business One.

How does the flow from SAP Business One to the DGI work?

1. The user adds an A/R invoice (object 13) or A/R credit memo (object 14) in SAP B1 as usual.
2. The add-on reads the document, checks the DGI rules it can check locally, and builds the NUC-JSON.
3. It posts the JSON to Digifact (/api/v2/transform/nuc_json, query params TAXID, FORMAT, USERNAME). Digifact turns it into the DGI XML, signs it and gets the authorisation.
4. The answer carries the CUFE, the protocol, the authorisation date and the QR URL. The add-on writes them to user fields on OINV/ORIN and attaches the XML and PDF to the document.

Two design decisions saved me the most trouble:

• One registry row per document (a user table, @FE_PA_DOC, keyed 13-<DocEntry> or 14-<DocEntry>). Two workstations that add documents at the same time can never send the same invoice twice.
• Query before resend. If the send timed out, the add-on first asks Digifact whether that NumeroDF already exists, and only then sends again. In the test, pressing “Reintentar” on an already authorised invoice returned the same CUFE and sent nothing.

Which SAP B1 fields map to which NUC-JSON fields?

The NUC-JSON is case-sensitive. Buyer.TaxID works, buyer.taxid does not. Many values go in lists of { "Name": ..., "Value": ... } objects rather than plain properties, which is the first thing that trips people coming from Guatemala FEL or El Salvador DTE.

Two details from testing that the spec does not make obvious:

• Line amounts, not header amounts. Build every total from the lines and let the header be their sum. I had zero mismatches across multi-rate invoices (0, 7 and 10 % on one document) and a 105-line invoice by rounding each line to two decimals first, then adding.
• Foreign currency companies. If the company’s local currency is not USD, DocTotal, LineTotal and VatSum are in local currency. The e-invoice must carry the document currency, so read DocTotalFC, TotalFrgn and VatSumFrgn instead. My test company had GBP as local currency, which is how this showed up.

Which user fields do you need in SAP Business One?

Inputs (the user or the BP master fills them): U_FE_TipoRec, U_FE_TipoRuc, U_FE_DV, U_FE_CodUbi on OCRD; U_FE_CPBS on OITM; U_FE_Incoterm, U_FE_PuertoEmb and U_FE_TipoDoc on the document.

Outputs (written by the add-on on OINV and ORIN): status, CUFE, protocol, authorisation date, QR URL, NumeroDF, issue date/time sent, error text, attempts, and the cancel reason. The QR URL is about 560 characters, so it needs a memo field, not a 254-character alphanumeric one.

Many clients already have their own fields for RUC type or DV from a previous localization. My settings screen lets you point each key to an existing field instead of creating a duplicate. Whatever you do, create the fields through the DI API or the UI, never with ALTER TABLE.

Before go-live I run this check. It lists the master data that will be refused before anything reaches the PAC. SQL Server version first:

-- Customers that will fail: contribuyente/gobierno without RUC, DV or location code
SELECT C.CardCode, C.CardName, C.LicTradNum, C.U_FE_TipoRec, C.U_FE_DV, C.U_FE_CodUbi
FROM OCRD C
WHERE C.CardType = 'C'
  AND ISNULL(C.U_FE_TipoRec, '01') IN ('01', '03')
  AND (ISNULL(C.LicTradNum, '') = '' OR ISNULL(C.U_FE_DV, '') = '' OR ISNULL(C.U_FE_CodUbi, '') = '');

-- Items sold in the last 90 days without a CPBS code
SELECT DISTINCT L.ItemCode, I.ItemName
FROM INV1 L
INNER JOIN OINV H ON H.DocEntry = L.DocEntry
INNER JOIN OITM I ON I.ItemCode = L.ItemCode
WHERE H.DocDate >= DATEADD(DAY, -90, GETDATE())
  AND ISNULL(I.U_FE_CPBS, '') = '';

SAP HANA version (quoted identifiers, IFNULL, ADD_DAYS):

SELECT C."CardCode", C."CardName", C."LicTradNum", C."U_FE_TipoRec", C."U_FE_DV", C."U_FE_CodUbi"
FROM "OCRD" C
WHERE C."CardType" = 'C'
  AND IFNULL(C."U_FE_TipoRec", '01') IN ('01', '03')
  AND (IFNULL(C."LicTradNum", '') = '' OR IFNULL(C."U_FE_DV", '') = '' OR IFNULL(C."U_FE_CodUbi", '') = '');

SELECT DISTINCT L."ItemCode", I."ItemName"
FROM "INV1" L
INNER JOIN "OINV" H ON H."DocEntry" = L."DocEntry"
INNER JOIN "OITM" I ON I."ItemCode" = L."ItemCode"
WHERE H."DocDate" >= ADD_DAYS(CURRENT_DATE, -90)
  AND IFNULL(I."U_FE_CPBS", '') = '';

If you only have SQL Server queries today, the SQL to HANA converter handles most of the dialect changes.

How do credit notes reference the original invoice?

A credit memo in SAP B1 that is based on an invoice (RIN1.BaseType = 13, BaseEntry = <invoice DocEntry>) becomes DGI type 04. It must carry three values in AdditionalInfo: the issuer name (NombEmRef), the issue date/time of the original e-invoice (FechaDFRef) and its CUFE (CUFERef). That is why the issue time must be stored when the invoice is sent. You cannot rebuild it later from DocDate.

A credit memo without a base document, or based on an invoice from before your go-live date, is a generic note, type 06, with no reference.

The DGI rules that bit hardest, all of which I now check in SAP before sending:

A credit note on a base invoice that is not authorised yet is not an error. My add-on holds it until the invoice has its CUFE, then sends it.

What causes the most common Panama FE rejections?

From the sandbox tests, in the order I hit them:

• Government receiver (03) with a normal RUC. Rule 1604: the RUC must be in the DGI table of government entities (Tabla 30). If the customer is not on that list, use receiver type 01. After correcting the RUC, a simple retry authorised the same invoice.
• Consumidor final with a legal-entity RUC. Rule 1621: a jurídico RUC (TaxIDType 2) cannot be receiver type 02.
• Export or foreign operation without INCOTERM. For types 03 and 10 the sandbox answered that the delivery conditions (CondEntr) were missing. Put the INCOTERM in a document UDF and send it in AdditionalInfo.
• The < character in an item description. One test invoice came back “XSLT failed” because of a < in the line text. Escape or replace it before sending. ñ, á, &, " and > were all accepted, including a customer called “Compañía Ñandú & Hijos”.
• Document-level discount. OINV.DiscSum has no clean place in the item structure. My add-on blocks a document that still has a header discount and asks for line discounts instead. The same header-discount problem distorts sales reports too, see why SAP B1 sales totals do not match.

How do you cancel (anular) an e-invoice from SAP Business One?

Cancellation goes to Digifact’s CancelFePA endpoint with the issuer RUC, the CUFE, a reason (Motivo) and the user. Two things I measured on the test environment:

1. Right after authorisation, the cancel fails with {"Codigo":9019,"Anulado":false,"Mensaje":"Anulacion incorrecta. Verifique si el CUFE pertenece a una FE existente"}. Three to eight minutes later the same call was accepted. My add-on retries once a minute instead of showing the user an error.
2. Short reasons fail with the same 9019. Twenty characters or fewer were always refused, 25 or more always accepted, although the DGI technical sheet allows 15 to 1000. I enforce a 25-character minimum in the form.

In SAP B1, Data > Cancel on an authorised invoice should cancel at the DGI first. If the DGI refuses, block the SAP cancellation, otherwise SAP shows the invoice as cancelled while the DGI still counts it as valid. An invoice that never reached the DGI can be cancelled in SAP directly.

If you are building this as an add-on yourself, the event handling, packaging and DI posting patterns are in my SAP Business One add-on development guide, and the fields of the tables above are in the SAP B1 table reference.

What is still open?

Contingency mode (TipoEmision 02/04) and currencies other than USD are not in my add-on yet. Debit notes (05 and 07) were authorised on the sandbox, but a company with UK localization cannot post them from the DI API (DocumentSubType = DN is refused), so test those in a company with Panama or Latin America localization.

If you run SAP Business One in Panama and need FE through Digifact, tell me about your setup. I have done the same kind of integration for Guatemala FEL, El Salvador DTE, Ecuador SRI and Saudi ZATCA.

Sources

• Digifact: Documentación técnica NUC-JSON Panamá V2.0.8
• DGI Panamá: Factura electrónica

Related services

• E-invoicing integration
• SAP Business One development