Sage · Uganda · URA EFRIS

Fiscalise Sage invoices to URA EFRIS, automatically

Raise the invoice in Sage as you already do. It is submitted to EFRIS, and the fiscal document number, verification code and QR code come back — ready to print on the document your customer receives. Nobody re-keys anything into the URA portal.

Get my Sage connected API docs for developers

“Sage” is several different products

More than any other accounting brand, the name says less than people expect. Two businesses both running “Sage” can have almost nothing in common underneath. Which one you have decides how the invoice is read, so it is the first thing to establish — and it is usually answered in a single phone call.

Sage 50 and Pastel

The most common in Uganda by a distance, and desktop: the company data sits on a machine or a server in your office. A connector runs alongside it, reads invoices as they are posted and writes the EFRIS result back.

The machine holding the data has to be on when invoices are raised.

Sage 200 Evolution and Sage 300

Mid-market, usually on a SQL Server in your own building or in a data centre, and built to be extended. Invoices can be picked up as they are posted, and the fiscal details written back onto the document so the printed invoice carries them.

Multi-branch and multi-warehouse setups are ordinary here, which matters — see the numbering point below.

Sage X3 and Sage Business Cloud

Both expose web services, so the connection is made over the network with no software installed on anyone's desk. Business Cloud Accounting is authorised once and refreshes itself from then on; X3 is larger, and its integration is scoped alongside whoever maintains it.

This is the cleanest of the three routes where it is available to you.

If you are not sure which you have, the version line on the login screen or the Help → About window settles it, and we can tell from that alone what the work involves.

What comes across

EFRIS needs more than the invoice itself. These are read from Sage and kept in step.

Invoices

Fiscalised to EFRIS, with the fiscal document number, verification code and QR code returned for printing on the document.

Credit notes

Raised against the original invoice, which URA requires — a credit note detached from its invoice is rejected.

Inventory and service items

Registered with URA through the API as part of the integration, carrying their unit of measure and tax treatment. Nothing is keyed in by hand.

Stock movements

For goods: opening stock and subsequent movements, which URA requires before those goods can be invoiced. Services carry no stock.

Customer accounts

Buyer type and TIN where the sale is business-to-business, which changes what EFRIS requires on the document.

Tax treatment

Standard-rated, zero-rated, exempt and deemed VAT, plus excise duty where it applies — resolved from your own tax codes, whatever they are numbered.

Where Sage and EFRIS disagree

The connection is not the difficult part. Reconciling how the two systems think about a sale is, and it is where in-house attempts usually stall.

Your tax codes mean whatever your company decided they mean

Sage tax types are set up per company, so tax code 1 in your books and tax code 1 in the business next door can be entirely different things. EFRIS has one fixed set of tax categories and no interest in your numbering. The mapping between them is specific to your installation, has to be established once against your actual VAT return, and is the single most common reason a Sage integration produces invoices URA accepts but the accountant does not recognise.

An item valid in Sage can still be unknown to URA

A product has to exist in the EFRIS catalogue before an invoice can mention it, and its unit of measure must come from URA’s own list rather than whatever the inventory master calls it. Registration happens through the API — it is one of the first calls an integration makes — so this is handled, not typed in somewhere.

Goods need stock recorded before they can be sold

URA rejects an invoice for goods it holds no stock against, so opening stock and subsequent movements have to be reported. Services are not stocked and need none of this. Where Sage is running several warehouses, the stock URA holds is against the taxpayer rather than against your warehouse structure, so the two do not map one to one.

Rounding is computed twice, and both answers have to agree

Sage works out the tax on a document with its own rounding rules; EFRIS recomputes it and rejects the document if the figures do not reconcile. A cent of difference on a long invoice is a rejection with a code and no hint that rounding was the cause. The reconciliation has to be done deliberately rather than assumed.

Document numbers collide across companies and branches

EFRIS enforces uniqueness of the seller reference per taxpayer, across every till and every integration on that TIN. Sage numbers documents per company and per document type, so two branches numbering independently — routine in a multi-company Pastel or Evolution setup — will produce the same number twice, and the rejection reads as a duplicate submission.

Each of these is a rejection code we have already worked through. The error-code reference documents them, free to read, whether or not you ever work with us.

Two ways to do this

Most businesses want the first. Sage resellers and teams with their own developers usually want the second.

We set it up

We set up the environment and everything your business needs to start issuing fiscalised invoices. You keep working in Sage exactly as before.

Talk to us

Your developers build it

Send invoices to our API as ordinary JSON and it handles the EFRIS protocol, the signing and the tax reconciliation — you stay on the Sage side of the problem, which is the side you know. Or licence the whole platform as source and run it on your own infrastructure.

efrisgateway.com

Questions & Answers

Sage and EFRIS — common questions

Can Sage connect to URA EFRIS?

Yes. Sage does not talk to EFRIS on its own, but it can be connected so that invoices raised in Sage are fiscalised with URA automatically and the fiscal document number, verification code and QR code are returned for printing. This applies to Sage 50 and Pastel, Sage 200 Evolution, Sage 300, Sage X3 and Sage Business Cloud Accounting; the route differs between them.

Which version of Sage do I need?

None in particular — the version you already run is usually the one we work with. What it changes is how the invoice is read: the desktop products are reached by a connector running alongside the company data, while Sage X3 and Sage Business Cloud Accounting are reached over web services with nothing installed locally. You do not need to upgrade Sage in order to fiscalise.

Does it work with Sage Pastel?

Yes, and it is the most common case we see in Uganda. Pastel keeps its company data on a machine or server in your office, so a connector runs alongside it, reads invoices as they are posted and writes the fiscal document number, verification code and QR code back for printing.

Do I have to change how I raise invoices in Sage?

No. You continue raising invoices in Sage as you do now. The fiscalisation happens behind it, and what changes is that the printed document carries the EFRIS fiscal document number, verification code and QR code that URA requires.

What happens when URA rejects an invoice?

The rejection is reported with the URA code and the specific reason, rather than a generic failure, so it can be corrected and resubmitted. Both sides of every submission are stored, which means a rejected document can be examined afterwards instead of reconstructed from memory.

Do I need to be a URA-accredited integrator to use this?

No. The fiscalisation is done using your own taxpayer credentials and device, so the invoices are issued by your business exactly as URA expects.

Other systems

Running something else?

The EFRIS side is identical whatever you run. What changes is how the invoice leaves your system, so each has its own notes.