Client Portal

The client reads the paperwork before they agree to it.

A separate, invitation-only login where a client contact opens the board minutes and the written resolution themselves — not a title and a covering note. The approval records a hash of exactly what they were shown, and your own screen warns you if the pack has changed since.

Book a demo Where the documents come from

A login of its own

The portal is a separate route tree with its own guard. A client-portal user asking for a practice screen gets a 404, and a member of your staff asking for the portal gets one too. Signing in takes a client contact to their own companies, never to your workspace.

The documents, rendered to be read

Each approval still waiting for an answer carries the minutes and the resolution in full, built from the approved corporate action and the register behind it, section by section on the page.

A record of what was shown

The pack's content hash is captured at the moment approval is asked for. Before anybody applies the change to the statutory register, the pack is rebuilt and compared with it.

client record per portal login

The client id is read from the session, never the request, and compared in the same statement as the write.

SHA-256

of the documents the client saw

Recorded when the approval is requested, and re-derived before the change reaches the register.

practice screens a portal login can open

The workspace returns 404 to a client user; the portal returns 404 to staff. Neither guard relies on the other.

The login

There is no sign-up form behind this.

A portal account exists because somebody at your practice deliberately asked for one, against one named client record. It is not a role your staff can hand out: the invitation screen offers owner, admin, manager and staff, and the client role is deliberately not among them.

Provisioning is an operator step, not a self-serve one. It refuses to run without an explicit confirmation and a named database, and it checks that the client belongs to the practice being provisioned for — so one mistyped id cannot bind an external login to another firm's client.
It refuses to convert an existing account. Addresses are unique across the whole system, so re-pointing one would either hand a member of your staff an external login or move one client's representative onto another client's affairs. It stops and says so instead.
Nothing is e-mailed by the provisioning step. The credentials are handed over the way a staff password is — through a password manager, on a different channel from the address.
Access is withdrawn by disabling the user, and a disabled account is rejected at the next request rather than at the next sign-in.
Asking a client to approve something is refused outright when that client has no portal login, because a request nobody can answer leaves a corporate action waiting on a consent that will never arrive. The control is hidden and the action behind it checks again — a hidden form stops nobody.

What the client sees at the top of the page is your practice’s name, not ours. To them this is their accountant’s portal, and a client who cannot tell whose site they are on will not use it.

What the client sees

The document, not the title of the document.

An approval that shows a title, the company name and whatever covering note the practice typed — while the practice’s record stores a hash of board minutes and a written resolution as evidence of that client’s agreement — is a record of something the client had provably never been shown. A hash is evidence of what a document said. It is not evidence that anybody read it.

Every request waiting for an answer carries its documents: the board minutes, the members' written resolution, generated from the approved corporate action and the register behind it, and laid out heading by heading to be read rather than linked to.
Packs are built only for the requests still waiting, and only after the query has already scoped the rows to that client — so authorisation is settled before a single document is generated.
Where a pack cannot be built, the request still appears and says plainly that the paperwork could not be displayed, and to ask the accountant for it rather than approve something unread. An empty approval that looked complete would be worse than none.
Declining requires a reason. An unexplained refusal leaves the practice with nothing to act on, which is how a portal becomes a place work goes to die.
Alongside approvals, a client sees the companies your practice has linked to their account, and can download only the files marked as visible to them. Anything outside that set returns the same answer as something that does not exist.

One approval, end to end

Your practice asks the client to approve a corporate action that has not yet been applied.
The pack is built and its content hash stored on the request.
The client signs in, opens the documents and reads them.
They approve, or they say what needs changing.
Before the action is applied, the pack is rebuilt and compared with the hash.

Asking twice returns the request that already exists, so the client never gets two identical items and the practice never has two answers to reconcile.

What approving means

An instruction to proceed. Not a signature.

Approving in the portal records the client contact telling your practice to go ahead. It is not the execution of any document, and it does not pass a resolution. A written resolution is agreed to by an authenticated document sent to the company under section 296(1) of the Companies Act 2006; minutes are authenticated by the chair. The directors or the members still sign.

The person signed in may be neither a director nor a member — they are the contact your practice named when the login was created. So the portal says this above its own button, in the client’s own terms:

“Your accountant prepares the paperwork; nothing is recorded as agreed until you say so here. Approving tells them to go ahead. It is not a signature — the directors or members still have to sign the documents themselves — and it is not legal advice. If anything below is wrong or you are unsure, say so instead of approving.”

And the same thing is repeated on your side, beside the recorded decision, so that nobody reading the file a year later mistakes the row for the resolution having been passed.

Evidence

Consent to a document is consent to that document.

The documents are generated from the record rather than stored as a second copy, and the generator is reproducible — no clock, no randomness — so the same inputs produce the same bytes and the same hash. That is what makes the comparison worth anything: rebuilding the pack a year later either proves the client agreed to this exact document, or proves it changed.

The comparison runs on the corporate action screen — the one a reviewer reads before applying anything to the statutory register — and it has three possible answers.

The pack matches

Stated quietly, because it is the expected case: the documents in this pack are the ones the client was shown. Nothing needs doing.

The pack has changed

What they agreed to is not what the pack now says. The screen says so before the change can be applied, and tells the reviewer to send it again and get a fresh approval.

There was nothing to compare

Where the pack could not be built when approval was asked for, there is no hash — so the screen says the approval cannot be tied to this pack and to treat it as agreement in principle only. Claiming a match would be worse than admitting there is none.

Scoped by the session, not the form

Every portal read and every portal write takes the client id from the session and never from the request. A Server Action is a public endpoint, so anything submitted to it is attacker-controlled; the answer is written as a guarded update that compares practice, client, status and revision in the same statement as the change. An approval belonging to another client cannot be answered even with its id, and two open tabs cannot both answer the same request.

In the same trail as everything else

Asking, withdrawing, approving and declining each write an audit entry naming the practice, the user, the company and the corporate action — and the reason given for a decline is recorded with it, because a decline is only useful if the reason survives. Asking a client to approve something that has already been applied to the register is refused: recording their answer as consent would misrepresent it.

The documents themselves — what they assert, and what they refuse to assert — are covered on the Company Secretarial page.

Limits, stated

What the portal does not do.

Published because a practice needs this list before it buys, not after — and because two of these are the point rather than a gap.

It does not sign, and it does not pass a resolution. The approval is an instruction to your practice; the directors or members still execute the documents.
It does not let a client change anything. Their answer is a decision recorded against a request. It moves no statutory register and applies no corporate action — a person at your practice still does that, on a screen that shows them what the client saw.
It does not notify. Asking for an approval sends nothing; the request appears in the portal with a count beside it, and telling the client it is there is your practice's job, done the way you already contact them.
It does not create its own accounts. Every portal login is provisioned deliberately, one client at a time, by somebody who has to confirm which database they are writing to.
It does not tell a client what exists outside their own affairs. A request or a file beyond their scope and one that never existed return the same answer, so the portal cannot be used to find out whether something is there.

Bring us an approval you had to chase by e-mail.

Half an hour, no slides. We will set up a portal login, ask the client to approve a corporate action, show you what they read — then change the underlying record and let the warning fire in front of you.

Book a demo Contact us