A firm implementing audit software should sequence the work in four stages: migrate existing working paper data deliberately rather than all at once, configure the methodology to match how the firm actually works before anyone's live deadline depends on it, run one real pilot engagement end to end before a firm-wide switch, and train staff with time built in for the friction a new system always creates on its first few files. Skipping the pilot to save a season is the single most common cause of a rollout that staff come to resent.
Before anything: decide what moves and what doesn't
Not every existing working paper needs to migrate into the new system on day one. Decide explicitly which prior-year files move, which stay as Excel archives referenced but not re-entered, and which engagements are too close to their deadline to be a safe first candidate for a new tool.
- Prior-year balances and permanent file information that next year's engagement will need: migrate these.
- Historical working papers for closed years, kept only for retention requirements: archive as-is, do not re-key.
- Any engagement within a few weeks of its reporting deadline: run it on the existing process. A new tool belongs on a file with room to absorb a slow week.
Stage 1: data migration
The riskiest part of migration is not moving the data, it is trusting a migration that silently dropped or mangled something. Excel-based working papers rarely have a single consistent structure across engagements, which means an automated migration has to be checked, not assumed.
- 01Pick a small number of representative files firstOne simple engagement, one with unusual formatting, one with a large number of schedules. A migration that handles all three cleanly is a reasonable basis for trusting it on the rest.
- 02Reconcile totals after migration, not just row countsA migration that moved every row but dropped a formula-driven column will show the right row count and the wrong figures. Check control totals against the source file.
- 03Keep the original files untouched and accessibleDo not delete or overwrite source Excel files until at least one full review cycle has confirmed the migrated version is complete and correct.
- 04Document who checked what migrated and whenIf a figure in a migrated file is later questioned, there should be a record of who verified the migration, not just that it happened.
A bulk migration run over a weekend with no plan to spot-check it is a common point of failure. The problem rarely shows up at migration time. It shows up months later, as a figure that does not match what anyone remembers from the prior year, with no way to tell whether the error is in the new file or was always in the old one.
Stage 2: methodology configuration
Audit software encodes a methodology — risk assessment structure, sections, sign-off levels, standard procedures — and that structure has to reflect how the firm actually works, not the vendor's default template. Configuring this after staff have started using the system on live files means changing the ground under an engagement that is already running.
| Area | What to decide |
|---|---|
| Sign-off and review levels | Who signs what, and whether the system's default review chain matches the firm's actual review structure |
| Standard procedures and checklists | Which of the vendor's defaults the firm keeps, drops, or edits to match its own documentation standards |
| Materiality and risk framework | Whether the system's built-in approach matches the firm's methodology or needs to be adapted |
| Access and confidentiality settings | Who can see which engagements, and whether access is scoped by client or by role |
Stage 3: the pilot engagement
Pick one real engagement, run it fully on the new system from planning to sign-off, and treat the choice of which engagement deliberately. Too small, and the pilot will not surface the problems a complex file would. Too large or too close to deadline, and a rollout problem becomes a client-facing problem.
- A mid-sized recurring client the team knows well, so unfamiliar software is the only new variable.
- An engagement with enough runway before its deadline to absorb a slower-than-usual first pass.
- A team willing to flag friction honestly rather than work around it quietly to hit the deadline.
Common practice, not a requirement
Firms that skip the pilot and roll out firm-wide at the start of a busy season usually do so to save the time a pilot would cost. In practice this trades a bounded, contained cost for an uncontained one: every engagement team hits the same unresolved configuration problems simultaneously, during the period the firm can least afford it.
Stage 4: training and the friction that follows
Staff who are fast in Excel will be visibly slower on a new system for the first several files, and this is normal rather than a sign the rollout has failed. Budget for it rather than being surprised by it.
- 01Train on the firm's configured methodology, not the vendor's generic walkthroughA generic demo does not show staff the sign-off chain or checklist structure they will actually use.
- 02Identify one or two staff per team as the first point of contact for questionsRouting questions through a few people who learn the system deeply is faster than everyone escalating to the vendor individually.
- 03Set the expectation explicitly that the first few engagements will run slowerA team expecting the new system to immediately save time will read early friction as a failed decision rather than a normal cost of switching.
How we think about this
An implementation succeeds or fails on sequencing more than on the software itself. The firms that do well treat migration, configuration, the pilot and training as four separate decisions made in order, each checked before the next begins. Lekhya's onboarding is built around exactly that sequence — migrate what matters, configure before anyone's deadline depends on the defaults, pilot on one real file, then expand — because a rollout that skips a step tends to pay for it later, at a worse time.
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
- Technology, data & AI in auditMigrating from Excel working papers to audit softwareWhat a firm actually gains and loses leaving Excel, the version chaos Excel creates across a review chain, and a realistic first-engagement timeline.
- Technology, data & AI in auditChoosing an audit automation vendor: a checklistThe questions that separate a vendor worth trusting with client data from one that merely demos well: security, what's computed versus generated, exit terms, pricing, and India-specific fit.
- Technology, data & AI in auditAudit software ROI for small CA firms: how to think about itA worksheet a firm fills in with its own numbers: hours on repetitive matching, the value of partner time, and what that adds up to before and after.
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.