Bangladesh Individual Income Tax Return (Form IT-11GA, 2023 edition)

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-12
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2612. It opens Bangladesh as this registry's 46th jurisdiction, via its Taxes vertical (1 of 6), using the National Board of Revenue's (NBR) IT-11GA ("Form of Return of Income for Individual Person"), 2023 edition. Bangladesh was scouted and screened in GOV-2591's prior cycle (see that issue's own memory record): DMV (BRTA), Business Formation, Passport, and National ID were all confirmed dead ends or weak (portal-migrated, garbled-font/no-fields, or a scanned raster background with no OCR text layer behind the AcroForm fields), and IT-11GA was flagged as the strongest candidate — a clean, text-layer-only, no-login-gate PDF. This cycle independently re-verified that characterization from scratch, since no exact prior-cycle URL, hash, or page/ field count had been recorded to reproduce.

Source verification (independently re-derived, not copied from the task)

• Located this cycle via a fresh fetch of NBR's own English income-tax-forms page, https://nbr.gov.bd/form/income-tax/eng (HTTP 200 with a browser-like User-Agent; a bare curl with no User-Agent returns HTTP 403 — a WAF rule, not a dead source). That page currently lists the individual return as Individual_Return_IT-11Ga(2023)5.pdf (a second, differently-suffixed copy, ...3.pdf, also surfaced in web search but is not the one linked from NBR's own current forms page — the 5.pdf copy was treated as canonical for that reason).
• URL: https://nbr.gov.bd/uploads/form/Individual_Return_IT-11Ga(2023)5.pdf
• Fetched independently this cycle via curl (with a browser User-Agent; bare curl also 403s on the uploads host):
  • HTTP 200, Content-Type: application/pdf, Content-Length: 381696 bytes, Last-Modified: Tue, 07 Nov 2023 06:09:28 GMT.
  • sha256: 2a7f51e37ac8f6e61fd153f002b799f36ca8ced56b0013ca5ff7d1459f76f724 (computed independently via sha256sum on the freshly-downloaded file).
