Client portal for accounting firms: a request workflow you can test before you buy

01What should a client portal for an accounting firm do?

A client portal is where your firm asks clients for documents and answers, receives them and keeps the record. Many portals offer secure upload, messaging, reminders and a branded login. Those features matter, but they are not the point. The point is that every request reaches a clear outcome, and anyone in the firm can see where it stands.

So judge a portal by the workflow it supports. Can a request name the company, period and document? Does the portal show what is still missing? Does a client's answer stay beside the item it concerns? Can you limit each person to the companies and engagements they work on? Is there a record of who requested, uploaded, changed and closed each item? The table compares three common routes. Every 'yes' in the portal column depends on how it is set up: a portal with no request structure behaves like a shared folder with a logo.

02How do you write a document request a client can act on?

Start with the purpose: a monthly close, an audit area, a payroll change or a tax return. A request such as 'send the bank records' leaves too much open. Name the company, the account, the period and the document type. Say whether you need a statement, a transaction export or an explanation, and in what format. Add a due date and the person in your firm who owns the next step.

Make one item per document. If you need three statements, set up three items. Each can then be received, reviewed and closed on its own, and the client can see what they have already sent without rereading a thread. Keep the wording short enough to act on from a phone. If a request needs a paragraph of explanation, it is probably two requests.

• Company and, where it matters, the account or area.
• Period covered, with start and end dates.
• Document type and an acceptable format, for example the bank's PDF statement or a CSV export.
• Why you need it, in one line the client understands.
• Due date and the staff owner who acts next.

03Why keep received and reviewed as separate states?

A file arriving does not prove that it covers the right period or answers the question. A file arriving is the start of the work, not the end of the request. Use distinct states, and agree what each one means before rollout. Adapt the names to your firm. What matters is that every state has a rule for moving on. The table at the end of this section sets out one workable set.

Checking what arrives takes real time. ICAEW's July 2026 report on analytics in external audit, based on interviews across the UK audit market, found that validating client data is still one of the most time-consuming and technically challenging parts of the analytics process. A portal cannot validate data for you. It can stop an unchecked file from looking finished.

For audit work there is a standards reason too. ISA 500 requires the auditor to consider the relevance and reliability of information to be used as audit evidence (paragraph 7). When the information is produced by the entity, the auditor evaluates whether it is reliable enough, including its accuracy and completeness (paragraph 9). In Malta, S.L. 281.02 defines compliance with generally accepted auditing standards as adherence to the IAASB's standards, insofar as they are relevant to the statutory audit. The IAASB published proposed revisions to ISA 500 in August 2026, with comments due by 15 December 2026. They are proposals, not a final standard.

04What happens after the client replies?

When an invoice or a payment needs explaining, attach the question to that item and say who should answer. Make the next action specific: confirm the business purpose, upload the invoice, or explain the difference. A message saying 'the books need attention' hands the diagnosis to the client.

When the answer arrives, the item goes back to its staff owner. A reply does not mean the accounting treatment is accepted. The owner reads it, decides and records the outcome on the item. This handoff matters most when several people work on the same company, because the person who asked may not be the person who reviews.

05Who owns each request, and how do you test access?

Agree who creates requests, who receives notifications, who follows up and who may close each item. Give the client one route for questions, and name the staff owner inside the firm. Arrange cover for leave and busy periods, so no request depends on one person's inbox.

Then test access with sample users and fictional data. The UK National Cyber Security Centre's cloud security principles (version 2.1, reviewed June 2023) give a useful frame for the questions. They apply to software-as-a-service as well as cloud platforms. They expect a provider to give you tools to manage who can do what (principle 9), to limit access to authenticated identities (principle 10) and to give you audit information about what happened and when (principle 13). They are UK guidance, not Maltese law, but the questions apply to any portal.

• A client contact with two companies sees both, and nothing else.
• An employee assigned to one engagement cannot open another client's file.
• A reviewer can see several files and the full history of each item.
• Removing a client contact or a leaver ends their access, and you can see that it did.
• The activity history shows who requested, uploaded, changed and closed an item, and when.

06What should you ask a portal supplier about client data?

A portal holds bank statements, payslips, identity documents and tax records, and much of that is personal data. The GDPR has applied since 25 May 2018. It defines the controller as the person or body that determines the purposes and means of processing personal data, and a processor as one that processes personal data on the controller's behalf (Article 4(7) and (8)). Which role your firm and the portal supplier each have depends on the facts of each service, so confirm it for your own setup.

Article 32 asks both controller and processor for security appropriate to the risk. Its examples include encryption, keeping systems confidential, intact, available and resilient, restoring access after an incident, and regularly testing the measures. A 'GDPR compliant' badge on a website settles none of this. Ask any portal supplier for its list of sub-processors, where the data is stored, how a restore works and how security is tested, and record the answers. The NCSC draws the same line: its principles help you choose a provider, but you still have to configure the service securely yourself.

Where your firm is the controller and the supplier processes personal data on its behalf, ask for the contract. Article 28(1) says a controller may use only processors that give sufficient guarantees of appropriate technical and organisational measures. Article 28(3) requires a contract, or another binding legal act, which must cover, among other points:

• processing only on your documented instructions;
• confidentiality from the people who handle the data, by their commitment or a statutory duty;
• the security measures that Article 32 requires;
• using sub-processors only with your prior written authorisation;
• deleting or returning the data at the end of the service, at your choice;
• making available the information needed to show compliance, and allowing audits and inspections.

07How do you know the portal workflow is working?

Run a small pilot before you move every client. Pick a few clients, one common request and one awkward case. Agree the measures before you start, so a quiet month is not mistaken for success.

Look for repeated causes, not for clients to blame. If most clarifications come from one request wording, fix the template. Timing depends on the task, the client's records and your staffing, so compare like with like. The tracker below turns the rollout decisions into a plan with an owner and a date for each. It records what you tell it. It does not test any software or assess security.

• Requests that were clear on first receipt, with no clarification needed.
• Clarifications per request, grouped by cause: wrong period, wrong document, missing explanation.
• How long an item waits between a client's reply and a staff review.
• Items closed with the outcome recorded, not just a status change.
• Requests that still went by email, and why.

08How do you walk through your own request in a Vacei demo?

Vacei describes itself as the operating system for accounting and audit firms. Its homepage describes a client portal for requests, documents and live figures, in your firm's brand, on the web and on the client's phone. The portal carries your logo, colours and domain, with a small 'Powered by Vacei' mark. For audits, the homepage says requests go to the client portal, new evidence is filed into the audit file and re-tested, and the auditor reviews every working paper and signs. Its outsourced audit page says audit requests go out under your firm's name and each answer lands in the file.

Those are the supplier's own descriptions. Use a firm demo to see them against your own workflow. Vacei says it shows the demo on sample data, and its homepage links to a sample client portal with fictional data. Bring one common request and one awkward case, such as the half-month bank statement above, described rather than sent as client records. Ask to see the request as the client sees it on a phone, where the answer lands, and where review and sign-off happen.

Then write down what your firm still has to decide itself, whichever portal it uses: request wording, states, owners, reminders and access rules. Those decisions are yours, and the rollout tracker above keeps them in one plan.