Finance teams invoicing in Uganda face a hard split between where the sale actually happens and where it becomes legal. The revenue is recognised in Dynamics 365 Business Central, but the fiscal document only exists once the Uganda Revenue Authority EFRIS service has accepted it and issued a Fiscal Document Number, a verification code and a QR payload. The usual workaround is the EFRIS web portal or an offline client: an accountant re-keys the customer TIN, the line items, the commodity codes and the tax categories a second time, pastes the FDN back into a spreadsheet, and hopes nobody edits the invoice in between. Every re-key is a chance for the posted Sales Invoice Header in Business Central and the fiscal record at URA to disagree — and the disagreement is only discovered at audit, when the two sets of numbers are compared.

Business Central out of the box has no concept of any of this. Its VAT posting setup, VAT statements and electronic-document framework are built around EU/UK-style reporting and the generic e-document connectors; there is no EFRIS T-code client, no AES/RSA envelope handling, no goods-and-services registration against the URA commodity dictionary, no credit-note approval state, and nothing on the invoice page to hold an FDN. You can post a perfectly correct invoice in Business Central and still be non-compliant, because compliance in Uganda is defined by what URA has on file, not by what your ledger says.

What ECOSIRE builds is an AL extension that closes that gap inside the system you already run. Table and page extensions add the fiscal fields — FDN, verification code, invoice issuing status, URA reference, QR data and the raw response envelope — to the sales invoice and credit memo, posted and unposted, plus an EFRIS Setup page holding the taxpayer TIN, device number, environment endpoint and key material in Isolated Storage rather than in a plain setup table. A dedicated communication codeunit assembles the EFRIS T-code payloads (login/session, goods and services upload, invoice upload, invoice query, credit note application and approval query), applies the AES content encryption and RSA signature the service expects, and posts over HttpClient. Event subscribers on the posting routines create the fiscal request the moment a document is posted, so nobody has to remember a second step, and a Job Queue Entry drains the queue with bounded retries — an EFRIS timeout never blocks the posting transaction or leaves a half-posted document behind. Mapping is driven from your existing master data: item and G/L account mapping to URA commodity codes and unit-of-measure codes, VAT posting groups to EFRIS tax categories, and customer TIN/NIN validation on the Customer card, so the payload is derived from records your team already maintains rather than a parallel list.

Rejections are treated as a first-class workflow, not an error log. Every attempt is written to an EFRIS Transaction Log with the request, the response, the URA return code and a human-readable reason, and a rejected document lands in a correction queue with the offending field identified — a missing commodity code, a TIN that fails validation, a rounding difference on tax. The user corrects and resubmits from the document page; nothing is silently retried into a duplicate registration, because submissions are keyed idempotently on the posted document number. Credit memos follow the two-step reality of EFRIS: the application is filed, the document sits in a pending state, and a background query promotes it once URA approves or surfaces the rejection reason. Both the human-readable output (the invoice report layout carries the FDN, verification code and QR image so the printed or emailed document is the compliant one) and the machine format (the archived signed envelope) come from the same posting — you never generate two versions that can drift. Archived envelopes and log entries are retained with a defined retention policy, exposed through an API page (REST API v2.0 / OData v4) so an auditor request, a Power BI reconciliation or a Power Automate flow can read the fiscal state without a developer.

This is a build-to-order engagement, not an instant download. We start with a scoping call, confirm your Business Central deployment (SaaS online or on-premises), your release wave, whether you need a per-tenant extension or an AppSource-track app, your EFRIS taxpayer and device registration status, and the specific document flows in scope — standard sales, POS-style receipts, credit notes, exports and exempt supplies each carry different tax categories. From confirmed scope, typical delivery is 2-4 weeks: we build against your sandbox, run UAT with your finance team on the EFRIS test environment, then install into production with a rollback plan and a support window. You receive the AL source, the git repository, technical and user documentation and a training session — the extension is yours, on your tenant, and it can be extended later by us or by your own team.