CentraleVirksomhedsregister

The Central Business Register (CVR) is Denmark’s authoritative registry of all organizations—from one-person enterprises to multinational corporations. It is a core component of the Grunddatamodellen.

This page inherits shared contracts from Grunddatamodellen and only documents CVR-specific rules:

Register Information

Property	Value
Name	CentraleVirksomhedsregister
ID	EAPK_5CC19393_669B_4e92_9C5B_E0931BBF44D1
Domain	Business & Economic
Object Classes	27
Attributes	361
Source	2.2.0_CentraleVirksomhedsregister.xml

Overview

CVR captures:

Company entities: Legal identifiers (CVR number), names, addresses, industry codes
Ownership structures: Ownership relations, stakeholders, beneficial owners
Leadership: Management boards, executive officers, authorized signatories
Financial data: Accounting reports, taxes, balance sheets
Operations: Production units, employees, business activities
Relations: Dependencies between companies, group structures, ownership chains

Agent Start Here

If an agent arrives from SPHERE or a leaf page, use this page as the shortest collection-specific handoff.

1. Pick the right leaf first

User need	Start leaf	Primary CVR entities	Spatial path	Time rule
Identify a legal business entity	\|Firms	`Virksomhed`, `CVREnhed`, `Navn`, `Virksomhedsform`	registered office via `CVRAdresse` → DAR	current = `registreringTil IS NULL` and `virkningTil IS NULL`
Find business activity / sector	\|Economic Activities	`Branche`, `Virksomhed`, `Produktionsenhed`	via `CVRAdresse` → DAR	current = `registreringTil IS NULL` and `virkningTil IS NULL`
Locate firms or establishments	\|Business Locations	`Produktionsenhed`, `Virksomhed`, `CVRAdresse`	`CVRAdresse` → `Adresse` → geometry	current = `registreringTil IS NULL` and `virkningTil IS NULL`
Find owners / controllers	\|Ownership and Governance	`Ejerforhold`, `Reelejerrelation`, `Legalejerrelation`, `Virksomhed`	map owned entity via `Virksomhed` → `CVRAdresse` → DAR	time-slice on relation entity, not only on `Virksomhed`
Find accounts / employment	\|Economics and Employment	`Regnskab`, `Beskæftigelse`, `Virksomhed`, `Produktionsenhed`	map reporting entity via `CVRAdresse` when needed	respect both accounting period and bitemporal validity
Measure service availability	\|Services and Amenities	`Produktionsenhed`, `Branche`, `CVRAdresse`	service point via `Produktionsenhed` → `CVRAdresse` → DAR	current = `registreringTil IS NULL` and `virkningTil IS NULL`

2. Apply the minimum interpretation rules

Virksomhed = legal entity anchor
Produktionsenhed = operational site / establishment
CVRAdresse = text-based address object, not geometry by itself
registrering* = system transaction time
virkning* = real-world legal validity time

3. Use the semantic bridge before entity pages

Key Entity Types

virksomhed - Company/organization core entity
ledelse - Leadership and board members
regnskab - Financial accounts
produktionsenhed - Production units and establishment records
ejerforhold - Ownership relationships
reelejerrelation - Beneficial ownership links
ledelserelation - Leadership role assignments
kapitalforhold - Capital share relationships
And 19 others (see links below)

Minimal Decision Matrix

If the user asks…	Start from	Prefer access path	Why
”Which companies match these filters?”	`Virksomhed` or `Produktionsenhed`	GraphQL	push filters early and avoid bulk joins
”Give me all businesses in this municipality / sector”	relevant leaf → entity bundle	GraphQL if bounded, file download if broad	depends on expected result volume
”Build a full local snapshot”	collection index → entity catalog	File download	CVR is normalized and bulk-friendly
”Show owners / ownership chain”	ownership leaf → relation entities	GraphQL for targeted lookup, file download for graph rebuild	ownership spans several relation entities
”Geocode business data”	business-locations leaf	either, but DAR join required	CVR stores address components, not geometry

How to Read CVR’s Normalized Structure

CVR is highly normalized. This means many sub-entities are not separate “themes” but structural parts of one business-domain model.

Tip: If you have a specific question, start from a Leaf rather than the entity catalog below. Leaves are purpose-specific entry points:

Firms — What firm is this, as a legal registered entity?

Economic Activities — What economic activity does a business perform?

Business Locations — Where does a business physically operate?

Ownership and Governance — Who owns, controls, or governs a firm?

Economics and Employment — What are the economic and employment characteristics of a firm or establishment?

Services and Amenities — What services or amenities are available at or near a location?

For humans and AI, the key interpretation is:

virksomhed is the anchor entity (start here)
many sub-entities are attached properties or relations (for example leadership, branches, ownership, accounts)
in file-download workflows, each entity is delivered separately and must be joined into an analysis-ready model

Practical Rule

Treat CVR as a joinable entity graph, not as one flat table.

Add a Semantic Layer

Use a second layer that maps technical entities to business meaning, so key concepts do not get hidden inside normalized structures.

Semantic organization guide: CVR Semantic Organisation
Machine-readable semantic map: cvr.semantic.entity-attribute-map.v1.json

Access Strategy: GraphQL vs File Download

Access path	Best when	Trade-off
GraphQL	You have hard filters (industry, municipality, active status, time slice) and want targeted records	Less post-processing, more query design effort
File Download API	You need broad extraction or full snapshots without strict early filters	Fast bulk retrieval, but requires local joins across many entities

