Every interaction with ZIMRA through the Tax and Revenue Management System (TaRMS) depends on a quiet pair of modules that beginners overlook and professionals never neglect: Notifications (how ZIMRA reaches you) and E‑Messaging (how you reach ZIMRA for routine matters). They are the nervous system of the Self-Service Portal (SSP). Get them right and every deadline-bearing event — an assessment, a refund approval, a certificate, an audit finding, a debt alert — reaches you in time to act. Get them wrong and you discover an assessment only after the 30-day objection window has closed and it has become, in the words of Section 62(5) of the Income Tax Act [Chapter 23:06], "final and conclusive."

The Notifications module (SSP guide module 18) has two pages: Taxpayer Notifications (messages addressed to the taxpayer, visible after you shift into a taxpayer) and User Notifications (messages addressed to the SSP user personally, visible in User mode before shifting). The guide is explicit about what flows through here: "assessment notices, refund approvals, certificate availability, audit findings, debt-management alerts, payment confirmations and system messages." In other words, almost every legally significant event ZIMRA initiates is delivered as a Notification — which makes this module the trigger for nearly every deadline in the portal. The guide's single most important operational instruction sits here: "Configure email forwarding so notifications also arrive in your inbox; do not rely on logging in to the SSP daily to catch them."

The E‑Messaging module (module 17) is "the closest the SSP gets to email-style correspondence with ZIMRA," also with two pages: Messages (compose and send, and view the list of e‑messages exchanged, in either User mode or Taxpayer mode) and Drafts (composed but not yet sent). Its proper use is routine queries — the guide lists "clarification on assessments, follow-up on instalment plans, requests to allocate a misallocated payment." And it carries the warning that ties this lesson to the previous one: "Formal objections still go through Case Management." E‑Messaging is the help-desk window, not a place to perform statutory acts.

The law that gives these screens their force lives in Part VIIIA of the Income Tax Act, Sections 80I to 80L — the electronic-communications provisions. Section 80I attributes an electronic communication to its originator and fixes the time of receipt as the moment it "enters the computer" system — the legal anchor that decides when a notice was delivered and therefore when a deadline begins. Section 80J carries a presumption that will discipline how you treat your login: data authenticated by your digital signature "shall be presumed, in the absence of proof to the contrary, that such signature was so used with the consent and authority of the registered user" — so a message sent, or a notice deemed received, under your credentials binds you. Section 80K provides the paper fallback when the system is down, and Section 80L criminalises using another person's digital signature (level 12 fine or up to 10 years). Alongside these sits the older Section 89, which governs service of documents — personal service, service at a place of business, or service by post deemed effected when the notice would arrive in the ordinary course of post.

Two further legal threads run through the lesson. First, a notice of assessment must actually be given (Section 51 of the Income Tax Act; Nestlé Zimbabwe v ZIMRA), and the notice itself must announce the 30-day objection window (Barclays Bank v ZIMRA 04‑HH‑162) — so the Notification is not a courtesy, it is the legal delivery of the document that starts the clock. Second, the 30-day objection deadline under Section 62 (income tax) / Section 32 (VAT) runs from the date of the notice, not from the date you happen to open it — which is exactly why the email-forwarding instruction is not housekeeping but risk management.

Finally, a security thread the guide insists on: "Treat ZIMRA emails with mild suspicion — phishing campaigns sometimes mimic ZIMRA. ZIMRA notifications come through Notifications, not unsolicited emails with attachments." The authoritative channel is the in-portal Notifications page; the forwarded email is a convenience copy, never the place to click attachments or enter credentials.

This lesson is the communications capstone of the TaRMS course. It explains the channels that deliver every notice produced in tarmsassessmentnotices and tarmsauditnotices, that start the clocks enforced in tarmscase, and that confirm the payments made in tarmsnewpayment. Screen specifics are grounded in the local SSP External Guide §17, §18 and §20 (confirmed verbatim this run, because the live online help was again unreachable); the law is grounded verbatim in the Acts.

Tax administration is, at bottom, an exchange of documents and deadlines. ZIMRA assesses, demands, approves and warns; the taxpayer files, pays, objects and queries. For any of this to be lawful and timely, two questions must always have clear answers: how does a document reach the other side, and when is it treated as having arrived? In a paper system the answers were envelopes, registry date-stamps and the post. In TaRMS the answers are Notifications and E‑Messaging, underpinned by the electronic-communications law in Sections 80I–80L.

