Hungary Individual Income Tax Return — 24SZJA

Candidate selection

GOV-4687 ("GovSchema Standard Research"). GOV-4638's parallel new-jurisdiction scouting pass (Hungary, Belgium, Tunisia) banked Hungary's strongest candidate as Taxes: "NAV's 24SZJA individual income-tax return, a genuine ~30-page blank form (711KB) plus a matching field-by-field instruction guide (2.9MB), both fetched unauthenticated from nav.gov.hu." This cycle first re-verified Belgium's own banked Visa candidate (Belgium stood at 2/6, and this routine's own standing preference is to close a vertical on an already-open jurisdiction before opening a new one) — but a field-by-field comparison against this registry's own fr/france-visas/schengen-visa-application@1.0.0 found Belgium's "national long-stay visa" PDF (cotedivoire.diplomatie.belgium.be/.../blancobelgianapplicationform-fr.pdf) is a field-for-field duplicate of the harmonized EU Schengen visa application template (Annex I to Regulation (EC) No 810/2009), the same wall this registry's own GOV-1774 precedent already hit for Poland, Spain, Portugal, and Switzerland's own national D-visa forms. Not authoring a duplicate; Belgium's Visa vertical is re-banked as a confirmed duplicate, not an open gap (see the Known Gaps update below). With no non-duplicate strong candidate left for an already-open jurisdiction this cycle, this cycle opens Hungary as a new jurisdiction instead, using GOV-4638's own STRONG, uncaveated Taxes finding.

Reaching the live source

https://nav.gov.hu/pfile/file?path=/nyomtatvanyok/letoltesek/nyomtatvanykitolto_programok/nyomtatvanykitolto_programok_nav/24szja/24szja-nyomtatvanykep

• Located via NAV's own download page for form 24SZJA, nav.gov.hu/nyomtatvanyok/letoltesek/nyomtatvanykitolto_programok/nyomtatvanykitolto_programok_nav/24szja, which links the blank/printable form ("24SZJA nyomtatványkép"), its completion guide ("24SZJA kitöltési útmutató", 2961 kB), and the ANYK fill-in program installers.
• Plain unauthenticated curl request, no session/cookie/CAPTCHA gate beyond ordinary session cookies NAV's web server sets on every request.
• HTTP 200, 727,940 bytes retrieved — matching GOV-4638's own banked ~711KB estimate closely (the discrepancy is consistent with the estimate being taken from the page's rounded display value).
• PDF header %PDF-1.4 at byte 0; confirmed via pdfjs-dist.
• sha256 of the retrieved bytes: 4a93c5ff84eada2bac6d8e8d5359c310407abfe142b3e370bcaae82e41a14116.
• 30 pages, confirmed via pdfjs-dist's numPages; 0 AcroForm widgets on every page (a flat, print-and-write specimen, not a fillable PDF).

Authority attribution

The form's own header reads "Nemzeti Adó- és Vámhivatal" (National Tax and Customs Administration, NAV) — Hungary's tax authority, per the hosting domain's own organizational identity.

Extraction method

