Kyrgyzstan Application for Taxpayer Registration/Re-registration (Form STI-163)

Candidate selection

GOV-4703 ("GovSchema Standard Research"), authoring the STI-163 candidate GOV-4410 had identified as Kyrgyzstan's strongest remaining Business Formation candidate but could not verify at the time: sti.gov.kg's file-serving endpoint (/section/view-pdf) was returning HTTP 500 for every file tested that cycle, confirmed via more than ten independent fetch attempts. This cycle re-fetched the same URL fresh and found it recovered (HTTP 200). Opens Kyrgyzstan's Business Formation vertical (2 of 6), following GOV-4399's Taxes-vertical opening.

Reaching the live source

Target: the State Tax Service's (GNS) forms-listing page, https://sti.gov.kg/section/0/%D1%84%D0%BE%D1%80%D0%BC%D1%8B_%D0%B7%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9 ("Формы заявлений"), HTTP 200, 304,694 bytes. Confirms a "DOC STI-163" listing entry dated 22 января 2026, with anchor text "Заявление на регистрацию / перерегистрацию налогоплательщика (DOC STI-163)" matching the form's own printed heading exactly.

Independently re-fetched the form PDF itself rather than trusting GOV-4410's own banked description alone: https://sti.gov.kg/section/view-pdf?filePath=websti%2F2026%2F01%2F23%2FDOC%20STI-163%20(%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9).pdf — HTTP 200, Content-Type: application/pdf, 223,620 bytes. sha256 fae770687ecb18b30addcce355326c051b301265c3b561e4980f215c9ad86869.

No separate field-by-field completion guide ("Порядок заполнения") is linked anywhere on the listing page for STI-163, unlike the sibling kg/gns/unified-tax-declaration schema (whose own STI-091 form has one); only two sibling forms (STI-164, deregistration, and STI-024/025, a registration card) are listed alongside it, none of which are completion guides for STI-163 itself. Every interpretation below is derived from the form's own printed captions only.

Fetched with a plain curl -A "Mozilla/5.0"; no login/CAPTCHA/WAF gate. One transient connection-level failure (curl exit 000) recurred on both the form URL and the listing-page URL during this session, resolved on retry within seconds on both — a flaky-network blip, not a durable gate, clearly distinct from GOV-4410's own multi-attempt, multi-tool-confirmed, multi-minute outage on the same endpoint.

Extraction method

pdfjs-dist (vendored at /tmp/node_modules/pdfjs-dist) getAnnotations() confirmed zero /Widget annotations across both of the specimen's 2 pages — a flat, non-AcroForm specimen. getTextContent() read every text item's raw string and its transform x/y position. Page 1's Section II checkbox grids print several checkbox-grid columns side by side rather than in a single top-to-bottom reading order; reconstructed by grouping items on rounded x-coordinate into columns first, then reading each column top-to-bottom — a variant of this registry's already-documented non-sequential-reading-order PDF-extraction pattern (gov-form-pdf-extraction, previously seen on be/mobilit). No vector checkbox glyphs were found anywhere in the text layer; the form's own instruction text ("нужное отметить знаком «Х»", mark the applicable one with an "X") confirms checkboxes are hand-marked squares rendered as vector graphics, not text glyphs, matching this registry's already- documented vector-checkbox extraction pattern (previously seen on tn/dgsn/national-identity-card-application).

Document structure

Page 1: an order-citation header (Приложение 1 к приказу ГНС от «22» января 2026 года № П-19); the form title; Section I "ИНФОРМАЦИЯ О НАЛОГОПЛАТЕЛЬЩИКЕ" (taxpayer information — items 102-104, then a "Реквизиты налогоплательщика" sub-heading over items 112-116: registered address, actual-residence address, business address, phone, email); Section II "СОДЕРЖАНИЕ ЗАЯВЛЕНИЯ" — item 117, a 3-column, 7-option checkbox grid selecting the requested registration/re-registration action; a "Основание для регистрации" (grounds for registration) block with a single checkbox option (intent to conduct economic activity) plus a free-text description blank; a "Заявляю о применении налогового режима" heading over a further 3-column checkbox grid of 11 tax-regime options; and a closing applicant declaration (a combined position/full-name blank, a signature blank, and item 300, the application's submission date). Section III "ИНФОРМАЦИЯ НАЛОГОВОГО ОРГАНА" (items 900-902 — incoming application number, receipt date, and the receiving officer's own INN) plus a second signature/position blank for the receiving tax-authority employee are entirely tax-authority- populated and excluded from this schema. Page 2, "ПРИЛОЖЕНИЕ 1: СТАВКА ЕДИНОГО НАЛОГА" (Appendix 1: Unified Tax Rate), is a companion rate-selection schedule applicable only when Section II's tax-regime checkbox selects Единый налог (unified tax); excluded from this v1.0.0, see Finding 5 below.

Disclosed findings and interpretation choices

