Switzerland (St. Gallen) Sole Proprietorship Commercial Register New-Registration Application — Anmeldung Neueintragung Einzelunternehmen

Candidate selection

GOV-3288 ("GovSchema Standard Research", 2026-07-16) scouted Switzerland's Business Formation vertical (Switzerland was at 4/6: Passport, DMV, Taxes, National ID modelled; Business Formation and Visa open) and left it as a disclosed, ready-to-author backlog candidate (GOV-3293), which this cycle (GOV-3298) picked up and completed.

The federal one-stop-shop wizard (EasyGov.swiss) is a confirmed dead end — its very first screen requires an account login, with no unauthenticated field-level content visible before authentication. Switzerland's 26 cantons each run their own commercial register (Handelsregisteramt), and several publish a structurally similar AcroForm PDF for registering a new sole proprietorship (Einzelunternehmen). Five candidates were fetched and widget-counted this cycle before picking one to author against:

| Canton | Source | Pages | AcroForm widgets | Field-name style | | --- | --- | --- | --- | --- | | St. Gallen (SG) | sg.ch | 3 | 50 | Self-documenting (Firma, Sitz politische Gemeinde, Rechtsdomizil, Zweck 1–8, HeimatortStaatsangehörigkeit 1, …) | | Graubünden (GR) | gr.ch | 2 | 39 | Self-documenting but terser (2 pages instead of 3, no separate non-public contact block) | | Aargau (AG) | ag.ch | 3 | 47 | Self-documenting, closely parallels SG | | Lucerne (LU) | lu.ch | 3 | 32 | Self-documenting, fewer signatory/contact fields | | Appenzell Ausserrhoden (AR) | ar.ch | 3 | 47 | Terse/opaque (Feld1, Feld3, zb1_zb, fusg1) — harder to independently corroborate field meaning from the name alone |

St. Gallen's form was selected as the authoring source: the richest widget count, the clearest one-to-one correspondence between AcroForm field names and their printed labels, and a distinct third "Kontaktangaben (nicht öffentlich)" contact/submitter block the thinner siblings lack. All five are genuine, live, unauthenticated PDFs — no login/CAPTCHA/WAF gate on any of them — so this is a "pick the richest of several equally-open candidates" decision, not a case of ruling out weaker candidates as dead ends. The other four remain viable candidates for a future companion-schema cycle (e.g. modelling one as a distinct sibling the way this registry already does for CH-ZH's Steuererklärung companion schedules), left as disclosed, unauthored backlog rather than pursued further this cycle.

