Registry entry

Austria Schengen Visa Application (Formular C1 / Antrag auf Erteilung eines Schengen-Visums)

Austria's implementation of the EU-standard uniform short-stay ('Schengen', category C) visa application form — Annex I to Regulation (EC) No 810/2009 establishing the Community Code on Visas — as published by the Bundesministerium für europäische und internationale Angelegenheiten (BMEIA) for use at Austrian embassies and consulates abroad. The 37-field layout, printed declaration text, and required supporting documents are legally harmonised and near-identical across every Schengen state; this document models BMEIA's own central multilingual (German/English/French/Spanish) specimen, submitted by or on behalf of third-country nationals applying for a short stay of up to 90 days in any 180-day period in the Schengen area via an Austrian mission. Modelled from a flat/print PDF specimen carrying no AcroForm layer (0 widgets confirmed with pdfjs-dist across all 4 pages) — the source's own field numbering (1-37) is used directly as this document's field grouping and 'sourceRef' anchor, following this registry's established convention for numbered-line (non-fillable) specimens (e.g. 'is/skatturinn'). Fields 19, 20, 31, 32 and 33 carry a printed asterisk on the source: they are not to be filled in by family members of EU/EEA/Swiss citizens exercising their right of free movement (who instead complete fields 34-35) — a real conditional exemption stated only in the form's own footnote prose, disclosed here (in each affected field's own 'description') rather than encoded as a machine-checkable 'requiredWhen', since the source states it only as free-standing prose, not as a structured rule tied to a single yes/no field. The lengthy declaration paragraph the applicant signs (data-processing/VIS consent, awareness that the visa fee is non-refundable and that a multi-entry visa requires travel medical insurance, and the standard accuracy/completeness declaration) is paraphrased into a single attestation entry in 'documents[]' rather than quoted verbatim or split into separate checkboxes, since the source presents it as one continuous prose block ahead of a single signature line, with no per-statement checkbox of its own. GovSchema is independent and is not affiliated with, endorsed by, or operated by the Republic of Austria, the Bundesministerium für europäische und internationale Angelegenheiten, any Austrian embassy or consulate, or the European Union.

Registry entry

at/bmeia/schengen-visa-application

Jurisdiction
Austria · national
Version
1.0.0
Verification
draft
Authority
Bundesministerium für europäische und internationale Angelegenheiten (BMEIA), acting through Austria's embassies and consulates abroad, applying the EU-harmonised Schengen visa rules (Regulation (EC) No 810/2009, the Visa Code)

Authoritative source 'Formular C1' / 'Antrag auf Erteilung eines Schengen-Visums' / 'Application for Schengen Visa', BMEIA's own central multilingual (German/English/French/Spanish) 4-page flat/print PDF specimen of the EU-harmonised Annex I uniform application form, hosted in BMEIA's central 'Allgemein/Formulare' forms library

Machine access

Schema document
registry/at/bmeia/schengen-visa-application/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/at/bmeia/schengen-visa-application/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

74 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • surname string required

    Per the form's own footnote '(x)': fields 1-3 (surname, surname at birth, first name(s)) shall be filled in in accordance with the data in the travel document.

    length: 1–200classification: pii
  • surnameAtBirth string optional

    Surname at birth (former family name(s))

    length: 0–200classification: pii
  • firstNames string required

    First name(s) (given name(s))

    length: 1–200classification: pii
  • dateOfBirth date required

    Date of birth

    classification: sensitive-pii
  • placeOfBirth string required

    Place of birth

    length: 1–200classification: pii
  • countryOfBirth string required

    Country of birth

    length: 1–100classification: pii
  • currentNationality string required

    Current nationality

    length: 1–100classification: pii
  • nationalityAtBirthIfDifferent string optional

    Nationality at birth, if different from current nationality

    length: 0–100classification: pii
  • sex enum required

    Sex

    enum: male | female
  • maritalStatus enum required

    Marital status

    enum: single | married | separated | divorced | widowed | other
  • maritalStatusOtherDescription string optional

    Description of other marital status

    length: 0–200
  • minorLegalGuardianDetails string optional

    For minors: surname, first name, address (if different from the applicant's) and nationality of the holder of parental authority/legal guardian

    length: 0–500classification: pii
  • nationalIdentityNumber string optional

    National identity number, where applicable

    length: 0–50classification: sensitive-pii
  • travelDocumentType enum required

    Type of travel document

    enum: ordinary-passport | diplomatic-passport | service-passport | official-passport | special-passport | other
  • travelDocumentTypeOtherDescription string optional

    Description of other travel document type

    length: 0–200
  • travelDocumentNumber string required

    Number of travel document

    length: 1–50classification: sensitive-pii
  • travelDocumentIssueDate date required

    Date of issue of travel document

  • travelDocumentValidUntil date required

    Travel document valid until

  • travelDocumentIssuedBy string required

    Travel document issued by

    length: 1–200
  • applicantHomeAddressAndEmail string required

    Applicant's home address and e-mail address

    length: 1–400classification: pii
  • applicantTelephoneNumbers string required

    Applicant's telephone number(s)

    length: 1–100classification: pii
  • residesInOtherCountry boolean required

    Resident in a country other than the country of current nationality

  • residencePermitOrEquivalentNumber string optional

    Residence permit or equivalent document number

    length: 0–100classification: sensitive-pii
  • residencePermitValidUntil date optional

    Residence permit or equivalent document valid until

  • currentOccupation string optional

    Printed with an asterisk on the source form: fields marked '*' (19, 20, 31, 32, and 33) shall not be filled in by family members of EU, EEA, or CH citizens exercising their right of free movement (see field 34/35) — a real conditional exemption stated only in the form's own footnote prose, not encoded here as a machine-checkable condition (disclosed rather than falsely modelled; see VERIFICATION.md).

    length: 0–200
  • employerOrEducationalEstablishmentDetails string optional

    Same asterisked exemption as 'currentOccupation' applies (see its description).

    length: 0–400
  • mainPurposeOfJourney enum required

    Main purpose(s) of the journey

    enum: 11 values
  • mainPurposeOfJourneyOtherDescription string optional

    Description of other main purpose of journey

    length: 0–200
  • memberStatesOfDestination string required

    Member State(s) of destination

    length: 1–200
  • memberStateOfFirstEntry string required

    Member State of first entry

    length: 1–100
  • numberOfEntriesRequested enum required

    Number of entries requested

    enum: single | two | multiple
  • durationOfIntendedStayDays integer required

    Duration of the intended stay or transit (number of days)

    range: 1–365
  • schengenVisasIssuedPastThreeYears boolean required

    Schengen visa(s) issued during the past three years

  • schengenVisaValidFrom date optional

    Date of validity from (most recent Schengen visa issued in the past three years)

  • schengenVisaValidUntil date optional

    Date of validity until (most recent Schengen visa issued in the past three years)

  • fingerprintsCollectedPreviously boolean required

    Fingerprints collected previously for the purpose of applying for a Schengen visa

  • fingerprintsCollectedDate date optional

    The source form itself marks this sub-field optional ('falls bekannt' / 'if known') even when the parent question is answered 'Yes', so it carries no 'requiredWhen' — only 'visibleWhen'.

  • entryPermitIssuedBy string optional

    Entry permit for the final country of destination, where applicable — issued by

    length: 0–200
  • entryPermitValidFrom date optional

    Entry permit valid from

  • entryPermitValidUntil date optional

    Entry permit valid until

  • intendedArrivalDateInSchengenArea date required

    Intended date of arrival in the Schengen area

  • intendedDepartureDateFromSchengenArea date required

    Intended date of departure from the Schengen area

  • invitingPersonOrHotelName string optional

    Same asterisked exemption as 'currentOccupation' applies (field 31 is asterisked).

    length: 0–300classification: pii
  • invitingPersonOrHotelAddressAndPhone string optional

    Address, e-mail, telephone and fax of the inviting person(s)/hotel(s)/temporary accommodation(s)

    length: 0–400classification: pii
  • invitingCompanyOrOrganisationNameAddress string optional

    Same asterisked exemption as 'currentOccupation' applies (field 32 is asterisked).

    length: 0–300
  • invitingCompanyPhoneFax string optional

    Telephone and telefax of inviting company/organisation

    length: 0–100
  • invitingCompanyContactPersonDetails string optional

    Surname, first name, address, telephone, fax and e-mail address of the contact person in the company/organisation

    length: 0–400classification: pii
  • fundedByApplicant boolean optional

    Same asterisked exemption as 'currentOccupation' applies (field 33 is asterisked). This and the following three 'fundedBy...' fields are mutually exclusive per 'exclusivityGroups' below.

  • fundedBySponsor boolean optional

    Cost of travelling and living covered by another sponsor (host, company, organisation)

  • fundedBySponsorDescription string optional

    Description of the sponsor (host, company, or organisation)

    length: 0–300
  • fundedBySeeField31Or32 boolean optional

    Cost of travelling and living covered as referred to in field 31 or 32

  • fundedByOtherEntity boolean optional

    Cost of travelling and living covered by another entity

  • fundedByOtherEntityDescription string optional

    Description of the other entity covering cost of travelling and living

    length: 0–300
  • hasCashApplicant boolean optional

    Means of support during stay (applicant) — cash

  • hasTravellersChequesApplicant boolean optional

    Means of support during stay (applicant) — traveller's cheques

  • hasCreditCardApplicant boolean optional

    Means of support during stay (applicant) — credit card

  • hasPrepaidAccommodationApplicant boolean optional

    Means of support during stay (applicant) — prepaid accommodation

  • hasPrepaidTransportApplicant boolean optional

    Means of support during stay (applicant) — prepaid transport

  • hasOtherApplicant boolean optional

    Means of support during stay (applicant) — other

  • otherMeansOfSupportApplicantDescription string optional

    Description of other means of support (applicant)

    length: 0–200
  • hasCashSponsor boolean optional

    Means of support during stay (sponsor) — cash

  • hasAccommodationProvidedSponsor boolean optional

    Means of support during stay (sponsor) — accommodation provided

  • hasAllExpensesCoveredSponsor boolean optional

    Means of support during stay (sponsor) — all expenses covered during the stay

  • hasPrepaidTransportSponsor boolean optional

    Means of support during stay (sponsor) — prepaid transport

  • hasOtherSponsor boolean optional

    Means of support during stay (sponsor) — other

  • otherMeansOfSupportSponsorDescription string optional

    Description of other means of support (sponsor)

    length: 0–200
  • euRelativeSurname string optional

    Fields 34-35 are filled in only by applicants who are family members of an EU, EEA, or Swiss citizen exercising their right of free movement — the same population exempted from the asterisked fields (see 'currentOccupation').

    length: 0–200classification: pii
  • euRelativeFirstNames string optional

    First name(s) of the family member who is an EU, EEA or CH citizen

    length: 0–200classification: pii
  • euRelativeDateOfBirth date optional

    Date of birth of the family member who is an EU, EEA or CH citizen

    classification: sensitive-pii
  • euRelativeNationality string optional

    Nationality of the family member who is an EU, EEA or CH citizen

    length: 0–100classification: pii
  • euRelativeTravelDocumentOrIdNumber string optional

    Number of travel document or ID card of the family member who is an EU, EEA or CH citizen

    length: 0–50classification: sensitive-pii
  • euRelativeRelationship enum optional

    Family relationship with the EU, EEA or CH citizen

    enum: spouse | child | grandchild | dependent-ascendant
  • signaturePlace string required

    Place of signature

    length: 1–100
  • signatureDate date required

    Date of signature

Verification record

Candidate selection

This is Austria's Visa vertical, a candidate already screened and confirmed viable (but left unauthored) in the prior GOV-2121 cycle ("Austria's National ID vertical opens"): the EU/Schengen uniform "Formular C1" Schengen visa application (Antragsformular_Visum_C_NEU.pdf, 285,208 bytes, 4 pages, field-numbered with no AcroForm layer). That cycle noted it as "a real, legitimate, open candidate for a future cycle, but a comparatively thinner 'Austria' story" than the other two verticals it screened (Passport, National ID) — both of which have since been authored (GOV-2121, GOV-2128). With Business Formation, Taxes, National ID, and Passport now all live, Visa is Austria's last remaining open, viable, screened backlog candidate; DMV remains a confirmed weak/dead-end candidate from an earlier cycle (Kfz-Zulassung is in-person/counter-driven with no downloadable specimen).

This document does not re-litigate that screening; it starts from a fresh, from-scratch re-fetch and re-extraction of the candidate the prior cycle identified only by filename and byte count, rather than trusting those numbers.

Source

  • Primary: https://www.bmeia.gv.at/fileadmin/user_upload/Allgemein/Formulare/Antragsformular_Visum_C_NEU.pdf — confirmed by direct curl fetch with a browser User-Agent: HTTP 200, content-type: application/pdf, exactly 285,208 bytes (SHA-256 502e46f0b12a52b3f8af1ce9023bbd53b3a54d702e28a391bbcf1581894edf42) — matching the byte count the prior GOV-2121 cycle independently recorded when it screened (but did not author) this same specimen. Hosted directly in BMEIA's central "Allgemein/Formulare" forms library, the same host already established as canonical for this registry's other at/bmeia and at/bmi schemas.
  • Authority page: https://www.bmeia.gv.at/en/travel-stay/entrance-and-residence-in-austria/visa — HTTP 200, BMEIA's own English-language visa overview page, which itself names "Form C1" and discusses the Schengen short-stay visa process.
  • This is the EU-harmonised uniform application form set out in Annex I to Regulation (EC) No 810/2009 (the Visa Code) — legally identical in field content across every Schengen state, though each state hosts and administers its own copy/translation set and intake process. A search of this registry found no existing schema modelling this literal harmonised paper template under any jurisdiction: the closest neighbours are fr/france-visas/schengen-visa-application (France's own bespoke online-portal intake form for the same visa category, with a France-specific field set, not the Annex I paper template) and several national/long-stay (category D) visa schemas (de/auswaertiges-amt/national-visa-application, es/maec/solicitud-visado-nacional, cz/mzv/zadost-o-udeleni-dlouhodobeho-viza, ee/vm/long-stay-visa-application), which are explicitly not EU-harmonised (only short-stay Schengen "C" visas use the uniform Annex I template; long-stay "D" visas remain each state's own design). This document is therefore this registry's first schema modelling the literal harmonised short-stay template, via Austria's own hosted copy of it.

Extraction technique

Fetched the PDF directly and processed it with pdfjs-dist (the same technique this registry's prior is/skatturinn and at/* cycles used):

  • getDocument(...).numPages → 4.
  • page.getAnnotations() on every one of the 4 pages → 0 Widget-subtype annotations on any page (confirmed independently for pages 1-4, not assumed from the prior cycle's disclosure).
  • doc.getFieldObjects() → an empty object (0 keys), consistent with the above.

This is therefore a genuine flat/print specimen with no AcroForm layer, exactly as the prior GOV-2121 screening cycle disclosed — independently reconfirmed here, not merely trusted. All page text was then extracted with getTextContent() (per-page, with each text run's x/y position) and cross-walked against the form's own printed field numbers ("1." through "37.") visible in that text stream, to build this document's field list. No field numbering, label wording, or checkbox option set was taken from prior knowledge of the well-known EU Annex I template without confirming it against this session's own extraction of this specific PDF.

Field model

The source's own numbering (fields 1-37) is used directly as this document's sourceRef anchor for every field, following this registry's established convention for numbered-line, non-fillable specimens. Several numbered items expand into more than one GovSchema field because the printed box contains more than one independently blank sub-item (e.g. field 17's address/e-mail heading and its distinct "Telephone number(s)" heading; field 26's own conditional validity-date sub-block) or more than one independent checkbox (e.g. field 33's cost-of-travel-funded-by selector and its two separate means-of-support checklists) — yielding 74 fields in total from the 37 printed items. Two constructs from GSP-0013 are used for the first time in an at/bmeia cycle:

  • exclusivityGroups: field 33's four "who pays" checkboxes (fundedByApplicant, fundedBySponsor, fundedBySeeField31Or32, fundedByOtherEntity) are modelled as independent optional booleans (this specimen carries no AcroForm radio-group layer to merge them into a true enum, unlike the sibling at/bmi cycle's genuine PDF radio groups) but are declared mutually exclusive via one exclusivityGroups entry, since the source's own layout ("werden getragen ... vom Antragsteller selbst/... von anderer Seite/... siehe Feld 31 oder 32/... von sonstiger Stelle") presents them as one single-answer question. The two means-of-support checklists nested under this question (6 for the applicant, 5 for the sponsor) are deliberately not placed in an exclusivity group — the source lets an applicant tick more than one (e.g. both "cash" and "credit card").
  • crossFieldValidation: two compare rules — the intended departure date from the Schengen area must be on or after the intended arrival date (fields 29-30), and the travel document's expiry must be on or after its issue date (fields 14-15).

Disclosed scope decision — asterisked fields. The source form itself prints a beside fields 19, 20, 31, 32, and the cost-of-travel selector of field 33, with a footnote (in all four printed languages) stating these "shall not be filled in by family members of EU, EEA or CH citizens ... while exercising their right to free movement" — who instead complete fields 34-35. This is a real conditional exemption, but the source states it only as free-standing footnote prose tied to the applicant's own family-member status, not as a structured rule keyed to a single yes/no field this document already models (fields 34-35 have no companion "are you such a family member?" boolean of their own — their being filled in at all is* the signal). Rather than inventing a field the source does not print solely to drive a requiredWhen, each affected field's own description discloses the exemption in prose — the same "disclosed rather than falsely encoded" approach this registry's at/bmi cycle took for its own four-way identity-proof branch.

Disclosed scope decision — the declaration paragraph. Pages 3-4 carry a lengthy, multi-paragraph declaration (data-processing/VIS consent; awareness that the visa fee is non-refundable; awareness of the travel-medical- insurance requirement for a multiple-entry visa; the standard accuracy/completeness declaration and its consequences; awareness that visa possession alone does not guarantee entry) immediately before the single signature line (field 37). The source presents this as one continuous prose block with no per-statement checkbox of its own — unlike, say, a form with one checkbox per acknowledgement — so it is paraphrased into a single documents[] attestation entry's statement, not quoted verbatim (the full text is long, multilingual, and includes legal citations) and not split into invented per-statement boolean fields the source does not itself provide.

Photo requirement. Page 1 carries a "PHOTO" placeholder box (top right) with no accompanying AcroForm widget, consistent with the flat/print nature of the whole specimen — modelled as a required documents[] entry (applicantPhoto), matching this registry's precedent for other AT identity/travel-document schemas.

Mock conformance test run

Two scenarios were built under conformance/at/bmeia/schengen-visa-application/1.0.0/ and checked against this schema's own required/requiredWhen/visibleWhen/validation/ documents[]/exclusivityGroups/crossFieldValidation grammar with a disposable checker script (/tmp/gov2135-at-visa/check_conformance.mjs, not committed — the same technique used for at/bmi/national-identity-card-application, GOV-2121, extended to also evaluate exclusivityGroups and crossFieldValidation, since this is the first at/bmeia/at/bmi cycle to use either construct):

  • application-packet-tourist-single-entry.json: Marina Alvarez, a Colombian tourist applying for a single-entry, 10-day Schengen visa, self-funded, no prior Schengen visa, no fingerprints previously collected, not a family member of an EU/EEA/CH citizen. 30 fields collected, 44 correctly not-applicable, 0 errors; both required documents[] entries (applicantPhoto, applicantOrRepresentativeSignature) provided.
  • application-packet-eu-family-member-multiple-entry.json: Yelena Petrova, a Bulgarian national resident in Switzerland (holding a Swiss residence permit), the spouse of a Swiss citizen (populating fields 34-35 and correctly leaving the asterisked fields 19/20/31/32 blank per the disclosed exemption), applying for a multiple-entry, 30-day visa, sponsor-funded by her spouse (who also provides accommodation and covers all expenses), with a Schengen visa issued in the past three years and fingerprints previously collected. 44 fields collected, 30 correctly not-applicable, 0 errors.
  • Eight mutation/negative controls, each derived from a base scenario with exactly one defect introduced, and each correctly raised exactly one error (confirming the checker is not vacuously passing):
    1. Removing the required surname from scenario 1 → missing-required.
    2. Setting durationOfIntendedStayDays to 400 on scenario 1 (violates the maximum: 365 bound) → range-violation.
    3. Setting sex to "unspecified" on scenario 1 (not in its 2-option enum) → enum-violation.
    4. Setting maritalStatus to "other" on scenario 1 while leaving maritalStatusOtherDescription unset → requiredWhen conditional- required violation.
    5. Removing the required applicantPhoto document from scenario 1 → missing-required-document.
    6. Removing the required applicantOrRepresentativeSignature document from scenario 1 → missing-required-document.
    7. On scenario 2, additionally setting fundedByApplicant to true (alongside the base scenario's fundedBySponsor: true) → exclusivity-violation on the costOfTravelFundedBySelection group — confirming the new exclusivityGroups construct actually fires.
    8. On scenario 1, setting intendedDepartureDateFromSchengenArea to a date before intendedArrivalDateInSchengenArea → cross-field-violation on the departureNotBeforeArrival rule — confirming the new crossFieldValidation construct actually fires.

The schema was also validated against the GovSchema v0.3 meta-schema with node tools/validate.mjs and node tools/validate-ajv.mjs (both pass), and against node tools/verify-sources.mjs registry/at/bmeia/schengen-visa-application/1.0.0 (0 warnings, 3 URLs checked, 0 allowlisted, all clear).

Pre-PR re-verification

Immediately before finalizing this record, the primary source PDF was re-fetched live a second time in this same session, with a realistic browser User-Agent: HTTP 200, content-type: application/pdf, exactly 285,208 bytes, SHA-256-identical to the first fetch (502e46f0b12a52b3f8af1ce9023bbd53b3a54d702e28a391bbcf1581894edf42). The authority URL was re-checked live and returns HTTP 200. node tools/verify-sources.mjs registry/at/bmeia/schengen-visa-application/1.0.0 reports all clear (0 warnings) on this same re-verification pass.

Path to a verified claim (next step)

To advance from status: draft to status: verified, a future reviewer would: confirm with BMEIA or an Austrian mission whether any mission-level variant (bilingual/trilingual, per-mission translations) has superseded this central specimen, mirroring the companion-variant question already open for at/bmeia/passport-or-identity-card-application; and consider whether a second Schengen state's own hosted copy of the same Annex I template is worth cross-checking byte-for-byte on the shared numbered fields (expected to match exactly, since the template is EU-harmonised), as an additional-source corroboration in the style of this registry's de/gewerbeamt and at/gewerbebehoerde multi-edition cross-checks.

Scope and jurisdiction notes

Gives Austria (GovSchema's 31st jurisdiction) its 5th of 6 verticals (Business Formation, Taxes, National ID, Passport, Visa); DMV remains a confirmed weak/dead-end candidate from a prior cycle (in-person/counter- driven Kfz-Zulassung, no downloadable specimen) — the last open item before Austria could reach full 6/6 coverage would require a materially different kind of source (e.g. a live administrative contact) than the PDF-forms approach this registry's AT cycles have used so far.

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Bundesministerium für europäische und internationale Angelegenheiten (BMEIA), acting through Austria's embassies and consulates abroad, applying the EU-harmonised Schengen visa rules (Regulation (EC) No 810/2009, the Visa Code) or any government. The authoritative source is always the live government form and its official instructions.