Secure file sharing for accountants

Send each client one upload link per engagement, with a list of the documents you need. The client should not have to create an account, because every signup screen is a point where clients give up and email you a phone photo instead. The files should be encrypted in the client’s browser so that they are stored as ciphertext, not as readable copies sitting with a third party.

If you also need e-signatures, invoicing and a client login for the whole year, that is a practice-management portal, and it does more than an upload link. Our roundup of secure file sharing tools for accountants compares those suites vendor by vendor.

1. Write the document list before you contact the client. For a US individual return, start from the Form 1040 document checklist and delete what does not apply.

2. Create one request per client and engagement. In ShieldFive you can start from the Form 1040 template or a blank list, and set when the link expires (up to 7 days on the free plan; 30 or 90 days, or never, on Firm seats).

3. Send the link by email or message, and the PIN by a different channel, such as a text or a phone call.

4. The client opens the link on a phone or computer, sees your list, and uploads. No account, no app.

5. You get an email when files arrive. Open them in your browser, file them, and revoke the link when the engagement is done.

Email needs no setup, which is why clients default to it. The file then stays readable in the client’s sent folder, your inbox and both mail providers’ servers, with no expiry and nothing to revoke. There is no list of what is still outstanding, so chasing is manual.

A Dropbox file request takes uploads without a Dropbox account, emails you on each upload and can be closed at any time (Dropbox: create a file request). Dropbox encrypts at rest with keys it manages and says it “doesn’t offer client-side encryption” (Dropbox: how security works), so Dropbox can read what your clients upload. A Google Form upload question needs the client to sign in to a Google account (Google Forms: file upload).

Practice-management portals give each client a login and put document requests, e-signature, invoices and messages in one place. For a firm that runs its whole practice through one system, that is worth paying per user for, and ShieldFive does not replace it.

The trade-offs are client effort and key custody. Clients have to set up and remember a login, which many do once a year at best. And most portals encrypt files with keys the vendor holds, so the vendor can read them. Check the vendor’s security page for a statement that files are encrypted on the client’s device to a key only you hold. The ShareFile and SmartVault comparisons go through two of them.

Does the client need an account to send me a file? Who holds the keys to files at rest, the vendor or only my firm? Can I expire or revoke the link? Will I be told when files arrive? The guide to collecting documents from clients securely goes through each of these in detail, and the FTC Safeguards Rule guide for tax preparers covers what US rules expect. To send a finished return back to the client as well, see CPA secure file transfer in both directions.

It is for receiving documents, not for running your practice. There are no e-signatures, no invoicing and no tax-software integrations.

Chasing is light. On Firm seats (and during the trial), if you add the client’s email, ShieldFive reminds them at most twice, after about three and seven days, while required items are missing. The reminder cannot contain the upload link, because the decryption key never reaches our server, so it points the client back to the link you sent. You also get a reminder to follow up. Your firm name and logo appear on the upload page on the paid plan and during the 14-day trial. There are no recurring requests.

You need a free ShieldFive account to create requests and hold the keys; only the client skips signup. Every link needs a PIN of at least four characters.

Like any web app, we serve the JavaScript that does the encryption. The guarantee is “encrypted in the client’s browser, ciphertext at rest”, not a claim that no compromised server could ever interfere. The request security page sets out the threat model.