Zambia's Smart Invoice spec now requires customer phone and email during reward campaigns

What changed in detail

The Zambia Revenue Authority published an updated Smart Invoice VSDC (Virtual Sales Data Controller) API Specification, now linked from the ZRA Smart Invoice page in place of the previous v1.0.7 specification of August 2024.

The document’s own revision table records two changes to the Sales Information service (endpoint /trnsSales/saveSales), both under the heading Reward Management:

1. Customer contact details — phone number and email address — must now be captured when a reward campaign is active on Smart Invoice, to enrol the customer in the programme.
2. The API response body now returns whether an active reward programme is running, whether the customer has entered the draw, and whether the customer has won a reward.

The request schema carries the corresponding field: custMblNo, “Phone number for the customer participating in a reward”, VARCHAR, optional, length 20.

The specification also records security enhancements, including remediation of vulnerabilities associated with the H2 database.

A dating caveat. The document carries no internal version number and no publication date. The 2 September 2026 date is taken from ZRA’s own publication path for the file (/wp-content/uploads/2026/09/…updated-02-09-2026.pdf) and from the fact that the Smart Invoice page now links this file where it previously linked the 2024 v1.0.7 document. That is why this change is recorded at medium rather than high confidence.

What it means

The substance is small; the way it arrives is the point. This is a compliance obligation delivered as a specification revision, with no notice, no gazette entry and no version number — a business learns that its integration is out of date only by noticing that the PDF behind an unchanged link is a different PDF.

That matters for change detection. A monitoring process watching ZRA’s news feed would not see this at all. The signal is the file path, which is why the publication route is the only dating evidence available and why the confidence is qualified.

On the substance itself, two things are worth separating. The custMblNo field is declared optional in the schema while the revision note says contact details “must now be captured” when a campaign is active. Those are consistent only if the requirement is conditional — mandatory during a campaign, absent otherwise — which means an integration cannot satisfy it by making the field permanently required or permanently optional. It has to react to campaign state, and campaign state is something the API reports back rather than something the integrator controls.

The second is that collecting a customer’s phone number and email address at the point of sale is a personal-data collection, introduced through an API specification rather than through a tax notice. Businesses implementing it are taking on a data-protection question that the specification does not address.