Multi-office administration and single sign-on are two separate, technically unrelated Firm-plan features — one organises members and clients by branch for reporting, the other centralises how people log in through the firm's identity provider. They don't interact technically, but the same kind of firm tends to want both at once: a larger, multi-branch practice with enough headcount and enough IT structure that both administrative overhead and login governance have become worth solving properly.
Two different problems that show up at the same size of firm
A four-person single-office firm has no real staffing-report problem and no real login-governance problem — everyone is known to everyone, and a shared password habit, while not ideal, isn't a crisis. By the time a firm has three or four offices and fifty-plus staff, both problems are real: nobody can mentally track who sits where without a report, and nobody wants IT fielding password resets for forty people across four cities.
| Multi-office administration | Single sign-on |
|---|---|
| Answers "who's in which branch" for reporting | Answers "how do people prove who they are" for login |
| Tags members and clients with an office | Routes authentication through the firm's identity provider |
| Has zero effect on what anyone can access | Has zero effect on which engagements a member can see once logged in |
| Useful even for a firm with one login method | Useful even for a firm with one office |
Where they complement each other operationally
- A firm managing joiners and leavers across four branches wants both: SSO so IT can deactivate access centrally through the identity provider, and office tagging so the firm still knows which branch that person belonged to for records and reporting
- A partner reviewing branch-by-branch headcount doesn't need to separately reconcile who logged in through which method — SSO is invisible to that report, which is exactly the point
- Neither feature asks the other to do anything; they sit next to each other on the Firm plan because the firms that need one administrative layer usually need the other too
Both multi-office administration and SSO are Firm-plan features. A smaller firm on a lower plan can still operate across multiple physical branches without either — they're conveniences for scale, not requirements for having more than one office.
Don't expect SSO group mappings or identity-provider roles to set a member's office, or expect office tagging to influence login behaviour. The two systems don't read each other's configuration — each has to be set up on its own terms.
How we think about this
Lekhya keeps multi-office administration and SSO as genuinely independent features rather than bundling them into one "enterprise" switch, because a firm can legitimately need one without the other. They happen to appear together on the Firm plan because that's the tier aimed at firms large enough to need both, not because either depends on the other.
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 & automationAudit software for firms with 50+ audit staff: what changesPast roughly 50 audit staff the decision stops being about one partner's workflow and starts being about standardising dozens of them at once.
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.