Requesting client documents without a portal login
How a firm requests documents and answers from clients through personal links in Achekam, with an optional one-time code, and where the uploads are filed.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
"I can't remember my password for your portal. Can I just e-mail them?" Firms that have launched a client portal hear this often, usually from the client whose documents are most urgently needed. The bank statements then arrive as a string of separate e-mails, one of them with the wrong month, and a junior spends the afternoon saving attachments into folders.
Achekam takes a different route. Clients do not sign in at all. They receive a personal link for each request, answer it and upload what is asked for, and what they send lands in their folder in the firm's document vault. This article explains how that works, what security options a firm has, and why there is no client portal.
One console for every request
Staff create, send and track requests to clients in one place: the RFI console, under RFI & Client Requests. A request can ask for documents, answers to questions or confirmations.
Requests do not have to start in the console. They can also be raised from a work item, from the document console or from an assurance review room, using the same form. Wherever a request was raised, it is tracked in the same console. A manager who wants to know what is outstanding from a client looks in one place, not in each engagement.
The personal link, and the optional code
A client opens a request from a personal link sent by e-mail, without an Achekam account. Request links last 14 days by default.
The firm can also require a one-time code, sent to the client's e-mail address, before the request opens. The code is off by default. Consider switching it on for requests that ask for sensitive material, such as identity documents, payroll records or bank statements, where a forwarded link reaching the wrong person would matter.
The trade-off is simple. A code adds a step for the client and protects against a forwarded or intercepted link. For a request for last year's municipal rates account, most firms will not bother. For a request for directors' identity documents, most should. Requests like these collect personal information, and in South Africa the Protection of Personal Information Act sets the conditions for processing it lawfully.
What the client can do on the request page
On the request page, the client can upload files or whole folders and answer the questions the firm asked. Uploading a folder is more useful than it sounds: a client who has a folder called "Year-end" on their computer can send all of it in one go, rather than attaching files one at a time.
A few protections apply to what is uploaded. Executable file types are blocked. Files are limited to 100 MB each by default. Files are virus-scanned only when the server operator has configured ClamAV; otherwise structural checks run, and the record says which happened. If your firm needs to know that a file was scanned, read the record on the upload rather than assuming.
Where the uploads go
What the client sends is filed in that client's folder in the vault. The Document Centre is a vault with a folder per client and lead, where staff can also upload, keep versions, tag, archive and restore with a reason, and search.
That removes the most tedious step in the old process: nobody has to save attachments from an inbox into the right folder. The upload is already where it belongs.
Why there is no client portal
Achekam has no client sign-in or client portal account. Clients deal with the firm through the links it sends: for requests, signing, shared documents, payment and statement review. Under Clients there is a Client Portal View, but it is a staff-side preview of what a client would see, not a page the client opens.
For many practices this suits clients well. Clients do not have accounts to forget, passwords to reset or a separate site to learn. Each link does one job, and the request, sharing and signing links expire. The cost is that a client cannot log in and browse everything the firm holds for it; if a client asks for a document, the firm shares it with a link. The full set of links a client may receive is described in do clients need a login?.
Writing a request a client can actually answer
The software makes requests easy to send. Whether they get answered depends on how they are written.
- Ask for each document by its name as the client knows it: "your bank statements for every account, March to February", not "bank".
- Say why you need it, in one line. Clients prioritise requests they understand.
- Ask questions that can be answered in a sentence. Split compound questions.
- Group requests by who at the client will answer them, so the bookkeeper and the director each get their own.
- Switch on the one-time code for sensitive material.
- Set expectations about timing in the covering message, and keep the default reminders on.
What happens after the client responds, including accepting or rejecting items, reminders and delivery problems, is covered in request reminders, returns and delivery problems. Requests to third parties during an audit, such as bank confirmations, follow a separate route described in external confirmations and component auditors by link.
Where to begin
Take the year-end document list you currently send clients as an e-mail or a PDF, and rebuild it as one request in the RFI console. Send it to a few clients who are usually prompt, and see how the uploads arrive before rolling it out to everyone.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
