Kenyan VAT-registered businesses must transmit invoice data to the Kenya Revenue Authority through eTIMS, and the tax authority — not your finance team — decides when an invoice is legally issued. Dynamics 365 Business Central posts a clean sales invoice, calculates VAT from your posting groups, and prints a report layout, but it has no concept of a control unit, an invoice signature, a KRA item classification code, or a transmission that can be rejected hours after posting. Teams fill that gap with a spreadsheet, a separate eTIMS client, and someone re-keying invoice lines twice a day — which is where the numbers drift, item descriptions stop matching, and a VAT return has to be reconciled against a system nobody in finance controls.

We build a Business Central extension that closes the loop inside the application. A table extension on Sales Invoice Header (plus the credit memo, customer and item tables) carries the eTIMS fields: control unit invoice number, receipt signature, internal data, signing timestamp, transmission status, and the KRA classification, packaging unit and quantity unit codes. A codeunit subscribing to OnAfterPostSalesDoc enqueues the document rather than blocking the posting session — the user who posts an invoice is never held hostage by a device timeout. A job queue entry drains that queue, builds the eTIMS payload strictly from posted data (never from the unposted document), calls your OSCU or VSCU endpoint, and writes the response back onto the posted record. Where you run a hardware control unit on-premises, the same codeunit reaches it through a configurable local endpoint; where you use the virtual unit, it calls the KRA-facing service directly.

One posting produces both outputs. The human-readable document — the report layout your customers receive — is extended to carry the control unit number, signature block and QR payload, so the PDF a customer holds and the record KRA holds originate from the same posting event rather than two parallel processes. Master-data mapping is configuration, not code: a setup page maps VAT posting setup combinations to eTIMS tax categories, and the item card gains classification, packaging unit and quantity unit fields with validation, so an unclassified item is caught during scoping rather than at 4pm on a filing deadline.

Rejections are treated as a workflow, not an error log. Every attempt writes a record with the request, response code, KRA message and retry count. Rejected documents land on a dedicated correction list page where a finance user reads the reason, fixes the underlying data — a missing classification code, a customer PIN that fails validation, a tax mapping gap — and re-submits, with retries bounded and audited so nobody silently re-sends the same invoice twenty times. Successful transmissions are immutable: the signature, payload hash and timestamp are locked, permission sets separate the clerk who submits from the controller who can force a correction, and the archive is queryable through custom API pages (REST API v2.0 / OData v4) so auditors, a Power BI model, or a Dataverse-connected Power App can read it without a database login.

This is build-to-order. Nothing is downloaded from AppSource. You request a quotation, we run a scoping call against your actual Business Central version, localisation, device type and document flows, and we then build the extension for your tenant. Typical delivery is 2 to 4 weeks from confirmed scope. You receive the AL source, the app deployed to a sandbox for UAT before production, and a written rollback plan. The extension is versioned in a git repository handed over at the end, so you own it whether or not you keep working with us.