Ukraine Tax Declaration on Property Status and Income — Annex Ф1 (Investment Asset Transactions)

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-18

This is a GovSchema Standard Research cycle (GOV-3639, authoring child issue GOV-3641), deepening Ukraine's own disclosed Taxes backlog — the ten companion schedules the GOV-3531 cycle disclosed but did not model when it authored ua/dps/individual-income-tax-declaration (the main declaration sheet), of which three (Annex АП, Annex Ф4, Annex МПЗ) were already modelled by the GOV-3588, GOV-3623, and GOV-3632 cycles respectively.

Why this candidate

This cycle re-scanned CATALOG.md's own "Genuinely open, well-sourced candidates" section fresh. Kazakhstan's Form 220.0X companion-schedule series remains fully closed (GOV-3477 through GOV-3616); its own disclosed Form 250.00 lead remains unscreened and was not used again this cycle without first confirming a genuine unauthenticated source. Ukraine's own disclosed Taxes backlog (seven remaining companion schedules — ЄСВ1, ЄСВ2, ЄСВ3, КІК, Ф1, Ф2, Ф3 — to the already-published main declaration) remains the strongest immediately-actionable candidate: the source workbook is already fetched, hashed, and structurally inventoried (GOV-3531, GOV-3588, GOV-3623, GOV-3632), so no new source-discovery risk is involved.

The GOV-3632 cycle had already sized all eight then-remaining sheets fresh (XLSX.readFile + !ref/!merges count):

| Sheet | !ref | !merges | |---------|---------------|-----------| | ЄСВ 1 | A1:CA244 | 241 | | ЄСВ 2 | A1:CZ250 | 211 | | ЄСВ 3 | A1:CY226 | 131 | | КІК | A1:BO207 | 116 | | Ф 1 | A1:CT213| 101 | | Ф 2 | A1:CR183 | 278 | | Ф 3 | A1:BQ420 | 202 | | ~~МПЗ~~ | A1:DG72 | 153 (modelled GOV-3632) |

Of the seven sheets remaining after МПЗ, Ф 1 has the fewest merges (101) of any remaining sheet — fewer even than Ф 2's smaller row extent (183 rows but 278 merges, the densest of the seven). Low merge count was МПЗ's own proxy for "clean, fully bounded structure" last cycle, and re-inspecting Ф 1 directly this cycle confirmed the same holds here: a single fixed-capacity investment-asset entry (not an unbounded or even a multi-row table), a short two-section computation, and no repeating blocks of unknown size.

Sources examined

Primary source

