Client onboarding for accounting firms, automated

What does the onboarding sequence actually look like?

Five steps, each triggered by the completion of the one before it. It starts when a person confirms scope, fee basis and risk profile, which is a decision rather than a step to automate. Most practices take weeks because every handover in the middle waits for someone to remember.

1. Engagement letter goes out. Generated from a template with the scope and fee inserted, sent for electronic signature, tracked.
2. Verification pack collected. Identity and entity documents requested through a secure upload, reminders automatic, arrival logged.
3. Access arranged. Software access, agent or authority arrangements, and internal file setup begin the moment the letter is signed.
4. Document request issued and chased. A checklist tailored to the entity type and service, with scheduled reminders and a status the client can see.
5. First-meeting brief assembled. A single page pulling together what arrived, what is outstanding, what looks unusual, and the questions worth asking.

Nobody has to remember anything in the middle. The human moments are the yes at the front, the risk judgement, and the review of the brief at the end.

Where should the engagement letter fit?

First, and it should generate itself from the fields already captured during the proposal. Everything downstream keys off the signature event, so nothing else should start until it exists.

Your template holds the fixed clauses. The variable parts are scope, fee, entity details, service period and responsible partner, and those come from the record created when the enquiry arrived. If you are retyping client details into a letter, fix your intake first.

Send it for signature through a system that emits an event when it is signed, because that event triggers the next step. A signed PDF filed by whoever noticed the email is not a reliable trigger.

Build in the chase: a reminder at day three and day seven, then an alert to the responsible partner. Unsigned engagement letters are usually forgetfulness, not reluctance.

Do not automate the scope wording. A generated paragraph that quietly includes something you did not intend to do is an expensive error, and exactly the mistake a model makes cheerfully. Templates with human-set variables, not generated prose.

How do you collect ID and verification safely?

Through a secure upload that writes into your document management system with access controls and a retention rule, never through email attachments, and with the assessment left to a person.

Verification obligations for Australian accounting practices have been changing, and what you must collect, how you assess it and how long you keep it depends on your services and circumstances. Confirm current requirements with your professional body before you design the collection. What follows is about handling the data, not about what you are required to collect.

The handling rules that hold regardless:

• Never by email. Attachments persist in mailboxes, on phones, in sent items and in backups, with no retention control and broad internal access. The most common weak point in a small practice.
• Collect the minimum. If you do not need a document, do not ask for it. Every extra field is something you have to protect for years.
• Restrict access by role. Identity documents should not be readable by everyone with a login. Set this on the folder before the first client uses it.
• Set retention on day one. A rule configured at build time actually happens. One that depends on someone deleting files in five years does not.
• Treat tax file numbers as the most sensitive field you hold. They carry their own handling expectations in Australia, and should never sit in a spreadsheet, chat message or CRM note.
• Log access. Who opened what, and when. If you ever have to answer a question about a breach, this is the record that answers it.

Automate the request, the reminders, the filing and the record. Leave the judgement about whether you are satisfied, and what to do if you are not, to a person trained to make it.

What about software access and authority arrangements?

Start it the moment the letter is signed, run it in parallel with the document request rather than after it, and keep a checklist per entity type because the steps differ.

Typical items: internal file creation, ledger or workpaper setup, access invitations to whatever accounting and lodgement software the client uses, and the agent or authority arrangements relevant to your services. Some can be triggered automatically, some need a person in a portal. The practical answer is a task list that generates itself with owners and due dates.

Two things worth building deliberately:

A dependency map. Some steps cannot start until another finishes, and a checklist that ignores that produces a list of blocked tasks. Encode the order.

A stall alert. If a step has not moved in a set number of days, someone hears about it. Onboarding rarely fails loudly; it stalls quietly while everyone assumes someone else is on it.

Keep credentials out of the automation. Access setup can be prompted, tracked and confirmed without the workflow ever holding a password.

How do you stop the document request being ignored?

Make the list specific to the client rather than generic, show them what is still outstanding, and chase on a schedule that a person does not have to remember.

Generic checklists get ignored because most of the list does not apply, and working out which parts do is work the client must do before they can start. Build the request from the entity type, the services engaged and the prior year where you have one. A second-year sole trader should see what changed, not the full annual template.

The mechanics that make the difference:

• One link to a status page showing received, outstanding and not applicable
• Reminders at intervals you set, stopping automatically when everything is in
• Partial completion accepted and acknowledged, so the client is not stuck at the start
• Each item marked received the moment it arrives, without anyone updating a list
• An escalation to the responsible person after a defined number of unanswered reminders

The escalation matters. Reminders that continue forever train clients to ignore them. After the second or third, a person should phone, because by then the silence usually means something.

How do you prep the first meeting automatically?

Assemble a one-page brief from what has already arrived, and have a person read it before the meeting rather than build it.

The brief covers entity and structure, services engaged, what arrived and what is outstanding, anything materially different from the prior year, any figure that looks out of place, and three or four questions worth asking. A model helps by reading what came back and drafting those questions. It does not help by stating anything as fact.

Keep the numbers computed and the commentary marked as draft. A line reading "revenue up 40% on last year" should be a figure your system calculated, with the model limited to noticing it and phrasing the question.

Fifteen minutes of partner reading beats an hour of partner assembling, and clients remember a first meeting where the accountant has clearly read everything.

What to do next

Time your current process before changing it: from the day a client says yes to the first productive meeting, in calendar days, for the last ten clients. Then mark where the days went. The delay usually sits in two specific handovers.

Automate the engagement letter and its chasing first: it is the trigger everything else depends on, and the least sensitive data in the sequence. Do verification collection second, with your obligations confirmed in writing first. Leave the brief until last.

Whether you build it yourself or have Shift build it in your own accounts, the two rules hold: identity data gets the strictest handling in the practice, and the risk judgement never gets automated.