As a firm opens new offices and headcount grows, the person managing access can no longer rely on personally knowing who's who — a managing partner who used to recognize every clerk by name now has staff across branches they've never met. SSO doesn't solve the multi-office administration problem by itself, but it does make the authentication half of it tractable: one identity provider, one place to add and remove people, instead of separate logins per office that nobody is tracking centrally.
What changes as offices multiply
A single-office firm has a natural check built in: the partner or senior manager overseeing access usually has direct, personal knowledge of everyone on staff. They notice if someone who left six months ago is still showing up in a user list, because they'd recognize the name as odd. That informal check disappears once a firm opens a second office, and disappears further with a third — staff in the Pune branch are not names the Mumbai partner reviewing access recognizes instantly, if at all.
At that point, access management has to become a system rather than a memory. Centralizing authentication through one identity provider is the first and easiest piece of that system to put in place, because most growing firms already have some identity provider in place for email and office tools — the SSO integration is extending something that already exists rather than building something new.
What SSO actually contributes here
- One place to see who's active across the whole firm, not per-office spreadsheets or per-office logins that drift out of sync.
- Offboarding and role changes made at the identity provider apply uniformly, regardless of which office the person is based in.
- New offices onboard faster — staff joining a newly opened branch use the same identity-provider setup as everyone else, with nothing office-specific to configure for login.
- The firm's own password and security policy — however strict or lenient — gets enforced in one place rather than negotiated per office.
Centralized authentication is not the same as centralized access control. SSO tells you who successfully logged in; it says nothing about whether that person's role and engagement memberships are correct for their actual job. A firm with three offices and SSO switched on can still have a Mumbai associate with lingering access to a Bangalore client's engagement from a project they rotated off eight months ago — that's a membership review problem, not an authentication problem.
The administration work SSO doesn't touch
Multi-office administration is really about who manages what: which partner has visibility into which office's engagements, how roles map across offices that may have slightly different internal structures, and how a firm keeps its client assignments straight as it scales past the point where one person can hold the whole picture in their head. None of that is an authentication question, and SSO has nothing to say about it. A firm still needs a deliberate process — typically a periodic access review — to keep roles and engagement memberships matched to who actually needs what, across every office.
| Question | Who/what answers it |
|---|---|
| Can this person log in at all? | The firm's identity provider, via SSO |
| Which client files can they see? | Their role and engagement memberships inside the audit tool |
| Is their access still correct for their current job? | A periodic firm-run access review, not SSO |
| Who at the firm is accountable for that review? | The firm's own governance — a partner, a quality-control lead, or a designated admin |
When the switch flips from nice-to-have to necessary
There's no fixed headcount threshold, but the pattern is consistent: once a firm has enough offices and enough staff that the person responsible for access can no longer personally vouch for every active account, centralizing authentication stops being a convenience and starts being the only realistic way to keep offboarding and onboarding consistent across locations. For most growing firms, that point arrives well before the firm feels 'big' in any other sense.
How we think about this
Lekhya's SSO is a Firm-plan feature precisely because it's aimed at firms at this stage — multi-office, higher headcount, enough turnover that memory-based access tracking has stopped working. It centralizes authentication against the firm's own identity provider; the engagement and role structure that multi-office administration actually depends on is handled separately, through Lekhya's own membership and role system.
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
- Audit workflow & automationMulti-office administration: organising a firm by branch without rebuilding access controlA firm with three branches needs to know who sits where. It doesn't need a second, parallel access-control system to find that out.
- Audit workflow & automationSingle sign-on for audit firms: why it matters more at 80 engagements than at eightBelow a certain headcount, SSO is a convenience. Above it, it's the only realistic way offboarding actually happens on the day someone leaves.
- Audit workflow & automationMulti-partner firm technology decisions: who needs to be in the roomA managing partner, an audit partner, and a quality-control partner are evaluating three different things when they look at the same software. Here's what each one actually cares about.
- Internal audit & IFCUser access review audit procedure for financial systemsA signed-off access review spreadsheet is evidence someone looked at a list. Whether access was actually removed as a result is a separate fact the audit has to test.
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.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.