This lesson completes the agency arc. The Tax Agent Registration lesson explained how a person becomes a ZIMRA-registered tax agent; the Agent Licence lesson explained the credential that keeps that status alive. This lesson covers the step that actually connects an agent to a client: the assignment — the act by which a specific taxpayer, inside the Self-Service Portal, appoints a specific registered agent and defines what that agent may do. The procedural home is the Assignee Management module, whose three pages the local SSP External Guide confirms: Roles ("set the access permissions that can be granted to assignees — typical roles: read-only viewer, return preparer, return submitter, payment authoriser"), Assignees ("register assignees, search the list, view and edit their permissions, deactivate or remove an assignee"), and Tax Agent Assignment ("set tax agents (registered via the ZIMRA Tax Agents Registration process) and assign them predefined roles"). The agent-side trace is the Requests page of Taxpayer Information — "list of tax agent assignment requests submitted in the user's name". The full grammar of roles belongs to the next lesson (Roles & Permissions); here the focus is the assignment transaction itself: who initiates it, what it confers, how it is varied, and how it ends.

The legal load-bearing wall is authority and attribution. An assignment is the SSP's expression of the authority that Section 37(5) of the Income Tax Act [Chapter 23:06] demands — a return may be signed "by his agent duly authorized in that behalf" — and once the assigned agent acts, the statutory deemings close over the taxpayer: the signatory is deemed cognizant of all statements in the return (Section 37(6)), the return is deemed duly made and signed by the taxpayer unless the taxpayer proves it was not made on his behalf (Section 37(7)), and under the self-assessment system the filed return is the assessment (Section 37A(10)–(11)). Assignment therefore does something contractually modest but legally enormous: it manufactures the evidentiary record that will defeat any later "my agent did it without authority" argument. Conversely, revocation of an assignment is the taxpayer's only system-level kill-switch — engagement letters end relationships on paper; only the SSP grant ends the agent's ability to transact. The lesson pairs the SSP procedure with the paper layer a prudent taxpayer keeps in step: the engagement letter whose scope mirrors the granted roles, and the written authority that Section 65(9) requires if the agent is ever to appear for the taxpayer before the Special Court.

The lesson distinguishes the two appointment channels that the SSP guide reveals. General assignee grants (Assignees page) can be given to any SSP user — the in-house bookkeeper route. Tax agent assignment (the third page) is reserved for ZIMRA-registered agents and works through predefined roles. Both end up granting access, but they differ in eligibility (anyone vs registered agents), in role architecture (custom vs predefined), and in what they represent to ZIMRA (internal delegation vs professional representation). It also restates the standing hygiene rules in their assignment-specific form: one person, one login (the Section 5 secrecy architecture); revoke on the day a relationship ends; keep at least two submission-capable users per taxpayer so an agent transition never strands a deadline; and review the whole grant book quarterly ("review the assignees list at least quarterly", local guide, confirmed). Worked scenarios cover the SME outsourcing its books, the practice firm onboarding sixty clients, the agent switch executed without missing a P2 deadline, and the non-resident whose Section 25B(6) resident representative is operationalised through assignment. Case law specific to SSP assignments does not exist (stated honestly); the Section 37(7) deeming and the Afritrade-line collection authorities from the earlier lessons supply the litigation backdrop. Screen-level specifics — field lists, initiation direction (whether the agent can also request assignment), approval steps — carry verification flags because the official SSP online help was unreachable this run.

Every outsourced compliance relationship has two layers. The commercial layer — an engagement letter, a fee, a scope of work — lives on paper between client and agent. The system layer — who can actually open the taxpayer's record and press Submit — lives in TaRMS. Beginners assume the paper layer is the real one and the system layer is plumbing. Zimbabwean tax law inverts that: when ZIMRA asks "who had authority to file this return?", the answer it reaches for first is the system record — which login, holding which granted role, submitted the return — and Section 37(7) then deems the return the taxpayer's own unless the taxpayer can prove otherwise. The assignment is the handshake; the deeming is the grip.