• Authority: Державна податкова служба України (State Tax Service of Ukraine, DPS) — official site confirmed at https://tax.gov.ua.
• Document — Форма податкової декларації про майновий стан і доходи (the same combined workbook as the main declaration and all three prior annexes), approved by Order of the Ministry of Finance of Ukraine No. 859 of 2 October 2015, as amended by Order No. 119 of 26 February 2025 (the edition modelled here, effective for reporting periods from 1 January 2026), this cycle modelling its own Ф 1 sheet.
  • Cited URL (same as the parent declaration and all three prior annexes): https://tax.gov.ua/data/normativ/000/001/65107/Podatkova_deklarats_ya_pro_maynoviy_stan_dohodi_vvoditsya_v_d_yu_z_01_s_chnya_2026_roku_.xls
  • Access note: direct fetch again returns HTTP 403 to this sandbox (re-confirmed this cycle). Fetched instead via the same Wayback Machine mirror the parent declaration's and all three prior annexes' own VERIFICATION.md files cite (https://web.archive.org/web/2024/https://tax.gov.ua/data/normativ/000/001/65107/Podatkova_deklarats_ya_pro_maynoviy_stan_dohodi_vvoditsya_v_d_yu_z_01_s_chnya_2026_roku_.xls), HTTP 200 on the first attempt, no transient-500 flake.
  • File identity: 869,376 bytes, sha256:7c67f4c421a1a8fc610f9226819d223debcb56b3fd1fc3d5f75ce0247cc7f0ac — byte-identical to the hash the parent declaration's and all three prior annexes' own VERIFICATION.md files already recorded, confirming the same unchanged source file across five cycles now.
  • Extraction method: parsed with the xlsx npm package (fresh scratch install at /tmp/ua_dps_f1, not committed to this repository) via XLSX.readFile, confirming all 11 declared sheets (including Ф 1 — note the sheet name itself carries a literal space between the letter and the digit, unlike the Ф4 sheet's own name). The Ф 1 sheet (!ref = A1:CT213) was read cell-by-cell with XLSX.utils.decode_range/encode_cell (not the row-array convenience helper, which merges adjacent non-empty cells) across its full extent, and cross-referenced against the workbook's own !merges array (101 entries for this sheet) to resolve exactly which column range each header label spans.

Structure confirmed

The Ф 1 sheet's 74-row printed extent (rows 75-213 are blank print-area padding) resolves to a title/header block, a single-entry investment-asset table with its own total row, a short two-section computation, footnotes, and a signature block — no attestation sentence:

• Title block (rows 1-20): the receipt-stamp placeholder (not modelled, officer-facing), the "Додаток Ф1 до податкової декларації про майновий стан і доходи" heading, the calculation's own subtitle ("Розрахунок податкових зобов'язань з податку на доходи фізичних осіб та/або військового збору з доходів, отриманих від операцій з інвестиційними активами"), and the taxpayer identification field (rows 15-18).
• Declaration type/period header (rows 21-24): declaration type (Звітна/Звітна нова/Уточнююча — the same three-value enum as the parent declaration's and all three prior annexes' own declarationType) and reporting period. Confirmed via direct inspection of every non-empty cell in rows 21-24 that this header carries no companion "місяць" (month) column in either period box — matching Annex Ф4's and Annex МПЗ's own convention rather than Annex АП's month-bearing one.
• Розділ І — investment-asset table (rows 27-42): a table with a fixed printed capacity of exactly one entry row, unlike Annex Ф4's three-entry real-estate/movable-property tables or Annex МПЗ's four-entry land-plot table. Row "1" (the entry) spans rows 34-36 (text-wrap lines for the type/description columns) with its own data cells on row 34; row 37 is the section's own "УСЬОГО" total row, printed within the same four-row-tall row-number merge (A34:C37) but with its own distinct income/cost/result cells (confirmed cell-by-cell: D37:AD37 holds only the "УСЬОГО" label, while AE37/AR37/BD37 are separate, independently merged total cells — the same "total row overlaid on the last wrap-line of the last entry" layout this registry has now seen across all four authored UA DPS annexes). Six numbered columns: row number, asset type (footnote-coded 1-4), name/characteristics, sale income, acquisition cost, and financial result (profit (+) or loss (–)). Below the table: the carried-forward prior-period negative financial result (line 2), the overall financial result (line 3, defined by the sheet's own printed formula as the total row's own financial-result column minus line 2), and its own positive/negative split (lines 3.1/3.2, each explicitly printed "без знака" — without sign — for the negative case).
• Розділ ІІ — tax obligations (rows 44-51): PIT (line 4, defined by the sheet's own printed formula as line 3.1 × the Article 167 rate, with the Article 170.2.8 carve-out cited inline) split into the portion withheld by a tax agent (line 4.1) and the portion payable directly by the taxpayer (line 4.2, the positive value of line 4 minus line 4.1); and the same withheld/payable split for military levy (lines 5, 5.1, 5.2, the levy rate cited to point 161 of subdivision 10 of Chapter XX of the Tax Code).
• Footnotes (rows 66-70): the asset-type code list (footnote , four categories: corporate rights other than securities; exchange-traded securities/derivatives; non-exchange-traded securities/derivatives; foreign-source investment assets) and the related-non-resident/low-tax- jurisdiction arm's-length pricing rule (footnote *, citing sub-clause 39.2.1.2 of Article 39 of the Tax Code) — neither modelled as fields, consistent with this registry's established treatment of footnote/legend text as field-level description context rather than data.
• Signature block, no attestation sentence (rows 72-74): a genuine structural difference from all three prior annexes — Annex Ф4 (row 65), Annex МПЗ (row 57), and Annex АП each print an explicit accuracy- attestation sentence ("Інформація, наведена в додатку до декларації, є правильною." / "Наведена інформація є правильною.") immediately before the signature block. This cycle dumped every non-empty cell across the entire Ф 1 sheet (rows 1-213, columns A-CU) and confirmed no such sentence, or any text resembling it, exists anywhere on this sheet — only the signature-block label itself ("Фізична особа – платник податку або уповноважена особа") and the "(підпис)"/"(власне ім'я та прізвище)" captions, all officer/applicant-facing and not modelled as data. Because no attestation statement text is printed on this sheet, the documents key is omitted entirely (per the spec's own minItems: 1 constraint, which forbids an empty array when the key is present — confirmed via tools/validate-ajv.mjs) rather than fabricating an attestation entry to match the sibling annexes' own convention — a disclosed deviation, not a silent omission.

Scope and disclosed boundaries

This schema models the Ф 1 sheet in full — the single-entry investment-asset table and its total row, the header/period fields, and both Розділ І's and Розділ ІІ's own computation lines — since the sheet's own structure is already fully bounded (no unbounded repeating rows). Scoping decisions made and documented here rather than silently:

• The one entry row is the sheet's own fixed printed capacity (row 34, wrapped across rows 34-36, numbered "1" in the source itself), not an arbitrary cap chosen by this schema — the same convention already established by Annex Ф4's three-entry tables and Annex МПЗ's four-entry table, here simply at its smallest observed size (n=1) in this registry's UA DPS series so far.
• investmentAssetTotalIncomeAmount/investmentAssetTotalCostAmount/ investmentAssetTotalFinancialResult (the "УСЬОГО" row) are modelled as their own distinct fields, even though they are numerically identical to investmentAsset1IncomeAmount/investmentAsset1CostAmount/ investmentAsset1FinancialResult — the source prints the total row as its own separate merged cells with a distinct label ("УСЬОГО"), the same practice this registry's Annex МПЗ VERIFICATION.md already established for totalMinTaxObligationAmount (also numerically a carry-forward of a distinct printed box, not silently collapsed into one field).
• investmentAsset1Type is modelled as a semantic enum, not a raw numeric code, translating the sheet's own footnote-coded values (1-4) into descriptive identifiers (corporate_rights, securities_exchange_traded, securities_non_exchange_traded, foreign_source_assets) — matching this registry's established declarationType-style convention of semantic enum values over literal source codes.
• No documents attestation entry (the key is omitted entirely, not an empty array — see the spec's minItems: 1 constraint above) — see "Signature block, no attestation sentence" above. This is the first of this registry's four authored UA DPS annexes to have no documents at all; the omission is disclosed, not an oversight.
• Row/column numbers themselves are not modelled as fields. They are fixed, printed labels (№ з/п, line codes 1-6, 2, 3, 3.1, 3.2, 4-5.2), the same treatment this registry's other UA DPS annexes and the kz/kgd series both give their own fixed row/item numbers.
• investmentAsset1FinancialResult, investmentAssetTotalFinancialResult, and totalInvestmentFinancialResult carry no minimum constraint — each is explicitly definable as either a profit (+) or a loss (–) per the sheet's own column header and line 3's own label, unlike lines 3.1/3.2 (investmentProfitAmount/investmentLossAmount), which the sheet itself instructs to state "без знака" (without sign) and are therefore constrained to minimum: 0.
• Two representative crossFieldValidation rules are included (pitPayableByTaxpayer ≤ pitAmount; militaryLevyPayableByTaxpayer ≤ militaryLevyAmount, since both "payable by taxpayer" lines are defined as the positive value of (total minus withheld-by-agent), and both totals have their own minimum of 0) — consistent with Annex Ф4's and Annex МПЗ's own established practice of reserving crossFieldValidation for simple two-field comparisons, not multi-field sum formulas.
• taxpayerTaxNumberOrPassport reuses the parent declaration's own either/or free-string modelling (RNOKPP, or a religious objector's passport series/number) rather than a fixed-length numeric pattern, for the same reason the parent field and all three prior annexes' own fields do.
• No visibleWhen/requiredWhen gating is attached to any Розділ І/ІІ field. Nothing in the sheet's own source text ties the investment-asset table or the tax-obligation computation to a specific declarationType value — a qualifying taxpayer files this annex regardless of whether the parent declaration is original or corrective, so gating here would be an invented rule not supported by the source.

Not modelled, left as open backlog:

• The other six companion schedules disclosed by the parent declaration's own VERIFICATION.md (ЄСВ1, ЄСВ2, ЄСВ3, КІК, Ф2, Ф3) remain open backlog for future companion schemas.
• Kazakhstan's own unscreened Form 250.00 lead (surfaced by the GOV-3616 cycle closing the Form 220.0X series) remains unscreened this cycle too — see "Why this candidate" above.

Conformance fixtures

9 fixtures are committed under conformance/ua/dps/individual-income-tax-declaration-annex-f1/1.0.0/: 2 valid submissions (0 errors each — one minimal original-type filing with only the header fields, no investment-asset entry filled in, and one fuller corrective-type filing exercising the investment-asset entry, its total row, the prior-period-loss carryforward, the profit/loss split, and the full Розділ ІІ tax computation) and 7 mutation-control fixtures (each expected to raise exactly 1 class of error): a missing required taxpayerTaxNumberOrPassport, an invalid declarationType enum value, a missing correctedPeriodYear when declarationType is corrective, a negative investmentAsset1IncomeAmount, a wrong-type investmentAsset1Type, an unknown field rejected, and a crossFieldValidation violation (pitPayableByTaxpayer exceeding pitAmount). All 9 were checked with a from-scratch, throwaway Node mock validator implementing this schema's own required/requiredWhen/validation/crossFieldValidation rules (not committed, per this registry's established per-cycle practice). Both tools/validate.mjs and tools/validate-ajv.mjs pass across the full registry with this schema added.

Known gaps

• The other six companion schedules to ua/dps/individual-income-tax-declaration (ЄСВ1, ЄСВ2, ЄСВ3, КІК, Ф2, Ф3) remain open backlog — see "Scope and disclosed boundaries" above.
• Kazakhstan's own Form 250.00 lead (surfaced by the GOV-3616 cycle closing the Form 220.0X series) remains unscreened — a future cycle should independently confirm whether a genuine unauthenticated field-by-field source exists for it before treating it as ready to author.
• Ukraine's Passport-vertical companion schedule (the consular-mirrored PDF disclosed by the GOV-3537 cycle) and Ukraine's remaining DMV/National ID verticals (both previously found weak) were not re-screened this cycle.

Verification method assessment

manual-source-review-v1 — a human/agent read the primary source directly (the same parsed legacy .xls workbook already opened for the parent declaration and all three prior annexes, this cycle's own dedicated sheet read cell-by-cell) 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.