India Individual/HUF/Firm Income Tax Return (ITR-4 SUGAM, Assessment Year 2026-27)

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-05

Why this cycle picked up ITR-4 SUGAM

This is a direct follow-up to GOV-1224's research, tracked as GOV-1229. GOV-1224 found that in/incometax/individual-tax-return-itr1-sahaj (GOV-900) only covers ITR-1 SAHAJ filers (salary/pension, no business income), leaving ITR-2, ITR-3, and ITR-4 as an open gap for India's Taxes vertical. ITR-4 (SUGAM) was picked first of that set because it is closest in filer profile and form shape to ITR-1 — both are simplified, single-schedule returns for filers under the Rs. 50 lakh total-income ceiling — giving the highest reuse of ITR-1's already-published general-information, deduction, taxes-paid, bank-details, and verification scaffolding. ITR-2 (capital gains/foreign assets, no business income) and ITR-3 (business/professional income with full books of account — the most complex of the three) remain candidate for future cycles.

Sources examined

• Document (id, version): in/incometax/individual-tax-return-itr4-sugam / 1.0.0
• Spec version: GovSchema 0.3.0
• Authority: Income Tax Department, Government of India; the ITR forms themselves 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-4 SUGAM Excel utility for Assessment Year 2026-27, version 1.1 (ITR4_AY_26-27_V1.1.zip → ITR4_AY_26-27_V1.1.xlsm), fetched directly from the e-Filing portal's own Downloads page (https://www.incometax.gov.in/iec/foportal/downloads) at https://www.incometax.gov.in/iec/foportal/sites/default/files/2026-07/ITR4_AY_26-27_V1.1.zip — HTTP 200, no access block, byte size (4.99 MB) matching the size the Downloads page itself advertises (4.76 MB, consistent within rounding). This is the same channel (incometax.gov.in, not the WAF-blocked incometaxindia.gov.in gazette host) already used and recorded for in/incometax/individual-tax-return-itr1-sahaj.
• Retrieved / reviewed: 2026-07-05.
• Reviewer: GovSchema Engineering (Standards Engineer — initial authoring source review).

Extraction technique: OOXML zip/XML parsing, with a self-closing-cell fix