It is tempting to treat these as mere plumbing — the boring modules between the exciting ones (returns, payments, certificates). That instinct is dangerous. The most expensive event in Zimbabwean tax practice is a missed deadline, and almost every deadline in TaRMS is triggered by a Notification. An assessment notice you never read still runs your 30-day objection clock (the clock runs from the date of the notice, not the date of reading — Trek Petroleum v ZIMRA 17‑SC‑056). A refund approval you never see leaves your money sitting as an unwithdrawn credit. A debt-management alert you ignore is the prelude to a garnishee that needs no further warning (Central African Road Services v ZIMRA 17‑HH‑110). The Notifications module is therefore not background — it is the single most consequential inbox a Zimbabwean taxpayer owns.

E‑Messaging plays the opposite, complementary role: it is the channel for the taxpayer's routine outbound communication — the questions and housekeeping that do not rise to the level of a statutory act. The guide is careful to bound it: routine queries yes; formal objections no. Understanding which channel for which purpose is half the lesson. The other half is understanding why the law treats a portal message as effective at all — which is where Sections 80I–80L come in.

Where these modules sit. The SSP guide groups the portal's back-office as "Audit, debt, case management and direct messaging with ZIMRA officers." Module 17 (E‑Messaging) and module 18 (Notifications) sit immediately after Case Management (16), and you move constantly among the three: a Notification announces a ZIMRA act → if it is a dispute, you respond in Case Management → if it is a routine query, you use E‑Messaging → the outcome returns through Notifications. Hold that loop in mind throughout.

Why this is examinable. Candidates and practitioners are tested on the legal effect of electronic communications (when is a notice "received"? whose act is a portal submission deemed to be?), on the service-of-documents rules (Section 89), and on the deadline consequences of delivery (the 30-day clock from the notice date). These are not portal trivia; they are the rules that decide whether an assessment can still be challenged and whether a taxpayer is bound by something done under their login.

The screens are administrative; their authority is statutory. We walk the governing provisions.

B.1 Attribution and timing of electronic communications — Section 80I

Section 80I ("Sending and receipt of electronic communications") is the legal engine of the whole portal. Subsection (1) attributes a communication to its originator:

"An electronic communication through a computer system established in terms of section eightyD or the record of such communication shall be attributed to the originator— (a) if it was sent by the originator; or (b) if it was sent by a person who had the authority to act on behalf of the originator …; or (c) if it was sent by a computer system programmed by or on behalf of the originator to operate automatically."

So a message or submission made through the SSP is, in law, the registered user's communication — including where it was sent by someone authorised to act for them (the link to Roles & Permissions in tarmsroles). Subsections (2)–(3) deal with acknowledgements of receipt. Subsection (4) fixes lodgement: "the lodgement of an electronic communication occurs when it enters a computer system outside the control of the originator." Subsection (5) fixes time of receipt:

"The time of receipt of an electronic communication shall be the time when the electronic communication enters the computer— (a) where [from] a registered user, at any office of the Zimbabwe Revenue Authority … and such office shall be the place of receipt; or (b) if … sent by the Zimbabwe Revenue Authority or the Commissioner to a registered user, at the place of receipt that is stipulated in the user agreement."

This is the provision that answers "when was the notice delivered?" — and therefore "when did my 30-day objection clock start?" Subsection (6) gives an electronic signature the same effect as a manuscript one ("shall … have effect as if it was affixed thereto in manuscript"), and subsection (7) lets the Commissioner permit submission over the Internet. The portal's notices and your messages are, by Section 80I, legally effective communications with defined moments of dispatch and receipt.

B.2 The credential presumption — Section 80J

Section 80J ("Obligations, indemnities and presumptions with respect to digital signatures") is the provision that should govern how seriously you guard your login. Subsection (1) imposes a duty: if your digital signature's security "has been compromised in any manner," you must inform the Commissioner in writing without delay. Subsection (2) shields ZIMRA from any failure on your part to secure your signature, and entitles ZIMRA to assume that data authenticated by your signature — received before you reported a compromise — was sent by you or with your authority. Subsection (3) makes the presumption evidential:

"Where … the question arises whether a digital signature affixed to any electronic communication … was used … with or without the consent and authority of the registered user, it shall be presumed, in the absence of proof to the contrary, that such signature was so used with the consent and authority of the registered user."

