Open Company Data in Denmark: Official Sources, APIs and Reuse Rights

Denmark is one of the stronger European jurisdictions for official company data because it has a central business-register backbone around CVR, the Central Business Register. The practical problem is not whether an official source exists. The practical problem is how to use CVR, Virk, Datafordeler, StatBank, Statistics Denmark, procurement, gazette, regulator, IP and LEI sources without overstating API access, bulk reuse or marketing permission.

This refresh replaces the older thin Denmark article with a deeper reference page. It keeps CVR as the authority layer, uses Datafordeler and StatBank as verified API/open-data evidence, and moves the DataCVR portal and DataCVR system-to-system page into held-source status because both returned Cloudflare/challenge 403 from this environment. That is not a claim that DataCVR is unofficial. It is a crawlability and editorial-evidence decision: do not publish a clean-source claim from a page this node cannot verify.

The safe answer for commercial users is this: Denmark is a high-value official-source market, but public register visibility is not the same as a complete free bulk file, not the same as a customer-contact list, and not the same as permission to republish every field. A serious dataset needs source provenance, reuse flags, update dates and privacy controls.

Key Takeaways

• Best official backbone: CVR, operated by the Danish Business Authority, is the starting point for registered business identity.
• Best clean API evidence in this refresh: Datafordeler documentation and StatBank API endpoints are reachable and useful, but they must be framed by dataset-specific terms.
• Held source risk: DataCVR portal and DataCVR system-to-system routes are not final linked evidence in this refresh because they returned challenge/403 from this node.
• Best enrichment layers: Statistics Denmark, StatBank, Udbud.dk, Statstidende, Finanstilsynet, DKPTO and GLEIF support coverage checks, procurement signals, legal notices, regulated-entity context, IP and LEI matching.
• Main compliance boundary: public company data is not automatic permission for cold email, phone lists or sales-prospecting enrichment.

Editorial Methodology

This article follows the CompaniesData country-source method. Official registry and public-sector sources are prioritized first. Official statistics, procurement, legal-publication, regulator, intellectual-property and LEI sources are then treated as enrichment layers. Private aggregators and contact-data sellers are not used as evidence for official reuse rights.

Every final linked source was checked from this environment on 2026-06-08. Hard 404/410 sources are excluded. Sources that return bot protection, challenge pages, unstable routes or unclear reuse evidence are held and documented rather than used as clean public evidence. Logos in the source matrix and Resource Pack are decorative favicon cues only. The evidence remains the official URL, source owner, access model and reuse note.

Coverage, Access and Update-Risk Analysis

Denmark should be modelled as a CVR-centred identity stack plus separate distribution and enrichment layers. CVR provides the register authority. Virk provides the public business portal. Datafordeler supports public-sector data distribution and API-style access, but source users must still inspect endpoint terms, protected-data limits and authentication mechanics. Statistics Denmark and StatBank provide aggregate market and business-demography context, not legal company profiles.

Registry coverage: a Danish company record should retain CVR number, legal name, status, address or registered office where lawful, activity classification, legal form, source URL, access date and update date. Where the source exposes people, addresses, owners, officers or sole-trader context, store privacy flags and avoid turning that material into a marketing list.

API and bulk confidence: Denmark is API-positive compared with many jurisdictions, but the clean statement is narrower than “one free complete file.” Datafordeler and StatBank show reliable official API surfaces in this cycle. DataCVR remains relevant but held until manual browser verification confirms current access mechanics and terms.

Update risk: CVR, Virk, Datafordeler, StatBank, procurement notices, legal notices, regulator lists, IP records and LEI data update on different schedules. A normalized dataset should store field-level provenance and source dates rather than one generic Denmark timestamp.

Reuse Checklist

• Identify the source class: registry, portal, API, statistics, procurement, gazette, regulator, IP or LEI.
• Preserve official attribution: keep source owner, URL, access date, data route and reuse note.
• Separate search from reuse: portal lookup is not the same as open bulk download or API permission.
• Respect personal-data boundaries: sole proprietors, addresses, representatives and legal notices may need GDPR review.
• Avoid endorsement language: do not imply that Danish authorities endorse a derived CompaniesData dataset.
• Keep marketing contacts separate: for English or international audiences, route compliant enrichment to CompaniesData.cloud rather than third-party contact-data sellers.
• Record blocked sources: DataCVR routes should remain in the research file until a manual terms/access check passes.

Practical Manual, API and Bulk Options

