This lesson covers the complete credential life-cycle of a ZIMRA Self-Service Portal (SSP) user account: how the password is first created, how it is routinely changed, how it is recovered when forgotten, and what happens when repeated failed attempts lock the account. The SSP at https://mytaxselfservice.zimra.co.zw is the public front-end of the Tax and Revenue Management System (TaRMS), and the password is the single key to everything a user can do in it — filing returns, making payments, requesting tax clearance, and corresponding with ZIMRA. The relevant portal pages all live in the Getting Started module: SSP Registration, Login to the Portal, Password Reset, SSP User Profile, Changing the Password, and User Inactivity and Logout.

Three operations that beginners habitually conflate are kept rigorously distinct throughout this lesson. Password creation happens once, at sign-up: after ZIMRA verifies the registration data, it emails a password-creation link to the registered address, and the user sets the first password by following it. Password change is the routine, authenticated operation — the user is logged in, navigates to Getting Started → Changing the Password, and enters the current password plus the new password twice. Password reset is the unauthenticated recovery operation — the user clicks Forgot Password on the login page, supplies a username or registered email, and receives an emailed reset link. A fourth state, the account lock, is triggered by repeated incorrect login attempts and is cured by waiting the prescribed period or contacting ZIMRA support — not by hammering the reset button.

No section of the Income Tax Act [Chapter 23:06] says the word "password". The legal weight of credential management is indirect but real: Section 5 (preservation of secrecy, with offences in Section 5(5)/(5a)) is the statutory reason every person has their own login; Sections 53–61 (representative taxpayers and the public officer) and Section 37A(10)–(11) (the self-assessment return is the assessment) mean that what is done under a login is attributed — to the user, and through the user to the taxpayer. And because every filing and payment deadline (P2 by the 10th, VAT 7 by the 25th, QPDs under Section 72, the four-month ITF 12C under Section 37A) is enforced regardless of whether the taxpayer could log in, a recovery delay is never an excuse — which is why this lesson treats password hygiene as a compliance control, not an IT nicety.

The recovery machinery has one critical dependency: the email address and phone number on the SSP user profile. The reset link goes to the registered email; browser verification codes go to the registered phone or email. A stale email address converts a thirty-second self-service reset into a support ticket with ZIMRA — potentially straddling a filing deadline. Keeping the profile current (Getting Started → SSP User Profile) is therefore the first rule of recovery, and the lesson closes with a deadline-day failure drill: every taxpayer should have at least two SSP users with submission rights, so that one locked account never strands a return.

Because the SSP's own online help was not reachable when this lesson was prepared, screen-level specifics (lock thresholds, link validity windows, password-complexity rules) are stated generally and flagged for verification against the live portal.

Every interaction a Zimbabwean taxpayer has with ZIMRA — short of a physical visit to a regional office — now runs through the Self-Service Portal (SSP), the public-facing front-end of TaRMS. As established in the lesson on Introduction to TaRMS & the Self-Service Portal (tarmsintroduction), the SSP organises its functions into sixteen modules, and as established in SSP Registration (tarmssspregistration), access begins with a user account: one human being, one login, registered once and used for ever after. The password attached to that account is the only thing standing between the outside world and the taxpayer's returns, balances, bank details, refund applications and correspondence with the Commissioner-General's officers.

This lesson is the dedicated treatment of that password's life-cycle. The login lesson (tarmslogin) introduced the three credential events in outline — reset versus change versus lock — and this lesson now walks each one procedurally, screen by screen, and then asks the harder governance questions: who in an organisation should hold SSP credentials, what happens when the one person who knows the password resigns or is on leave on deadline day, and why ZIMRA's legal machinery makes "we were locked out of the portal" a costly rather than a sympathetic explanation.

Two framing points before the detail.

First, the password protects a user, not a taxpayer. Recall the SSP's foundational distinction: an SSP user is a natural person with a login; a taxpayer is the legal person (individual, company, trust, partnership) whose affairs are managed. One user can represent many taxpayers — a tax agent with a portfolio of clients, an in-house accountant handling the employing company and its subsidiaries — by "shifting" into each taxpayer after login. A compromised or lost password therefore exposes every taxpayer that user can shift into, which is exactly why multi-taxpayer practitioners must hold their credentials to a higher standard than a sole trader managing only their own TIN.