This lesson teaches the handshake properly:

• Before assignment: what the taxpayer must verify (agent registered? licence current? — the previous two lessons), and what the agent must verify (client's taxpayer record real and in the agent's engagement-acceptance standards).
• At assignment: the SSP transaction — module, page, the role bundle granted, and the paper that should mirror it.
• During: maintenance — editing permissions, monitoring the Requests page, the quarterly review.
• At the end: revocation done cleanly, with no orphaned deadlines and no lingering access.

Why it matters practically: the single most common agency failure in practice is not fraud — it is drift. Engagements end, staff change, scopes narrow, and the grant book silently stops matching reality. Every stale grant is a live login with legal effect. The Assignee Management module exists to make authority visible and editable; this lesson is about keeping it true.

B.1 The authority requirement: Section 37(5) "duly authorized in that behalf"

Section 37(5) (confirmed verbatim in the Tax Agent Registration lesson) permits the return to be signed by the taxpayer "or by his agent duly authorized in that behalf". Unpack the phrase: duly authorized — there must be an actual grant of authority, not assumption or habit; in that behalf — the authority must cover the tax function in question. A general power to "manage the business" is weaker evidence than a specific mandate to prepare and submit returns. The SSP assignment, granting a named role such as return submitter over a named taxpayer, is the cleanest possible record that both elements existed at the moment of filing.

B.2 The attribution deemings: Section 37(6)–(7) and Section 37A(10)–(11)

Once an authorised agent files: Section 37(6) deems the signatory cognizant of all statements in the return (the agent cannot plead ignorance of contents); Section 37(7) deems the return "duly made and signed by the person affected, unless such person proves that such return was not made or signed by him or on his behalf" (the taxpayer bears the onus of disowning it); and Section 37A(10)–(11) makes the filed self-assessment return the assessment itself. Stack them and the assignment's legal gravity is plain: the moment the assigned agent submits, an assessment exists, attributed to the taxpayer, whose contents the agent is deemed to know. Errors are then corrected through the amendment and objection machinery (Tax Return Management's amendment route while "Waiting for Approval"; Section 62 objections through Case Management — see the Introduction lesson), not by denying authority.

B.3 The written-authority rule for representation: Section 65(9)

For appearances before the Special Court, the appellant "may appear in person or represented by a legal practitioner or by an agent authorized by him in writing". The SSP grant does not satisfy this by itself — it is a system permission, not a signed instrument addressed to the court. Practice rule: every tax agent engagement should include a signed written authority clause broad enough to cover objection and appeal representation, renewed when the engagement renews.

B.4 The secrecy and identity architecture: Section 5 and one-person-one-login

As established in the Logging In and User Profile lessons, Section 5 (preservation of secrecy, offences in Section 5(5)/(5a)) is the statutory reason the SSP insists each human uses their own account, and the local guide's permissions-hygiene passage states the operational rules verbatim: "Review the assignees list at least quarterly. Remove staff who have left, restrict permissions to the minimum needed, and never share an SSP user account between people." Assignment is how authority travels without credentials travelling.

B.5 The compelled-appointment overlay: Section 25B(6)–(8)

For non-resident registrable taxpayers, the resident representative duty (Section 25B(6)), its written notification (Section 25B(7)) and the Commissioner's default powers (Section 25B(8) — appointment and work-permit cancellation) were walked in the Tax Agent Registration lesson. The assignment procedure in this lesson is how that statutory appointment becomes operational: the representative (often a registered agent) is assigned over the non-resident's taxpayer record so it can actually register, file and pay. The statute creates the duty; the SSP grant performs it.

B.6 What assignment does NOT do