Switzerland's Visa vertical was also re-screened this cycle: sem.admin.ch's national-visa AcroForm PDF was fetched and its field sequence compared against de/auswaertiges-amt/national-visa-application, already modelled in this registry. It is a field-for-field match — the same EU-harmonized Schengen long-stay-visa questionnaire this registry has already found and declined to re-author for Czechia, Portugal, Poland, and Slovakia (see CATALOG.md's "Confirmed dead ends" section). Not authored; recorded there as a fresh confirmation for Switzerland.

Source

• URL: https://www.sg.ch/content/dam/sgch/recht/handelsregister-notariate/einzelunternehmen/Anmeldung%20Neueintragung.pdf
• Fetched fresh this session with two independent plain HTTP GETs (no login/session/cookie): HTTP 200, 206,104 bytes both times, genuine %PDF header, identical sha256 8f643f455e075e22ba76f9cb209a23f38395326b86150f9d9baab7fdbdc0a433 on both fetches — confirms a stable, non-dynamically-varied source.
• The document carries no printed form number/edition code; it is the Amt für Handelsregister und Notariate's current live download, cited by its own on-page filename/title.

Extraction technique

pdfjs-dist v3.11.174 (legacy/build/pdf.js) was used two ways, from a disposable script against the downloaded PDF:

1. page.getAnnotations() per page — enumerated every /Widget annotation's fieldName, fieldType (Tx text vs. Btn button), rect (page coordinates), and for buttons, radioButton/checkBox/ buttonValue/exportValue. 50 widgets across 3 pages: 36 text fields, 8 radio-button options across 3 mutually-exclusive groups (Gruppe1 — c/o vs. own premises, 2 options; Gruppe2 — signature authority type, 4 options; Gruppe3 — has-UID-number yes/no, 2 options), and 6 independent (non-grouped) checkboxes (2 identity-document confirmation checkboxes in the Beilagen section, 4 "best reached via" contact-method checkboxes on page 3).
2. page.getTextContent() per page — recovered every section heading and the surrounding instructional prose (e.g. the c/o-domicile declaration requirement, the "cross out if not desired" register-extract order instruction, the public-notarization signature requirement), used to write accurate field descriptions and to confirm which page content is applicant-entered vs. purely instructional/non-field.

All 50 widgets are accounted for in schema.json's fields[]/documents[] — none were dropped silently. The mapping:

| Widget(s) | Modelled as | | --- | --- | | Firma, Sitz politische Gemeinde, Rechtsdomizil, PLZ Ort | companyName, registeredOfficeMunicipality, registeredOfficeStreetAndNumber, registeredOfficePostalCodeAndCity | | Gruppe1 (2 radio options) | domicileType (enum) | | c/o-Adresse text field | domicileHolderAddress (requiredWhen domicileType == C_O) | | Zweck 1–Zweck 8 | businessPurpose (single field, 8 ruled lines folded into one maxLength: 720 string — these are one continuous purpose statement, not 8 distinct repeating entries) | | Personalien...1/2, HeimatortStaatsangehörigkeit 1/2 | ownerFamilyName, ownerGivenNames, ownerHometownOrNationality, ownerResidenceAddress | | Weitere Zeichnungsberechtigte, undefined_2, HeimatortStaatsangehörigkeit 1_2/2_2 | additionalSignatory* (all four, requiredWhen signatureAuthorityType in [JOINT_SIGNATURE_BY_TWO, JOINT_PROCURATION_BY_TWO]) | | Gruppe2 (4 radio options) | signatureAuthorityType (enum) | | Gruppe3 (2 radio options) | hasUidNumber (boolean) | | UID text field | uidNumber (requiredWhen hasUidNumber == true) | | Kopie eines gültigen Ausweises...1/Kontrollkästchen2 | ownerIdentityDocumentHolderName field + ownerIdentityDocumentCopy document | | Kopie eines gültigen Ausweises...2/Kontrollkästchen3 | additionalSignatoryIdentityDocumentHolderName field + additionalSignatoryIdentityDocumentCopy document (both requiredWhen the joint-signature condition) | | Page-1 c/o declaration instruction (no widget of its own) | domicileHolderDeclaration document (requiredWhen domicileType == C_O) | | Section 8 pre-checked register-extract order (no widget of its own) | registerExtractOrder document, category: payment, amount: {CHF, 40} | | 1, 2, HeimatortStaatsangehörigkeit 1_3/2_3, Telefon G, P, M, EMail | submitterFamilyName, submitterGivenNames, submitterHometownOrNationality, submitterResidenceAddress, submitterPhoneWork, submitterPhonePrivate, submitterPhoneMobile, submitterEmail | | Kontrollkästchen4–7 | preferredContactViaWorkPhone/PrivatePhone/Mobile/Email (4 independent booleans, not a single enum — confirmed via getAnnotations() that these are 4 separate, ungrouped Btn/checkBox widgets rather than one radioButton group, so the source genuinely allows multiple simultaneous selections) | | 1_2, 2_2, 3, 4 | additionalRemarks (single field, 4 ruled lines folded into one maxLength: 360 string, same pattern as businessPurpose) |

Disclosed judgment calls

• businessPurpose and additionalRemarks are modelled as single fields, not arrays. The spec's field.type enum (string, number, integer, boolean, date, enum, file, object) has no array/repeating type; each set of ruled lines is genuinely one continuous piece of prose on the source form (a purpose statement, or free-text remarks), not a bounded set of independently-labeled repeating rows like this registry's other "up to N rows" tables (e.g. no/skatteetaten/skattemelding-for-forhandsfastsetting's wages/pension tables). A single string with a maxLength sized to the ruled-line count is the correct model here.
• The two "Kopie eines gültigen Ausweises" name text fields are modelled as data fields (ownerIdentityDocumentHolderName, additionalSignatoryIdentityDocumentHolderName) paired with corresponding documents[] entries, rather than folded entirely into the document requirement. The source form genuinely asks for both a checkbox (confirming the copy is attached) and a name (whose copy it is) — both are applicant-entered content and are kept as distinct concerns per GSP-0014's fields/documents split.
• The register-extract order (registerExtractOrder) is modelled as a documents[] entry with category: payment, not a boolean fields[] entry, since it carries a genuine amount (CHF 40) and is pre-selected by default on the source form (opt-out via crossing it out, per the form's own instruction) — this follows the same category: payment pattern used elsewhere in this registry rather than inventing a new boolean-with-amount shape.
• The wet-ink signature and public-notarization requirement (Section 10, "Unterschriften") are not modelled as fields — signatures must be authenticated in person by the Amt für Handelsregister und Notariate, a notary, or a municipal administration under presentation of a valid identity document. This is a physical-attestation process step, not applicant-entered data, consistent with this registry's established precedent for wet-ink signature sections elsewhere.
• ownerHometownOrNationality/additionalSignatoryHometownOrNationality/ submitterHometownOrNationality each model a single combined Heimatort-or-Staatsangehörigkeit concept (place of origin for Swiss citizens, nationality for foreign nationals) as one free-text field, matching the single AcroForm widget backing each — the source form does not split this into two separate inputs.
• No steps[] — this is a flat multi-page paper form, not a live multi-step wizard, consistent with this registry's other flat-PDF schemas (e.g. the NO Skattemelding sibling).

Validation

• node tools/validate.mjs — see CI/commit log for the exact before/after totals.
• node tools/validate-ajv.mjs — same.
• node tools/verify-sources.mjs --base origin/main — confirms the single cited source URL is live and unauthenticated.
• Conformance fixtures under conformance/ch/sg/handelsregisteramt/anmeldung-neueintragung-einzelunternehmen/1.0.0/: 2 valid fixtures (sole-signature-no-UID, and joint-signature-with-UID covering every requiredWhen branch) plus mutation-control fixtures each raising exactly one error.

GovSchema is independent and is not affiliated with, endorsed by, or operated by the Swiss Confederation, the Canton of St. Gallen, or its Amt für Handelsregister und Notariate. This schema does not file the registration itself; the live source (sg.ch) is always authoritative.