# Verification record — `in/incometax/individual-tax-return-itr3` v1.0.0 This file is the **source-review record** for this document version, per the [`manual-source-review-v1`](../../../../../practices/manual-source-review-v1.md) practice. ## Current claim - **`status`:** `draft` - **`verification.method`:** `manual-source-review-v1` - **`verification.lastVerifiedAt`:** `2026-07-05` ## Why this cycle picked up ITR-3 CATALOG.md's Known Gaps list (last regenerated by GOV-1240) identifies India ITR-3 as "the sole open candidate of the ITR-1/2/3/4 set" now that ITR-1 (GOV-900), ITR-2 (GOV-1247), and ITR-4 SUGAM (GOV-1229) are all published. ITR-3 is the return for filers with income from profits and gains of business or profession who are not (or do not opt to be) taxed on a presumptive basis under sections 44AD/44ADA/44AE — i.e. filers required to maintain regular books of account under section 44AA, and where applicable obtain a tax audit under section 44AB. It is the most complex of the four ITR forms (66 worksheets vs. ITR-2's fewer sheets), reflecting the Balance Sheet, Trading Account, Profit and Loss Account, and Schedule BP computation of business income that ITR-1/2/4 do not have. ## Sources examined - **Document `(id, version)`:** `in/incometax/individual-tax-return-itr3` / `1.0.0` - **Spec version:** GovSchema `0.3.0` - **Authority:** Income Tax Department, Government of India; the ITR forms are notified annually by the Central Board of Direct Taxes (CBDT) under the Income-tax Rules, 1962. - **Primary source (field-by-field detail):** the ITR-3 **Excel utility for Assessment Year 2026-27, version 1.1** (`ITR3_AY_26-27_V1.1.zip` → `ITR3_AY_26-27_V1.1.xlsm`), fetched directly from the e-Filing portal's own Downloads page () at — **HTTP 200, no access block**, 12,295,538 bytes (≈11.7 MB), matching the size the Downloads page itself advertises. Same channel already used and recorded for ITR-1/ITR-2/ITR-4 (incometax.gov.in, not the WAF-blocked incometaxindia.gov.in gazette host). - **Retrieved / reviewed:** 2026-07-05. - **Reviewer:** GovSchema Engineering (Standards Engineer — initial authoring source review). ## Extraction technique The `.xlsm` is a standard OOXML zip archive of 66 worksheets (`PART A - General`, `Nature Of Business`, `Part A - BS`, `Manufacturing Account`, `Trading Account`, `Profit and Loss`, `Part A - OI`, `BP`, `CG`, `OS`, `VI-A`, `Part B - TI TTI`, `Verification`, and 53 others). It was extracted with Python's `zipfile` module; `xl/sharedStrings.xml` and each relevant `xl/worksheets/sheetN.xml` were parsed directly as XML with the self-closing-cell-aware regex already established for this registry's prior OOXML extractions (`]*?)(?:/>|>(.*?))`, matching self-closing empty cells and content-bearing cells as distinct alternatives — see `in/incometax/individual-tax-return-itr4-sugam` VERIFICATION.md for the original bug this fixes). Cells were keyed by sheet name and cell reference (`xl/workbook.xml` / `xl/_rels/workbook.xml.rels` map each sheet name to its worksheet file). Every field's `sourceRef` cites the specific worksheet and cell it was read from, plus the form's own line code where one exists. ## Scope decisions (what is modelled vs. deferred) ITR-3's genuine standard-value-add over the already-published ITR-1/ITR-2/ ITR-4 is its business/professional-income computation with full books of account. This document models that content in full, and the general-filing scaffolding needed for the document to be a complete, submittable return on its own, but defers full re-derivation of schedules that are structurally identical to ones already published in this registry: - **Modelled in full:** the extended general/identity, address, residency, representative-assessee, and director/partner/unlisted-shares eligibility questions (shared with ITR-2/ITR-4, re-derived against this document's own ITR-3 workbook cell references — not copied from ITR-2's citations); section 115BAC(6) current-year regime election; seventh-proviso filing eligibility; the section 44AA books-of-account and section 44AB tax-audit gates, with full auditor detail (name, membership number, firm name/ registration number/PAN, UDIN, date of audit report, acknowledgement number) — the core distinguishing content of this form; nature of business/ profession (primary activity code, trade name, description); the Balance Sheet, gated on whether regular books of account are maintained — either the full Sources-of-Funds/Application-of-Funds aggregate statement (7 required totals: proprietor's fund, loan funds, sources of funds, fixed assets, investments, net current assets, application of funds, plus 3 optional line items for deferred tax liability/advances/other application) or the four-line "No Account Case" summary (sundry debtors, sundry creditors, stock-in-trade, cash balance) for section 44AA(2) filers not maintaining regular books; the Trading Account and Profit and Loss Account aggregates (gross receipts of business, gross receipts from profession, total revenue from operations, opening/closing stock, purchases, direct expenses, gross profit transferred to P&L, other income, total credits, profit before interest/depreciation/tax, interest expense, and net profit before taxes — the taxpayer-input starting point for Schedule BP's computation); an aggregate Chapter VI-A total deduction figure; aggregate advance-tax and self-assessment-tax payments; primary bank account details for refund; and the verification block. - **Deferred (out of scope), and why:** Schedule BP's own book-to-tax adjustment lines (net profit/loss from speculative or section-35AD specified business, disallowances under sections 36/37/40/40A(3)/43B, depreciation as per the Income-tax Act vs. the books, and the final A37+B42+C48 income-chargeable computation) are the e-Filing portal's own computed/derived figures built from `netProfitBeforeTaxesPL` and are not modelled as input fields, consistent with this registry's "don't model what the source computes for the filer" principle already applied to every prior tax-return schema (gross total income, tax payable, refund, etc. are never modelled either). The Manufacturing Account, Quantitative Details, GST turnover-reconciliation schedule, Schedule 112A/115AD securities detail, Schedule AL assets-and-liabilities, and the multi-business/ multi-director/multi-partner/multi-unlisted-share/multi-bank-account per-item sub-tables behind the fields modelled here are out of scope, the same per-item-schedule-detail deferral already applied to ITR-1/ITR-2/ ITR-4. **Most significantly:** full field-by-field modelling of Schedule S (salary), House Property, Schedule CG (capital gains), OS (other sources), and the itemised (80C/80D/80G/etc.) Chapter VI-A deduction schedule is deferred — these schedules are structurally identical (same CBDT-notified layout, same field set) to the ones already published in full in `in/incometax/individual-tax-return-itr2`, which an ITR-3 filer with salary, house-property, capital-gains, or other-source income alongside business/professional income can consult for the same section structure. Re-deriving ~200+ additional field-level citations against this document's own workbook (Schedule CG alone spans 2,665 extracted cell values) for content that does not distinguish ITR-3 from ITR-2 was judged to add registry-maintenance burden without new standard-modelling value, and is left to a future version if a consumer need for it is identified. This is an explicit, one-way scope decision, not an oversight — a filer whose facts require those income heads will need to consult both documents until a future version merges or cross-references them. - **Not independently confirmed:** every field cited in Schedule BP itself (`F5`/`K5` "Profit before tax as per profit and loss account (item 53 ...)" restates the P&L's own line 53) is definitionally identical to `netProfitBeforeTaxesPL`, so no separate BP-sheet field was added for it. - **Not machine-enforced (documented only):** the form's own eligibility boundary — that ITR-3 filers must have income from business or profession and either maintain regular books or fall within section 44AA(2)'s no-account-case allowance — is expressed only via the `maintainsRegularBooksOfAccount`/`liableToMaintainAccounts44AA` eligibility fields, not as a `crossFieldValidation` rule, consistent with this registry's existing precedent for eligibility conditions that are not a clean field-absence check (GSP-0013's grammar is built around `requirePresent`/`requireAbsent`). - **No live e-Filing portal walkthrough.** Filing ITR-3 online requires a PAN-linked, OTP/Aadhaar-authenticated e-Filing account not available in this environment, so the field-by-field comparison the practice requires against the live online screens has not been completed. ## Mock-data test run Two representative scenarios were authored and checked field-by-field against every `type`/`required`/`requiredWhen`/`visibleWhen`/`enum`/ `pattern`/`minimum`/`maximum` constraint in `schema.json`, using a one-off Python condition evaluator (not committed to the repo) implementing the same `equals`/`notEquals`/`in`/`greaterThan`/`all`/`any`/`not` grammar as GSP-0013's `Condition` schema (spec v0.3 §8.1), the same evaluator already used for ITR-1/ITR-4. **Scenario 1 — Individual retail-trade filer with regular books and a section 44AB tax audit:** Anita Sharma, a Jaipur-based sole proprietor of a textile trading business (turnover Rs. 85 lakh) who maintains regular books of account, is liable for a section 44AB tax audit, and files an original return under the new tax regime. **Scenario 2 — HUF professional filer, "No Account Case," revised return filed by the Karta:** a Nagpur-based HUF professional practice not maintaining regular books of account (section 44AA(2) no-account case), filing a section 139(5) revised return via its Karta as representative assessee, opted out of the new tax regime, and filing under the seventh proviso to section 139(1) due to electricity expenditure exceeding Rs. 1 lakh. Both runs: ``` PASS — Scenario 1 - Individual retail trader, regular books maintained, tax-audited under 44AB, new regime, original return satisfies every type/required/requiredWhen/visibleWhen/enum/pattern constraint. PASS — Scenario 2 - HUF professional, no-account case (44AA(2)), revised return via Karta representative, opted out of new regime satisfies every type/required/requiredWhen/visibleWhen/enum/pattern constraint. ``` Scenario 1 correctly triggered the section 44AB audit-detail fields (date of audit report, acknowledgement number, auditor name/membership number, UDIN) and the regular-books Balance Sheet aggregates, while Scenario 2 correctly triggered the no-account-case four-line Balance Sheet summary, the representative-assessee fields (Karta capacity), the revised-return original- receipt fields, and the seventh-proviso follow-up questions — and correctly did *not* require the regular-books Balance Sheet aggregates or the audit fields, since neither condition applied to it. A deliberately-broken variant of Scenario 1 (dropping the five audit-detail fields despite `liableForAudit44AB: true`, and dropping `verificationFullName`) was also run, to confirm the evaluator itself correctly detects violations rather than passing everything by construction: ``` FAIL — Scenario 1 (deliberately broken) - sanity check: - MISSING required field 'dateOfAuditReport' - MISSING required field 'auditReportAcknowledgementNumber' - MISSING required field 'auditorName' - MISSING required field 'auditorMembershipNumber' - MISSING required field 'auditReportUDIN' - MISSING required field 'verificationFullName' ``` An earlier draft of this document also uniformly required every Balance Sheet line item whenever `maintainsRegularBooksOfAccount` was `true`, including line items (deferred tax liability, advances, "other application of funds") that are legitimately blank/zero for many filers; the mock-data run caught this over-tight `requiredWhen` scoping (both scenarios failed on it) and it was corrected to require only the seven backbone total fields, leaving the three itemised sub-lines optional. Both registry validators were run against the schema document itself and pass: ``` $ node tools/validate.mjs registry/in/incometax/individual-tax-return-itr3/1.0.0/schema.json ok registry/in/incometax/individual-tax-return-itr3/1.0.0/schema.json $ node tools/validate-ajv.mjs registry/in/incometax/individual-tax-return-itr3/1.0.0/schema.json ok registry/in/incometax/individual-tax-return-itr3/1.0.0/schema.json [v0.3] ``` Structural checks (no duplicate field names — 97 unique names across 97 fields; every `visibleWhen`/`requiredWhen` field reference resolving to a real field) were also run against the parsed document and found clean. ## Why most fields here are optional Like the other ITR schemas in this registry, `required: true` is reserved for identity, eligibility-gate, and always-applicable fields (PAN, name, date of birth, filer status, residential status, business/audit eligibility gates, filing section, representative-assessee gate, the `maintainsRegularBooksOfAccount` gate, and the verification block); the income and balance-sheet amount fields are `requiredWhen`-gated on the eligibility questions that determine whether they apply to a given filer. ## Time-versioning and the `edition` axis (flagged spec gap) Like ITR-1/ITR-2/ITR-4, ITR-3 is genuinely time-versioned (`ITR3_AY_26-27_V1.1`, form shape changing annually). Spec v0.3's `edition.scheme` enum remains **closed** to `us-tax-year`/`gb-tax-year`/ `award-year` (SPEC.md §5.7) and does not fit India's assessment-year cycle — this is the **tenth** reference schema in this registry to hit the same gap already flagged by GSP-0019 (after IE Form 11S, NZ IR3, CA T1, AU myTax, SG Form B1, DE ELSTER, FR 2042, and IN ITR-1/ITR-2/ITR-4). Published at the plain, non-edition registry path (`registry/in/incometax/individual-tax-return-itr3/1.0.0/schema.json`) as a workaround, consistent with all nine prior cases. See `spec/proposals/0019-generalize-edition-scheme-calendar-tax-year.md`. ## Scope and jurisdiction notes - Conditional requiredness/visibility is expressed with `requiredWhen`/ `visibleWhen` (GSP-0013), targeting spec v0.3, including the balance-sheet gate's mutually-exclusive `equals: true`/`equals: false` pair on `maintainsRegularBooksOfAccount`. - `discovery/catalog.json` gained a `published` candidate entry for this document (inserted after the ITR-2 entry it follows), consistent with `discovery/README.md`'s "candidate becomes a schema" workflow. The client registry index was regenerated (`npm run build-index` in `tools/govschema-client`). - India's Taxes vertical now has all four of the ITR-1/2/3/4 set authored. Corporate/business tax (SG IRAS, ZA SARS ITR14, IE corporation tax) remain the next candidates per CATALOG.md. ## Path to a `verified` claim (next step) To advance to `status: verified`, a reviewer applies `manual-source-review-v1` Procedure step 2 against the live, authenticated incometax.gov.in e-Filing "File Income Tax Return" online screens (a PAN-linked, OTP-authenticated account), confirms the exact online-screen grouping and pre-fill behavior of the sections modelled here, and records the outcome here — shipping a new schema version if discrepancies are found (VERSIONING.md §3, immutability). ## Re-verification Per the practice's Cadence, `nextReviewBy` is set to **2027-01-01** (6 months), and in any case before the AY 2027-28 edition of ITR-3 is notified, since the source content itself changes annually.