The consequence for messaging is direct: an E‑Message sent under your credentials, and a notice deemed received in your account, bind you. You cannot disown a portal communication by saying "an employee sent it" or "I never logged in" — the presumption runs against you unless you prove the contrary, and you were obliged to report any compromise the moment you knew of it. This is the legal spine of the guide's security housekeeping (§20).

B.3 The system-down fallback and the offence — Sections 80K and 80L

Section 80K ("Alternatives to electronic communication in certain cases") provides that when the SSP "is inoperative," the user and the Commissioner "shall communicate with each other in writing in the manner prescribed in this Act" — i.e. the portal's downtime does not suspend obligations; correspondence reverts to the prescribed paper/written channel, and the Commissioner may still require original documents. Section 80L ("Unlawful uses of computer systems") makes it an offence for a person who is not the registered user to use that user's digital signature without authority — punishable by a fine up to level 12 or imprisonment up to 10 years — and criminalises falsifying electronic records. Sharing logins is therefore not merely poor practice; it puts both parties on the wrong side of Section 80L.

B.4 Service of documents — Section 89

For documents that are served rather than transmitted through the portal, Section 89 ("Forms and authentication and service of documents") still governs. Subsection (2) lets any authorised officer sign notices on the Commissioner's behalf; subsection (3) authenticates a document by the name of the issuing officer written on it. Subsection (4) sets out valid service:

"Any notice required or authorized under this Act to be served upon any person shall be sufficiently and effectually served— (a) if personally served upon him; or (b) if left with some adult person apparently resident at … his usual or last known abode, office or place of business …; or (c) if sent by post addressed to such usual or last known place of abode, office or place of business, or to any post office box rented in the name of such person …"

For a company, service on the public officer or at the company's address for service suffices. Subsection (5) adds the deemed-service-by-post rule: "unless the contrary is proved, the service shall be deemed to have been effected at the time at which the notice would be delivered in the ordinary course of post." Section 89 and Section 80I together cover both worlds — the posted notice and the portal notification — and both fix a moment of delivery that starts deadlines running.

B.5 The notice must be given, and must announce the clock — Sections 51 and 62/32

The Notifications module exists to deliver, above all, the notice of assessment. Section 51 of the Income Tax Act requires the Commissioner to give the taxpayer notice of the assessment (confirmed verbatim in tarmsassessmentnotices); the notice must be given (Nestlé Zimbabwe (Pvt) Ltd v ZIMRA 20‑SC‑290 / 23‑HH‑312), and the notice itself must state that any objection must be lodged within 30 days (Barclays Bank v ZIMRA 04‑HH‑162). Section 52 entitles the taxpayer to certified copies and keeps assessments out of public inspection. The 30-day objection clock under Section 62(1) (income tax) and Section 32(3) (VAT) then runs from the date of that notice — delivered to you through Notifications. This is the precise legal reason the email-forwarding instruction matters: the law starts the clock on delivery, and Notifications is the delivery.

C.1 Notifications (module 18)

Purpose. "Receive TaRMS notifications." This is ZIMRA's outbound channel to you — the authoritative in-portal inbox.

Page 1 — Taxpayer Notifications. Notifications "addressed to the taxpayer," visible after shifting to a taxpayer. Because TaRMS separates the human user from the taxpayer entity they act for (the User-mode/Taxpayer-mode distinction from tarmslogin, tarmsuserprofile and tarmsroles), notices about a taxpayer's tax affairs — assessments, refunds, audit findings, debt alerts — appear here once you have shifted into that taxpayer. An agent or public officer handling several taxpayers must shift into each to see that taxpayer's notifications.

Page 2 — User Notifications. Notifications "addressed to the SSP user personally," visible in User mode, before shifting to a taxpayer. These concern you as a registered user — access, profile, and account-level system messages — independent of any one taxpayer.

What arrives here. The guide's list is the syllabus of consequence: assessment notices (start the 30-day clock — tarmsassessmentnotices), refund approvals (your cue to withdraw — tarmsrefund/tarmswithdrawal), certificate availability (your ITF 263 is ready — tarmsautoclearance), audit findings (a case is moving — tarmsaudit), debt-management alerts (the demand ladder is engaging — debt-course territory), payment confirmations (your remittance posted — tarmsnewpayment), and system messages. Each is a trigger: read it, classify it, and act before its deadline.

