cra-assistent

← Curriculum /E-services and digital channels /Level 2

Represent a Client — authorisation online

Draft — unverified

Work through these first

Foundations covers who may act for a taxpayer — the authority question, which is a matter of law and applies however a request arrives. This tutorial covers how that authority is created, seen and confirmed in CRA's systems, and what it does and does not permit once it exists. Two properties do most of the work on calls. Authorisation has a **level**, so a representative may be entitled to see information without being entitled to change anything. And authorisation has a **scope**, attaching to particular accounts rather than to the taxpayer in general. A representative who is correctly identified, genuinely professional and plainly acting in good faith may still be entitled to nothing on the account being asked about, and recognising that quickly is most of the skill here.

How to work through this tutorial

This runs from creating an authorisation to relying on one: 1. Recall the rule from Foundations, and see where the channel begins. 2. Learn how an authorisation is created, online and otherwise. 3. Learn what a level of access means, and why it is not a formality. 4. Learn what scope means — which accounts an authorisation reaches. 5. Learn how authorisations end, and who can end them. 6. Understand what to confirm before disclosing anything to a representative. 7. Work through an example of a legitimate representative entitled to nothing. 8. Check your work against the common errors. 9. Verify every specific against CRA's published guidance before relying on it.

Where the rule ends and the channel begins

The prerequisite for this tutorial is the Foundations topic on authorising a representative, and the division between them is worth stating. The **rule** is that a taxpayer's information is confidential and is disclosed to a third party only where the taxpayer has authorised it, or where the law otherwise permits. That is true on the phone, in writing and online, and it does not change because a portal exists. The **channel** is Represent a Client: the mechanism by which an authorisation is recorded, made visible, and acted on. It implements the rule and adds operational detail — levels, scope, expiry — that the rule alone does not specify. An agent who has only learned the channel will reason from screens, and will eventually conclude that because something is visible it is permitted. It is the other way round.

How an authorisation is created

The routes have changed over time and continue to, so confirm the current position rather than describing the one you learned. Broadly: a representative registers for Represent a Client and receives an identifier of their own. They then request authorisation for a client, and the taxpayer confirms it — historically through the taxpayer's own online account, and by other means where a taxpayer cannot do that. A representative may be an individual or a firm, and a firm's authorisation lets its employees act under the firm's identifier. A taxpayer can also initiate the authorisation themselves from their own account. There are also authorities that do not arise from the taxpayer at all — a legal representative acting under a power of attorney, or for an estate, or a trustee in bankruptcy. Those are established by documentation rather than by an online request, and they are not the same thing as an authorisation even though they produce a similar result. Do not treat them as interchangeable.

Levels of access

An authorisation carries a level, and the level decides what the representative may do rather than what they may see about themselves. The distinction that matters most on a call is between access that permits **viewing** information and access that permits **changing** things — updating information, making requests that alter the account. A representative with view access who asks for a change is not being obstructed by a technicality; they have not been given that authority by their client. Business accounts add a further dimension, because a representative's access can be granted per program account and can include the ability to manage other representatives' access. The practical habit: when a representative asks for something, the question is not only "are they authorised" but "are they authorised to do *this*". Those are different questions and the second is the one usually missed.

Scope, expiry and ending an authorisation

An authorisation attaches to specified accounts. On the individual side that is the taxpayer's account; on the business side it is particular program accounts, and a representative authorised on payroll is not thereby authorised on GST/HST. An authorisation can carry an expiry date, set when it is given. It also ends when it is cancelled — and it can be cancelled by the taxpayer at any time, without the representative's agreement and without notice to them. A representative who has "lost access" to a client may simply have been removed by that client. A taxpayer can see and cancel their authorisations in their own account, which is worth telling them: a taxpayer who no longer deals with an accountant from four years ago often does not realise that access persists until it is removed. Death, bankruptcy and similar events change who has authority in ways an online authorisation does not describe. Those cases run on the documentation route rather than this one.

Before disclosing to a representative

Three checks, in order, and none of them substitutes for another. **Is this person who they say they are?** The identity check from the security tutorial applies to representatives exactly as it does to taxpayers. **Are they authorised on this account?** Not on the taxpayer generally — on the account being discussed. **Does their level cover what they are asking to do?** Viewing and changing are different permissions. A failure at any one of the three ends the disclosure, and it is worth being comfortable saying so without apology or elaboration. "I'm not able to discuss that account with you" is a complete answer. Explaining *why* an authorisation is absent can itself disclose something about the taxpayer's affairs.

A worked example: the right accountant, the wrong account

Teaching example. The figures below are invented to show the method. They are not CRA figures, and no amount here should be used for a real taxpayer.

The details in this example are invented for teaching. Nothing here should be quoted as CRA's position. Suppose Priyanka is a bookkeeper. She has been engaged by a small manufacturing company for years, is registered in Represent a Client, verifies her identity without difficulty, and is asking about a GST/HST balance. She is authorised on the client's **payroll** program account. She was brought in originally to run payroll and the authorisation was set up then. Nobody has ever added the GST/HST account. Everything about her is legitimate. She is not attempting anything. Her client would almost certainly authorise her within the hour if asked. And she is entitled to nothing on the account she is asking about, because authority is granted per account and this one was not granted. Suppose she then says she only needs to know whether a payment of $2,100 was received. That is still a disclosure about an account she is not authorised on, and the small size of the question does not shrink the rule. What is genuinely helpful is to tell her what the client needs to do to add the account. That is not a disclosure, and it solves her problem properly rather than partially. The habit: check authorisation against the account in front of you, not against the relationship.

Common errors

Treating an authorisation as covering the taxpayer generally. It covers specified accounts. Checking that a representative is authorised without checking that their level covers what they are asking to do. Skipping the identity check because the authorisation is on file. Both, every time. Treating a legal representative acting under documentation as the same thing as an online authorisation. Explaining why an authorisation is missing in terms that themselves disclose the taxpayer's affairs. Assuming a representative's access persists indefinitely. It can expire and can be cancelled without their knowledge. Telling a taxpayer their old accountant "must have been removed by now". Access persists until it is removed. Making an exception for a small question. The size of the disclosure is not the test. Describing the current authorisation routes from memory. They have changed repeatedly.

What to verify this tutorial against

This was drafted without a source document. The authorisation routes and the naming of access levels have changed more than once, so confirm the current position throughout. CRA's pages on authorising a representative are the primary reference: how authorisation is requested and confirmed, the levels of access, expiry, and cancellation. CRA's Represent a Client pages cover registration by a representative, the identifier issued to them, and how a firm's employees act under it. CRA's guidance on authorising a representative for a business covers per-program-account authorisation and the management of other representatives' access. CRA's guidance on legal representatives — powers of attorney, estates, trustees in bankruptcy — is the reference for the documentation route, which is distinct from online authorisation and must not be conflated with it. The confidentiality provisions of the Income Tax Act are the legal basis for the disclosure rule. Confirm the provision before citing it. The Foundations tutorial on authorising a representative is the prerequisite and carries the rule this tutorial implements; check the two for consistency when either is revised.

Your progress

This is your own record of what you have worked through. It says nothing about whether the content has been verified.

Quiz not attempted. 5 questions available — marking this complete does not require taking it, but the quiz is the only thing here that distinguishes having read the page from having learned it. Take the quiz

Claims to confirm

These are the checkable specifics from this tutorial — the details most likely to be wrong in a drafted page. Confirm each against CRA guidance. 0 of 11 confirmed.

Verify this tutorial

11 claim(s) still unconfirmed. Confirm them above first — verifying the page while its specifics are outstanding would defeat the purpose of listing them.