Kazakhstan Individual Income Tax Declaration — Schedule 220.05 (Loss Accounting)

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields and states the current verification claim honestly.

Current claim

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

This is a GovSchema Standard Research cycle (GOV-3558), deepening Kazakhstan's Taxes vertical by authoring the fifth of the ten disclosed companion schedules to the Individual Income Tax Declaration (kz/kgd/individual-income-tax-declaration, GOV-3477) — Form 220.05, the loss-accounting schedule the GOV-3551 cycle's own Form 220.04 boundary check had already located (image 181, "distinct Раздел. Показатели layout headed Форма 220.05").

Why this candidate

CATALOG.md's own "Genuinely open, well-sourced candidates" section disclosed six remaining companion schedules (Forms 220.05-220.10) as open backlog after the GOV-3551 cycle authored Form 220.04. Given the disclosed, pre-located Form 220.0X backlog remained open and exact, this cycle deepened it directly rather than re-scouting new ground — the same preference this registry's routine already establishes, and the same schedule series the GOV-3484/GOV-3506/GOV-3544/GOV-3551 cycles already advanced four times.

Sources examined

Primary source

• Authority: Министерство финансов Республики Казахстан (Ministry of Finance of the Republic of Kazakhstan), via the Комитет государственных доходов (State Revenue Committee, KGD) — official site confirmed at https://kgd.gov.kz.
• Document — Order of the Minister of Finance of the Republic of Kazakhstan No. 695, 12 November 2025 ("Об утверждении форм налоговой отчетности с пояснением по их составлению и Правил их представления") — the same order the parent Form 220.00 and Forms 220.01-220.04 schemas source.
  • URL (directly re-fetched this cycle, HTTP 200 via curl -k): https://adilet.zan.kz/rus/docs/V2500037390
  • Access note — a genuine live outage hit this cycle, distinct from the already-documented TLS quirk: the domain's TLS-certificate-chain quirk (already documented in the GOV-3459/GOV-3477/GOV-3484/GOV-3506/ GOV-3544/GOV-3551 cycles) remains a non-issue with curl -k. However, this cycle's live re-fetch of the image-serving path (/rus/docs/V2500037390/files/1576/49/*.jpg) consistently returned HTTP 404 for every image tried — including images already known to exist and already published (179.jpg, 184.jpg) — with a response body that is the site's own template page containing the banner "Ведутся технические работы. Для поиска НПА просим перейти по ссылке" ("Technical maintenance work is underway. To search regulatory acts please follow the link"). This was re-tried repeatedly (with plain curl -k, with a fresh cookie/session, with a browser-like User-Agent/Referer, and after several delays) over roughly 30 minutes and never recovered during this cycle's session — a transient, site-wide maintenance outage on the image endpoint, not evidence the files were moved, renumbered, or removed. (The main document HTML page itself, at the URL above, stayed up throughout and was successfully re-fetched fresh.)
  • File identity confirmed via salvaged same-day cache, not a fresh fetch this cycle: because of the live outage above, this cycle could not obtain a fresh HTTP 200 for image 181.jpg. Instead it located and reused byte-identical copies of images 178.jpg-181.jpg already fetched fresh the same calendar day by the immediately preceding GOV-3551 (authoring) and GOV-3554 (review-gate) cycles, cached at /tmp/kz22004/ and /tmp/gov3554-verify/ respectively before the outage began. Both cached copies of each file are byte-identical to each other and their sha256 hashes match the values already disclosed in kz/kgd/individual-income-tax-declaration-schedule-220-04/1.0.0/VERIFICATION.md: These hashes matching an already-published, independently-derived record from a different cycle's own fresh fetch is treated as strong corroboration of authenticity, but this cycle is explicit that it is reusing a salvaged cache, not a fresh live fetch, for the image bytes themselves — unlike every prior Form 220.0X cycle, which did fetch its own images fresh.
    • 178.jpg sha256: f5d534500479a8b5c06f0b93c1e3145b59d3ff2941513d99e8ae2b292f7c900e
    • 179.jpg sha256: daebdfc2f6dcc5a9761dc962a5d71def890f3c1e0a07e30e7bd8efd6ee1168e0
    • 180.jpg sha256: fc43618c0f84af9b4b6550b4f119c18e1bf189d70d847a25131fcd684dbea091
    • 181.jpg sha256: 4aa00e5969bfb031ffea6026b57439f6ba15f9b5ec58e486f8831781383cbe20
  • Image 181.jpg read visually at native and zoomed (3x-8x, via the sharp npm package reused from /tmp/kz22004/node_modules, cropped per section) resolution.
  • Boundary check, near end: image 181.jpg's own printed header reads, directly and unambiguously ("форма 220.05 стр. 01"): title "УЧЕТ УБЫТКОВ" (loss accounting), subtitle "(Приложение 5 к Декларации)" (Appendix 5 to the Declaration — the form's own internal numbering relative to Form 220.00, distinct from the Order's own appendix numbering discussed below). No "стр. 02" appears anywhere, and no second image was needed to complete the table — the whole schedule fits on this one page, matching the parent Form 220.00 schema's own disclosed page-count estimate ("220.05 (loss accounting) — image 181, 1 page").
  • Boundary check, far end — not independently re-confirmed by a fresh image read this cycle, due to the live outage above. This cycle could not fetch image 182.jpg (repeated attempts, same 404/maintenance response) to visually confirm it shows a distinct "Форма 220.06" layout. The far-end boundary instead rests on two sources independent of the image fetch: (1) the parent Form 220.00 schema's own disclosed estimate, which already placed Form 220.06 (controlled-foreign-company taxation) at images 182-187; and (2) the Order's own Rules text (see below), whose Глава 7 (Form 220.05's own chapter) ends cleanly with Item 33(4) and is immediately followed by Глава 8 ("Пояснение по составлению формы 220.06 – Налогообложение финансовой прибыли контролируемой иностранной компании"), with no further 220.05-related content in between. This is disclosed as a real, if lower-confidence, gap in this cycle's own verification — a future cycle authoring Form 220.06 should independently re-confirm image 182 once the site's image endpoint recovers, rather than treat this cycle's reasoning as sufficient on its own.
  • Row-count determination: the "Раздел. Показатели" table's row count was confirmed two independent ways: (1) a direct visual count of a zoomed crop of column A's row-number boxes, counting 11 distinct 4-digit boxes with a blank, box-free margin below the 11th row extending to the page's own footer barcode; (2) a pixel-luminance scan down column A's box area (a small Node script reading raw pixel data via sharp), detecting 11 evenly-pitched (~23-24px) row-top border positions, consistent with the visual count and with no further row detected in the blank margin below. Unlike Forms 220.01-220.04, this schedule has no separate printed grand-total ("ИТОГО") row — both the pixel scan and the Rules text (Item 33, which describes only columns A-D uniformly, with no total-row instruction or cross-form carry-over language) agree on this.
  • Extraction method: every column was read directly off the rendered page image at zoom. Column A ("№") is 4 boxed digits — a row-ordinal control, not applicant data, per the same established convention as Forms 220.00-220.04 (row identity expressed by field-name ordinal entry1...entry11, not a separate row-number field). Column B ("Вид убытка") is a single wide text/selector field, not boxed digits — no fixed digit count was observed, consistent with modelling it as an unconstrained string. Column C ("период возникновения") is 4 boxed digits, the same box count and visual style as the header's own taxPeriodYear field, consistent with modelling it as an integer year. Column D ("Сумма") is a boxed money field with the same трлн/млрд/млн/ тыс (trillion/billion/million/thousand) place-value group labels already established for other Form 220.0X money fields.
  • No sheet-numbering box on this page, unlike Forms 220.03-220.04 — the header (Раздел. Общая информация о налогоплательщике) contains only two numbered items (1: ИИН; 2: Налоговый период... год), matching the Rules text's own Item 32, which likewise describes only these two header lines for this schedule. No currentSheetNumber field is modelled for this schema.

Secondary source — the Order's own Rules text

• This cycle fetched and read the Order's own full HTML page text (https://adilet.zan.kz/rus/docs/V2500037390) and found Глава 7. Пояснение по составлению формы 220.05 – Учет убытков (Items 31-33) — the Ministry's own line-by-line instructions for this exact schedule, immediately following Item 30's closing carry-over instructions for Form 220.04 and immediately preceding Глава 8 (Form 220.06).
  • Item 31 states the schedule's purpose: "Приложение 'Учет убытков' (форма 220.05) предназначено для отражения информации по учету убытков." (intended to reflect information on loss accounting).
  • Item 32 describes the taxpayer-information header: row 1 is the IIN (with the same trust-manager substitution rule already established for the parent form and sibling schedules — if a trust manager performs the tax obligation, this line shows the trust manager's own IIN instead); row 2 is the tax period.
  • Item 33 describes the "Показатели" table, column by column: (1) column A is the row's sequential number; (2) column B is "вид убытка, предусмотренный главой 35 Налогового кодекса" (a type of loss provided for in Chapter 35 of the Tax Code) — an external statutory reference, not enumerated inline anywhere in this Order's own text, unlike Form 220.04's income-type legend (Item 54(2)), which was fully inline. This cycle deliberately did not attempt to reconstruct or fabricate Chapter 35's own list of loss-type categories — that chapter's own text was not part of the source examined this cycle, and is disclosed as unverified rather than guessed at. Column B is therefore modelled as a plain, unconstrained string, per this registry's established discipline for undocumented external classifiers — a discipline this cycle deliberately leaned on rather than repeat the immediately preceding GOV-3551/GOV-3554 cycle's own experience of an over-eager, initially-mis-cited enum. (3) column C is the tax period in which the loss subject to carryforward arose. (4) column D is the amount of the loss being carried forward. No total-row or cross-form carry-over instruction is given for this schedule, unlike Forms 220.01-220.04.

Appendix-number citation — a discrepancy found in three already-merged sibling schemas

• While independently verifying this schedule's own source.documentRef, this cycle re-derived the Order's own enacting clause (the opening "ПРИКАЗЫВАЮ: 1. Утвердить: ..." numbered list, which assigns one Приложение number to each of the ~20+ tax-form/rules bundles this single Order approves) and cross-checked it against the HTML content stream's own "Приложение N к приказу ... № 695" headers.
  • The enacting clause's own Item 9 reads: "форму декларации по индивидуальному подоходному налогу (форма 220.00) с пояснением по ее составлению согласно приложению 9 к настоящему приказу" — i.e. Приложение 9 = Form 220.00, with its explanation (which, per the schedule's own structure, includes all ten of its companion schedules 220.01-220.10 as sub-parts of the same declaration package — there is no separate enacting-clause item for any individual 220.0X schedule).
  • The HTML content stream's own "Приложение 9 к приказу ... № 695" header appears exactly once in the entire ~2.66 MB document, and immediately precedes the entire scanned-image bundle spanning Form 220.00 through Form 220.10 (images 170-194 inclusive) — confirmed by checking that every image in this range (170, 171, ..., 184, etc.) has this single header, and no other, as its nearest preceding "Приложение N" occurrence.
  • This matches and corroborates kz/kgd/individual-income-tax-declaration's own existing documentRef ("Приложение 9 ... — форма 220.00") and kz/kgd/individual-income-tax-declaration-schedule-220-01's own existing documentRef ("Приложение 9 ... — форма 220.01") — both already correct.
  • However, the merged schemas for Forms 220.02, 220.03, and 220.04 each cite a different, sequentially-incremented appendix number instead (documentRef values "Приложение 10", "Приложение 11", and "Приложение 12" respectively). This cycle's re-derivation could not confirm any of those three as contiguous with those schedules' own images: the enacting clause's own Item 10 names Приложение 10 as Form 250.00 (декларация об активах и обязательствах физического лица — an individual assets/liabilities declaration, unrelated to Form 220.02); Item 11 names Приложение 11 as Form 270.00; Item 12 names Приложение 12 as Form 300.00 (VAT declaration) — three entirely different forms, each appearing much later in the document (positions 837718, 882022, and 997839 respectively in the raw HTML), well after the entire 220-series image bundle (which ends at image 194, long before those positions) has already concluded.
  • This looks like a same-shape "next sequential Приложение N" citation error — the same general class of mistake the GOV-3554 review gate already caught once this week for a legend Item number, but here for the documentRef field instead, and carried through three already -merged PRs (#583 for 220.02, #588 for 220.03, #589 for 220.04) without being caught by any review gate so far.
  • This cycle's own schema cites the re-derived, cross-checked "Приложение 9" (matching Form 220.00/220.01's own correct citations) rather than continuing the increment-by-one pattern that would suggest "Приложение 13". This discrepancy is flagged here explicitly for independent review — this cycle does not attempt to fix the three already-merged sibling schemas' citations, only to avoid repeating the same mistake in its own new document.

Form convention confirmed

• No grand-total row — a genuine structural difference from Forms 220.01-220.04, confirmed by both the pixel scan and the Rules text (see above).
• No sheet-numbering box — a genuine structural difference from Forms 220.03-220.04, likewise confirmed by both the image and the Rules text.
• Column A ("№", 4 boxed digits) is a row-ordinal control, not applicant data, per the same established convention as Forms 220.00-220.04.

Scope and disclosed boundaries

This schema is deliberately scoped to Form 220.05 in full — its single page, the taxpayer-identification header, and all 11 individual loss-entry rows (each with loss type, the tax period the loss arose in, and the carried-forward amount). Explicitly out of scope, and disclosed rather than silently omitted:

• The five other remaining companion schedules (Forms 220.06 through 220.10) remain open, disclosed backlog for future companion schemas — see the parent Form 220.00 schema's own VERIFICATION.md for each remaining schedule's page count and subject matter.
• Chapter 35 of the Tax Code's own list of loss-type categories. Column B (entryNLossType) references this chapter by number only; its own text was not examined this cycle and is not reproduced or guessed at. Modelled as an unconstrained string, not an enum.
• The trustee-filing substitution rule (Item 32: if a trust manager performs the tax obligation, line 1 shows the trust manager's own IIN) is disclosed in the iin field's description but not separately modelled — the field itself is unchanged either way.
• Far-end boundary re-confirmation (image 182, Form 220.06) was not independently re-derived this cycle due to the live image-endpoint outage — see "Boundary check, far end" above. A future GOV-3558+1 cycle authoring Form 220.06 should re-confirm this fresh.

Conformance fixtures

12 fixtures are committed under conformance/kz/kgd/individual-income-tax-declaration-schedule-220-05/1.0.0/: 2 valid submissions (one with only the two required header fields populated; one fuller filing populating three individual loss-entry rows across loss type, period, and amount) and 10 mutation-control fixtures (each expected to raise exactly 1 error): a missing required iin, a missing required taxPeriodYear, an invalid iin pattern (wrong digit count), an invalid taxPeriodYear type (string instead of integer), an invalid entry1LossPeriodYear type (string instead of integer), an invalid entry1LossAmount type (string instead of number), a negative entry1LossAmount (violating the minimum: 0 constraint), an invalid entry1LossType type (number instead of string), a wrong-type iin (number instead of string), and an unknown field not defined anywhere in this schema. All 12 were checked with a from-scratch, throwaway Node mock validator implementing this schema's own required/validation rules (not committed, per this registry's established per-cycle practice). Both tools/validate.mjs and tools/validate-ajv.mjs pass with this schema added — see the PR description for the exact pass count.

Known gaps

• Forms 220.06 through 220.10 remain open backlog for future companion schemas — see the parent Form 220.00 schema's own VERIFICATION.md for each remaining schedule's page count and subject matter.
• The far-end boundary against Form 220.06 (image 182) was not independently re-confirmed this cycle by a fresh image read, due to a live site outage — see above.
• Chapter 35 of the Tax Code's own loss-type categories were not examined this cycle; entryNLossType remains an unconstrained string.
• The Приложение-9-vs-10/11/12 documentRef discrepancy in the already-merged Forms 220.02/220.03/220.04 schemas was found and flagged this cycle but not corrected — that would require separate follow-up issues against those already-published documents.
• Kazakhstan's remaining verticals — DMV, Passport, Visa, and National ID — remain re-confirmed weak/gated per the GOV-3459 cycle (Visa: reCAPTCHA; DMV/Passport/National ID: login+EDS-gated egov.kz); not re-screened this cycle.

Verification method assessment

manual-source-review-v1 — a human/agent read the primary source directly (as a scanned page image, salvaged from a same-day cache due to a live site outage rather than fetched fresh, plus this cycle's own fresh read of the Order's HTML Rules text) and transcribed its fields. No automated re-verification tooling exists yet for this schema; nextReviewBy is set 6 months out per the practice's default cadence.