Registry entry

Estonia Private Limited Company (Osaühing / OÜ) Foundation Petition

The petition for entry of a newly-founded private limited company (osaühing, OÜ — Estonia's equivalent of an LLC) in the Commercial Register, submitted through the e-Business Register (e-äriregister) portal and reviewed by the Registration Department of Tartu County Court. Estonia has no single downloadable 'application form' for this process — the petition is instead built from the data the Commercial Code (Äriseadustik) requires a memorandum of association and articles of association to set out, plus the data the Commercial Register Act (Äriregistri seadus) requires on the resulting registry card — a portal-driven filing this registry models the same way it modelled Poland's passport application (governing statute as primary source, GOV-1685) and Estonia's own e-Residency application (GOV-1698). Scoped to the single-founder case — a natural person founding an OÜ alone, monetary or non-monetary contribution, with or without a supervisory board/procurator/auditor — since the Commercial Code's memorandum-of-association clause on 'division of shares among the founders' (§138(2)(4)) only becomes multi-valued once a second founder is added, a materially larger v1.1.0+ scope this document deliberately excludes (see VERIFICATION.md). GovSchema is independent and is not affiliated with, endorsed by, or operated by the Government of Estonia, the Centre of Registers and Information Systems (RIK), or the Estonian court system.

Registry entry

ee/rik/private-limited-company-foundation

Jurisdiction
Estonia · national
Version
1.0.0
Verification
draft
Authority
Registration Department of Tartu County Court

Authoritative source Commercial Register Act (Äriregistri seadus), official English translation, Riigi Teataja, consolidated text in force from 18.03.2025 (RT I, in force until superseded) — §§9-14 (registry/registry-card data), §§40-43 (form, manner, and review of a petition for entry). The live riigiteataja.ee page for this and every other Riigi Teataja document (including the direct /tolge/pdf/ download route) is a fully client-rendered Angular single-page app that returns an identical empty HTML shell to an unauthenticated fetch; the cited text was retrieved from the Wayback Machine's snapshot of the same URL (21 May 2024), consistent with this registry's established workaround for a government host that hangs/blanks on direct automated retrieval. Cross-referenced against the Commercial Code (Äriseadustik), official English translation, Wayback snapshot of https://www.riigiteataja.ee/en/tolge/pdf/509012023001 (10 Aug 2023) — Chapter 18 'Foundation' (§§137-145), which sets out the memorandum-of-association and articles-of-association content requirements this document's fields are drawn from.

Machine access

Schema document
registry/ee/rik/private-limited-company-foundation/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/ee/rik/private-limited-company-foundation/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

29 fields across 5 steps, 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.

Company identity

  • businessName string required

    The proposed business name of the private limited company being founded, which must include the abbreviation 'osaühing' or 'OÜ'.

  • registeredOfficeAddress string required

    The registered office (town/rural municipality) and address of the company being founded, to the accuracy of a building or part of a building registered in the address data information system.

    classification: pii
  • contactEmail string required

    E-mail address of the company, entered on the registry card.

    patternclassification: pii

Founder

  • founderFullName string required

    Full name of the founder (a natural person founding the company alone — see VERIFICATION.md for this document's single-founder scope).

    classification: pii
  • founderResidenceAddress string required

    Residence address of the founder.

    classification: pii
  • founderPersonalIdentificationCode string required

    Estonian personal identification code (isikukood) of the founder, or, in its absence, the founder's foreign personal identification code and date of birth.

    classification: sensitive-pii

Share capital and contribution

  • shareCapitalAmount number required

    The proposed amount of share capital, denominated in euros. No statutory minimum applies (the former EUR 2,500 minimum was abolished with effect from 1 February 2023); the founder must pay for the share in full before the petition for entry is submitted.

    range: 0.01–∞
  • numberOfShares integer required

    Number of shares held by the founder.

    range: 1–∞
  • nominalValuePerShare number required

    Nominal value of each share, in euros.

    range: 0.01–∞
  • contributionType enum required

    Whether the share is paid for in money or by a non-monetary contribution. A share is paid for in money unless the articles of association prescribe a non-monetary contribution.

    enum: monetary | non-monetary
  • nonMonetaryContributionDescription string

    The item of the non-monetary contribution being transferred to the company (any monetarily appraisable thing or proprietary right; not a service or work, and not the founder's own activities in founding the company).

  • nonMonetaryContributionValuationMethod string

    The method used to value the non-monetary contribution, based on the usual value of the thing or right (an auditor's valuation opinion is additionally required where the resulting share capital is at least EUR 25,000).

  • sharesPaidInFull boolean required

    Declaration that the founder has paid for the share(s) in full — a monetary contribution into a bank account opened in the name of the company being founded — before submission of the petition for entry, as the law requires.

Management board, supervisory board, procurator, auditor

  • managementBoardMemberFullName string required

    Full name of the member of the management board (the company's sole managing/representing body unless a supervisory board is also formed).

    classification: pii
  • managementBoardMemberPersonalIdentificationCode string required

    Personal identification code of the management board member.

    classification: sensitive-pii
  • managementBoardRepresentationRule enum optional

    Where the management board has more than one member, whether each member may represent the company alone or only jointly with (an)other member(s). Left unspecified where the board has a single member or the articles of association do not deviate from the statutory default.

    enum: each-member-solely | members-jointly
  • hasSupervisoryBoard boolean required

    Whether a supervisory board is formed for the company. Forming one is optional for an OÜ.

  • supervisoryBoardMemberFullName string

    Full name of a member of the supervisory board, where one is formed.

    classification: pii
  • supervisoryBoardMemberPersonalIdentificationCode string

    Personal identification code of the supervisory board member.

    classification: sensitive-pii
  • hasProcurator boolean required

    Whether a procurator (an agent holding a broad statutory power of representation) is appointed for the company at foundation.

  • procuratorFullName string

    Full name of the procurator, where one is appointed.

    classification: pii
  • procuratorPersonalIdentificationCode string

    Personal identification code of the procurator.

    classification: sensitive-pii
  • hasAuditor boolean required

    Whether an auditor is appointed for the company at foundation (independent of, and in addition to, the mandatory auditor valuation opinion that applies only where a non-monetary contribution and resulting share capital of at least EUR 25,000 is involved).

  • auditorNameOrFirm string

    Name of the auditor or auditing firm, where one is appointed.

Verification record

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 flow and states the current verification claim honestly.

Current claim

  • status: draft
  • verification.method: manual-source-review-v1
  • verification.lastVerifiedAt: 2026-07-08

This is GOV-1705: "GovSchema Standard Research" — catalog existing coverage, research an online government application/document system this registry is missing, document its fields, run a mock test, and author and catalog a new schema. Rather than open a brand-new (24th) jurisdiction or re-screen an older jurisdiction's already-confirmed dead ends, this cycle picked Estonia's own Business Formation gap: EE was the registry's most under-built jurisdiction at 1/6 verticals (only ee/ppa/e-residency-application, GOV-1698, National ID & Civic Documents), and its e-Residency programme's own flagship real-world use — a foreign national forming and remotely managing an Estonian company — has no corresponding Business Formation schema yet.

Candidate screening (Phase 1-2)

Candidate examined: e-Business Register (e-äriregister) live portal

ariregister.rik.ee is the public-facing e-Business Register site (company search, public data) and its companion filing portal ("ettevõtjaportaal") is where a founding petition is actually submitted. Multiple secondary sources (RIK's own English "e-Business Register Portal" page, e-Resident marketplace listings) confirm that submitting a petition requires digital signature authentication (Estonian ID card, Smart-ID, or Mobile-ID) before any field renders — an authenticated wizard, structurally the same kind of gate that blocked a live-field-level view of ee/ppa/e-residency-application's own eresident.politsei.ee SPA. Creating a throwaway account/session to walk the wizard live was ruled out, per this registry's standing discipline against creating accounts or submitting fabricated data against a live government system.

Picked approach: governing statute as primary source

Rather than a dead end, Estonia's company-formation law is unusually explicit about the petition's required content: the Commercial Code (Äriseadustik) §138 states verbatim what a memorandum of association "shall set out" (9 enumerated items), §139 states what the articles of association "shall set out" (8 enumerated items, one budget item for expedited-procedure use), and the Commercial Register Act (Äriregistri seadus, the newer 2023 act that split registry procedure out of the Commercial Code) §§12-14 state exactly which data items appear on the resulting registry card and shareholder list. This is the same "governing statute as primary source when the live application has no field-level transparency" technique this registry used for pl/mswia/wniosek-o-wydanie-paszportu (GOV-1685) and ee/ppa/e-residency-application (GOV-1698) — here applied to a second, independent EE agency/process, confirming the technique generalizes within a jurisdiction rather than being a one-off for a single agency's regulation.

Sources examined

Source 1 (primary, registry/petition procedure)
  • URL cited in source.url: https://web.archive.org/web/20240521195859/https://www.riigiteataja.ee/en/tolge/pdf/503012023001 (Wayback Machine snapshot, 21 May 2024, of Riigi Teataja's official English translation of the Commercial Register Act).
  • Why a Wayback snapshot, not a direct link: every route on riigiteataja.ee (including the /en/tolge/pdf/<id> "official translation PDF" route) is now served by a fully client-rendered Angular single-page app. Confirmed directly this cycle: a plain curl GET of both the human-facing consolidated-text page and the /tolge/pdf/ route returns an identical 51,744-byte HTML shell (<html data-critters-container>, a <title>Riigi Teataja</title>, and Angular bundle references) with content-type: text/html — no server-rendered legal text and no actual PDF bytes reach an unauthenticated automated client. The Wayback Machine's own snapshot (taken by a full browser crawl before or during a page-render) captured the underlying document as a real, extractable PDF (140,956 bytes, %PDF-1.4, produced by Apache FOP) — the same "government host hangs/blanks on direct fetch, use a Wayback snapshot" workaround this registry has used before for passports.gov.au/dfat.gov.au.
  • Extraction: the snapshot PDF's 18 pages were extracted with pdfjs-dist's text-content layer (no OCR needed — it is a real text layer, not a scan).
  • What it confirms: §9 (register comprises registry-card, public-file, registry-file data); §10 (personal-data submission rule — Estonian personal identification code, or in its absence a foreign code and date of birth; address to building/part-of-building accuracy); §12 (registry card data on a legal person — name, registry code, legal form, articles of association's effective date, registered office/address/e-mail, contact-person data, management board members' names and personal identification codes, financial-year note, other data); §13 (additional private/public limited company registry-card data — share capital amount, procurator data, register-of-securities notations); §14 (list of shareholders — names, personal identification codes, nominal values of shares); §40 (form and manner of delivery of a petition — notarised or digitally signed, submitted via the e-Business Register, not by post/ e-mail once electronic submission is possible); §§41-43 (registrar's review, 5-working-day standard timeline, and the specific requirements for the optional expedited 1-working-day procedure).
Source 2 (primary, memorandum/articles-of-association content)
  • URL: http://web.archive.org/web/20230810103145/https://www.riigiteataja.ee/en/tolge/pdf/509012023001 (Wayback Machine snapshot, 10 August 2023, of Riigi Teataja's official English translation of the Commercial Code, Äriseadustik).
  • Why a Wayback snapshot: same riigiteataja.ee SPA-shell problem as Source 1; the Wayback snapshot again resolved to a real, extractable PDF (621,189 bytes, 168 pages, same Apache FOP producer).
  • What it confirms: Chapter 18 "Foundation" (§§137-145): §137 (a private limited company may be founded by one or several natural or legal persons); §138 (memorandum-of-association content, 9 enumerated items — this document's core field source, and the source of the single-founder scoping decision below); §138(5) (a sole founder's memorandum of association is substituted by a notarised foundation resolution — modelled as an alternative form of the same memorandumOfAssociation document); §139 (articles-of-association content, 8 enumerated items, including legal reserve and management board representation rights); §139¹ (the simplified "articles of association used upon expedited procedure" — confirms that the standalone expedited pathway needs only a bounded subset of §139's items, informing which items this document treats as always-required); §140-141 (payment for shares — must be paid in full before the petition is submitted; monetary contributions go into a bank account opened in the founding company's own name); §142-143 (non-monetary contribution rules and valuation, including the EUR 25,000 auditor-verification threshold); §145 (additional registry-card data specific to a private limited company, including the financial year's beginning and end).
Source 3 (corroborating, registrar identity and portal operator)
Source 4 (checked, not used as a primary citation — the state fee amount)
  • Multiple secondary/practitioner sources (a legal-services blog, a chamber-of-commerce Q&A) converge on a EUR 200 standard / EUR 265 expedited-procedure state fee for entry of a private limited company, but this cycle could not retrieve the State Fees Act's (Riigilõivuseadus) own current fee-schedule section from a primary source within the same riigiteataja.ee SPA-shell obstacle, and no Wayback snapshot of the specific PDF/section carrying today's amount was located and confirmed. Disclosed rather than asserted: documents[].stateFeePayment is modelled as a required payment with no amount sub-object, and its sourceRef explicitly names this non-confirmation rather than silently omitting the caveat. The foundation-petition.json conformance fixture's projectedFoundationCosts value (EUR 265) is drawn from these secondary sources for realism only and is not asserted as a schema-level fact.

Field inventory (Phase 3)

29 fields[] entries and 4 documents[] entries, every one carrying its own sourceRef inline in schema.json, citing a specific Commercial Code/Commercial Register Act section. Summary by step:

| Step | Fields | Source | |---|---|---| | Company identity | businessName, registeredOfficeAddress, contactEmail | CC §138(2)(1); CRA §12(1),(5) | | Founder | founderFullName, founderResidenceAddress, founderPersonalIdentificationCode | CC §138(2)(2); CRA §10(1) | | Share capital and contribution | shareCapitalAmount, numberOfShares, nominalValuePerShare, contributionType, nonMonetaryContributionDescription, nonMonetaryContributionValuationMethod, sharesPaidInFull | CC §136, §138(2)(3)-(6), §140-143 | | Management board, supervisory board, procurator, auditor | managementBoardMemberFullName, managementBoardMemberPersonalIdentificationCode, managementBoardRepresentationRule, hasSupervisoryBoard, supervisoryBoardMemberFullName, supervisoryBoardMemberPersonalIdentificationCode, hasProcurator, procuratorFullName, procuratorPersonalIdentificationCode, hasAuditor, auditorNameOrFirm | CC §138(2)(7)-(8), §139(1)(7¹); CRA §12(7), §13(2) | | Foundation costs, legal reserve, financial year | projectedFoundationCosts, foundationCostsPaymentProcedure, legalReserveAmount, financialYearStartMonthDay, financialYearEndMonthDay | CC §138(2)(9), §139(1)(7), §145(1)(7) | | Documents | memorandumOfAssociation, articlesOfAssociation, nonMonetaryContributionValuationDocuments (conditional), stateFeePayment | CC §138(1),(3)-(5), §139, §142-143; Riigilõivuseadus |

Access notes and judgment calls

  1. Scoped to a single founder. The Commercial Code allows one or several founders (§137(1)), and §138(2)(4)'s "division [of shares] among the founders" only becomes a genuinely multi-valued data structure once a second founder exists. The v0.3 meta-schema's field type has no repeating-group/array primitive, so modelling more than one founder cleanly would require either N parallel flat field sets (an arbitrary, unbounded cap) or a documents[]-style "list of founders" escape hatch this meta-schema does not currently offer. Rather than force either, this document models the single-founder case explicitly — also the flagship real-world scenario this registry's own ee/ppa/e-residency-application schema exists to serve (an e-Resident forming and remotely managing their own one-person OÜ) — and defers multi-founder/co-founder scope to a future v1.1.0 or v2.0.0.
  2. managementBoardRepresentationRule is optional (required: false), not requiredWhen-gated. The Commercial Code states this data point is only meaningful "where the management board has more than one member" (§139(1)(7¹)), a fact this document does not otherwise track as a field (a single management-board-member scenario, matching the single-founder scope, makes a representation-rights choice moot). Left as a plain optional field rather than inventing an unconfirmed board-member-count field purely to gate it.
  3. Assigned/derived registry outputs are excluded from fields[]. The registry code (§22), the articles of association's own effective date once entered (§12(4)), and any registrar-assigned entry number are all outputs the registrar produces upon making the entry — never applicant-submitted data — and are not modelled, consistent with this registry's applicant-input-only convention.
  4. EMTAK activity classification and the e-Resident-specific "contact person" and virtual-office-address obligations are deliberately out of scope. Both are real, commonly-cited practical requirements (EMTAK is Estonia's statistical activity-classification code; a non-resident director/shareholder needs a registered contact person under a separate provision), but neither appears in the Commercial Code §§138-145 or Commercial Register Act §§9-14 sections this document cites as its primary source — including them here would mean sourcing them from a different, unreviewed statute this cycle did not verify. Left as a disclosed gap for a future revision rather than asserted on secondary-source authority alone.
  5. The exact current state fee amount is disclosed as unconfirmed, not asserted. See Source 4 above — documents[].stateFeePayment has no amount sub-object for this reason, unlike, e.g., ee/ppa/e-residency-application's confirmed EUR 150 fee.
  6. financialYearStartMonthDay/financialYearEndMonthDay use a MM-DD string, not the meta-schema's date type. A financial year's start/end (Commercial Code §145(1)(7)) is a recurring month-and-day pair, not a specific calendar date with a year component the way a date-typed field elsewhere in this registry (e.g. a document's issue date) would be; a pattern-validated MM-DD string avoids implying a fixed one-off year that does not exist in the source concept.
  7. The expedited (1-working-day) procedure is referenced in field sourceRefs (§139¹, §42) but not modelled as a separate exclusivity branch. §139¹'s simplified standard articles impose additional constraints this cycle chose not to fully encode (share capital "set out as a specific amount" only, no additional company-specific clauses permitted) since doing so correctly would require a second parallel articles-of-association field set — a real but separately-scoped extension, left for a future revision rather than half-modelled here.

Test run (Phase 4)

No live submission was attempted: the e-Business Register's actual filing portal requires an Estonian ID card, Smart-ID, or Mobile-ID digital signature session before any field renders, and even a successful petition creates a real, fee-liable legal entity in Estonia's commercial register — not a safe or reversible action to simulate against a live government system, consistent with this registry's standing discipline (the same reasoning ee/ppa/e-residency-application and pl/mf/zeznanie-pit-37 both documented for their own live/authenticated channels).

Instead, one fully hand-constructed mock record was built from this document's own field inventory — a fictional Finnish freelance consultant (the same kind of cross-border, remote-management scenario ee/ppa/e-residency-application exists to serve) founding a single-member OÜ with a EUR 2,500 monetary-only contribution, no supervisory board, no procurator, no auditor — and is committed as this document's conformance fixture (conformance/ee/rik/private-limited-company-foundation/1.0.0/foundation-petition.json). It was checked with a small ad hoc Node script (not committed) that compiles schema.json's own required/requiredWhen/validation rules (including the shared Condition grammar's equals leaf) and every documents[].required/requiredWhen rule, and evaluates them directly against the fixture:

`` $ node check.mjs registry/ee/rik/private-limited-company-foundation/1.0.0/schema.json conformance/ee/rik/private-limited-company-foundation/1.0.0/foundation-petition.json All required/requiredWhen/enum/pattern checks passed against conformance/ee/rik/private-limited-company-foundation/1.0.0/foundation-petition.json ``

Negative controls (each run against a variant payload, not committed as separate fixture files), confirming the script actually catches violations rather than passing vacuously:

  • (a) contactEmail: "not-an-email" — caught: fails the e-mail pattern.
  • (b) contributionType: "crypto" — caught: not in ["monetary","non-monetary"].
  • (c) businessName removed entirely — caught: FIELD businessName: required but missing.
  • (d) contributionType: "non-monetary" with nonMonetaryContributionDescription/nonMonetaryContributionValuationMethod omitted — caught: both flagged as required but missing, and the nonMonetaryContributionValuationDocuments document's own requiredWhen correctly fires (DOCUMENT nonMonetaryContributionValuationDocuments: required but missing) — confirming a field-level requiredWhen and a document-level requiredWhen gated on the same condition both evaluate consistently.
  • (e) documents.stateFeePayment omitted — caught: DOCUMENT stateFeePayment: required but missing.
  • (f) sharesPaidInFull: "yes" (a string, not a boolean) — caught: FIELD sharesPaidInFull: expected boolean, got string.
  • (g) shareCapitalAmount: -5 — caught: FIELD shareCapitalAmount: below minimum 0.01.

All seven negative controls were correctly identified by the script.

Both meta-schema validators were run against the finished document and pass clean:

``` $ node tools/validate.mjs registry/ee/rik/private-limited-company-foundation/1.0.0/schema.json ok registry/ee/rik/private-limited-company-foundation/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/ee/rik/private-limited-company-foundation/1.0.0/schema.json ok registry/ee/rik/private-limited-company-foundation/1.0.0/schema.json [v0.3]

1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

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 Registration Department of Tartu County Court or any government. The authoritative source is always the live government form and its official instructions.