The load-bearing instruction. "Configure email forwarding so notifications also arrive in your inbox; do not rely on logging in to the SSP daily to catch them." Email forwarding turns the passive portal inbox into an active alert. But note the legal nuance: the forwarded email is a convenience copy; the authoritative record is the in-portal Notification, and the law's time-of-receipt (Section 80I) attaches to the portal communication per the user agreement, not to your personal email's delivery time.

C.2 E‑Messaging (module 17)

Purpose. "Direct messaging between the SSP user / taxpayer and TaRMS" — "the closest the SSP gets to email-style correspondence with ZIMRA." This is the taxpayer's routine outbound channel.

Page 1 — Messages. A "list of e‑messages exchanged between the user / taxpayer and TaRMS, with the ability to compose and send messages in either User mode or Taxpayer mode." The mode you are in frames the message: a User-mode message is about you as a user; a Taxpayer-mode message is sent on behalf of the taxpayer you have shifted into — and, by Section 80I(1)(b) and the Section 80J presumption, it is attributed to and binds that taxpayer.

Page 2 — Drafts. "Composed but not yet sent messages." As with everything in TaRMS, Drafts is not Sent — a drafted message has communicated nothing.

Proper use — and its hard boundary. The guide prescribes E‑Messaging for routine queries: "clarification on assessments, follow-up on instalment plans, requests to allocate a misallocated payment." These are housekeeping conversations, not statutory acts. The boundary is stated in the same breath: "Formal objections still go through Case Management." An objection is a Section 62/Section 32 act with a deadline and detailed-grounds and burden-of-proof requirements (see tarmscase); sending your grievance as an E‑Message does not lodge an objection, does not stop the 30-day clock, and will let the assessment go final (Trek 17‑SC‑056). Likewise, a refund is applied for in Refund Management, a return is filed in Tax Return Management, a payment is made in Payments — E‑Messaging is the channel to ask about these, never to perform them.

C.3 How the channels interlock — the communication loop

Put the modules together and a clean loop emerges, which every monthly cycle (tarmsroutine) repeats:

1. ZIMRA acts (assesses, approves, audits, alerts) → the act is delivered as a Notification (Taxpayer Notifications).
2. You read and classify the Notification. Is it a dispute (assessment you contest)? → Case Management. A routine query (allocation, plan, clarification)? → E‑Messaging. A prompt to transact (refund approved, certificate ready)? → the relevant transactional module.
3. You respond in the correct channel — statutory acts in their modules, routine talk in E‑Messaging.
4. ZIMRA's outcome (objection decision, refund payment, certificate) returns through Notifications, closing the loop.

The discipline: Notifications is where you watch; E‑Messaging is where you chat; Case Management and the transactional modules are where you act. Confusing "chat" with "act" is the cardinal error this lesson exists to prevent.

C.4 Security and authenticity — the phishing perimeter

Because Notifications carries money-moving and deadline-bearing news, it is a phishing target. The guide's §20 housekeeping is law-adjacent risk management: each user has their own login (do not share — Section 80L makes shared use an offence); use a strong password, rotated at least annually (tarmspassword); review Assignee Management quarterly and remove ex-staff promptly (tarmsroles); always log out on shared devices; and crucially — "Treat ZIMRA emails with mild suspicion … ZIMRA notifications come through Notifications, not unsolicited emails with attachments." The operational rule that follows: verify anything alarming by logging into the SSP and reading the in-portal Notification directly; never act on a forwarded email's links or attachments. The Section 80J presumption is the reason this matters so much — if a credential leaks and is misused, the law presumes the acts were yours until you prove otherwise and you reported the compromise.

D.1 Individuals (employees and sole traders)

Scenario — Chipo, a sole trader, and the unread assessment. ZIMRA raises an estimated assessment and delivers it to Taxpayer Notifications on 4 March 2026. Chipo, who logs into the SSP only when filing, does not see it until 10 April. By then the 30-day objection window (Section 62, running from the 4 March notice date — Trek) has closed; the assessment is final and conclusive (Section 62(5)). Had Chipo followed the guide's instruction and configured email forwarding, the notice would have reached her inbox on 4 March, she would have diarised 3 April, and she could have objected in time (the displacement-bundle play from tarmscase). The lesson costs nothing to learn and everything to ignore: the clock runs on delivery, not on reading.