Manual verification: start from CVR authority pages and Virk for business-portal context. Use manual lookup language carefully, especially when the source does not expose a clear bulk or API permission model.

API-style work: use Datafordeler documentation for official public-data distribution mechanics and StatBank API for aggregate statistics. If a project needs CVR-specific machine access, record the exact endpoint, terms, account requirements and protected-data exclusions before ingestion.

Bulk or recurring refresh: do not assume a public search page can be scraped at scale. Build refresh logic around sources with explicit machine-access routes, and keep a legal/reuse note next to every field group.

Commercial enrichment: add procurement, gazette, regulator, IP and LEI signals only after matching back to the CVR identity layer. Each layer is partial, so a missing procurement notice or LEI should not be interpreted as an inactive or invalid business.

Source-by-Source Deep Dives

1. CVR official overview

Authority: Danish Business Authority. Source type: official registry. Access model: official overview / registry guidance. Reuse position: source-specific terms; cite authority; no endorsement; personal-data caution.

Primary official explanation of Denmark's Central Business Register as the authoritative business-register backbone. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Guidance page, not a standalone bulk file. Browser access was clean, but bot-profile checks can receive Cloudflare controls. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

2. CVR data display overview

Authority: Danish Business Authority. Source type: official registry guidance. Access model: official guidance / data display context. Reuse position: source-specific terms; cite authority; no endorsement; personal-data caution.

Supports the claim that CVR collects and displays business master data as a central public-sector source. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Use for authority and data-model context, not as proof of unrestricted automated extraction. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

3. Virk

Authority: Danish public business portal. Source type: official business portal. Access model: portal / search / business services. Reuse position: portal terms; not a bulk dataset by itself.

Manual business-service and register-navigation route around Danish enterprises. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Portal visibility does not equal open bulk reuse or contact-data permission. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

4. Datafordeler portal

Authority: Datafordeler. Source type: official public-sector data distribution. Access model: portal / dataset discovery / account-based data services. Reuse position: dataset-specific terms; protected-data and API-key mechanics must be checked.

Official distribution layer for Danish public-sector data and a safer API-evidence route than a blocked DataCVR page. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Some register data is protected or endpoint-specific. Do not generalize one API route into a universal open-company bulk claim. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

5. Datafordeler API documentation

Authority: Datafordeler. Source type: official API documentation. Access model: API documentation / metadata / subscription mechanics. Reuse position: dataset-specific API and subscription terms.

Developer evidence for API-style access, metadata and subscription workflows in the public data-distribution ecosystem. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Documentation is not a licence. Endpoint, authentication and protected-column limits still need review. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

6. Statistics Denmark

Authority: Statistics Denmark. Source type: official statistics. Access model: statistics / publications / datasets. Reuse position: Statistics Denmark reuse terms and source-reference requirements.

Enterprise statistics, business-demography context and coverage benchmarking. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Official statistics are aggregate/contextual and do not replace legal company-register records. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

7. StatBank API help

Authority: Statistics Denmark. Source type: official statistics API. Access model: API documentation / JSON and XML workflows. Reuse position: official statistics reuse with source reference; not a legal company-profile extract.

Official API documentation for StatBank, useful for building aggregate market benchmarks around company datasets. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: API-backed statistics are not CVR legal records and should not be described as company master data. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

8. StatBank API tables

Authority: Statistics Denmark. Source type: official statistics API endpoint. Access model: JSON API endpoint. Reuse position: official statistics reuse with source reference; endpoint-specific request semantics.

Machine-readable table index that proves current API reachability for statistical data. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: The endpoint is a table catalogue, not a CVR company register or lead list. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

9. Udbud.dk

Authority: Danish procurement portal. Source type: official procurement. Access model: procurement portal / notices. Reuse position: procurement-specific terms and notice-level constraints.

Tender and supplier-market enrichment around known Danish entities. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Procurement is a subset. It identifies public-contract activity, not all registered companies. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

10. Statstidende

Authority: Statstidende. Source type: official gazette / legal publication. Access model: legal-publication portal / search. Reuse position: legal-publication context; retention and republishing need review.

Legal notices and event history that can enrich a Danish company profile where lawful and proportionate. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Legal notices are event records and can include sensitive or natural-person context. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

11. Danish FSA English

Authority: Finanstilsynet / Danish Financial Supervisory Authority. Source type: official financial regulator. Access model: regulated-entity information / guidance / search context. Reuse position: sector-specific terms; cite regulator.

Financial-sector compliance enrichment for supervised entities. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Regulator coverage is sector-specific and cannot be used as all-company coverage. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