1. iin (item 102) is modelled as optional (required: false), unlike the sibling kg/gns/unified-tax-declaration schema's own iin field, which is required. That sibling schema is a recurring report filed by an already-registered taxpayer who necessarily already holds an ИНН; this form is the taxpayer's own first registration/ re-registration event, at which a first-time individual-entrepreneur or natural-person registrant may not yet hold an ИНН. No completion guide exists for this form to resolve the ambiguity either way, so the more permissive reading is taken and disclosed here rather than asserted.
2. businessAddress (item 114) is modelled with requiredWhen gating on registrationAction being individual_entrepreneur_registration or farm_enterprise_registration — the two registration-action options that structurally imply an operating place of business, distinct from a plain natural-person tax registration (individual_registration), which has no inherent place-of-business concept. This mirrors this registry's established discriminator-gated- field pattern (e.g. be/partena's INDIVIDUAL/COMPANY/ UNINCORPORATED_ORGANIZATION discriminator).
3. economicActivityDescription is modelled with requiredWhen gating on registrationAction being one of the three substantive first-time- registration actions (individual_entrepreneur_registration, individual_registration, farm_enterprise_registration) rather than unconditionally required. The "Основание для регистрации" block prints exactly one selectable ground — intent to conduct economic activity, with a free-text description blank — and it reads naturally as applicable to a fresh registration rather than to a pure re-registration action (change of regime/details/district) that does not itself register a new activity. No explicit conditional instruction is printed on the form to this effect; disclosed as an interpretation choice rather than a literal source rule, following this registry's own precedent of gating only the unambiguous case rather than fabricating an unstated instruction.
4. taxRegime is modelled as unconditionally optional (required: false) despite the "Заявляю о применении налогового режима" heading reading as a general declaration. Whether every one of the seven registrationAction values necessarily requires a fresh regime declaration (e.g. a pure "change of registration details" re-registration arguably would not) is not stated anywhere on the form; rather than fabricate a registrationAction-keyed requiredWhen gate the source does not itself state, this field is left optional and the ambiguity is disclosed here.
5. Page 2 ("ПРИЛОЖЕНИЕ 1: СТАВКА ЕДИНОГО НАЛОГА") is excluded from this v1.0.0, disclosed as open backlog for a future minor version. It is a companion rate-selection schedule (a further nested checkbox grid distinguishing trade-activity, processing, and several sector-specific sub-rates) that this form's own printed text states is required only "при выборе данного режима" (when this [unified-tax] regime is chosen) — i.e. conditionally scoped to a single one of taxRegime's 11 values. Rather than model an entire second-page companion schedule behind a single enum branch in this v1.0.0, this schema follows this registry's established main-form-now/companion- annex-later convention (e.g. Hungary's 24 deferred companion sheets, Latvia's VID annex series, Kazakhstan's Form 220.00/250.00 series).
6. Section III (items 900-902) and the tax authority's own signature/ position blank are excluded as tax-authority-populated, not applicant-supplied data, matching this registry's own convention for analogous authority-completed receipt blocks (e.g. this schema's own sibling kg/gns/unified-tax-declaration's cell-901 exclusion, Kazakhstan's Form 220.00 bottom block).
7. applicantPositionAndFullName combines the source's own single blank line for "(должность, Ф.И.О. заявителя)" into one field, rather than splitting it into separate position/fullName fields, since the source prints only one undivided blank for both, not two structurally distinct entry areas.
8. iin is modelled without a specific digit-count pattern, matching the sibling kg/gns/unified-tax-declaration schema's own disclosed finding — neither this form nor any completion guide states the ИНН's digit length.

Conformance

3 valid mock scenarios — valid-individual-entrepreneur-registration (a full individual- entrepreneur registration selecting the patent tax regime, exercising the businessAddress and economicActivityDescription requiredWhen gates in their required-true branch), valid-natural-person-registration (a plain natural-person tax registration with no place-of-business, exercising businessAddress's requiredWhen gate in its required-false branch while still requiring economicActivityDescription), and valid-reregistration-district-change (a pure district-change re-registration, exercising both businessAddress and economicActivityDescription's requiredWhen gates in their required-false branch) — plus 9 static-required-field mutation fixtures, 2 requiredWhen-gate mutation fixtures (mutation-missing-businessaddress-requiredwhen-entrepreneur, mutation-missing-economicactivitydescription-requiredwhen-individual), and 1 unknown-field-rejected fixture, committed under conformance/kg/gns/tax-registration-application/1.0.0/.

An ephemeral, from-scratch conformance checker (deriving required/ requiredWhen rules directly from this schema's own fields[], discarded after use, not committed) ran all 15 fixtures: all 3 valid scenarios at 0 errors, all 11 mutation controls each raising exactly 1 error, and the unknown-field fixture correctly rejected. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run. registry-index.json regenerated via npm run build-index in tools/govschema-client/.