pdfjs-dist (vendored at /tmp/node_modules/pdfjs-dist, loaded via legacy/build/pdf.js through createRequire since no .mjs build is vendored) getTextContent() read every text item's raw string and x/y transform position per page. Unlike several recent non-Latin-script cycles, this specimen's text layer decodes to correct, readable Hungarian text with no glyph-scramble or glyph-paint-order artifact; the only correction needed was sorting each page's items by descending y then ascending x to reconstruct top-to-bottom, left-to-right reading order, since the raw content-stream order interleaves label/value pairs and column groups (the same class of reading-order artifact as be/mobilit/vehicle-registration-application@1.0.0, though without any glyph-level corruption). No canvas render was needed — the sorted text-item order was unambiguous and internally consistent with this form's own well-documented public structure (row numbers 1-201 running continuously across the specimen's sheets, each with a stable descriptive label).

Document structure

30 pages total. Page 1 is the cover sheet (24SZJA): submission-channel and office-use boxes (excluded, not applicant-facing), taxpayer identification (name, tax ID, birth name, mother's name, date/place of birth, sex, address, phone), a code-box checklist of which companion detail sheets are attached (excluded — pure cross-referencing bookkeeping for sheets not modelled), return-nature marking (original/correction/self-revision, draft acceptance), a refund/payment-routing block (full vs. partial refund, domestic or foreign bank account), a legal-representative/proxy block (excluded — a secondary path used only when someone other than the taxpayer signs), and the taxpayer's own signed declaration plus an optional tax-advisor countersignature block (excluded — applies only when a paid preparer completes the return). Pages 2-4 are sheets 24SZJA-A/B/C — a single continuous computation running rows 1-96: Section I (consolidated tax base income by category, rows 1-22) and its youth/mothers allowances (rows 23-28); Section covering personal/first-married/family allowances (rows 29-44); Section II (tax on the consolidated base, rows 45-49); Section III (agricultural producer tax allowance, rows 50-51); Section IV ("other data", rows 55-58); Section V (final 2024 settlement — total liability, withholding, quarterly advance tax, balance due/refundable, installment election, rows 61-81); Section VI (EKHO settlement, rows 90-91); Section VII (social contribution tax settlement, rows 95-96). Pages 5-30 are 24 further companion detail sheets for specific declarant types: the 1+1% designation (EGYSZA), dependents/young-mothers-allowance eligibility declarations (II-IV), interest-income detail (05/06), swap-transaction income (07), EKHO detail (08-01/08-02), social contribution tax detail (09), a transfer/refund request (170), agricultural producer detail (12-01/02/03), individual entrepreneur detail (13-01 through 13-08), a supplementary declaration under the personal income tax act (14), and self-revision annexes (16-01/16-02).

Scope: sections and fields excluded from this v1.0.0

This version models the main declaration only — the cover sheet's applicant-facing identification/return-type/refund-routing/declaration fields, plus sheets A/B/C's full rows 1-81 (excluding rows 90-96, which report outputs computed from the EKHO and social-contribution-tax companion sheets this version does not model). Excluded, and banked as open backlog for a future minor version, matching this registry's established main-form-now/companion-schedules-later precedent (Kazakhstan's 220.00/250.00 series; Tunisia's dgi/irpp-declaration@1.0.0):

• All 24 companion detail sheets (pages 5-30) — the 1+1% designation, dependents/young-parent-allowance eligibility declarations, interest income, swap-transaction income, EKHO settlement detail, social contribution tax detail, the transfer/refund request form, agricultural producer income detail, individual entrepreneur income/loss detail, the supplementary declaration, and the self-revision annexes. Each applies only to a specific declarant type (agricultural producers, individual entrepreneurs, EKHO-taxed performers/athletes, taxpayers with foreign interest income, taxpayers claiming dependents, or those filing a self-revision) rather than to every filer.
• The code-box checklist of attached companion sheets (cover sheet, section (C)) — pure cross-referencing metadata naming quantities of sheets this version does not model.
• The legal-representative/authorized-proxy block (cover sheet, section (E)) — completed only when someone other than the taxpayer signs on their behalf, a secondary path.
• The tax-advisor/countersigning-preparer block (cover sheet, section (F)'s second half) — completed only when a paid tax advisor or expert prepares the return, not by the taxpayer themselves.
• Rows 90-91 (EKHO settlement) and 95-96 (social contribution tax settlement) — each is a pure output computed from a companion sheet (08-01/08-02, 09 respectively) this version does not model; including them without their source sheets would invite fabricated values.
• Domestic postal money-order address (cover sheet section (D)) — the fallback payment-routing path for taxpayers with no bank account at all; excluded in favor of the two more common paths (domestic bank account, foreign bank account) already modelled.

Scope: field-collapsing judgment calls

1. addressStreetLine collapses seven separate printed boxes (street name, street type, house number, building, staircase, floor, door) into one free-text field, matching this registry's precedent for collapsing minor multi-part address subdivisions the source does not itself gate logic on.
2. foreignBankAccountDetails collapses eight separate printed boxes (account holder name, account number, country code, currency, IBAN yes/no indicator, SWIFT code, institution name, institution address) into one free-text field — this is a secondary payment-routing path used only by taxpayers without a Hungarian bank account.
3. Rows 1-21's per-category a/b/c (revenue/cost) sub-columns are collapsed to each row's declared income (d) figure only. Most rows in practice populate only the income column directly; modelling every category's separate revenue and cost sub-figures across 21 rows would roughly double this schema's size for line items this version's description/sourceRef text already documents precisely enough to locate on the source.
4. Rows 8-12 (informational sub-portions of row 7's self-employment income for specific professional categories — real-estate rental, European Parliament members, local-council members, statutory auditors, other contract work) are excluded — each is explicitly marked on the source ("nem figyelembe veendő sor" — not to be counted again) as a narrow-professional-category breakout that does not change the row-22 total, not a distinct declarable amount.
5. Purely mechanical intermediate-subtraction rows are excluded (e.g. rows 24/26/28/30/32/36/38/39/40/43/44/48/69/76/77, each a simple difference or sum of two or more already-modelled or excluded fields) — kept are the genuinely independent declared amounts (the allowance figures themselves) and the headline checkpoint totals a downstream consumer needs (consolidatedTaxBaseIncomeTotal, taxOnConsolidatedBase, totalTaxLiability2024, taxPayablePerReturn/taxRefundable).
6. addressCountry/addressCity/addressStreetLine are modelled from the cover sheet's own "külföldi cím" (foreign address) heading, since this one-page cover sheet provides no separate, distinct domestic-address block; treated here as the taxpayer's general address (defaulting to Hungary for domestic filers) rather than invent a second address block the source does not print.

Scope: judgment calls on requiredness and conditional logic

This specimen carries no asterisk/mandatory-marking convention for most lines (unlike, e.g., the Schengen visa form's *-flagged boxes), so requiredness was assigned by engineering judgment: core identification/income-total/tax-total/signature fields required, all individual income-category and allowance line items left optional (most taxpayers populate only a handful of the 21 income rows and several allowance rows, depending on their own circumstances).

1. correctedReturnBarcode gated on returnType notEquals "ORIGINAL". Safe here because returnType is itself an unconditionally required field (always present), avoiding this registry's own documented notEquals-against-an-absent-optional-field trap.
2. domesticBankAccountNumber gated on refundPreference in ["FULL_REFUND", "PARTIAL_REFUND_OR_TRANSFER"], not notEquals "NONE". refundPreference is itself optional (a taxpayer who owes rather than is owed money leaves it blank), so an notEquals gate would incorrectly evaluate true — and spuriously require a bank account — whenever refundPreference is simply absent. in against an absent value correctly evaluates false, the same fix pattern this registry's own notequals-empty-string-absent-field-bug reference documents. Exercised directly as conformance scenario 8 below.
3. installmentPaymentMonths gated on installmentPaymentRequested equals true. installmentPaymentRequested is an optional boolean; an absent value is treated as false by every consumer this registry has modelled this pattern for before (e.g. be/mobilit/...'s isSpeedPedelec), so equals: true is the safe direction here (no absent-vs-false ambiguity, unlike the notEquals case above).
4. taxPayablePerReturn/taxRefundable are both left plain optional, not mutually gated via requiredWhen. The source form's own rows 79 and 80 are true alternatives (only one produces a positive figure from the taxpayer's own arithmetic), but the Condition grammar (GSP-0013) has no field-presence/absence primitive to express "required when the other field is NOT present" — only value comparisons. Rather than force an incorrect encoding, this mutual exclusivity is documented in both fields' own description text as a real-world business rule outside what requiredWhen can validate.

Conformance

11 mock scenarios were exercised programmatically (ephemeral, uncommitted Node script) against this schema's own fields[]/requiredWhen conditions: (1) a minimal valid original return with no refund routing, no correction, no installment plan — resolves with zero outstanding required fields; (2) a correction (CORRECTION) return without correctedReturnBarcode — correctly flags only that field; (3) the same scenario supplied with the barcode — resolves cleanly; (4) a self-revision (SELF_REVISION) return without the barcode — correctly flags it; (5) refundPreference: FULL_REFUND without a domestic account number — correctly flags only domesticBankAccountNumber; (6) the same scenario supplied with an account number — resolves cleanly; (7) refundPreference: NONE — the account number correctly stays optional; (8) refundPreference left entirely unset — confirms the account number is NOT spuriously required (the specific trap in was chosen over notEquals to avoid, per the judgment-call note above); (9) installmentPaymentRequested: true without a month count — correctly flags only installmentPaymentMonths; (10) the same scenario supplied with a month count — resolves cleanly; (11) installmentPaymentRequested: false explicitly — the month count correctly stays optional. All 11/11 scenarios passed. All three requiredWhen conditions in this schema were exercised both triggered and untriggered, including the specific absent-optional-field edge case each was designed to handle safely.

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (ajv 2020-12 against spec/v0.3/govschema.schema.json). registry-index.json regenerated via npm run build-index in tools/govschema-client/.

Models 82 fields[] across 8 steps, 1 documents[] entry (the taxpayer's signed accuracy declaration).