Decision Rules

Use GraphQL when the user already gives municipality, activity code, status, owner, or time filters.
Use File Download when the user needs broad extraction, cross-entity reconstruction, or repeatable local analysis.
Use DAR join after CVR selection, not before, unless the primary task is address matching or geocoding quality control.
Use Produktionsenhed for operational location questions and Virksomhed for legal-registration questions.

Why this matters

If you pull CVR through file download, you typically download multiple entities independently, then reconstruct business objects by joining on CVR identifiers and temporal keys.

Join Blueprint (Human + AI)

Canonical join keys

Key	Meaning	Where used
`CVREnhedsId`	stable business-side identifier	joins legal entity, ownership, leadership, financial records
`pnummer`	production-unit identifier	establishment-level analysis
`id_lokalid`	record-level primary key	entity-local identity
`kommunekode` + `vejnavn` + `husnummer` (+ `bogstav` / `postnummer`)	address matching tuple	CVR → DAR geocoding

Task recipes

Task	Base entity	Attach	Output shape
Economic activity lookup	`Virksomhed` or `Produktionsenhed`	`Branche`, `Navn`, optional `CVRAdresse`	business list or establishment list
Business geolocation	`Produktionsenhed`	`CVRAdresse` → DAR	point dataset
Beneficial ownership	`Virksomhed`	`Reelejerrelation`, `Legalejerrelation`, `Ejerforhold`	graph / relation view
Financial extraction	`Virksomhed`	`Regnskab`, `Beskæftigelse`, optional `Revision`	yearly panel or current snapshot

1. Build base table

load virksomhed as base
keep only required records (for example active entities)
retain stable IDs (CVREnhedsId) and temporal fields (registreringFra, relevant virkning fields)

2. Attach core relation groups

produktionsenhed (operational units)
ledelse + ledelserelation (management)
ejerforhold + reelejerrelation (ownership)
regnskab (financials)

3. Add spatial linkage

extract address components from CVR
normalize text and number format
join to DAR for coordinates/geocoding

4. Build analysis views

company-centric view (one row per virksomhed)
establishment-centric view (one row per produktionsenhed)
relation/graph view (ownership and leadership networks)

Current vs Historical Queries

Use this rule before any extraction:

Current snapshot: filter registreringTil IS NULL and virkningTil IS NULL
Historical slice: filter by target date inside virkningFra <= t < virkningTil (or open-ended validity)
Audit / transaction history: inspect registreringFra and registreringTil

Do not treat registrering* and virkning* as interchangeable.

AI Execution Contract (Recommended)

For machine execution, use the canonical source manifest plus a compact playbook:

Canonical source manifest: cvr.source.manifest.v1.json
CVR access playbook: cvr.access.playbook.v1.json
CVR semantic map: cvr.semantic.entity-attribute-map.v1.json
Shared temporal superclass: grunddata.common.temporal-superclass.v1.json
Shared access pattern: grunddata.common.access-pattern.v1.json

The playbook is intended to prevent two common failure modes:

treating normalized sub-entities as independent datasets without join planning
extracting full snapshots and only later discovering that required hard filters were missing

If a referenced machine-readable companion is unavailable in the published site, treat this page plus CVR Semantic Organisation as the canonical human-readable fallback.

Entity Catalog

Each entity type is documented separately:

Entity	Purpose
\|virksomhed	Core company entity with identification
\|ledelse	Leadership roles and board members
\|regnskab	Annual financial accounts
\|produktionsenhed	Production units / establishments
\|ejerforhold	Direct ownership relationships
\|reelejerrelation	Beneficial ownership tracking
\|ledelserelation	Leadership assignments

Role of the Collection Page

This page is intentionally execution-oriented. It should tell humans and agents how to route from a question to the right entities, joins, temporal filters, and access path.

Most concept-heavy interpretation should live in the relevant leaves.

See all 27 entity types in the folder

Access CVR Data

Service Access

GraphQL: Query with flexible field selection → Datafordeleren GraphQL Guide
OData / REST: Standard RESTful endpoints
File Downloads: Bulk exports from Datafordeleren portal
SOAP: Legacy SOAP services

Getting Started

Create a Datafordeleren account: https://portal.datafordeler.dk/
Generate an access token
Query via GraphQL, REST, or download (see Datafordeleren services)

Register Details

Definition: Ingen definition tilgængelig.

Comment: —

Example: —

Relationships to Other Registers

CVR entities connect to other Grunddatamodellen registries:

Person: CVR leadership roles link to individual persons via Person register
DanmarksAdresser (DAR): Company addresses are linked to DAR
Matrikel: Production units and offices may be linked to cadastral parcels
Ejerfortegnelsen: Company ownership of property appears in Ejerfortegnelsen
DAGI: Companies are classified by administrative division (municipality, region)

Semantic Classification (NOIR)

CVR data spans all NOIR levels:

Nominal: CVR numbers, company names, industry codes (not orderable)
Ordinal: Company size classifications, management tier levels
Interval: Founded date, registration date (no natural zero)
Ratio: Employee count, revenue, capital amounts (true zero)

Bitemporality

CVR maintains historical records with both:

Transaction time: When a change was recorded in the system
Valid time: When the change took effect in reality

Example: “What was company X’s board composition on 2020-06-15?” requires valid-time queries.

Explorer