Acumatica Uganda URA EFRIS Integration — A Complete Guide

Uganda's URA rolled out EFRIS — the Electronic Fiscal Receipting and Invoicing Solution — as a mandatory real-time invoicing system, and any Acumatica tenant selling in Uganda needs a way to get invoice data to URA at the moment of posting, not in a nightly batch. The integration is conceptually simple; the operational details around downtime and document types are where implementations go wrong.

What EFRIS actually requires

Every taxable sale needs to be reported to URA in real time: an e-invoice for B2B transactions where the buyer has a TIN, and an e-receipt for B2C retail sales. URA's system validates the submission and returns a Fiscal Document Number (FDN) and a QR code, both of which must appear on the printed or emailed document the customer receives. Without a valid FDN and QR code, the invoice isn't compliant, regardless of what your GL says.

URA exposes this through the EFRIS API (commonly integrated via the T130 web service interface) and also offers a EFRIS Client — a local application some businesses run as a virtual fiscal device when they don't want to build direct API integration. For an Acumatica integration, direct API calls from a customization or middleware layer is the more maintainable path; running a separate client app alongside Acumatica just adds another moving part to keep alive.

Hooking invoice posting to EFRIS submission

The natural trigger point is the AR Invoice posting event — you want the EFRIS submission to fire once the invoice is released and posted to GL, not before, since a voided or on-hold invoice shouldn't generate a fiscal document. Acumatica's business events can watch for the AR Invoice status change to Open/Closed and call a webhook or a custom processing screen that builds the EFRIS payload and calls the API. For higher-volume tenants, a PXGraphExtension override on the release graph gives you more control over retry and error handling than a business event alone.

{
  "invoiceNo": "INV-2026-04211",
  "sellerDetails": { "tin": "1009873456", "ninBrn": "", "legalName": "Example Traders Ltd" },
  "buyerDetails": { "tin": "1004521987", "legalName": "Kampala Retail Partners" },
  "goodsDetails": [
    {
      "item": "Assorted stationery",
      "qty": 40,
      "unitPrice": 12000,
      "taxRate": "18%",
      "total": 480000
    }
  ],
  "invoiceType": "1",
  "invoiceKind": "1",
  "currency": "UGX",
  "issuedDate": "2026-07-22 10:14:00"
}

Handling EFRIS downtime and offline mode

URA's infrastructure has outages, and a business can't stop invoicing while it waits for EFRIS to come back. EFRIS supports an offline allowance — invoices can be issued locally and submitted once connectivity returns, within a defined window. Your integration should mirror that: queue the invoice payload locally (a staging table or a message queue) if the EFRIS call fails or times out, retry on a schedule, and only mark the document as "fiscalised" once URA actually returns an FDN and QR code. Never fabricate a placeholder FDN — an invoice without a real one isn't compliant no matter how the Acumatica record looks.

Storing the fiscal number and QR code

Once EFRIS returns a response, store the FDN and QR code data against the AR Invoice — typically as Usr-prefixed custom fields on the ARInvoice DAC (UsrEfrisFdn, UsrEfrisQrData) so they're available to the print/email template. The invoice or receipt report needs to render the QR code image and the FDN text before it goes to the customer; if your print layout ships before the EFRIS round trip completes, you'll hand out non-compliant paper.

Reconciling what was actually submitted

Because EFRIS calls happen out-of-band from the posting transaction, build a periodic reconciliation: pull all posted AR Invoices for a date range and confirm each one has a stored FDN. Anything without one either failed silently or is still in the retry queue — either way it needs attention before month-end, since URA's own records will show a gap that your GL won't.

Wrapping up

EFRIS integration is a real-time posting-event problem more than it's a batch-reporting one: hook the invoice release event, submit immediately, queue and retry through outages, and store the FDN and QR code before anything reaches the customer. Reconcile posted invoices against submitted ones regularly so a quiet EFRIS failure doesn't turn into a compliance gap.