The .xlsm is a standard OOXML zip archive (24 worksheets — more than ITR-1's 21 — including Income Details, HP, 44AE, Part A Gen_139(8A), Schedule EA 10(13A), Schedule 24(b), BP, TDS, TCS, IT, Part B ATI, Taxes Paid and Verification, 80D, 80G, 80DD_80U, 80GGC, 80E_80EE_80EEA_80EEB, 80C, AL, SUMMARY, Help, DB, TaxCalc). It was extracted with Python's zipfile module and its xl/sharedStrings.xml (143,701 shared strings — far larger than ITR-1's, reflecting a bigger dropdown/validation surface) and xl/worksheets/sheetN.xml files parsed directly as XML, keyed by cell reference and sheet name (xl/workbook.xml/xl/_rels/workbook.xml.rels map each sheet to its file).

A real extraction bug surfaced and was fixed during this cycle: the initial cell regex (<c r="X"[^>]*>(.*?)</c>) does not match Excel's self-closing empty-cell form (<c r="E1" s="70"/>), which this workbook uses heavily. Non-greedy matching then skipped forward past runs of self-closing cells to the next real </c>, silently misattributing later cells' content to earlier, unrelated cell references (e.g. a cell reported as holding '142294' was actually empty; the real content belonged to a cell dozens of positions later). The regex was corrected to <c r="X"([^>]*?)(?:/>|>(.*?)</c>), matching the self-closing and content-bearing forms as distinct alternatives, and every cell reference used in this document's sourceRefs was re-extracted with the corrected script and spot-checked against the sheet's own printed row/column layout. This generalizes beyond this one workbook: any future OOXML cell-scraping in this registry should use an alternation-based regex (or a real XML parser), not a single non-greedy <c>...</c> pattern, whenever the sheet may contain blank (self-closing) cells.

Scope decisions (what is modelled vs. deferred)

ITR-4 reuses ITR-1's general-information, Chapter VI-A deduction, taxes-paid, bank-details, and verification/TRP scaffolding directly (adjusted for this utility's own cell references), and adds the fields that distinguish it from ITR-1:

• Modelled in full: filer type (individual/HUF/firm) and the extended representative-assessee questions (capacity, address, PAN, Aadhaar) that ITR-1 does not ask; presumptive business income under section 44AD (turnover split and declared profit), presumptive professional income under section 44ADA (receipts split and declared profit), and presumptive goods-carriage income under section 44AE (aggregate, gated on a 1-10 vehicle count per the section's own eligibility ceiling); the "Financial Particulars of the Business" simplified balance sheet (Schedule BP lines E11-E16, E18-E24) that presumptive filers must report in place of full books of account, with the form's own five mandatory lines (sundry creditors, inventories, sundry debtors, balance with banks, cash-in-hand) marked requiredWhen the presumptive-income step applies; section 112A long-term-capital-gains reporting (sale consideration, cost of acquisition) — the narrow allowance (up to Rs. 1.25 lakh, not chargeable) that distinguishes ITR-4 from ITR-1, which permits no capital gains at all; and the two royalty deductions (80QQB, 80RRB) not present on ITR-1, relevant to ITR-4's professional (44ADA) filers.
• Deferred (out of scope), and why: consistent with this registry's existing main-form/schedule-detail precedent (see in/incometax/individual-tax-return-itr1-sahaj VERIFICATION.md), the following per-item schedule detail behind this document's aggregate fields is out of scope: Schedule BP's own up-to-three business-activity breakdown (only a single aggregate natureOfBusinessOrProfession/ businessOrProfessionCode pair is modelled); Schedule 44AE's ten-row per-vehicle table (registration number, ownership type, tonnage, holding period per vehicle — only the aggregate totalPresumptiveIncomeGoodsCarriage44AE is modelled, alongside the vehicle count, which the section's own 10-vehicle eligibility ceiling makes a genuine eligibility fact rather than schedule sub-detail); the GST turnover-reconciliation schedule (multiple GSTINs, each with its own outward-supply value); the TDS1/TDS2(i)/TDS2(ii)/TCS/advance-tax schedules' own per-employer/per-deductor/per-challan rows (same reasoning and precedent as ITR-1); Schedule HP's co-owner/tenant/section-24(b) loan-by-loan sub-detail (only the aggregate interest-on-borrowed-capital line per property is modelled, as in ITR-1); the 80D/80DD/80DDB/80G/80GGA sub-schedules' own donee-by-donee or dependent-by-dependent breakdown (aggregate only, as in ITR-1); the dividend income's own quarterly (advance-tax-interest) breakdown; and the Part A Gen_139(8A) sheet (the section 139(8A) updated-return "ITR-U" computation block) and the full multi-year Form 10-IEA regime-history sub-schedule (A23(A)/A23(B) branching across prior assessment years) — both deferred the same way ITR-1 deferred its Part B-ATI sheet, as a materially different filing posture from a normal original/revised/belated return. This document models only the current-year regime election (optsOutOfNewTaxRegime115BAC6) and its immediate Form 10-IEA filing date/acknowledgement number, not the historical audit trail of prior opt-ins/opt-outs.
• Not independently confirmed: system-computed fields (annual value, presumptive-income totals E6/E7/E8 derived from E2/E4/E5, gross total income, tax payable, cess, rebate, interest under sections 234A/234B/234C/234F, the E17/E25 balance-sheet totals, amount payable/refund) are intentionally not modelled as input fields — they are the e-Filing portal's own computed outputs, the same "don't model what the source computes for the filer" principle already applied to every prior tax-return schema in this registry, including ITR-1. presumptiveIncome44AD and presumptiveIncomeProfession44ADA are modelled as inputs (not purely computed), because the form's own text — "6% of E1a ... or the amount claimed to have been earned, whichever is higher" — makes the declared profit a genuine taxpayer input that may exceed the statutory minimum, not a pure formula output.
• Not machine-enforced (documented only): ITR-4's own eligibility requires at least one of section 44AD/44ADA/44AE presumptive income to apply (per the form's title-cell eligibility text); this document does not encode that as a crossFieldValidation rule, since GSP-0013's requirePresent/requireAbsent grammar is built around field absence, not "at least one of several booleans is true" — the same category of not-fully-machine-enforced business rule already accepted elsewhere in this registry (e.g. ITR-1's percentage-based presumptive minimums are not re-derived either).
• No live e-Filing portal walkthrough. Filing ITR-4 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), extended from the evaluator used for in/incometax/individual-tax-return-itr1-sahaj.

