EFRIS Invoice — every invoice, fiscalised
Fiscalise every customer invoice and credit note to the Uganda Revenue Authority through EFRIS in real time. The Fiscal Document Number (FDN), the verification (anti-fake) code and the EFRIS QR come straight back and print on the invoice PDF. VAT is reported in the EFRIS categories — Standard 18%, Zero-rated, Exempt and Deemed — plus item-level excise.
One-time purchase · unlimited documents · free updates on every URA EFRIS spec change. Requires the free EFRIS Base.
Post as usual — EFRIS compliance happens for you
Posting a customer invoice enqueues a T109 fiscalisation; the accountant never waits on the URA server. Credit notes are raised as T110 applications referencing the original invoice, and the FDN, verification code and QR land on the record and on the printed PDF. Because everything flows through the async queue, posting is never blocked — a fiscalised document is simply guarded from being reset to draft.
T109, done right
Every posted invoice is uploaded to URA EFRIS as a T109 fiscalisation — sellerDetails, buyerDetails, goodsDetails, taxDetails and summary built to the EFRIS specification — and the FDN comes straight back onto the record.
The FDN on the paper
The Fiscal Document Number, the verification (anti-fake) code and the EFRIS QR are stored on the record and printed on the invoice PDF, so any buyer can validate the sale on the URA EFRIS app or portal.
VAT the EFRIS way
Tax is reported in the EFRIS categories — Standard 18%, Zero-rated, Exempt (the literal “-” convention) and Deemed — plus item-level excise duty, matched to the shilling.
From draft to fiscalised — every detail on the invoice
Every posted invoice is declared to URA in real time
Posting a customer invoice builds the complete EFRIS T109 upload — sellerDetails, buyerDetails, goodsDetails, taxDetails, summary and payWay — and hands it straight to the submission queue. The chatter records the moment: “Queued for URA EFRIS declaration (T109)”, then “EFRIS fiscalised. FDN: ...” once URA answers. Your accountant never waits on the URA server, and if a declaration cannot even be built the invoice still posts — the failure is recorded on the document instead of blocking your books.
The whole URA acknowledgement lives on the invoice
Every customer invoice gains an EFRIS tab carrying the EFRIS Status, the Fiscal Document Number (FDN), the EFRIS Invoice ID, the Verification (anti-fake) Code, the EFRIS Reference used on the upload and the verification QR payload URA returned. Nothing is hidden in a log file — the full fiscal acknowledgement sits on the record, ready for an audit or a buyer query. If URA rejects the document, the rejection reason appears in the same tab in plain words so you can fix the invoice and re-send it.
Fiscal state at a glance, one click to re-declare
A shield pill in the invoice header shows the EFRIS state on the record itself — To Declare, Queued, Fiscalised, Failed or No EFRIS Config. A “Declare to EFRIS” button appears on any posted invoice that has not yet been fiscalised, so an accountant can push a held or failed document to URA on demand rather than waiting for the next sweep. Only posted documents can be declared; the action refuses drafts, and an already-fiscalised invoice is simply skipped.
FDN, verification code and QR print on the invoice
Once URA answers, the printed invoice carries a proper fiscal footer: Fiscal Document No (FDN), Verification Code, EFRIS Invoice ID, your TIN and a scannable QR, under the statement “This is a fiscal document issued through URA EFRIS”. Your buyer scans the QR in the URA EFRIS app, or checks the code on the URA portal, and confirms the sale is genuine in seconds. The block prints only on documents URA has actually fiscalised, so a draft or an undeclared invoice can never carry a fake FDN.
The numbers URA validates are the numbers you print
Line amounts come straight from Odoo’s own tax engine, so tax-inclusive and tax-exclusive price lists both declare correctly: quantity, unit price, net, gross and tax per line, to two decimals. taxDetails is then aggregated per EFRIS category, and the summary carries the net, tax and gross amounts plus the item count. The VAT 18% totals on the printed invoice are exactly what was uploaded — matched to the shilling, with no re-keying and no second calculation to reconcile.
Refunds go to URA as a proper T110 application
A refund is raised as an EFRIS credit-note application (T110), never as a hand-patched invoice. The upload references the original invoice’s EFRIS Invoice ID and FDN, carries the URA reason and reason code, and comes back with its own FDN and verification code on the credit note’s own EFRIS tab. That is the URA-approved way to reverse a fiscalised sale — and the credit note prints with its own fiscal footer just like the invoice it reverses.
Map your taxes to EFRIS once and stop the rejections
Each sale tax carries an EFRIS Tax Category: 01 Standard (18%), 02 Zero-rated, 03 Exempt or 04 Deemed. Exempt lines are sent with the literal “-” rate that EFRIS expects rather than a plain zero — a detail that quietly causes rejected uploads for anyone who has not met it before. Set the category once per tax and every invoice afterwards reports VAT in the exact buckets URA validates.
Unmapped taxes still declare, deemed lines flag themselves
You do not have to hand-map a long tax table before going live. Any sale tax left without an EFRIS category falls back sensibly — Standard when its rate is above zero, Exempt when it is not — and a built-in classifier can stamp every unmapped sale tax in one pass. Lines whose tax is category 04 are automatically marked as deemed on the upload, and every line carries its excise flag, so the goods detail URA receives is complete without extra clicks.
A fiscalised invoice cannot be quietly edited
Once URA has fiscalised an invoice, Reset to Draft is blocked with a plain explanation: the document is fiscalised at URA under its FDN, editing it would diverge your books from EFRIS, and a credit note is the correct remedy. This stops the single most damaging mistake in a fiscalised ledger — reopening a document the revenue authority has already accepted. Invoices that were never declared, or that were skipped, reset to draft exactly as normal.
Keep the documents that must never reach URA out of it
A “Skip EFRIS” tick box on the EFRIS tab holds a document out of the declaration flow entirely — the right answer for opening balances, migrated history and internal invoices that should never be fiscalised. It is copy-safe: duplicate the invoice and the flag does not travel with it, and neither do the FDN, verification code or EFRIS reference of the original. Everything else posts and declares exactly as usual.
A URA outage never costs you an invoice
Declarations flow through the EFRIS queue, which shows the interface (T109 invoice, T110 credit note), the source document, the FDN when it lands, the attempt count, the next attempt time and a colour-coded state — Sent in green, Pending in grey, Failed in red with the URA message spelled out. A background sweep retries failures on a widening back-off (a minute, then two, five, ten, twenty, thirty, up to an hour), and “Send now” pushes any row immediately. Re-declaring a document updates its pending entry rather than adding a second one, so nothing is ever declared twice.
AES-encrypted, RSA-signed, and it re-keys itself
EFRIS is a URA cloud API, not a fiscal box: every upload is AES-encrypted and RSA-signed inside the URA envelope, precisely as URA’s own reference client does it. Initialize Device runs the URA handshake once and stores your device keys; the session key is then cached and silently refreshed the instant URA reports it expired, and the upload is retried without anyone noticing. Sandbox and production URLs are both prefilled, so you prove the whole flow on the EFRIS sandbox and flip a single radio button to go live.
We connect you to URA EFRIS
Buying the app includes the setup: we help you register your device on the URA EFRIS portal, initialize the secure keys with URA over the cloud API, validate the full flow on the EFRIS sandbox, then switch you to production.
Device on the URA EFRIS portal
TIN, TaxpayerID, device, tax categories
Full flow on the EFRIS sandbox
Switch to production, declare for real
One suite, sold your way
Buy only what you need on the free Base, or take the all-in-one Suite.
Frequently asked
Does it need the EFRIS Base?
Yes — the free EFRIS Base provides the URA connection, the AES/RSA crypto and the async submission queue this app builds on.
What about credit notes?
They are raised as an EFRIS credit-note application (T110) against the original invoice, with a reason, and tracked through URA approval — the compliant way to reverse a fiscalised sale.
Does it ever block me from posting?
No. Fiscalisation runs on the async queue and retries on its own; a fiscalised document is guarded from being reset to draft, but posting an invoice is never blocked.
Ready for URA EFRIS compliance?
Install now, or write to us — we set up your EFRIS connection with you.
reach@aminitechsolutions.comURA EFRIS e-invoicing for Odoo · Uganda · T109 · FDN + verification QR
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Invoicing (account)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1005 |
| Technical Name |
aminitech_efris_invoice |
| License | OPL-1 |
| Website | https://www.aminitechsolutions.com |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module