Scenario — using E‑Messaging correctly. Chipo notices a PAYE payment was posted to the wrong tax type. This is a routine allocation query, exactly what the guide assigns to E‑Messaging: she sends a Taxpayer-mode message asking ZIMRA to reallocate the misposted payment, attaching the payment reference. She does not try to "object" to anything — there is nothing to object to; it is a housekeeping fix. The message, sent under her credentials, is attributed to her (Section 80I(1)) and forms part of the record.

D.2 SMEs and partnerships

Scenario — Mbare Hardware (Pvt) Ltd and the instalment follow-up. Mbare Hardware has an approved instalment plan on a VAT liability. Its accountant uses E‑Messaging to follow up on the plan — confirming the next instalment date and asking ZIMRA to confirm receipt of the last payment. This is precisely the guide's second listed use ("follow-up on instalment plans"). When a debt-management alert later appears in Notifications warning that an instalment is overdue, the accountant treats the Notification as the authoritative trigger — logs in, reads it in-portal, and acts — rather than waiting for, or trusting, any email. The two modules work in tandem: Notifications warns; E‑Messaging clarifies.

Scenario — the multi-taxpayer agent's blind spot. Mbare's external accountant acts for several SME clients. Each client's notices appear only in that client's Taxpayer Notifications, reachable by shifting into each taxpayer. The accountant's discipline must be to shift into and check every client, because a notice for Client A is invisible while shifted into Client B. Email forwarding per taxpayer (where configurable) is the safety net. whether forwarding is configured per user, per taxpayer, or both.

D.3 Large corporates and multinationals

Scenario — a corporate's notification governance. A large taxpayer with dozens of SSP users and a public officer cannot leave Notifications to chance. It builds governance: email forwarding to a monitored shared mailbox, a rota that checks Taxpayer Notifications daily, and an internal SLA that any assessment notice or audit finding is escalated to tax counsel within 24 hours (because the 30-day objection clock and the audit-response timelines are unforgiving). It enforces Section 80J/80L hygiene: one login per user, no sharing, immediate de-provisioning of leavers via Assignee Management, and an incident process to report any suspected credential compromise to the Commissioner without delay (Section 80J(1)) — both to comply and to rebut the presumption that misused-credential acts were authorised. For a multinational, the same Notifications stream also carries refund approvals worth large sums; a missed approval is idle cash, so withdrawal is triggered off the Notification (link to tarmswithdrawal).

A note on attribution risk. Because Section 80I attributes portal communications to the originator and Section 80J presumes authority, a large taxpayer's exposure is not only missing a notice but being bound by a message an over-permissioned or departed user sent. Governance of who can send in Taxpayer mode (roles — tarmsroles, Section 80J presumption) is therefore part of communications control, not a separate concern.

The messaging and notification modules are delivery mechanisms, and — honestly — there is no reported Zimbabwean case on the SSP Notifications or E‑Messaging screens themselves. The relevant jurisprudence is about delivery, timing and finality, which these modules implement:

• Trek Petroleum (Pvt) Ltd v ZIMRA 17‑SC‑056 — the objection clock and finality: an assessment unobjected within the window is final and conclusive. Because the clock runs from the notice date, the case is the strongest argument for monitoring Notifications and forwarding them to email. Facts/issue: late challenge to an assessment; principle: finality under Section 62(5); today: read your Notifications or lose your rights.
• Nestlé Zimbabwe (Pvt) Ltd v ZIMRA 20‑SC‑290 / 23‑HH‑312 — a notice of assessment must be given; delivery is a legal requirement, not a formality. Notifications is the channel that gives it.
• Barclays Bank of Zimbabwe v ZIMRA 04‑HH‑162 — the notice itself must announce the 30-day objection window. The content delivered through Notifications is held to this standard.
• Central African Road Services (Pvt) Ltd v ZIMRA 17‑HH‑110 — ZIMRA need give no separate notice before garnishee enforcement; a debt-management alert in Notifications may be all the warning a taxpayer gets before collection. The case underscores that ignoring Notifications has direct enforcement consequences.
• Mayor Logistics (Pvt) Ltd v ZIMRA 14‑CC‑007 — pay-now-argue-later; relevant because the outcomes and demands that drive payment obligations are delivered through this channel.