Scenario 1 — Individual retail-trade filer under section 44AD, plus salary and a self-occupied house: Ravi Kumar, a Pune-based individual with Rs. 18 lakh retail turnover (mostly banking-channel receipts) declaring Rs. 1.1 lakh presumptive profit under section 44AD, plus salary income and one self-occupied house property, filing an original return in the new tax regime.

Scenario 2 — Firm operating goods carriages under section 44AE, old tax regime via Form 10-IEA, revised return filed by a representative partner: Shree Transport Services, a Nagpur-based firm (other than an LLP) with 5 goods carriages declaring Rs. 4.5 lakh presumptive income under section 44AE, salary/interest paid to partners, having opted out of the new regime via Form 10-IEA, filing a section 139(5) revised return through a representative partner.

Both runs:

`` PASS — Scenario 1 - Individual, 44AD business + salary, new regime, self-occupied house property satisfies every type/required/requiredWhen/visibleWhen/enum/pattern constraint. PASS — Scenario 2 - Firm, 44AE goods carriage (5 vehicles), old regime via Form 10-IEA, revised return, representative-filed satisfies every type/required/requiredWhen/visibleWhen/enum/pattern constraint. ``

Scenario 2 correctly triggered every requiredWhen-gated follow-up specific to ITR-4 (the Form 10-IEA filing date/acknowledgement number, the original return's receipt number/date, the representative's name/email/contact/ capacity/PAN, the 44AE vehicle count and aggregate presumptive income, the firm-only salary/interest-to-partners field, and the financial-particulars mandatory lines), while Scenario 1 (new regime, original return, not representative-filed, no goods-carriage income) correctly required none of them and instead triggered the 44AD-specific fields.

A deliberately-broken variant of Scenario 1 (dropping verificationPAN and setting filingUnderSeventhProvisoOnly: true without its four gated follow-up questions) 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 'depositsExceedOneCroreInCurrentAccounts' - MISSING required field 'foreignTravelExpenditureExceedsTwoLakh' - MISSING required field 'electricityExpenditureExceedsOneLakh' - MISSING required field 'meetsOtherSeventhProvisoConditions' - MISSING required field 'verificationPAN' ``

Both registry validators were run against the schema document itself and pass:

``` $ node tools/validate.mjs registry/in/incometax/individual-tax-return-itr4-sugam/1.0.0/schema.json ok registry/in/incometax/individual-tax-return-itr4-sugam/1.0.0/schema.json

$ node tools/validate-ajv.mjs registry/in/incometax/individual-tax-return-itr4-sugam/1.0.0/schema.json ok registry/in/incometax/individual-tax-return-itr4-sugam/1.0.0/schema.json [v0.3] ```

Structural checks (no duplicate field names, every field referenced by exactly one step, every visibleWhen/requiredWhen field reference resolving to a real field, every steps[].next resolving to a real step id) were also run against the parsed document and found clean.

Why most fields here are optional