• Parsed with pdfjs-dist@3 (legacy build, getAnnotations({intent:'display'}), filtered to subtype === 'Widget'), installed in a scratch directory (not a repo dependency), following this registry's established PDF-extraction practice:
  • 10 pages, 0 AcroForm widgets on every page — confirming GOV-2591's prior characterization: this is a printed, numbered-line-item form with no fillable AcroForm fields, not a form to extract via widget metadata.
  • Every field below was instead extracted by reading getTextContent()'s position-sorted text rows (grouped by rounded y, sorted by x within each row) directly, confirming each printed line's own numbering, heading, and checkbox layout (independently-tickable checkbox glyphs render as empty strings in this font; their presence/absence and count per row was used to distinguish an independent multi-select checkbox row from a mutually-exclusive one — e.g. residentialStatus's two Resident/Non-resident checkboxes vs. the six independent special-benefit checkboxes) before modeling it.

Scoping decision (per GOV-2612's own explicit permission)

IT-11GA is a wide return: the 3-page main return (identification, income/tax summary, tax-payment particulars, verification) plus five annexed schedules (pages 4-6), a lifestyle-expense statement (IT-10BB, page 7), and a wealth/net-worth statement (IT-10B, pages 8-9). This v1.0.0 deliberately scopes to the general/salaried resident-individual filing pathway, modeling:

1. Page 1 — full taxpayer identification: name, National ID/passport number, TIN, circle/taxes zone, assessment year, residential status, taxpayer's legal status, the six independent special-benefit checkboxes, date of birth, spouse name/TIN, address, contact details, employer name, and the (source-fidelity-only, not-applicable-to-this-scope) business/ firm-identification fields.
2. Page 2 — the full Statement of Income and Tax (items 1-19): the in-scope incomeFromEmployment line plus the other nine income-category lines modeled as optional pass-through fields (0/absent for a pure salaried filer with no other income), the total-income aggregate, and the full tax-computation cascade (gross tax, rebate, net tax, minimum tax, tax payable, surcharges, delay interest/penalty, total amount payable).
3. Page 3 — the full Particulars of Tax Payment (items 20-26), the free-text list of documents furnished, and the verification/signature block.
4. Schedule 1, part (b) (page 4) — Income from Employment for employees other than those on a government pay scale: the general/private-sector salaried case this v1.0.0 targets. All 15 numbered items, including the header's repeated taxpayer-name/TIN identification line.

Out of scope, disclosed

• Schedule 1, part (a) (page 4, y≈753-413) — the parallel Income from Employment schedule for employees receiving salary under a government pay scale (17 numbered items: basic pay, arrear pay, special/house-rent/ medical/conveyance/festival/support-staff/leave allowances, honorarium, overtime, Bangla Noboborsho allowance, PF interest, lump grant, gratuity, others, total). Not modeled — this v1.0.0 targets the general/private- sector case (part (b)) instead, per the task's own explicit scoping permission.
• Schedule 2 (page 5) — Income from Rent (10 items: rent/annual value, advance rent, benefit value, adjusted advance rent, vacancy allowance, total rental value, 6 sub-items of allowable deduction, total admissible deduction, net income, taxpayer's share).
• Schedule 3 (page 5) — Income from Agriculture (4 items: sales/ turnover, gross profit, expenses, net profit).
• Schedule 4 (page 6) — Income from Business (16 items: sales/turnover, gross profit, expenses, bad debt, net profit, plus a summary balance sheet — cash/bank, inventory, fixed assets, other assets, total assets, opening/closing capital, drawing, liabilities, total capital & liabilities).
• Schedule 5 (page 6) — Investment Tax Credit (11 itemized investment categories: life insurance, DPS, government securities/mutual fund/ETF units, listed securities, Provident Fund Act 1925 contributions, self/employer Recognized-Provident-Fund contributions, superannuation fund, benevolent fund/group insurance, Zakat fund, others). Its own bottom-line carry-forward figure into page 2 item 13 (taxRebate) is still modeled, as an optional pass-through field, since the in-scope page-2 tax computation itself presents that line.
• IT-10BB (2023) (page 7) — Statement of Expenses Relating to Lifestyle (9 numbered expense categories: fooding/clothing, housing, personal transport, utilities, education, travel/vacation, festival, tax deducted at source on Sanchaypatra profit, and interest on personal loans, plus a total and its own verification/signature block). Per the source's own page-10 instruction (8), this statement's signature is mandatory for every individual filer regardless of asset level — not field-modeled in this v1.0.0, but disclosed as an unmodeled companion-document requirement (documents[].wealthAndLifestyleStatements) so a future cycle is not confused about its absence.
• IT-10B (2023) (pages 8-9) — Statement of Assets, Liabilities and Expenses (a net-wealth statement: sources of fund, net wealth roll-forward, personal liabilities, and a detailed particulars-of-assets section — 8 numbered top-level items with further lettered/roman-numeral sub-items for business assets, director's shareholdings, non-agricultural/agricultural property, financial assets, motor vehicles, ornaments, furniture/ electronics, other assets, and cash/bank balances, plus assets outside Bangladesh and a grand total). Per the source's page-8 preamble, mandatory for: all public servants; any individual with total assets (in/outside Bangladesh) exceeding Taka 40,00,000; any individual owning a motor vehicle, having invested in house property/apartment within a City Corporation area, owning assets outside Bangladesh, or being a shareholder-director of a company; and, per instruction (8), mandatory regardless for every individual's own signature. Not field-modeled in this v1.0.0 for the same reason as IT-10BB — disclosed via the same documents[] entry.

Field-by-field inventory and disclosed judgment calls

Page 1 (identification)

• taxpayerTin/spouseTin/declarantTin/schedule1Tin: the source prints the TIN line as three dash-separated blank segments ("TIN: ... - ... - ...") with no digit-count guide printed on the form itself (this is a printed form, not an AcroForm with per-character comb boxes). Modeled as a single 12-digit e-TIN (^[0-9]{12}$) per Bangladesh's current NBR e-TIN standard (in force since the 2013 online-registration system; the pre-2013 manual TIN was 10 digits and holders were required to re-register to the 12-digit e-TIN) — a disclosed judgment call resolving an external, official numbering-scheme fact not itself printed on this specific PDF's blank-line layout.
• businessIdentificationNumber: similarly modeled as a 13-digit BIN (^[0-9]{13}$) per the current NBR e-BIN standard, though not applicable to the general/salaried filer this v1.0.0 targets (included only for page-1 source fidelity, since the source prints this line on every IT-11GA regardless of applicability).
• Special-benefit checkboxes (isWarWoundedFreedomFighter/isFemale/ isThirdGender/isDisabledPerson/isAged65OrOlder/ isParentOfDisabledPerson): confirmed as six independently-tickable checkboxes (not a single mutually-exclusive enum) by dumping each row's raw text items — each label is followed by its own distinct checkbox glyph (rendered as an empty string by this PDF's font), unlike residentialStatus and taxpayerLegalStatus, which are also checkbox-per-option but read here as intended to be mutually exclusive given their single-answer nature ("Resident / Non-resident", "Individual / Firm / HUF / Others").
• taxpayerLegalStatus: this form is titled "FOR INDIVIDUAL PERSON" yet its own item 7 checkbox row prints all four values (Individual / Firm / Hindu Undivided Family / Others) — modeled with the full enum for source fidelity, since this v1.0.0 targets the typical "individual" value for this specific form variant.
• spouseTin: the source has no discrete boolean widget for "is your spouse a taxpayer" distinct from the TIN blank itself (item 10 reads "TIN (if spouse is a Taxpayer)"). Left optional with no requiredWhen, since encoding one would require inventing a field the source does not present — disclosed rather than silently modeled (the same pattern this registry has used before, e.g. th/rd/pit-90-personal-income-tax-return's own spousePassportNumber).
• businessOrganizationName/businessIdentificationNumber/ partnersNamesAndTins: items 13(a), 13(b), and 14 are firm/business/ partnership-specific fields not applicable to the general/salaried individual filer this v1.0.0 targets. Modeled as plain optional fields for page-1 source fidelity (the source prints these lines on every IT-11GA), consistent with how th/rd/pit-90-personal-income-tax-return modeled its own out-of-scope-adjacent businessEstablishmentName/ businessWebsite fields.

Page 2 (Statement of Income and Tax)

19 fields modeled across items 1-19. Items 2-10 (rent, agriculture, business, capital gain, financial assets, other sources, firm/AoP share, minor/spouse income, foreign income) are each carried from an out-of-scope schedule (or, for capital gain/financial assets/other sources/firm-AoP- share/minor-spouse-income/foreign-income, from no schedule this form itself annexes for those lines) — modeled as optional pass-through numeric fields, 0/absent for the general/salaried filer this v1.0.0 targets, consistent with how th/rd/pit-90-personal-income-tax-return modeled its own out-of-scope carry-forward lines (e.g. section11CarriedFromRealEstateSchedule) as optional pass-throughs rather than omitting the line entirely (every filer's tax computation still presents these lines, in-scope or not).

Disclosed non-computation: grossTaxOnTaxableIncome (item 12) is computed per Bangladesh's statutory progressive personal-income-tax bands. This schema does not itself assert or embed the current band table (which also varies by taxpayerLegalStatus/gender/senior-citizen/disability status per the special-benefit checkboxes) — the field is modeled because the source itself presents it as a line the filer/preparer completes, not because this schema computes it. The two conformance fixtures below use figures consistent with a plausible application of Bangladesh's publicly documented tax-year 2023-24 slabs, for internal fixture consistency only, not as an asserted-current legal figure encoded in the schema itself — the same disclaimer pattern th/rd/pit-90-personal-income-tax-return used for its own tax-band-dependent fields.

Disclosed absence of a printed formula: unlike item 24 (page 3, explicitly "20 + 21 + 22 + 23"), the source prints no explicit arithmetic for item 25 ("Excess Payment"). excessPayment's description discloses this is presumed to be the excess of item 24 over item 19 when positive, not an asserted computation this schema itself performs.

Page 3 (tax payment, documents list, verification)

13 fields modeled. Disclosed judgment call on the verification clause: the source prints "I ...........................................................father / husband.........................................................................................." with no further disambiguating punctuation in the extracted text layer. Modeled as declarantName (the blank before "father / husband") plus declarantFatherOrHusbandName (the blank after it), read as the declarant identifying themselves via their father's or husband's name — a common identification convention on Bangladeshi/South Asian government forms — rather than, for example, two entirely separate declarant/witness names. documentsFurnishedList is modeled as a single free-text field since the source prints only the heading with blank space beneath it, with no discrete per-document-type checkboxes (unlike, e.g., a checkbox-per-document attachment list).

Schedule 1(b) (page 4, general/salaried employment income)

17 fields modeled (2 header-identification repeats + 15 numbered items). Every widget-free printed line was read directly from its row's y-sorted text; no ambiguity encountered in this section — the part (b) column is a single, unambiguous 15-line list with one amount column (unlike part (a), which the source itself splits into separate Total/Exempted/Taxable-amount columns for the 16 government-pay-scale line items, itself a further disclosed reason this v1.0.0 chose the simpler, more common part (b) pathway as its general/salaried scope).

Conformance run

Two hand-authored valid fixtures under conformance/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0/:

• valid-single-salaried-resident-refund-due.json — a single resident individual filer with 720,000 taka of Schedule-1(b) salary income (600,000 basic pay + 120,000 allowances), no other income, a computed gross tax of 32,000 taka, no rebate, 35,000 taka already deducted at source, resulting in a small excess payment / refund position (3,000 taka).
• valid-married-female-benefit-tax-due.json — a married female taxpayer (the isFemale special-benefit checkbox ticked) with 1,600,000 taka of Schedule-1(b) salary income (basic pay, allowances, perquisites, and an employer Provident Fund contribution, less an exempted amount), a computed gross tax of 160,000 taka, a 20,000-taka investment-tax-credit rebate (Schedule 5, out of scope — modeled as the pass-through taxRebate field), tax deducted at source plus advance tax plus a final payment with the return, resulting in an exact balance-due-with-return position (no excess payment, no further amount payable beyond what is paid with the return).

Both were checked with a from-scratch Node conformance checker (check_conformance.mjs, not committed — a disposable script per this registry's own established practice) validating required/requiredWhen/ type/validation.{enum,minimum,maximum,pattern,minLength,maxLength} directly against spec/v0.3/SPEC.md's own rules:

`` $ node check_conformance.mjs schema.json \ valid-single-salaried-resident-refund-due.json \ valid-married-female-benefit-tax-due.json valid-single-salaried-resident-refund-due.json: 0 error(s) valid-married-female-benefit-tax-due.json: 0 error(s) ``

Five mutation-control fixtures, each isolated to raise exactly one error:

• mutation-control-missing-required-field.json — drops taxpayerTin (a static required: true field) from the single-filer valid fixture.
• mutation-control-invalid-enum-value.json — sets residentialStatus to "expatriate", not one of the enum's two values.
• mutation-control-invalid-tin-pattern.json — sets taxpayerTin to a 12-character all-letter string ("ABCDEFGHIJKL"), preserving length 12 so only the pattern check (not minLength/maxLength) fires.
• mutation-control-invalid-assessment-year-pattern.json — sets assessmentYear to "2026-27" (a 2-digit trailing year, not the YYYY-YYYY pattern this field requires).
• mutation-control-negative-income-amount.json — sets incomeFromEmployment to -5000, violating its minimum: 0 constraint.

This schema has no requiredWhen fields (every conditional relationship the source implies — e.g. spouse fields, refund-adjustment year — lacks a discrete boolean gate on the source itself, so each was left optional and disclosed above rather than encoded with an invented condition), so no requiredWhen-specific mutation control was needed; the five controls above exercise every other validation-keyword class this schema uses.

`` $ node check_conformance.mjs schema.json \ mutation-control-missing-required-field.json \ mutation-control-invalid-enum-value.json \ mutation-control-invalid-tin-pattern.json \ mutation-control-invalid-assessment-year-pattern.json \ mutation-control-negative-income-amount.json mutation-control-missing-required-field.json: 1 error(s) - taxpayerTin: required but missing mutation-control-invalid-enum-value.json: 1 error(s) - residentialStatus: value "expatriate" not in enum ["resident","nonResident"] mutation-control-invalid-tin-pattern.json: 1 error(s) - taxpayerTin: value "ABCDEFGHIJKL" does not match pattern ^[0-9]{12}$ mutation-control-invalid-assessment-year-pattern.json: 1 error(s) - assessmentYear: value "2026-27" does not match pattern ^[0-9]{4}-[0-9]{4}$ mutation-control-negative-income-amount.json: 1 error(s) - incomeFromEmployment: value -5000 below minimum 0 ``

All five negative controls raised exactly one error each, and neither valid scenario raised an unexpected error.

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

``` $ node tools/validate.mjs registry/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0/schema.json ok registry/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0/schema.json 1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0/schema.json ok registry/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0/schema.json [v0.3] 1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

(tools/node_modules did not have ajv present in this worktree at the start of this cycle; ran npm ci --include=dev inside tools/ first, per this registry's own known NODE_ENV=production gotcha.)

node tools/verify-sources.mjs registry/bd/nbr/individual-income-tax-return-form-it-11ga/1.0.0 was run clean immediately before opening this PR (1 directory, 4 URLs checked, 0 warnings, 0 allowlisted). The full registry (all 392 schema.json documents, including this one) was also re-validated with tools/validate.mjs and confirmed to pass, to check this PR did not regress any other document.

tools/govschema-client/registry-index.json was regenerated via npm run build-index inside tools/govschema-client/ (392 entries, up from 391 before this cycle).

Scope and jurisdiction notes

• Opens Bangladesh as this registry's 46th jurisdiction, via its Taxes vertical (1 of 6). jurisdiction.level is national — the National Board of Revenue is Bangladesh's national tax authority.
• No edition member: GovSchema v0.3's edition.scheme vocabulary is closed to us-tax-year/gb-tax-year/award-year (§5.7), none of which fit a Bangladesh assessment year. Consistent with ke/kra/it1-individual-resident-return and th/rd/pit-90-personal-income-tax-return's own precedent (also annual returns with no edition member), the assessment-year identity is instead modeled via a plain assessmentYear field and disclosed in source.documentRef.
• process.type is filing; process.language is en — this specific PDF edition (fetched from NBR's own /eng forms page) is entirely in English; a separate Bengali-language edition of the same return also exists on NBR's Bengali-language portal but was not the source used here.
• documents[] carries the printed verification/certification statement (attestation), a salary-statement supporting-evidence requirement tied to the in-scope Schedule 1(b) income (supporting-evidence), and an unmodeled-companion-document disclosure for the mandatory IT-10B/IT-10BB statements (supporting-evidence, required: false since no boolean field in this schema gates its actual applicability thresholds).
• Companion-schedule/statement candidates for a future cycle, in priority order: Schedule 5 (Investment Tax Credit — likely the single highest- incidence companion for a salaried filer claiming a rebate), the IT-10B wealth statement and IT-10BB lifestyle-expense statement (both effectively mandatory per the source's own instructions), Schedule 1(a) (government-pay-scale employees), then Schedules 2-4 (rent, agriculture, business) by expected filer incidence.
• Bangladesh's other four verticals (DMV/BRTA, Business Formation, Passport, National ID) were screened in GOV-2591's prior cycle and found weak/dead-end: BRTA's vehicle-registration AcroForm fields sit over a scanned raster background with no OCR text layer (field labels not machine-extractable); Business Formation, Passport, and National ID were each portal-migrated or garbled-font/no-fields. This cycle did not re-screen those four verticals; a future cycle re-confirming them before writing them off entirely would be prudent, per this registry's own "dead-end reversals need an independent search too" lesson (GOV-2516/GOV-2517).

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-12 (6 months). A future review should prioritize: (1) independently confirming Bangladesh's currently legislated personal income tax bands/thresholds (which vary by taxpayer category and the special-benefit checkboxes this schema models), since this schema's conformance fixtures use a plausible application of the publicly documented tax-year 2023-24 band structure for internal consistency only, not as an asserted-current legal figure encoded in the schema itself; (2) Schedule 5 (Investment Tax Credit) as the strongest companion-schedule candidate, since it has its own dedicated carry-forward line (taxRebate) already modeled on the main return; (3) the IT-10B/IT-10BB companion statements, given their near-universal mandatory applicability per the source's own instructions; and (4) re-screening Bangladesh's other four verticals before treating GOV-2591's prior dead-end findings as permanent.