Where this lesson states screen behaviour (page names, modes, email forwarding), that is administrative guidance (SSP External Guide), not case law — and the electronic-communications and service rules (Sections 80I–80L, 89) are statute, not case law. The honest position: the courts police the consequences of delivery and timing; the portal merely performs the delivery.

1. Relying on logging in to "catch" notices. The guide warns against it directly. A notice read late is still delivered on time in law (Section 80I; Trek). Correct approach: configure email forwarding and check Notifications on a fixed rota.
2. Treating a forwarded email as the authoritative document — or trusting a fake one. The forwarded email is a convenience copy; phishing mimics ZIMRA. Correct approach: verify anything significant by reading the in-portal Notification; never click attachments/links in unsolicited "ZIMRA" emails (guide §20).
3. Using E‑Messaging to object. "Formal objections still go through Case Management." An E‑Message stops no clock and is not a Section 62/Section 32 act. Correct approach: objections in Case Management → New Objection (see tarmscase); E‑Messaging only for routine queries.
4. Confusing "chat" with "act." Refunds, returns and payments are performed in their own modules; E‑Messaging only asks about them. Correct approach: match the task to the transactional module; use E‑Messaging to clarify, not to transact.
5. Forgetting the User-mode / Taxpayer-mode split. Taxpayer Notifications are visible only after shifting into the taxpayer; an agent checking in the wrong mode sees nothing. Correct approach: shift into each taxpayer and check both notification pages.
6. Leaving a message in Drafts. Composed ≠ sent. Correct approach: confirm the message moved from Drafts to the sent list.
7. Sharing logins. Section 80L makes unauthorised use of another's signature an offence; Section 80J presumes acts under your credentials are yours. Correct approach: one login per user; remove leavers via Assignee Management promptly; report any compromise to ZIMRA without delay (Section 80J(1)).
8. Assuming downtime pauses obligations. Section 80K reverts communication to writing when the system is inoperative; deadlines do not stop. Correct approach: if the SSP is down near a deadline, communicate in the prescribed written manner and keep proof.
9. Ignoring debt-management or audit-finding alerts. These are the quiet preludes to enforcement (CARS — no further notice needed) and to closing the VDA01 door (tarmsaudit). Correct approach: triage every alert the day it lands.
10. Pacing the monthly cycle to the guide's outdated dates. The guide's §19.1 still lists VAT 7 by the 25th; the law (Section 28(1), shortened 25th→15th by the Finance (No.2) Act 7 of 2024 w.e.f. 1 January 2025) makes it the 15th — and the legislation prevails (the load-bearing conflict from tarmspitfalls/tarmsroutine). Correct approach: diary VAT to the 15th, PAYE to the 10th, regardless of the guide's stale text.

Work through the questions one at a time. Choose an answer and it is graded immediately, with an explanation and the provision it comes from. Your progress is saved, so you can stop and resume.

• Notifications is ZIMRA's authoritative inbox to you (module 18): two pages — Taxpayer Notifications (after shifting to a taxpayer) and User Notifications (User mode) — carrying assessment notices, refund approvals, certificate availability, audit findings, debt-management alerts, payment confirmations and system messages.
• Configure email forwarding and check Notifications on a rota — "do not rely on logging in daily." The objection clock runs from the notice date (Section 62; Trek), delivered here, so delivery — not reading — starts the deadline.
• E‑Messaging is the routine-query channel (module 17): two pages — Messages (User/Taxpayer mode) and Drafts (unsent). Use it for clarification, instalment follow-ups, allocation fixes. Formal objections go through Case Management — never E‑Messaging.
• Watch / chat / act. Notifications is where you watch; E‑Messaging is where you chat; Case Management and the transactional modules are where you act. Never perform a statutory act by message.
• Electronic communications have legal force under Sections 80I–80L: Section 80I attributes them and fixes time of receipt; Section 80J presumes acts under your login are authorised (report compromise without delay); Section 80K reverts to writing in downtime (deadlines continue); Section 80L criminalises using another's signature.
• Service of documents (Section 89): personal, left-with-adult, or post — with deemed service in the ordinary course of post; the law always fixes a moment of delivery.
• Security is law-adjacent: one login per user (Section 80L), strong rotated passwords, prompt removal of leavers (Assignee Management), and mild suspicion of "ZIMRA" emails — verify in-portal, because real notifications come through Notifications, not unsolicited attachments.
• Honest scope: no case law touches the SSP messaging screens themselves; the jurisprudence (Trek, Nestlé, Barclays, CARS) governs the delivery, timing and finality these modules implement. This lesson completes the TaRMS communications loop, delivering the notices of tarmsassessmentnotices/tarmsauditnotices, starting the clocks of tarmscase, and confirming the payments of tarmsnewpayment.