Like in/incometax/individual-tax-return-itr1-sahaj, this document's defining shape is reviewing a pre-filled return: the e-Filing portal pre-fills salary, TDS/TCS, and interest/dividend data from Form 26AS and the AIS before the filer opens the return. required: true is reserved for fields every filer supplies or confirms regardless of pre-fill: identity (PAN, name, date of birth/formation), filer type, residential status, nature of employment, primary contact/address, the filing-section selection, the representative-assessee gate, the three presumptive-income eligibility gates, the section 112A capital-gains eligibility gate, and the verification block.

Time-versioning and the edition axis (flagged spec gap)

Like ITR-1, ITR-4 is genuinely time-versioned (ITR4_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 ninth 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 SAHAJ. Published at the plain, non-edition registry path (registry/in/incometax/individual-tax-return-itr4-sugam/1.0.0/schema.json) as a workaround, consistent with all eight 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 any composition (GSP-0013 §1) for the financial-particulars step, which applies whenever any of the three presumptive-income sections (44AD, 44ADA, 44AE) is in use.
• discovery/catalog.json gained a published candidate entry for this document (inserted after the ITR-1 SAHAJ entry it extends), 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 two of the ITR-2/3/4 set authored (ITR-1 already published, ITR-4 this cycle); ITR-2 and ITR-3 remain candidate for a future cycle, per the priority order GOV-1224 recorded.

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-4 is notified, since the source content itself changes annually.

Independent review (GOV-1237) — 4 sourceRef mis-citations found and fixed pre-merge

An independent reviewer re-downloaded ITR4_AY_26-27_V1.1.zip directly from the same incometax.gov.in URL (byte-identical, 4.99 MB), re-parsed every worksheet with a from-scratch OOXML cell extractor implementing the same self-closing-cell-aware regex this document's own extraction technique describes, and cross-checked all 118 quoted-cell citations in this document's sourceRefs against the live workbook's actual cell contents. 114 matched verbatim (including the multi-line seventh-proviso/representative-assessee notes, the exact E1a/E1b/E1c/E3a-style line-code parentheticals, and the 80QQB/80RRB/80GGA cell references). Four did not, and were corrected in this version prior to merge (the document had not yet been published, so no version bump was needed per VERSIONING.md §3):

• property1Type cited cell H19 for the label "Type of house property?". H19 actually holds the dropdown's (Select) placeholder; the real label is in merged cell F19. Corrected to cite F19 as the label cell and H19 as the selection dropdown.
• property2Type — the same error, one property over: cited H60 for the label; the label is at F60, H60 is the (Select) placeholder. Corrected the same way.
• hasLongTermCapitalGains112A cited cell D18 for the label "Long Term capital gains u/s 112A not chargeable to Income-tax". D18 actually holds the line code D20(a); the label itself is in merged cell E18:I18. Corrected to cite E18 as the label and D18 as the line-code cell.
• salaryInterestPaidToPartners cited cell H68 (line E6) for the label "Salary and interest paid to the partners". H68 is actually a different line's (unrelated) computed subtotal — "Presumptive Income under section 44AD and 44AE (E2+E3)" — one row up from where the salary/interest-to- partners field actually lives. The real label is at E69, with its value cell at I69. Corrected to cite E69/I69.

All four were the same failure mode: a hand-transcribed cell reference one row or one column off from the label it was quoting, none of them traceable to the self-closing-cell extraction bug already described above (all four cells involved are content-bearing, not self-closing). After the fix, the same 118-citation cross-check run against the live workbook found zero remaining mismatches. Both node tools/validate.mjs and node tools/validate-ajv.mjs were re-run post-fix and still pass; the document's structural checks (duplicate field names, every field referenced by exactly one step, every visibleWhen/requiredWhen field reference and steps[].next resolving) were also re-run clean. tools/govschema-client/registry-index.json was independently regenerated and diffed against the committed version (zero diff), and discovery/catalog.json's new candidate entry was confirmed consistent with the published schema.