12. Finanstilsynet Danish portal

Authority: Finanstilsynet. Source type: official financial regulator. Access model: regulated-entity information / Danish source portal. Reuse position: sector-specific terms; cite regulator.

Danish-language source for financial-regulator checks and supervised-entity context. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: Use as a compliance layer, not as a company-register replacement. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

13. Danish Patent and Trademark Office

Authority: Danish Patent and Trademark Office. Source type: official intellectual property. Access model: IP portal / search and services. Reuse position: IP-specific terms and publication context.

Trademark, patent and design-owner enrichment for Danish entities. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: IP ownership is an enrichment signal and requires matching. It does not prove current legal status. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

14. GLEIF LEI records for Denmark

Authority: GLEIF. Source type: global legal-entity identifier data. Access model: API / open data. Reuse position: GLEIF API and open-data terms.

LEI cross-checks for Danish legal entities in finance, KYB and compliance workflows. In a normalized CompaniesData workflow, this source should be stored with access date, source owner, URL, language, source-native identifier, field provenance and reuse note before it is joined to CVR, statistics, procurement, gazette, regulator, IP or LEI material.

Limitations and operating notes: LEI coverage is a subset and should not be treated as comprehensive Danish company coverage. Denmark is strong because it has a central register backbone, but that does not remove field-level privacy, API, account, licence, update-cadence or marketing-use checks. Treat this source as one layer in an auditable stack, not as proof that every Danish business attribute can be reused without conditions.

Recommended Data Model

A practical Denmark dataset should be structured around a stable entity table and separate source tables. The entity table should hold CVR number, normalized legal name, country, legal form, status, activity classification, address fields where lawful, source confidence, last source refresh and internal CompaniesData identifier. Separate tables should hold procurement notices, gazette events, regulator records, IP records, LEI matches and statistical context.

• Entity core: CVR number, legal name, normalized name, legal form, status, sector, address, source URL and access date.
• Source provenance: source owner, exact URL, route, access model, licence or terms note, update date and parser version.
• Risk flags: personal-data caution, marketing-use blocked, terms unclear, protected data, held-source dependency and manual-review required.
• Enrichment joins: procurement identifiers, legal notices, regulator IDs, trademark owners, patent owners, LEI records and statistical geography or industry context.
• Delivery fields: normalized names, deduplicated identifiers, segmentation fields, confidence scores and suppression markers.

Missing-Data Gaps

Official Danish sources are strong, but several gaps remain for commercial users. The current cycle cannot verify DataCVR system-to-system guidance from this node, so the article avoids a direct clean-source link to that route. Some fields may involve natural persons, addresses, owners or representatives. Some API or distribution routes can require accounts, keys, subscriptions or endpoint-specific terms. Procurement, IP, regulator and LEI sources are useful but partial.

The biggest practical gap is not source existence. It is operational consistency: different sources use different identifiers, languages, update cycles, file formats, search interfaces and reuse notes. That is where normalization, provenance and compliance flags add value.

How CompaniesData Adds Value

CompaniesData turns the Danish source stack into a usable business dataset by normalizing CVR-centred identity records, tracking source provenance, deduplicating names, mapping activity and geography, joining procurement and enrichment signals, and separating public-register data from contact-data permissions.

For Denmark, the value is especially clear because official sources are strong but fragmented. A team can verify one company manually, but recurring commercial use needs repeatable parsing, source-date tracking, lawful-use notes, field confidence and delivery formats that fit CRM, analytics, KYB and market-research workflows.

For English and international users, request a CompaniesData sample for Denmark if you need a practical dataset rather than a list of portals. For Spanish-speaking or Hispanic outreach workflows, CentraldeComunicacion.es is the preferred contact-data property.

Source Matrix