No provision transfers the Section 6 charge: the taxpayer remains liable for the tax however completely the work is outsourced (the Section 25D logic — liability exists "regardless" — extended by analogy). Assignment also does not make the agent a representative taxpayer (ITA Sections 53–56) or representative registered operator (VAT Sections 47/49) — those flow from office, not from grants (Tax Agent Registration lesson, sense 2 of the taxonomy). And it does not insulate the agent: beyond Section 37(6), an agent holding client funds remains exposed to the ITA Section 58 / VAT Section 48 declared-agent collection powers (Afritrade International Ltd v ZIMRA 21-SC-003 line).

C.1 The two appointment channels

The Assignee Management module offers two distinct doors, and choosing correctly is the first decision:

	Assignees page (general grant)	Tax Agent Assignment page
Who can be appointed	Any existing SSP user	Only ZIMRA-registered tax agents
Role architecture	Roles configured by the taxpayer on the Roles page	Predefined roles (local guide, confirmed)
Typical use	In-house finance staff, internal bookkeeper	External accountant / tax practice
What it signals	Internal delegation	Professional representation
Covered in depth	Roles & Permissions lesson (next)	This lesson

Both channels produce the same fundamental thing — a named user with defined permissions over this taxpayer — but the tax agent channel adds the ZIMRA-side eligibility check (registration/licence, previous lessons) and standardised role bundles.

C.2 The assignment lifecycle, step by step

Step 0 — Due diligence (both directions). Taxpayer verifies the agent: appears in the Tax Agent Assignment lookup, licence current, agent's own ITF 263 produced (Agent Licence lesson, client-side routine). Agent verifies the client: TIN active, profile current (an out-of-date taxpayer profile delays everything downstream — Taxpayer Profile lesson), engagement risk acceptable.

Step 1 — Paper first. Sign the engagement letter before granting access, with scope clauses that mirror the roles to be granted (preparation only? submission? payment authorisation?) and the Section 65(9) written authority for objections/appeals. The paper and the grant should be twins; divergence between them is the seed of every later dispute.

Step 2 — Raise the assignment in the SSP. In Taxpayer mode (shifted into the correct taxpayer — confirm the active taxpayer name, the discipline from the Logging In lesson), open Assignee Management → Tax Agent Assignment; identify the registered agent; select the predefined role(s); submit.

Step 3 — The agent-side trace. The request appears on the agent side — the Taxpayer Information → Requests page lists "tax agent assignment requests submitted in the user's name" (local guide, confirmed). The agent monitors this page during onboarding seasons.

Step 4 — Confirm and test. Once active, the agent shifts into the client taxpayer and confirms the expected modules are visible (the module menu changes with role — "all modules available subject to user role", local guide). A two-minute test now beats a deadline-day discovery that the granted role stops at preparer when the calendar needs a submitter.

Step 5 — Maintain. Permissions are edited from the Assignees page ("view and edit their permissions"); the taxpayer's quarterly sweep covers grant accuracy, and the agent's own quarterly sweep covers its staff grants across all clients (User Profile lesson). Scope changes in the engagement (say, adding payment authorisation) are executed in both layers — letter and grant — on the same day.

Step 6 — End cleanly. On termination: complete or formally hand over in-flight filings; deactivate or remove the assignment (Assignees page verbs, confirmed); revoke same-day, not at month-end; and check the two-deep submission rule still holds — if the departing agent was one of only two submission-capable users, appoint the successor before revoking, or the taxpayer is one sick day away from a missed P2. The taxpayer's deadlines (10th P2, VAT 7, QPDs 25 Mar/25 Jun/25 Sep/20 Dec, ITF 12C +4 months — Introduction lesson) run through any transition.

C.3 Who initiates? The direction-of-travel question

The local guide describes the taxpayer "setting" tax agents through Assignee Management, while the agent-side Requests page lists requests "submitted in the user's name" — language consistent with either taxpayer-initiated grants or agent-initiated requests awaiting taxpayer/ZIMRA action. Practice accommodates both patterns in onboarding: a hands-on client raises the assignment itself; a practice firm onboarding a low-capability client typically walks the client through it or initiates and has the client confirm.

