Finance teams invoicing in Uganda live with a split process. The sale is recorded in Odoo, but the fiscal document is produced somewhere else — a URA EFRIS portal session, an offline client, or a spreadsheet someone re-keys at the end of the day. The result is predictable: FDNs that do not tie back to account.move records, credit notes issued in Odoo with no matching EFRIS credit application, VAT summaries that disagree between the ERP and the URA portal, and a month-end where the accountant reconciles two systems by hand. Odoo core does not know EFRIS exists. There is no Ugandan fiscal-device layer in Community or Enterprise, no FDN field on the invoice, no place to store a verification code, and the standard QWeb invoice report has no slot for a compliance QR. You can bolt on a tax group and call it VAT, but nothing in the stock product registers a document with a revenue authority or handles what comes back.

What we build is an EFRIS integration layer that lives inside your Odoo database and treats registration as part of posting, not as an afterthought. A dedicated model (typically efris.transaction) is linked one-to-one to each account.move and carries the full lifecycle: the payload we assembled, the signed request, URA's response, the FDN, verification code, QR payload, and the timestamp of each attempt. Confirming an invoice enqueues registration through a queued job or an automated action rather than blocking the user's click, so a slow or unreachable URA endpoint never freezes the accounting screen. Product and partner master data drive the payload: product.template gains the EFRIS goods/services classification code, unit-of-measure mapping and commodity category; res.partner carries TIN and buyer type; account.tax maps to the correct EFRIS tax category so exempt, zero-rated and standard-rated lines are declared exactly as they are posted. Computed fields with @api.depends keep mapped values in sync when master data changes, and a constraint blocks confirmation when a line's mapping is missing — the error surfaces at the desk, not at the revenue authority.

The response side is where most integrations fall down, so we build it explicitly. A successful registration writes the FDN, verification code and QR back onto the move and stamps a chatter message with the raw response for audit. The QWeb invoice and receipt reports are extended to render the human-readable fiscal block plus the QR image, so one posting produces both the document a customer can read and the machine record URA holds. Rejections are not swallowed: the transaction moves to a rejected state with URA's error code and message, an activity is raised on the responsible user, and a correction workflow lets finance fix the underlying data — a wrong classification code, a missing TIN, a tax mapping — and re-submit against the same move without creating a duplicate accounting entry. Credit notes route through the EFRIS credit-note flow with the reference to the original FDN carried automatically. Everything is reachable over Odoo's XML-RPC/JSON-RPC API so a POS front end, a webshop, or a third-party billing system can trigger the same code path, and access is controlled with ir.model.access.csv plus record rules so only the finance group can view credentials or re-submit a transaction.

This is a build-to-order product, not a download. EFRIS behaviour depends on your taxpayer configuration, the credentials URA issued you, the shape of your product catalogue, and whether you invoice from Sales, POS, Subscriptions or a custom flow. We start with a scoping call, confirm your Odoo version (17.0, 18.0 or 19.0), edition (Community or Enterprise — Enterprise-only dependencies are declared or avoided based on what you actually run), and your URA integration credentials and test environment. We then build against your data, deploy to a staging database for UAT with your own invoices, and only after your sign-off do we install on production with a rollback plan in hand.

Typical delivery is two to four weeks from confirmed scope. You receive the full source of the module — __manifest__.py, models, views, security rules, QWeb reports and data files — in a git repository you own, so nothing about your compliance path is locked to us. Where URA changes a schema or a field, the fix is a change in code you already hold, applied by us during your support window or by your own team afterwards.