Every clause and sub-clause of Form 3CD is mapped to its title, its description and the section it answers — so nothing is a free-text box you fill from memory. You see the whole report as a grid, and where each figure came from.
The data-heavy clauses — depreciation (18), the TDS/TCS tables (34), the s.43B and due-date tests (26, 20) — are computed by rule-based engines reading your imported ledger: same input, same output, every run, so a reviewer can re-perform the working rather than trust a black box. The judgement clauses — ICDS (13/14), s.37 (21(a)), deemed dividend (36A), the GST split (44) — are not auto-concluded: the engine surfaces the candidate and the rule it would apply, and hands the position back to you. A rule engine can't know that 'Misc exp — Sharma' is a partner's personal order; it flags the line, you make the call.
The same confirmed report is produced as the e-filing JSON (CBDT codes, schema-validated against the current utility), the government-format workbook and a DOCX. One source, three renders — the JSON you upload reconciles to the workbook you review and the DOCX you file with the client.
Every pre-populated clause sits as a draft until the auditor confirms it. The engine proposes; you dispose. Nothing reaches the JSON, the workbook or the DOCX without a human sign-off behind it.
Clause 8A surfaces the s.115BAC regime position; clauses 13 and 14 surface the ICDS adjustments and the s.145A inclusive method — proposed as candidates with the section and rule applied, for you to characterise. These turn on interpretation, so the engine drafts and cites; it never concludes the adjustment for you.
The depreciation schedule is computed block-wise from the asset register and additions — rates, put-to-use dates and the WDV roll-forward — reproducibly, so clause 18 ties to the same numbers your computation uses. Genuinely mechanical: same register in, same schedule out.
Clause 20 tests employees' contributions under s.36(1)(va) against the due-date; clause 26 applies the s.43B payment-basis allowance and disallowance, including the s.43B(h) MSME timing. Date tests, computed — timing differences surfaced with the date that decides them.
Clause 21(b) under s.40(a) — including the 100% disallowance on non-resident payments where tax wasn't deducted — is computed directly from the reconciled TDS position, not re-keyed. Clause 21(a) under s.37 is different: the engine surfaces the candidate ledger lines (personal, capital or penal in nature) with the rule, but you decide which is which — it never rules a line capital-vs-revenue on your behalf.
Clause 34's TDS and TCS tables are computed from the deduction-and-collection reconciliations — section-wise deductible vs deducted vs deposited — with shortfalls and s.201(1A) late-deposit interest exposure flagged. Clause 27(a) CENVAT/ITC is carried only for clients still running legacy balances; on most current files it's a footnote, not the work.
Clause 36A drafts the deemed-dividend position under s.2(22)(e) and clause 44 the GST expenditure break-up — both as candidates for your judgement, since 2(22)(e) turns on accumulated profits and beneficial shareholding the ledger doesn't state, and clause 44 only holds where the GST data actually ties to the books. Supporting engines — Partner Remuneration u/s 40(b), Deemed Dividend u/s 2(22)(e) and s.206AB/206CCA compliance — feed the clauses they touch, with the position left to you.
Every pre-populated figure is timestamped, cites the rule it applied, and traces to the source ledger row it came from — exportable to your working-paper file and re-performable line by line, not a number that appears with no parentage.
Flags and exceptions are gated by the materiality you set under SA 320 and aggregated rather than listed paisa by paisa — items below the threshold roll up instead of flooding the queue. A junior sees only what clears the gate; the disallowances and timing gaps that matter escalate to you, so review shrinks instead of trading re-keying for triaging soft flags.
Import from Tally, Busy or Excel, with a one-time chart-of-accounts mapping so the engine knows which groups are repairs vs capital and registered vs unregistered — because no two clients' COA agree. Blank or garbled GSTINs and PANs, amended documents and multi-registration clients are rolled up per registration, and rows that don't map are parked for your review, not silently guessed. It tolerates the messy file; it doesn't pretend the mapping isn't yours to confirm.
Because the JSON, the workbook and the DOCX render from one confirmed source, a peer reviewer can tie the uploaded e-filing JSON back to the working-paper workbook and the signed report — the same figure, three places, no silent drift.
No more copying depreciation and 43B figures clause to clause by hand. The mechanical clauses arrive computed and cited; the judgement clauses arrive drafted with the rule, so only the call itself needs a person.
Open the clauses that need a decision, not all 44. Every drafted figure is traced to its ledger row and its section, so the review is confirmation, not reconstruction.
The report is defensible — each clause rule-cited, materiality-gated, and re-performable under SA 230, with the JSON, workbook and DOCX agreeing for peer review, and the judgement clauses clearly marked as yours to conclude.