C.4 Scoping the grant: minimum necessary, but deadline-proof

Two principles pull against each other. Least privilege (the guide's "restrict permissions to the minimum needed") argues for narrow roles: the agent who only prepares should not hold payment authorisation. Continuity argues for redundancy: at least two humans must be able to submit at all times. Resolve the tension deliberately: narrow each person's grant, but ensure the set of grants covers preparation, submission and payment with redundancy on submission. A sensible SME pattern: agent firm's senior = preparer + submitter; agent firm's second = submitter (dormant, for cover); owner = payment authoriser + submitter of last resort. The taxpayer never grants its whole compliance existence to a single external login.

C.5 The assignment as evidence

Think like the dispute that has not happened yet. If a return is challenged years later, the record that decides the Section 37(7) question is: the assignment (who held what role, when — Assignee Management history), the submission metadata (which login filed — the SSP's attribution), and the engagement letter (what was authorised on paper). The taxpayer who keeps these three aligned has nothing to fear from the deeming; the taxpayer who let an ex-agent's grant linger, or let an unregistered "consultant" file through the owner's own login, has manufactured the evidence against itself. Record-keeping duty: Section 37B (six-year records, in English) comfortably covers engagement and authority documents — keep them as long as the returns they explain.

D.1 The SME outsourcing its compliance (SME)

Pamberi Hardware (Pvt) Ltd (the recurring Harare SME, VAT-registered, three employees) engages Rudo's practice. Sequence executed properly: engagement letter signed Monday (scope: prepare and submit VAT 7 and P2; prepare ITF 12C for owner's review; no payment authorisation; written authority for objections); owner shifts into Pamberi in the SSP, raises Tax Agent Assignment to Rudo's registered practice with the matching predefined roles; Rudo confirms access Tuesday and test-opens Pending Tax Returns; first P2 filed by the 10th. Payment stays with the owner: Rudo's submission of the P2 creates the liability record, the owner pays through Payments → New Payment. Total elapsed risk window: zero — the old arrangement (owner filing personally) stayed live until the new grant was tested.

D.2 The practice firm onboarding at scale (SME/professional)

Rudo wins sixty clients from a retiring practitioner. Onboarding architecture: a standard engagement pack (letter + role schedule + Section 65(9) authority); a tracking sheet of sixty assignments raised/active/tested; her two submission-capable staff granted across all clients per the role pattern in C.4; the Requests page checked daily through the transition month; and a hard rule that no client's prior arrangement is revoked until Rudo's grant is tested. The retiring practitioner's obligations mirror this in reverse: complete in-flight filings, hand over drafts (remembering from the Taxpayer Profile lesson that a draft discharges nothing — anything left in Drafts is undone work), and have each client revoke his grants on cut-over day.

D.3 Switching agents without missing a deadline (SME)

Tariro Logistics terminates its agent on 3 July for poor service; the July P2 is due the 10th. Wrong order: revoke on the 3rd, sign the new agent on the 8th, discover the new assignment needs setup time — deadline missed, penalty and interest on the Single Account, ITF 263 at risk (the compliance grid from the Certificates lesson). Right order: sign the new engagement on the 3rd; raise the new assignment and test it on the 4th; new agent confirms it can see the pending P2; revoke the old agent on the 5th; P2 filed on the 8th. Revocation is the last step of a switch, not the first — but it is never deferred past cut-over, because a terminated agent with live access is an unacceptable risk in the other direction.

D.4 The non-resident operationalising Section 25B(6) (large corporate / non-resident)

Khanyisa Mining GmbH (from the registration lesson) appointed a registered agent firm as its resident representative and notified ZIMRA in writing (Section 25B(7)). System expression: the firm secured Khanyisa's registration; Khanyisa's taxpayer record now carries the firm's assignment with full operational roles, since no Khanyisa employee resides in Zimbabwe. Governance compensations for the breadth of that grant: the engagement letter requires monthly reporting against the Summary Report (Taxpayer Accounting module), dual sign-off inside the firm for payments, and the parent's CFO holds her own SSP account with a read-only-equivalent role so the principal can watch what its agent does. Breadth of necessary delegation is managed by visibility, not trust.

Stated honestly: no reported Zimbabwean case in the source materials concerns SSP assignments or the Assignee Management module. The litigation backdrop is supplied by the provisions the assignment serves and the collection powers that surround agency, all met earlier: the Section 37(7) deeming (the return is the taxpayer's unless disproved — the provision every clean assignment record exists to satisfy); the self-assessment authorities annotated to Section 37A in the source Act and taught in the debt lessons (CF 18-HH-099, DNS 19-HH-722, IAB 22-HH-032, Nestlé 20-SC-290/23-HH-312 — the filed return binds, and must comply with the law); and the declared-agent line on VAT Section 48 / ITA Section 58 (Afritrade International Ltd v ZIMRA 21-SC-003; ZIMRA v Packers International 16-SC-028; Embassy Time Security (in Liquidation) 18-HH-248) with the representative-liability authority TG v ZIMRA 19-HH-578 on VAT Section 49(2) — the exposure map for agents who hold client money. No foreign authority is offered; the module is procedural and Zimbabwe-specific.

1. Granting access before signing the engagement. The grant is legal authority in action; paper that lags the grant leaves the scope of Section 37(5) authority to memory and goodwill. Letter first, grant second, always twins.
2. Revoking first in an agent switch. Creates an authority gap across a deadline. Sequence: new grant raised → tested → old grant revoked → file. (And the mirror error — leaving the old agent live "just in case" — violates same-day-revocation hygiene.)
3. The single-submitter taxpayer. One external login holding the only submission capability fails the two-deep rule; the agent's lock-out, leave or licence lapse becomes the taxpayer's penalty. Keep an internal submitter of last resort.
4. Credential sharing as a substitute for assignment. Giving the "consultant" the owner's password instead of an assignment defeats Section 5 architecture, destroys the attribution record that protects the taxpayer under Section 37(7), and marks the consultant as unregistrable. The cheap shortcut is the expensive one.
5. Scope drift. Roles granted in 2025 still live in 2027 though the engagement narrowed. The quarterly review exists precisely for this; "restrict permissions to the minimum needed" is a continuing verb, not a setup step.
6. Relying on the grant for court representation. The SSP role does not satisfy Section 65(9) — Special Court representation needs authority in writing. Build it into the engagement pack.
7. Forgetting drafts and in-flight items at handover. Drafts discharge nothing; an outgoing agent's half-built VAT 7 is invisible work. Handover checklists must inventory Drafts, pending returns and open Case Management items, not just "the files".
8. Assigning an unverified "agent". If the person cannot be found in the Tax Agent Assignment lookup, they are not a registered agent — use the general Assignees channel only with full knowledge that no ZIMRA professional gate stands behind them, or decline.

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.

• Assignment is authority made visible: the SSP record of who may act, which the Section 37(5) "duly authorized in that behalf" requirement contemplates and the Section 37(6)–(7) and Section 37A(10)–(11) deemings then enforce against both parties.
• Two channels: general assignee grants (anyone, custom roles) vs Tax Agent Assignment (registered agents only, predefined roles); the agent-side trace is Taxpayer Information → Requests.
• Lifecycle discipline: verify → paper → grant → test → maintain (quarterly review; "minimum needed") → revoke same-day at the end — with revocation last in a switch but never deferred past cut-over.
• Two-deep submission at all times; an agent transition is exactly when the rule earns its keep.
• The grant is not the whole authority stack: Section 65(9) court representation needs written authority; engagement letters and grants must be twins; Section 37B keeps the evidence six years.
• Liability never travels: all roles granted, the Section 6 charge stays home; the agent's own exposures (Section 37(6), Sections 58/48 on held funds, Section 49(6) if a representative office is also held) ride alongside.
• No case law on the module (stated honestly); initiation direction, predefined role content and approval steps are flagged pending a reachable help site.

Assignee grant vs tax agent assignment

Feature	Assignees page (general)	Tax Agent Assignment
Eligible appointee	Any SSP user	ZIMRA-registered tax agent only
Roles	Configured on Roles page	Predefined bundles
Professional gate behind appointee	None	Registration + licence (prior lessons)
Typical appointee	Employee, internal bookkeeper	External practice firm
Lifecycle verbs (guide, confirmed)	register, search, view, edit, deactivate, remove	set agent, assign predefined roles
Tracked agent-side	n/a	Taxpayer Information → Requests

The switch sequence (correct order)

Step	Action	Rule it serves
1	Sign new engagement + written authority	Paper and grant must be twins; Section 65(9)
2	Raise new assignment; agent tests access	Continuous authority; two-deep rule
3	Handover inventory: drafts, pending returns, open cases	Drafts discharge nothing
4	Revoke outgoing agent (deactivate/remove)	Same-day revocation hygiene
5	File and pay on calendar	Deadlines never pause for transitions

flowchart TD
 A[Engage a tax agent] --> B{Agent in Tax Agent Assignment lookup?}
 B -->|No| C[Not a registered agent: decline or general assignee route with eyes open]
 B -->|Yes| D
 D --> E[Sign engagement letter + Section 65 9 written authority]
 E --> F[Raise Tax Agent Assignment with predefined roles]
 F --> G[Agent confirms via Requests and tests access]
 G --> H[Operate: file, maintain, quarterly review]
 H --> I{Engagement ends or agent switched?}
 I -->|Switch| J[New grant raised and tested FIRST]
 J --> K[Revoke old grant same day]
 I -->|End| K
 K --> L[Confirm two-deep submission still holds]

Statutes & sections

• Income Tax Act [Chapter 23:06] — Section 5 (secrecy; offences Section 5(5)/(5a)) — the one-person-one-login rationale; Section 6 (charge — never delegated); Section 25B(6)–(8) (non-resident's resident representative; written notice; Commissioner appointment and work-permit lever); Section 25D (liability regardless of registration status — analogy); Section 37(5) (return signed by taxpayer "or by his agent duly authorized in that behalf"); Section 37(6) (signatory deemed cognizant of all statements); Section 37(7) (return deemed duly made by the taxpayer unless disproved); Section 37A(10)–(11) (filed return = assessment); Section 37B (six-year records — covers authority documents); Section 46 (additional tax; Section 46(6) remission); Section 62 (objections — via Case Management); Section 65(9) (Special Court representation by agent authorised in writing); Sections 81–83 (offences).
• VAT Act [Chapter 23:12] — Sections 47–49 (representative capacity and liability — what assignment does not create); Section 48 (declared agents — exposure on held funds).

Case law

• None on SSP assignment mechanics — stated honestly. Backdrop authorities (earlier lessons): Afritrade International Ltd v ZIMRA 21-SC-003; ZIMRA v Packers International (Pvt) Ltd 16-SC-028; Embassy Time Security (Pvt) Ltd (in Liquidation) v ZIMRA 18-HH-248 (declared-agent powers); TG v ZIMRA 19-HH-578 (representative liability, VAT Section 49(2)); self-assessment line on Section 37A (CF 18-HH-099; DNS 19-HH-722; IAB 22-HH-032; Nestlé 20-SC-290/23-HH-312).

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (local External Guide) — Assignee Management module (Roles • Assignees • Tax Agent Assignment; permissions hygiene: quarterly review, minimum permissions, no shared accounts); Taxpayer Information → Requests (tax agent assignment requests); module visibility by role ("all modules available subject to user role"). Official SSP online help (https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm) unreachable this run — initiation direction, identification fields, predefined role content and approval steps flagged .