Multi-client document intake without a portal nobody logs into
A client portal adds a login your client will forget. Here is an intake workflow built for the way accounting firm clients actually send documents — and why client-folder isolation is the part generic tools skip.
Every accounting firm has tried the same fix for messy client document intake at least once: build a portal, ask clients to log in and upload there. Adoption is consistently disappointing, for a simple reason — the portal adds a step to a habit the client already has (email, WhatsApp, a phone photo), rather than meeting the client where they already are.
Why the portal fix does not work
A client who already snaps a photo of a receipt and forwards it, or drops a PDF into an email thread, is not going to remember a separate login for a tool they open four times a year. The fix that actually works is not a better portal — it is removing the portal from the equation and letting documents arrive through the channel the client already uses, with the firm's processing pipeline doing the organizing.
What multi-client intake actually requires, that generic tools skip
Client-folder isolation, not just document tagging
A cabinet does not process "documents" — it processes this client's documents, separately from every other client's, with separate charts of accounts, separate correction histories, and separate review queues. A tool built around a single company's books, retrofitted with a client-selector dropdown, is not the same as a tool architected around client-folder separation from the ground up. The difference shows up the moment two clients use the same supplier: a correction learned for one client's mapping of that supplier must never silently apply to the other.
A minimum client count that matches how firms actually operate
Per-seat or per-user pricing models — common in generic bookkeeping software — do not map cleanly onto a cabinet's structure, where the relevant unit is the client file, not the internal user. A pricing model built around per-folder cost, with unlimited internal users, avoids the perverse incentive to limit how many collaborators can access a shared client file.
Batch handling for the client who arrives once a quarter with everything at once
Not every client trickles documents in steadily. The "shoebox" client who sends three months of receipts in one attachment needs the same processing — extraction, checks, coding, queue — applied to a batch, not a workflow designed only for one document at a time.
What changes when intake stops requiring a login
Documents dropped into a shared channel — a messaging tool, a shared inbox, a batch upload — land directly in the firm's processing queue, already being extracted and checked by the time a collaborator opens the file. The behavioral change required of the client is zero; the change in how fast documents actually arrive is not.
The review side: a queue, not a pile
Once documents are flowing in without friction, the second failure mode appears: a pile of pre-processed documents is still a pile, and piles get postponed. A keyboard-driven review mode — approve, reject, skip, one document at a time, corrections remembered per supplier — turns the queue into something that gets cleared rather than accumulated.
Related reading
- Managing FR/UK/US clients from one practice: what actually changes per jurisdiction
- Per-folder pricing vs. per-seat: why the billing unit matters for a multi-client practice
FAQ
Does removing the portal mean giving up security or audit trail?
No — encryption at rest and in transit, per-client access scoping, and an audit trail of every action are independent of whether the client-facing collection step is a portal or a shared channel. The portal was never the source of the security guarantee; it was just friction on top of it.
How does client-folder isolation affect billing and reporting?
Cleanly, when built correctly: usage, corrections and processing history roll up per client folder, which is what a cabinet actually needs to report to a client or to allocate internal cost — a per-user model obscures this because usage does not map to the client it belongs to.
What about clients who genuinely prefer a portal?
Nothing prevents offering one as an option — the point is not banning portals, it is not requiring one as the only path, since for most clients it is the requirement itself, not the existence of the option, that suppresses adoption.