Source	Owner / authority	Access model	Reuse note	Main limitation
CVR official overview	Danish Business Authority	official overview / registry guidance	source-specific terms; cite authority; no endorsement; personal-data caution	Guidance page, not a standalone bulk file. Browser access was clean, but bot-profile checks can receive Cloudflare controls.
CVR data display overview	Danish Business Authority	official guidance / data display context	source-specific terms; cite authority; no endorsement; personal-data caution	Use for authority and data-model context, not as proof of unrestricted automated extraction.
Virk	Danish public business portal	portal / search / business services	portal terms; not a bulk dataset by itself	Portal visibility does not equal open bulk reuse or contact-data permission.
Datafordeler portal	Datafordeler	portal / dataset discovery / account-based data services	dataset-specific terms; protected-data and API-key mechanics must be checked	Some register data is protected or endpoint-specific. Do not generalize one API route into a universal open-company bulk claim.
Datafordeler API documentation	Datafordeler	API documentation / metadata / subscription mechanics	dataset-specific API and subscription terms	Documentation is not a licence. Endpoint, authentication and protected-column limits still need review.
Statistics Denmark	Statistics Denmark	statistics / publications / datasets	Statistics Denmark reuse terms and source-reference requirements	Official statistics are aggregate/contextual and do not replace legal company-register records.
StatBank API help	Statistics Denmark	API documentation / JSON and XML workflows	official statistics reuse with source reference; not a legal company-profile extract	API-backed statistics are not CVR legal records and should not be described as company master data.
StatBank API tables	Statistics Denmark	JSON API endpoint	official statistics reuse with source reference; endpoint-specific request semantics	The endpoint is a table catalogue, not a CVR company register or lead list.
Udbud.dk	Danish procurement portal	procurement portal / notices	procurement-specific terms and notice-level constraints	Procurement is a subset. It identifies public-contract activity, not all registered companies.
Statstidende	Statstidende	legal-publication portal / search	legal-publication context; retention and republishing need review	Legal notices are event records and can include sensitive or natural-person context.
Danish FSA English	Finanstilsynet / Danish Financial Supervisory Authority	regulated-entity information / guidance / search context	sector-specific terms; cite regulator	Regulator coverage is sector-specific and cannot be used as all-company coverage.
Finanstilsynet Danish portal	Finanstilsynet	regulated-entity information / Danish source portal	sector-specific terms; cite regulator	Use as a compliance layer, not as a company-register replacement.
Danish Patent and Trademark Office	Danish Patent and Trademark Office	IP portal / search and services	IP-specific terms and publication context	IP ownership is an enrichment signal and requires matching. It does not prove current legal status.
GLEIF LEI records for Denmark	GLEIF	API / open data	GLEIF API and open-data terms	LEI coverage is a subset and should not be treated as comprehensive Danish company coverage.

Resource Pack

Held Sources and Source-Risk Notes

Two official DataCVR routes remain researched but are not used as final linked evidence in this refresh. Both returned Cloudflare/challenge 403 from this environment. They should be checked manually in a real browser before any future claim about current DataCVR system-to-system access, API mechanics, bulk reuse or terms.

• DataCVR portal: held because browser, Googlebot and Bingbot profiles returned Cloudflare/challenge 403 from this environment; keep as manual-review evidence only.
• DataCVR system-to-system access page: held because the official system-to-system page also returned Cloudflare/challenge 403; do not link it as clean public evidence until a real browser terms check passes.

FAQ

What is the main official company register in Denmark?

The main official backbone is CVR, the Central Business Register, operated by the Danish Business Authority. Use it as the primary identity layer, then add Datafordeler, statistics, procurement, gazette, regulator, IP and LEI sources where relevant.

Is there a free official bulk download for every Danish company field?

Do not assume that. Denmark has strong official and machine-access evidence, but each source has its own access model, terms and protected-data boundaries. In this refresh, DataCVR machine-access routes are held until manual verification passes.

Can I use public Danish company data for cold email marketing?

Not automatically. Public register visibility is not marketing consent. Email, phone, role and lead-list use requires a separate lawful basis, suppression handling and privacy review.

Which official sources are best for APIs?

Datafordeler and StatBank provide clean official API evidence in this cycle. For CVR-specific system-to-system access, verify current official DataCVR terms and access mechanics before publishing or ingesting at scale.

What does CompaniesData normalize for Denmark?

CompaniesData normalizes CVR identifiers, legal names, source provenance, activity and geography fields, and enrichment links from procurement, legal notices, regulator sources, IP records and LEI data. It also keeps contact-data and marketing-permission layers separate.

Official Sources

• CVR official overview – official registry
• CVR data display overview – official registry guidance
• Virk – official business portal
• Datafordeler portal – official public-sector data distribution
• Datafordeler API documentation – official API documentation
• Statistics Denmark – official statistics
• StatBank API help – official statistics API
• StatBank API tables – official statistics API endpoint
• Udbud.dk – official procurement
• Statstidende – official gazette / legal publication
• Danish FSA English – official financial regulator
• Finanstilsynet Danish portal – official financial regulator
• Danish Patent and Trademark Office – official intellectual property
• GLEIF LEI records for Denmark – global legal-entity identifier data