We use cookies to understand which pages and tools are useful, nothing more — no ad tracking across other sites. You can change this later from the footer.

Skip to content
Lekhya.in

Guide3 min readPublished

Onboarding a new branch into multi-office administration: what has to happen and what doesn't

A practical walk-through of what actually changes administratively when a CA firm opens a second or third office in its audit software — tagging members, tagging clients — and what deliberately stays untouched.

Onboarding a new branch into multi-office administration, on Lekhya's Firm plan, is a short administrative task: create the office with a name and a short unique code, then tag the members and clients that belong to that branch. It does not require touching engagement roles, re-staffing existing work, or changing how access to any file is governed — those stay exactly as they were before the office existed.

What actually needs to happen

  1. 01Create the office recordGive the new branch a name (e.g. "Hyderabad") and a short unique code the firm will recognise in filters and lists.
  2. 02Tag the members who sit thereAssign the office to each member who is based in or primarily works out of the new branch. This is a label on their profile, not a permission change.
  3. 03Tag the clients the branch owns the relationship withRecord which clients the new office is the administrative point of contact for — again, a label for reporting, not a restriction on who can be staffed on their engagements.
  4. 04Leave existing engagements aloneEngagement teams, roles, and sign-off chains that were already set up do not need to change because a new office now exists.

What deliberately does not need to change

  • No engagement needs its team re-staffed because of the new office
  • No existing client needs re-tagging unless the firm actually wants to move its recorded relationship owner
  • No role or permission on any file changes because a member now carries an office tag
  • No separate login, workspace, or data partition is created for the new branch — it's the same firm, same engagements, same roles

Multi-office administration is available on the Firm plan. A firm on a lower plan opening a second office can still run the branch operationally — the office-tagging layer just isn't part of that plan.

Where firms get this wrong

The common mistake is treating the new office like a fresh start — re-reviewing every existing client's staffing, or assuming members need to be "moved" into the new office's access scope. There is no access scope tied to office. A member tagged to the new Hyderabad office can still be staffed on a Mumbai-office client's engagement the day the branch opens, exactly as before.

If a firm's rollout plan for a new branch includes re-checking who can see what because of the new office tag, that's a sign the plan is assuming an access boundary that doesn't exist. Skip that step — it isn't needed and isn't how the feature works.

Common practice, not a requirement

Firms that onboard a branch cleanly usually do the office and member tagging in one sitting on day one, then let client tagging happen gradually as the new office starts to own specific relationships — there's no requirement to backfill every client's office on day one.

This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.

Related resources

Free tools, no signup

Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.