Zambia Smart Invoice Compliance

Key Features

Table extensions on `Sales Invoice Header`, `Sales Cr.Memo Header` and `Service Invoice Header` storing Smart Invoice number, ZRA identifiers, device/branch reference, transmission status and timestamp

Event subscribers on the sales and service posting codeunits queue fiscalization asynchronously so document posting is never blocked by ZRA latency

Dedicated transmission codeunit handling ZRA Smart Invoice API and local Smart Invoice device (VSDC-style) endpoints, selectable per branch

Tax-type and item classification mapping driven from `Item`, `Item Category` and VAT Posting Setup, with a validation page that flags unmapped combinations before go-live

Smart Invoice Log table capturing full request payload, response body, HTTP status, ZRA error code and user for every attempt — read-only by permission set

Fiscalization Worksheet page listing failed and pending documents with plain-language error text, filtering, and a guided correct-and-resubmit action

Idempotency key per posted document so a retry, a job queue re-run, or a concurrent session can never create a duplicate fiscal record at ZRA

Credit memo and correction flow that carries the originating invoice's fiscal reference so ZRA receives a linked correction rather than an unrelated document

Report extension adding the fiscal block and verification QR code to the posted sales invoice and credit memo layouts (RDLC or Word layout, your choice)

Job queue entry that drains the pending fiscalization queue on a configurable interval and escalates aged failures by notification or email

Smart Invoice Setup page with per-environment endpoints and credentials held in isolated storage, keeping sandbox and production strictly separated

API pages exposing fiscal status and log summaries over REST API v2.0 / OData v4 for Power BI, Power Automate or Dataverse virtual-table consumption

Permission sets separating post, re-transmit and read-only log access, aligned to your existing Business Central user groups

Statutory archive retention on the log with deletion blocked inside the retention window, plus an export action for auditor requests

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Zambian VAT-registered businesses must transmit sales documents to the Zambia Revenue Authority's Smart Invoice service and print the returned fiscal identifiers on the customer's copy. Dynamics 365 Business Central posts a clean Sales Invoice Header with VAT posting setup, currency and dimensions all correct — and then stops. There is no field to hold a Smart Invoice reference, no verification QR data, no retry when the ZRA endpoint or the local Smart Invoice device is unreachable, and no way to tie a posted credit memo back to the fiscal reference of the invoice it corrects. Finance teams end up keying the same invoice a second time into a separate ZRA portal or VSDC utility, reconciling two sets of numbers at month end, and discovering mismatches only when an auditor asks.

ECOSIRE builds a Business Central AL extension that closes that gap inside the ERP. Table extensions on Sales Invoice Header, Sales Cr.Memo Header and Service Invoice Header carry the fiscal state: Smart Invoice number, ZRA-assigned identifiers, device/branch reference, signature or verification payload, transmission timestamp and status. An event subscriber on the posting codeunits (OnAfterPostSalesDoc and equivalents) enqueues the document rather than blocking the user, so posting stays as fast as it is today. A dedicated transmission codeunit builds the ZRA payload from your master data — item classification and tax-type codes held on Item and Item Category, TPIN and branch codes on Company Information and Customer — signs and posts it to the Smart Invoice API or local device endpoint, and writes the response back onto the posted document.

Because the ZRA service will reject payloads, rejection is a first-class flow, not an error log. A Smart Invoice Log table records every attempt with request, response, HTTP status and error code, and a Fiscalization Worksheet page lets a finance user filter failed documents, read the ZRA message in plain language, correct the underlying master data, and re-submit — with an idempotency key so a retry can never produce a duplicate fiscal record. A job queue entry drains the pending queue on your chosen interval and escalates aged failures; credit memos carry the originating invoice's fiscal reference so ZRA sees a correction rather than an unrelated document. The same posting produces both outputs the regulation expects: the human-readable invoice report, extended with the fiscal block and verification QR, and the machine payload retained for the statutory archiving period in a locked, non-editable log.

Everything ships as versioned AL source with permission sets separating who may post, who may re-transmit, and who may only read the log. Setup lives on a dedicated Smart Invoice Setup page with per-environment endpoints, so sandbox and production never share credentials, and secrets are held in isolated storage rather than plain setup fields. API pages expose fiscal status over REST API v2.0 / OData v4 for Power BI reporting or a Power Automate alert, and Dataverse virtual tables are available where a wider Power Platform estate needs the same data. The extension targets your current Business Central release wave and runs on SaaS online tenants as a per-tenant extension or AppSource-track app, and on-premises where you host it yourself.

This is build-to-order, not a marketplace download. You request a quotation, we run a scoping call to confirm your document types, VAT and tax-type mapping, branch/device topology and ZRA registration status, and we quote a fixed scope. Typical delivery is 2-4 weeks from confirmed scope. We build against your Business Central version, deploy to your sandbox first for UAT against the ZRA test environment, then promote to production with a documented rollback. You receive the AL source and a git repository so the extension remains yours.

What you get

Installable AL extension (.app) plus complete source, built and tested against your exact Business Central version and release wave

Installation and configuration on your sandbox and production environments, including Smart Invoice Setup, endpoints, credentials in isolated storage, and job queue entries

Tax-type and item classification mapping workshop with the mapping loaded and validated against your live master data

Technical documentation: object ID ranges, table/page extensions, event subscribers, API page contracts, permission sets, and upgrade notes

End-user guide covering the Fiscalization Worksheet, rejection handling, credit-memo corrections and the fiscal invoice layout, plus a live training session for your finance team

UAT on a sandbox environment against the ZRA test endpoints, with a signed test script and a documented rollback plan before production promotion