Table 1 — The two modules compared

Table 2 — Which channel for which purpose

Diagram 1 — The communication loop

flowchart TD
 Z[ZIMRA acts: assess / approve / audit / alert] --> N[Notifications - Taxpayer Notifications]
 N --> C{Classify the notification}
 C -->|Dispute an assessment| CM[Case Management - lodge objection Section 62/32]
 C -->|Routine query| EM[E-Messaging - clarify / follow up]
 C -->|Prompt to transact| TX[Refund / Payment / Certificate module]
 CM --> OUT[Outcome delivered]
 EM --> OUT
 TX --> OUT
 OUT --> N

Diagram 2 — Is a portal communication legally effective and attributed to me?

flowchart TD
 A[Communication through the SSP] --> B{Sent by user, an authorised person, or auto-system? Section 80I 1}
 B -->|Yes| C[Attributed to the registered user]
 B -->|No| D[Not attributed]
 C --> E{Authenticated by the user's digital signature?}
 E -->|Yes| F[Presumed authorised Section 80J 3 - binds the user]
 E -->|No / compromise reported without delay Section 80J 1| G[Presumption may be rebutted]
 F --> H[Time of receipt fixed by Section 80I 5 - deadline runs]
 G --> H

Statutes & sections

• Income Tax Act [Chapter 23:06] —
• Section 80I "Sending and receipt of electronic communications": attribution to the originator (incl. authorised persons and automatic systems); lodgement when it leaves the originator's control; time of receipt when it enters the system; electronic signature has manuscript effect.
• Section 80J "Obligations, indemnities and presumptions with respect to digital signatures": duty to report compromise without delay; ZIMRA may assume authority; presumption that signature used with the user's consent and authority.
• Section 80K alternatives when the system is inoperative — communicate in writing; obligations continue; Commissioner may require originals.
• Section 80L unlawful use of another's digital signature / falsifying records — offence (up to level 12 / 10 years).
• Section 89 "Forms and authentication and service of documents": officer signature/authentication; service by personal/left-with-adult/post; deemed service in the ordinary course of post (Section 89(5)).
• Section 51 / Section 52 notice of assessment must be given and must announce the 30-day window; certified copies; not public.
• Section 62 objection within 30 days of the notice; finality if missed (Section 62(5)).
• Value Added Tax Act [Chapter 23:12] — Section 32 objection within 30 days of the notice (the VAT mirror delivered through Notifications); Section 28(1) VAT 7 deadline now the 15th (shortened from the 25th by the Finance (No.2) Act 7/2024 w.e.f. 1 Jan 2025) — the guide's §19.1 "25th" is outdated.

Case law

• Trek Petroleum (Pvt) Ltd v ZIMRA 17‑SC‑056 — objection clock/finality; the case for monitoring Notifications.
• Nestlé Zimbabwe (Pvt) Ltd v ZIMRA 20‑SC‑290 / 23‑HH‑312 — a notice of assessment must be given.
• Barclays Bank of Zimbabwe v ZIMRA 04‑HH‑162 — the notice must announce the 30-day objection window.
• Central African Road Services (Pvt) Ltd v ZIMRA 17‑HH‑110 — no separate notice required before garnishee; debt alerts are the warning.
• Mayor Logistics (Pvt) Ltd v ZIMRA 14‑CC‑007 — pay-now-argue-later (context for demand/outcome delivery).

Honest note: no reported case concerns the SSP Notifications or E‑Messaging screens themselves; the authorities govern the delivery, timing and finality these modules implement.

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (SSP External Guide) — §17 E‑Messaging (Messages/Drafts; routine queries; "formal objections still go through Case Management"), §18 Notifications (Taxpayer/User Notifications; contents list; configure email forwarding), §19.5 Objection workflow, §20 Security Housekeeping (logins, password rotation, Assignee Management, phishing caution). Confirmed verbatim this run.
• ZIMRA SSP online help (https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm) — unreachable this run (empty JS shell); live field labels flagged `.