This document outlines how our system processes and interprets employment data sourced from the Brønnøysund Register Center (brreg). It covers the data’s origin, reporting logic, historization, and considerations for statistical analysis.
We exclusively get Norwegian employment data Norwegian from brreg’s Enhetsregisteret (CCR), which is a monthly data source providing aggregated information from submitted A-melding.
A-melding is a monthly report submitted to NAV, SSB, and Skatteetaten that details income, employment relationships, tax deductions, as well as employer contributions like arbeidsgiveravgift and finansskatt. Rather than providing individual details, brreg supplies an aggregate count of these submissions.
Brreg categorizes employment data as follows:
| Employee Category | Representation | Explanation |
|---|---|---|
| No employees | 0 |
Indicates that the company has no active employment relationships. |
| 1–4 employees | Interval 1–4 |
The exact count is withheld (to comply with NAV and data protection guidelines), but it confirms submission of A-melding. |
| 5 or more employees | Exact number (e.g., 7) |
The precise employee count is provided. |
The interval 1–4 exists to maintain data privacy for smaller companies, ensuring that while we know they are reporting, the exact number of employees is not disclosed.
For operational purposes, when a specific numerical value is needed for companies reported in the 1–4 interval, our system defaults to using 1. We are considering future improvements to replace this default with a statistically derived value.
Our system maintains a historical record of employment data changes using two date fields: from_date and to_date.
to_date set to null is considered current. For example, if a company’s record has:"from_date": "2024-11-19T00:00:00",
"to_date": null
... it indicates that this data is actively in use.
from_date. At the same time, the previous record is updated with a to_date to mark the end of its validity. This historization ensures that our data reflects changes over time and maintains a clear audit trail of the employment data periods.Below is an example of how employment data is structured. Dummy UUIDs are used for confidentiality:
[
{
"uuid": "00000000-0000-0000-0000-000000000001",
"company_uuid": "00000000-0000-0000-0000-000000000010",
"employee_count": 0,
"employee_date": null,
"from_date": "2018-04-29T00:00:00",
"to_date": "2019-01-06T00:00:00",
"employee_count_from": 0,
"employee_count_to": 0,
"app_url": null
},
{
"uuid": "00000000-0000-0000-0000-000000000002",
"company_uuid": "00000000-0000-0000-0000-000000000010",
"employee_count": 0,
"employee_date": null,
"from_date": "2019-01-06T00:00:00",
"to_date": "2024-11-19T00:00:00",
"employee_count_from": 1,
"employee_count_to": 4,
"app_url": null
},
{
"uuid": "00000000-0000-0000-0000-000000000003",
"company_uuid": "00000000-0000-0000-0000-000000000010",
"employee_count": 5,
"employee_date": null,
"from_date": "2024-11-19T00:00:00",
"to_date": null,
"employee_count_from": 5,
"employee_count_to": 5,
"app_url": null
}
]
uuid & company_uuid: Unique identifiers for each record and the associated company.employee_count: Reflects the employee number used for computations:
0 indicates no employees.1 is used as a default for companies in the 1–4 interval.employee_date: The official date of the employment record. Not used by our new source.from_date & to_date:
from_date marks the start of the record's validity, i.e., when got notified of the change in number of employees.to_date marks the end of the record’s validity. A null value in to_date signifies that the record is current. When a change occurs (e.g., moving out of the 1–4 interval), a new record is initiated with a new from_date and the existing record’s to_date is updated.Explore statistical methods to derive a more representative default value for the 1–4 interval instead of always defaulting to 1. We consider 1 employee as a safe default for now.