Post-go-live support window covering defect fixes, ZRA endpoint or payload-schema changes encountered during the window, and configuration assistance

Private git repository handover with full commit history, branching notes and build instructions so the extension remains yours to maintain or extend

Who this is for

Finance Manager / Financial Controller, Zambia

Owns VAT filing accuracy and the ZRA relationship. Needs every posted invoice fiscalized once, visible failures surfaced daily rather than at month end, and a defensible audit trail linking each Business Central document to its Smart Invoice record.

Accounts Receivable / Billing Team Lead

Issues the invoices and answers when a customer says their copy is not valid. Needs the fiscal number and verification QR on the printed document straight from posting, and a self-service worksheet to fix and resubmit a rejection without raising an IT ticket.

IT Manager / Business Central Administrator

Accountable for the tenant, extension estate and monthly Microsoft update waves. Needs a per-tenant or AppSource-track extension with clean object ranges, permission sets, isolated-storage credentials and no unsupported base-app modifications.

Group Finance / Multi-Entity Operator

Runs Zambian entities alongside operations elsewhere. Needs Smart Invoice compliance enabled only for the Zambian companies and branches, with fiscal status readable over API pages for group-level Power BI reporting.

How Zambia Smart Invoice Compliance Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your Business Central setup	Built against your version, item mapping and branch topology from a scoping call	Fits exactly, but you specify it yourself from scratch	Generic configuration; your edge cases become change requests	No Smart Invoice concept exists in the base product
Fiscal data on the posted document	Table extensions store the ZRA number, identifiers and status on each posted header	Achievable, but the schema and upgrade path are your design decision	Usually present, sometimes held in a separate app-owned table	Nowhere to store it; teams resort to a spreadsheet or the ZRA portal
Rejection and correction handling	Worksheet page with plain-language errors, guided correction and idempotent resubmit	Often the last thing built, and the first thing that hurts at month end	Varies widely; some expose only a raw error log	Not applicable — no transmission to reject
Delivery timeline	2-4 weeks from confirmed scope, sandbox UAT before production	Depends on your AL capacity; usually longer once testing is counted	Install in a day, then weeks of configuration and gap discovery	Available now, but the compliance gap stays open
Source code and ownership	Full AL source plus a private git repository handed over to you	You own it entirely, and you own every future fix	Compiled app only; changes require a vendor request	Microsoft base app, no extension to own
Update-wave resilience	Extension model with event subscribers, no base-app modification	Depends on the discipline of whoever wrote it	Vendor-maintained, on the vendor's release schedule	Fully Microsoft-maintained
Reporting and Power Platform access	API pages over REST API v2.0 / OData v4, Dataverse virtual tables on request	Buildable, but usually skipped in the first release	Often limited to in-product pages and a fixed report	Standard Business Central APIs only, with no fiscal data to expose
Support model	Named post-go-live support window, then renewable or self-maintained	Internal team or contractor availability	Annual subscription tied to continued licensing	Microsoft support covers the base product, not local compliance

Frequently Asked Questions about Zambia Smart Invoice Compliance

How long does delivery take?

This is a build-to-order extension, not an existing AppSource download. Typical delivery is 2-4 weeks from confirmed scope — that clock starts once the scoping call has settled your document types, tax-type and item mapping, branch/device topology and ZRA registration details, and the quotation is accepted. Sandbox deployment and UAT sit inside that window; production promotion is scheduled with you.

Does this work on Business Central SaaS, or only on-premises?

Both. On a SaaS online tenant it installs as a per-tenant extension, or on the AppSource track if you prefer that governance model. On-premises it installs into your own service tier. It is built as a standard AL extension with table, page and report extensions plus event subscribers — no base-app modification — so it survives Microsoft's monthly and release-wave updates the supported way.

What happens when ZRA rejects an invoice or the endpoint is down?

Posting is never blocked. The document posts, the fiscalization attempt is queued, and every attempt is written to the Smart Invoice Log with the request, response and ZRA error code. Failures land on the Fiscalization Worksheet with plain-language error text; a user corrects the underlying master data and resubmits. Each posted document carries an idempotency key, so a retry or a concurrent job queue run cannot produce a duplicate fiscal record.

Do you connect to the ZRA Smart Invoice API or to a local device?

Whichever your ZRA registration uses — the setup supports API endpoints and local Smart Invoice device (VSDC-style) endpoints, and the endpoint is selectable per branch so a multi-site operation can mix them. We confirm which applies to you during scoping, and configure sandbox against the ZRA test environment before anything reaches production.

How is support and updates handled after go-live?

A post-go-live support window is included in every quotation: defect fixes, help with configuration, and adjustments for ZRA endpoint or payload-schema changes encountered during that window. After it ends you can renew support, or maintain the extension yourself — you hold the AL source and the git repository, so you are never locked to us. Business Central release-wave compatibility work is quoted separately when a new wave requires code changes.

Can we see fiscal status outside Business Central, in Power BI or a workflow?

Yes. API pages expose fiscal status and log summaries over REST API v2.0 / OData v4, which Power BI, Power Automate and custom integrations can consume directly. Where you run a wider Power Platform estate, we can expose the same data as Dataverse virtual tables. Scope that during the scoping call so the API contract is designed once rather than retrofitted.

What do we need to have ready before you start?

Your ZRA taxpayer registration and Smart Invoice enrolment details (TPIN, branch codes, device or API credentials), a sandbox Business Central environment we can deploy to, your current item and VAT posting setup for the mapping workshop, and a named finance owner for UAT sign-off. If any of these are still in progress we can build against the ZRA test environment and defer the production cutover.