Second, password failure is a compliance event, not just an inconvenience. The compliance calendar does not pause for a locked account: PAYE remittances and the P2 are due by the 10th of the following month, the VAT 7 by the 25th following the tax period, quarterly payment dates fall on 25 March, 25 June, 25 September and 20 December under Section 72 of the Income Tax Act [Chapter 23:06], and the self-assessment ITF 12C is due four months after year-end under Section 37A. A password recovery that takes three days at the wrong end of the month can convert directly into late-filing penalties, interest, a blemished compliance record, and — through the ITF 263 machinery covered in tarmscertificates — a revoked or unrenewable tax clearance certificate and the 30% withholding under Section 80. That chain is what makes this topic examinable and practically important far beyond its apparent simplicity.

There is no "Password Act". No provision of the Income Tax Act [Chapter 23:06], the VAT Act [Chapter 23:12] or the Finance Act [Chapter 23:04] prescribes how an SSP password must be composed, rotated or recovered — those are administrative design choices inside TaRMS. The legal significance of credential management is instead derivative: it flows from provisions that assume, and depend on, each login belonging to exactly one identifiable person.

The secrecy provision — Section 5

Section 5 of the Income Tax Act [Chapter 23:06] is the preservation-of-secrecy provision. As covered in depth in the lesson on Administration of Income Tax (itcadministration), it binds persons handling taxpayer information to confidentiality, with criminal offences in Section 5(5) and Section 5(5a) for unauthorised disclosure, and narrow statutory gateways (the Minister under Section 5(3), the Financial Intelligence Unit under Section 5(3a)). The SSP's one-person-one-login rule is the system-level expression of this scheme: taxpayer information displayed inside an SSP session is confidential information, and the portal can only police who saw it if each set of credentials maps to one human being. A shared password collapses that mapping. The correct mechanism for giving a second person access has never been "tell them the password" — it is a formal grant through the Assignee Management module, which creates an auditable, revocable permission in that person's own name (covered fully in the forthcoming lessons on Roles & Permissions and Assigning an Agent).

Attribution — Sections 53–61 and Section 37A(10)–(11)

The Act's machinery for companies and other entities works through identified natural persons: the representative taxpayer provisions in Sections 53–56 and the public officer requirement in Section 61 fix responsibility for an entity's tax affairs on named individuals. In the TaRMS era those individuals act through SSP logins. Meanwhile Section 37A(10)–(11) provides that a self-assessment return, once submitted, constitutes the assessment — the act of clicking "submit" inside an SSP session creates a legally operative assessment. Authorship therefore matters: ZIMRA's working assumption is that whatever was done under a login was done by the registered holder of that login. "Someone else used my password" is an admission of a control failure, not a defence with any promising track record.

Deadlines that do not wait — Sections 37, 37A, 72; FA Section 4B

The filing and payment provisions — annual returns under Section 37, self-assessment within four months of year-end under Section 37A, quarterly payment dates under Section 72, and the Finance Act's Section 4B remittance discipline for withheld amounts — all run on fixed statutory dates. None of them contains a proviso for portal lock-outs or forgotten passwords. The risk-management consequence is drawn out in section D below.

The registration clock — Sections 25B–25D

As established in tarmssspregistration, a registrable taxpayer must register within 30 days under Section 25B, on pain of the Section 25C civil penalty (US$30 plus US$30 per day, capped at 90 days, with a closure notice as the end-game — inserted by the Finance Act (No. 2) 7/2024 with effect from 1 January 2025), and Section 25D makes liability independent of registration. A stalled password-creation link (wrong email at sign-up, link expired unused) stalls the user account, which stalls the taxpayer registration behind it, while the 30-day clock keeps running.

Data protection law — noted generally

Zimbabwe also has cyber and data protection legislation imposing duties around the security of personal information and criminalising unauthorised access to computer systems; an organisation's handling of SSP credentials sits within that broader framework as well.

What the law does not prescribe

Password length, complexity, expiry, the lock-out threshold and the inactivity timeout are all TaRMS configuration, not statute. They can change without any amendment Act. That is why this lesson states them in the portal's own general terms and flags the unconfirmed numbers, rather than asserting specifics that could silently go stale.

The credential life-cycle has four distinct events. Learn them as four because the portal treats them as four — different pages, different preconditions, different failure modes.

C.1 Password creation — the one-time event

The first password is set as the final step of SSP user registration, covered procedurally in tarmssspregistration. The sequence, restated for completeness:

