Adding a one-time code to client request links
When a firm should require a one-time code on its client request and share links in Achekam, what the code protects against and what it cannot.
By Achekam · · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
The financial manager forwards the firm's request to her assistant to deal with. The assistant forwards it to the payroll bureau. The payroll bureau's clerk opens it, sees a request for the directors' identity documents and every employee's tax details, and uploads a file. Nobody did anything wrong, and the request has now been opened by three people the firm never met.
Links make it easy for clients to deal with a firm without passwords or portals. That ease is also the risk: a link can travel. Achekam lets a firm add a one-time code to its request links. This article explains what that code does, when it is worth the extra step for the client, and how to explain it.
How a request link works
In Achekam, a client opens a request from a personal link sent by e-mail, without an Achekam account. Without a one-time code, the link is what opens the request. With a code switched on, the person opening the link must also enter a code sent to the client's e-mail address.
Request links last 14 days by default. Documents shared from the vault use a similar link: staff can share a document with a named person by an e-mailed link that can block downloading, require a code and be revoked, and every view and download is recorded. Share links last 7 days by default.
What a forwarded link could expose
Think about what someone holding a forwarded or intercepted link could do without a code:
- read what the firm has asked for, which may itself reveal sensitive matters, such as a dispute, a restructuring or a tax inquiry;
- answer the firm's questions or upload files in the client's name;
- for a share link, view or download the document shared.
The first matters more than firms expect. A request titled "documents for SARS audit" or "information for the disciplinary hearing" says a good deal even before anything is uploaded.
Switching the code on
The code is off by default. Switch it on where the cost of the wrong person opening the request is high. A reasonable rule of thumb:
| Request or share | Code? |
|---|---|
| Identity documents, passports, proof of address | Yes |
| Payroll information, employee tax details, salaries | Yes |
| Bank statements and loan agreements | Usually |
| Medical, legal or disciplinary matters | Yes |
| Issued financial statements shared with a lender | Usually, with downloads blocked if appropriate |
| Routine monthly invoices and slips | Usually not |
| Requests that would go to a shared mailbox such as accounts@ or info@ | Ask for a personal address first |
The last row deserves emphasis. A request sent to a shared mailbox is, in effect, already forwarded to everyone who reads that mailbox, and the code would arrive in the same place. Ask for a personal address for the right person; the code then protects the request if it travels any further.
What the code does not protect against
A code sent to the client's e-mail protects against a link that travels without the mailbox: forwarded to a third party, pasted into a chat, picked up from a printed page. It does not protect against someone who already has access to the client's mailbox, because the code arrives there too. A compromised mailbox defeats both the link and the code.
The firm's side needs the same care. Users can turn on two-factor sign-in with an authenticator app, a firm can require it for all members, and members can sign in with Google or Microsoft Entra ID once the firm sets up single sign-on. A firm that protects client links with a code but lets staff sign in with a password alone has secured the smaller door.
If personal information does reach the wrong person, South Africa's Information Regulator gives step-by-step instructions for reporting a security compromise under section 22 of POPIA through its eServices portal. Firms in Nigeria and Kenya should know their own regulator's process before they need it.
How long links last, and the timeline
Expiry limits how long a forwarded link stays useful. The defaults of 14 days for requests and 7 days for shares suit most work; for highly sensitive shares, revoke the link as soon as the recipient confirms they have what they need.
For each request, staff see a timeline of e-mails, opens, clicks, uploads and answers, and a request is flagged 'Delivery failed' when the mail provider refused it or none is set up. Opens are detected with a tracking image, so they are only an indication; the timeline will not reliably tell you who opened a link, only that it was probably opened. For shared documents, every view and download is recorded, which is the stronger record when it matters who saw a file.
Explaining the code to clients
Clients accept an extra step when they understand why. A short line in the covering e-mail is enough: "Because this request asks for identity documents, you will be sent a one-time code by e-mail when you open the link. Please do not forward this request; if someone else at your company should answer it, let us know and we will send them their own."
That last sentence does more than the code. A client who knows to ask for a second request, rather than forward the first, keeps every link personal. How clients deal with the firm's links in general is covered in requesting client documents without a portal login, and what happens to files once uploaded is covered in what happens to files clients upload.
A worked example in words: a firm takes on payroll for a new client and needs every employee's tax number and bank details. The manager raises the request with the one-time code on, addressed to the client's HR manager personally rather than the general office address, with a covering note explaining the code. The HR manager opens it, enters the code and uploads the schedule. When the client's bookkeeper later asks for access, the manager sends a separate request rather than asking the HR manager to forward hers.
Set a firm policy
Decide once which kinds of request and share always carry a code, write it down, and build it into your request templates. Staff should not have to judge sensitivity afresh every time they send a link.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