1. The applicant completes the Sign Up form at https://mytaxselfservice.zimra.co.zw (resident path with National Registration ID, or non-resident path with passport number), supplying among the mandatory fields a unique username, a phone number and an email address.
2. ZIMRA verifies the submitted data against its records.
3. On successful verification, ZIMRA emails a password-creation link to the registered email address.
4. The applicant follows the link, sets the first password, and can then log in.

Two practical notes carry forward into everything that follows. First, the email address captured at sign-up is the recovery anchor for the life of the account — creation links, reset links and (where email is the chosen channel) browser-verification codes all go there. An error in that field at sign-up is the single most expensive typo in the SSP, and it is not self-service curable: a wrong registered email means contacting ZIMRA support. Second, the creation link is a one-time artefact; if it expires before use, the practical cure is the Forgot Password route once the account exists, or ZIMRA support if it does not.

C.2 Routine password change — the authenticated path

A logged-in user changes their password under Getting Started → Changing the Password. The screen asks for:

1. the current password, and
2. the new password, entered twice to guard against typos.

That the current password is demanded is not bureaucratic friction — it is the proof that the person at the keyboard is the account holder and not someone who found an unattended, logged-in session. (Recall from tarmslogin that the SSP's inactivity auto-logout is the backstop for exactly that scenario; the deliberate Log Out click remains the habit to build, particularly on shared devices.)

When to change, as a matter of discipline rather than statute:

• Periodically — the ZIMRA SSP guidance is to use a strong password and rotate it at least annually.
• Immediately on suspicion — a phishing email interacted with, a device lost or stolen, a session left open on a shared machine, or any indication another person may know the password.
• On role changes around the account — for instance, where (improperly) a password had ever been disclosed to a colleague, the cure is an immediate change plus a proper Assignee Management grant for the colleague.

A strong password in this context means the familiar canon: meaningful length, no dictionary words or personal details (note that the SSP registration data — name, date of birth, national ID — is exactly the data an attacker may hold), no reuse of a password used on any other site, and ideally a password manager rather than memory or a sticky note.

C.3 Password reset — the unauthenticated recovery path

When the password is forgotten, the user is by definition outside the portal, so recovery runs unauthenticated from the login page:

1. Go to https://mytaxselfservice.zimra.co.zw and click Forgot Password.
2. Enter the username or registered email address.
3. The SSP emails a password-reset link to the registered email address.
4. Follow the link, set a new password, and log in with it.

Anatomy of the design: the reset proves identity by control of the registered mailbox. That is the whole security model, and it cuts both ways. It is why the reset is fast and self-service when the profile is current — and why it fails completely when the registered email is a departed employee's corporate address, an abandoned webmail account, or a mailbox whose own password is also forgotten. It is also why reset emails are a favourite phishing costume: the standing rule from tarmslogin applies with full force — be suspicious of unsolicited password-reset emails. A genuine reset link arrives because you clicked Forgot Password moments earlier. An unrequested one is presumptively an attack; do not click it, and change your password through the authenticated path if you have any doubt.

Three procedural wrinkles:

• Check spam/quarantine first. As with the original creation link, corporate mail filters are the most common reason a reset email "never arrived".
• The reset link is time-limited. Use it promptly; if it expires, simply run Forgot Password again.
• A reset does not fix a username problem. If the user cannot remember the username, the registered email also works as the login identifier; reset cures lost passwords only.

C.4 Account lock — the involuntary state

Repeated incorrect login attempts cause the SSP to temporarily lock the account. The cure is to wait the prescribed lock period or contact ZIMRA support — repeated further attempts achieve nothing except, potentially, extending the problem. The tactical rule taught in tarmslogin bears repeating as doctrine: stop after two failed attempts. At that point, pause and think — is the keyboard layout right, is Caps Lock on, is this the correct username, was the password recently changed? — and if genuine doubt remains, go straight to Forgot Password before the lock engages, because a reset against an unlocked account is self-service and immediate, whereas a locked account adds a waiting period (or a support interaction) in front of everything.

Distinguish the lock from the reset conceptually: the reset is the user's voluntary recovery tool; the lock is the system's involuntary defence against credential-guessing attacks. They interact badly when a panicking user burns attempts and then resets — the new password may still have to wait out the lock.

C.5 The recovery anchor — the SSP User Profile

Everything in C.1–C.4 depends on one page: Getting Started → SSP User Profile, where the user maintains their username, phone number and email address. This is the user's profile, not the taxpayer's (taxpayer details live under Taxpayer Information — see the forthcoming tarmsuserprofile and tarmsprofile lessons for the full treatment of each). For password purposes the rule is simple and absolute: the profile must be kept current while you can still log in, because by the time you need recovery, you cannot. Changing jobs, changing mobile numbers, migrating off an old email provider — each of these events should trigger a profile update the same week. The browser-verification codes encountered at login (tarmslogin) ride on the same contact details, so a stale phone number can obstruct even a successful password's login.

C.6 Why there is no "admin gives me the password" route

Users coming from informal office IT cultures often expect a colleague or "the admin" to be able to look up or hand over a password. The SSP deliberately has no such route. Passwords are not retrievable by anyone — recovery always means setting a new one via a link to the registered email. And access for another person always means their own account plus an Assignee Management grant, never disclosure of credentials. This is the Section 5 secrecy architecture and the Sections 53–61 attribution logic (section B) expressed as user experience: the system is built so that the honest answer to "who did this?" is always a single named person.

D.1 The individual taxpayer — Rudo, a Harare employee with a side consultancy

Rudo registered on the SSP in 2025 to file her ITF 1. She logs in perhaps five times a year, which makes her the classic forgotten password case — infrequent users forget. In March she attempts to log in, fails twice, stops (the two-attempt rule), clicks Forgot Password, enters her email, finds the reset link in her inbox within minutes, sets a new password and is filing within a quarter of an hour. Total cost: nothing.

Contrast the counterfactual: Rudo had registered with her then-employer's corporate email, left that job in January, and never updated Getting Started → SSP User Profile. The reset link now goes to a mailbox she cannot open. Her path is ZIMRA support, with identity verification, during the filing season rush. The lesson writes itself: the profile update she skipped in January was the real failure; the forgotten password merely revealed it.

D.2 The SME — Tatenda & Sons (Pvt) Ltd, a Msasa hardware wholesaler

The company's entire SSP capability lives in one bookkeeper, Mr Phiri — sole SSP user with submission rights, registered with his personal Gmail. On 24 June (VAT 7 due the 25th; the June QPD due the 25th under Section 72), Mr Phiri is hospitalised. Nobody else can log in; sharing his password (even if known) would be precisely the control failure Sections 5 and 53–61 frame as culpable. The VAT 7 is filed late; penalty and interest follow; the compliance gap surfaces months later as a blocked ITF 263 renewal, and customers begin withholding 30% on payments above the Section 80 threshold.

The cure is structural, and it is the standing recommendation carried forward from tarmslogin: every taxpayer should have at least two SSP users with submission rights, each with their own login, granted through Assignee Management — for instance the bookkeeper and a director. The cost of the second account is one sign-up and one grant; the benefit is that no single password, illness, resignation or lock-out can strand a statutory deadline. Add the quarterly hygiene rules from the SSP guidance: review the assignee list at least quarterly, remove ex-staff promptly, and ensure every user's profile email is one the company's continuity does not depend on an individual remembering.

A worked illustration of the money at stake. Suppose Tatenda & Sons' June VAT liability is USD 18,400 and the locked-out period delays filing and payment by six days. Even before considering interest and the categorical 100%-band civil penalty exposure for late VAT, the knock-on ITF 263 lapse is the larger figure: if customers paying USD 120,000 of invoices in the gap month apply the Section 80 30% withholding for want of a valid clearance, USD 36,000 of cash flow is locked up as a provisional credit pending the next assessment cycle — a working-capital hole an SME feels immediately. (The mechanics of that example follow the pattern worked in detail in tarmscertificates.)

D.3 The large corporate and the tax agent — many users, many taxpayers

A listed group's shared-services centre might have a dozen SSP users across the group's TINs; a tax agency might have users shifting into fifty client taxpayers. At this scale, password management becomes formal identity governance:

• Joiners: each new staff member signs up for their own SSP account (corporate email, per tarmssspregistration) and receives Assignee Management grants scoped to the taxpayers and functions they actually need — minimum necessary permissions.
• Movers: role changes trigger grant adjustments, not credential hand-overs.
• Leavers: the same day a user exits, their grants are revoked in Assignee Management. Note carefully what is and is not in the group's power: the group can revoke the leaver's access to its taxpayers, but the leaver's SSP user account is the leaver's own — which is exactly why access must ride on grants rather than on a shared "tax department" login whose password walks out the door in the leaver's head.
• Compromise drills: any suspected phishing success against a user with multi-taxpayer access is treated as an incident across all taxpayers that user can shift into — immediate password change, review of recent submissions and bank-detail changes on each affected taxpayer (the SSP guidance specifically flags verifying bank-account changes under Taxpayer Information before any refund withdrawal is requested).

For agents, there is also a professional-liability angle: an agent submitting under Section 37A creates assessments for clients. The agent's credential hygiene is, functionally, part of the duty of care owed to every client in the portfolio.

There is, candidly, no Zimbabwean case law on SSP password mechanics — no reported decision turns on a reset link, a lock-out or a shared login, and this lesson will not pretend otherwise. The portal is recent and these are administrative mechanics; disputes that reach the courts arrive framed as penalty, assessment or procedural-fairness questions, not as password questions.

The relevant authorities are therefore the contextual ones already met in this course, which show how the surrounding obligations are enforced regardless of practical difficulty:

• The secrecy and administration framework of Section 5 and the Commissioner's powers, treated in itcadministration with its accompanying authorities, supplies the doctrinal reason credentials are personal.
• The objection-and-assessment machinery (Section 51 notices, the 30-day objection window) — see Nestlé Zimbabwe (20-SC-290) and Barclays Bank (04-HH-162) as treated in itcadministration — runs on fixed time limits that a locked-out taxpayer must still meet; the prudent reading is that portal access problems should be documented contemporaneously (support reference numbers, screenshots) if they ever need to be advanced in mitigation.
• On the clearance side, the principle that statutory clearance requirements bind notwithstanding commercial inconvenience, discussed via Sabeta (12-HH-079) and Sibanda v Masanga (24-SC-090) in tarmscertificates, illustrates the judiciary's general unreceptiveness to "the system made compliance hard" arguments.

No foreign authority is cited here because none is needed: the area is governed by statute and administrative design, not by case-made doctrine.

1. Sharing the password "just for month-end". The most common and most consequential failure. It breaks the Section 5 confidentiality architecture, destroys attribution under Sections 53–61/37A, and — practically — means the password is now only as safe as the least careful person who knows it. Correct approach: a second SSP account plus an Assignee Management grant takes minutes and is the designed route.

2. A stale recovery email. Registering with a corporate or throwaway address and never updating the profile after leaving the job/provider. The failure is invisible until the day recovery is needed, at which point it is no longer self-service. Correct approach: treat every job, phone or mailbox change as an immediate Getting Started → SSP User Profile update.

3. Burning login attempts until the lock engages. Panic-typing five guesses converts a thirty-second reset into a lock-out wait. Correct approach: stop after two failures, diagnose (Caps Lock, keyboard layout, username), then go straight to Forgot Password.

4. First attempting recovery on deadline day. Filing on the 25th and discovering the password problem on the 25th stacks the recovery time directly onto the statutory deadline. Correct approach: log in early in the cycle (the monthly compliance routine in the forthcoming tarmsroutine lesson builds this in), so any credential problem surfaces with days, not minutes, of slack.

5. Clicking unsolicited "reset your ZIMRA password" emails. Phishing campaigns mimic ZIMRA; genuine reset links arrive only in response to the user's own Forgot Password request, and genuine ZIMRA correspondence lands in the Notifications module, not in unsolicited emails with attachments or login links. Correct approach: never authenticate via an emailed link you did not just request; navigate to the portal by typing the URL.

6. Keeping an ex-employee's account alive as "the company login". It is not the company's account; it is the leaver's. Continuing to use it is unauthorised access of another person's credentials and a standing secrecy breach. Correct approach: same-day grant revocation in Assignee Management on exit, and properly-granted accounts for current staff.

7. Confusing the three "password pages". Trying to change a forgotten password (impossible — change requires the current password), or resetting when merely locked (the reset may still wait out the lock), or expecting the SSP User Profile page to manage taxpayer details. Correct approach: match the event to the page using the table in section C.

8. No second submission-capable user. The single-point-of-failure design of D.2. Correct approach: minimum two users with submission rights per taxpayer, verified by an actual test login each quarter.

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.

• Four credential events, four pages: creation (one-time emailed link after Sign Up), change (authenticated, Getting Started → Changing the Password, current password + new twice), reset (unauthenticated, Forgot Password → emailed link), lock (system-imposed; wait or contact ZIMRA support). Match the event to the page.
• The password protects a user, not a taxpayer — and one user may reach many taxpayers, so multi-taxpayer practitioners carry proportionally heavier credential duties.
• The legal weight is derivative but real: Section 5 secrecy (offences Section 5(5)/(5a)) explains personal logins; Sections 53–61 and Section 37A(10)–(11) make what happens under a login attributable and legally operative; Sections 37/37A/72 and FA Section 4B deadlines do not pause for lock-outs.
• The recovery anchor is the SSP User Profile (username, phone, email). Keep it current while you can still log in; every job/number/mailbox change is a same-week profile update.
• Stop after two failed attempts; diagnose, then reset — a voluntary reset against an unlocked account beats a forced wait against a locked one.
• Never share a password; never inherit one. Second-person access = own account + Assignee Management grant; leavers' grants are revoked same-day.
• Two submission-capable users per taxpayer, minimum — the cheapest insurance in the whole compliance calendar, as the Section 80 arithmetic shows (a one-month ITF 263 lapse can lock up 30% of receipts as a provisional credit).
• Phishing rule: genuine reset links arrive only when you just asked for one; genuine ZIMRA correspondence lands in the Notifications module. Type the URL; never log in via an unsolicited link.
• Screen-level specifics (lock threshold/duration, link validity, complexity rules, inactivity timeout) are TaRMS configuration, not statute — verify against the live SSP help before relying on a number.

Reset vs change vs lock — the practitioner's quick reference

Recovery dependencies

Decision tree — "I can't get into the SSP"

flowchart TD
 A[Cannot log in to the SSP] --> B{Failed attempts so far?}
 B -->|2 or more: STOP| C{Diagnose: Caps Lock, layout, right username?}
 B -->|Account already locked| L[Wait prescribed period or contact ZIMRA support]
 C -->|Found the slip| D[Retry carefully once]
 C -->|Password genuinely unknown| E[Forgot Password on login page]
 E --> F{Reset email received?}
 F -->|Yes| G[Follow link, set new password, log in]
 F -->|No| H{Checked spam and quarantine?}
 H -->|Found it| G
 H -->|Still nothing| I{Is the registered email still accessible?}
 I -->|Yes| J[Re-run Forgot Password / wait briefly]
 I -->|No - stale mailbox| K[Contact ZIMRA support: identity verification needed]
 D -->|Works| M[Logged in: update profile and consider password change]
 D -->|Fails| E
 L --> E
 K --> N[After recovery: update SSP User Profile immediately]
 G --> N

Statutes & sections

• Income Tax Act [Chapter 23:06] — Section 5 (preservation of secrecy; offences Section 5(5)/(5a); gateways Section 5(3)/(3a)): why SSP logins are personal; Sections 25B–25D (30-day registration; Section 25C civil penalty US$30 + US$30/day capped at 90 days with closure notice, as inserted by Finance Act (No. 2) 7/2024 w.e.f. 1 January 2025; liability independent of registration): the clock a stalled creation link runs against; Section 37 / Section 37A (returns; self-assessment within four months; Section 37A(10)–(11) return constitutes the assessment): attribution and deadline stakes; Sections 53–56, 61 (representative taxpayers; public officer): the named-person accountability that rides on logins; Section 72 (quarterly payment dates); Section 80 (30% withholding absent a valid tax clearance — the cash-flow consequence of credential-driven compliance lapses).
• Finance Act [Chapter 23:04] — Section 4B (remittance discipline for withheld amounts; context for deadline rigidity).
• Cyber and data protection legislation — referenced generally only.

Case law

• None on SSP password mechanics — stated honestly. Contextual authorities treated in earlier lessons: Nestlé Zimbabwe (20-SC-290) and Barclays Bank (04-HH-162) on assessment/objection time limits (itcadministration); Sabeta (12-HH-079) and Sibanda v Masanga (24-SC-090) on the bindingness of clearance requirements (tarmscertificates).

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (ZIMRA External Guide) — Getting Started module (§§3.3–3.6: Password Reset; SSP User Profile; Changing the Password; User Inactivity and Logout), §20 Security Housekeeping (own login; strong password rotated at least annually; quarterly assignee review; log out on shared devices; phishing caution; bank-detail verification before withdrawals), §22 sitemap (Getting Started pages).
• ZIMRA SSP online help, https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm — authoritative per-page reference.
• Zimbabwe Tax Compliance Calendar (ZIMRA) — the deadline rhythm (P2 by the 10th; VAT 7 by the 25th; QPDs 25 Mar/25 Jun/25 Sep/20 Dec; ITF 12C four months after year-end) against which recovery time is measured.

DTAs / international — none cited.