🇳🇴 Norway Bankruptcy Notices Scraper — Brreg Konkurs Gazette

Every Norwegian company bankruptcy, the day it is declared — with the court, the case number, the appointed trustee's name and e-mail address, the creditor claim deadline and the first creditors' meeting.

This actor reads Konkursregisteret's official gazette at w2.brreg.no/kunngjoring, the statutory publication the Brønnøysund Register Centre is required to make. Roughly 14,000–15,000 notices a year, about 3,500 of them fresh bankruptcy openings, covering the whole country.

---

🤔 What does this actor do?

It sweeps the gazette over any date range you choose, then opens each notice's official detail page and extracts the fields that only exist there.

• 🏢 Company name + 9-digit organisation number — joinable to any Norwegian company dataset
• ⚖️ Court (tingrett) and case number — e.g. OSLO TINGRETT, 26-114308KON-TOSL/08
• 👤 Trustee (bostyrer): name, e-mail address, postal address — the one human who controls the estate
• ⏳ Creditor claim deadline (frist for å melde krav) + days remaining
• 📅 Cut-off date (fristdagen) — the date that decides which transactions can be clawed back
• 🏛️ First creditors' meeting: date, time and courtroom
• 🧾 Notice type: opening, compulsory dissolution, compulsory liquidation, proceedings stopped, estate closed
• 💡 Åpnet etter: Oppbud — the debtor filed for their own bankruptcy. Present on 89.4% of openings (76 of 85, measured below), and one of the strongest credit signals in the dataset
• 🏗️ Industry — the debtor's own Bransje/stilling line, free-text NACE description — plus section / division / group filters
• 📍 County, municipality, postal code and city
• 💰 Dividend percentage and distribution day on closure notices
• 🔗 Free join to Brreg's open company register: NACE code, legal form, founding date, employee count, VAT status, website

---

🎯 Who buys this data

Buyer	What they do with a row
Debt collection / credit control	A claim deadline is a hard countdown. Miss it and the debt is worthless. Every opening notice with a trustee e-mail is an actionable filing.
Insolvency & restructuring law firms	Competitive intelligence on which firms are being appointed as bostyrer, by which court, and how often.
Credit bureaus & risk teams	Same-day insolvency events keyed by organisation number, with the court record behind them.
Asset buyers & liquidators	Estates in a chosen industry and county, with the trustee's e-mail to contact about the assets.
B2B sales & CRM hygiene	Suppress bankrupt customers before you invoice them, and catch a customer's insolvency before the AR ages.
Financial journalists & researchers	A structured, queryable feed of the statutory record.

---

🆚 Why not just use Brreg's free open data?

Brreg publishes an excellent free API — and it cannot answer any of the questions above. Verified 2026-09-04:

• data.brreg.no/enhetsregisteret/api/docs contains zero kunngjøring endpoints.
• The entity API exposes a single bare boolean: "konkurs": true.

That flag cannot tell you when the bankruptcy opened, which court opened it, the case number, who the trustee is, the trustee's e-mail, the claim deadline, the fristdag, or the first creditors' meeting. All of that lives on the gazette page and nowhere else. That gap is this actor.

This actor also uses the free API — for what it is good at. Turn on Enrich from the open company register and every row with an org number gains an entity block at no extra charge: legal form on 100% of rows, and NACE code, founding date, VAT status and business address on the 44.9% whose company record the register has not yet deleted (measured below).

---

📊 Measured field fill rates

Per-notice-type fields are absent by design, not missing. A closure notice ("Avslutning av bobehandling") legally carries only name, address, org number and case number — there is no trustee or claim deadline to publish. The actor branches on notice type and emits honest nulls rather than inventing values.

Measured on 316 notices, 30 August – 5 September 2026, whole country, category 51, all sub-types, every row detail-fetched (Apify run MGGjNb8cGiVqd0hzA). Notice-type mix in that window: 168 × Innstilling av bobehandling, 85 × Konkursåpning (incl. 1 amendment), 48 × Tvangsoppløsning, 12 × Avslutning av bobehandling, 3 × Tvangsavvikling.

Field	Fill	Note
kid, detailUrl, companyName, orgNumber, registryId, subjectType, brregEntityUrl, noticeDate, noticeDateIso, noticeType, noticeTypeCode, noticeTypeName, county, countyNumber, regionName	100% (316/316)	list page
noticeTypeFull, publishedByRegister, publishedDate, publishedDateIso, isAmendment, isBankruptcyOpening, hasTrusteeContact, fields	100% (316/316)	detail page, every notice type
caseNumber	100% (316/316)
court	99.4% (314/316)	the 2 exceptions are notices from the same court that simply omit the Tingrett line; the court is still encoded in caseNumber (26-140160KON-TIOF/TVAD). A Konkursåpning i hjemlandet — a foreign parent's insolvency issued by Foretaksregisteret rather than a court — likewise has no Norwegian court or case number; none landed in this particular window
postalCode, city, addressRaw	100% (316/316)	every published address yields a postcode and a city
addressStreet	98.4% (311/316)	5 debtors publish only a postcode and city, with no street line
trusteeName, trusteeEmails, trusteeEmail, trusteeAddress, claimDeadline, claimDeadlineIso, daysUntilClaimDeadline, cutOffDate, cutOffDateIso, firstMeetingDate, firstMeetingTime, firstMeetingVenue, industry	43.0% overall (136/316) — 100% of the 85 bankruptcy openings	only opening/liquidation notices carry a trustee, a deadline and an industry line; 53% of this window was Innstilling av bobehandling
openedDate, openedDateIso	26.9% (85/316) — 100% of openings
openedAfter (Oppbud)	24.1% (76/316) — 89.4% of openings	debtor's own petition rather than a creditor's — a strong credit signal
rulingPronouncedDate	53.2% (168/316)
rulingDate	16.1% (51/316)
dividendPercent, distributionDay	closure notices only — 3.8% (12/316)
previousNames	2.2% (7/316)
amendmentHeadline	0.3% (1/316)	present only on amendment notices
country, countryCode, homeCountryRegistrationNumber	0% in this window	foreign-parent (NUF) notices only; none occurred in these 7 days
filterIndustrySectionName, filterIndustryDivisionName, filterIndustryGroupName	0% here — by definition	these echo your industry filter, not the row. See the note below

The free company-register join (enrichWithEntityRegistry) measured separately on the same window, 316 rows all with an org number (run x3VQY4wlA6BrJ5nyQ):

entity.* sub-field	Fill
organisasjonsform (legal form)	100% (316/316)
naceCode, naceDescription, registeredDate, foundedDate, vatRegistered, bankruptFlag, businessAddress	44.9% (142/316)
employees	9.5% (30/316)
website	4.1% (13/316)

The join returns an object for every row with an org number, but a company the register has already deleted (slettedato — the normal end state after a closure notice) is served as a name-and-legal-form stub, with NACE and the rest null. That is the open API's own behaviour, not a fetch failure. Because this window was 53% closure notices, only 44.9% of rows still had a live entity record.

⚠️ industry vs filterIndustry* — which one is the row's own NACE

• industry is the debtor's own Bransje/stilling line from the notice. Detail-page only, 43.0% overall / 100% of openings above. This is per-row data.
• entity.naceCode / entity.naceDescription is the structured NACE code from the company register, when you turn the free join on. Also per-row data.
• filterIndustrySectionName / filterIndustryDivisionName / filterIndustryGroupName are a query echo: they repeat the industry filter you sent so a landed dataset is self-describing. They are identical on every row of a run and null on every row of a run with no industry filter (measured: 0 of 547 filled unfiltered, 20 of 20 filled with the same constant under industrySection: 70, industryDivision: 43). They were named industrySectionName / industryDivisionName / industryGroupName before 2026-09-05; the filter prefix exists so they are never mistaken for the debtor's own industry.

🧮 How many columns does a row actually have?

It depends on which optional blocks you switch on — all four counts measured on real runs:

Configuration	Fields per row	Run
fetchDetails: false (list-only sweep)	65	8yHANs2AzYahTKYO2
Default / prefill input — detail on	65 on list-only rows, 66 on detail-enriched rows	G8S6P7NSuXO1X8dyo
+ enrichWithEntityRegistry	67	FbzRYELvE6hsNb8Ww
+ enrichWithEntityRegistry and includeFullNoticeText and includeRawNoticeHtml	69	9eyKYaKalfZVlcVYc

So 69 is the maximum-configuration count, not the default one. The default row is 65–66 fields; entity, noticeText and rawNoticeHtml are the three opt-ins that take it to 69.

(Each count went up by 2 on 2026-09-07, build 0.1.8: every row now also carries searchWindowComplete and searchWindowMissingRanges — see the coverage section under Reliability. All four counts above were re-measured on that build, not adjusted on paper.)

Set Exclude notice sub-types to 52, 54 if you only want notices that carry a trustee and a deadline, or tick Only notices that name a trustee.

---

🎯 The three filters that read the detail page

Only notices that name a trustee, Claim deadline on/after, Claim deadline on/before and Sort by claim deadline cannot be answered from the gazette's list page — the trustee and the deadline only exist on the notice itself. So when any of them is set, the actor fetches the detail page for every candidate in your window before filtering, and Maximum detail fetches is deliberately ignored for that run. The log says so when it happens.

That is not a detail worth hiding, because the alternative is silently wrong: capping the fetch would mean the filter judges only the first n notices and throws the rest away unexamined, while still reporting the answer as complete.

Measured today, 2026-09-05, on a 45-day country-wide window:

Input	Register returned	Judged	Matched	Delivered	Time	Run
onlyNoticesWithTrustee: true	1,156 notices (1,127 after personal notices are dropped)	1,127 detail pages, 1,127 parsed (100%)	542	50 (maxItems default)	205 s	rNYeFj5W19ZiEA6zj
claimDeadlineAfter: "2026-09-20", sorted by deadline	same 1,156 / 1,127	1,127 detail pages, 1,127 parsed (100%)	281	50 (maxItems default)	175 s	85pqyvFQekDxmjkar

Two consequences worth planning around:

• Your bill is capped by Maximum notices to return, not by Maximum detail fetches. The cap is applied last, after filtering, so it never changes which notices match — only how many of the matches you receive. Raise it to collect the rest (542 and 281 above).
• These runs take minutes, not seconds, because they read every candidate notice, and their cost scales with the window, not with maxItems. The 45-day runs above took ~3 minutes and peaked at 226 MB of the 512 MB default memory (1,127 notices held in memory). For a multi-month sweep with one of these filters, raise the run's memory or take the range in slices. A run that hits its own timeout mid-fetch says so, loudly, and tells you how many candidates it never examined — it will not pass off a short answer as a complete one.

Every other filter (county, municipality, industry, notice sub-type, company name, org numbers, only new) is answered from the list page, so Maximum detail fetches applies normally there: the default enriches the first 25 delivered rows and the rest arrive list-only with detailFetched: false (measured: default input → 50 rows, 25 enriched, 12.1 s, run RIWBg9j6aLZuoyLVY).

---

⚙️ Reliability — and the one setting that matters

The register is an old JSP that streams slowly, and its response grows with the date range:

Range	Response	Rows	Time
3 days	236 KB	187	2.3 s
10 days	507 KB	441	3.7 s
34 days	978 KB	882	4.8 s
3 months	—	—	hard timeout at 60 s

So the actor never issues one wide request. It splits your range into slices of windowDays (default 14) and merges the results, deduplicated by the register's own notice id.

Measured over a full year of sweeps:

• 14-day slices: 25 of 26 requests succeeded (96.2%), 5,097 unique notices collected
• monthly slices: only 9 of 12 (75%) — three hard timeouts on 1–4 MB responses
• detail pages: 18 of 20 (90.0%)
• combined: 43 of 46 (93.5%)

Both failure modes were transient connection resets that recover on retry, so maxRequestRetries defaults to 3. Slicing is lossless: a 31-day window returned 695 rows, and the identical range crawled as 5 contiguous weekly slices returned 695 unique notices — 0 missing, 0 extra.

🔎 If a slice never returns, the run says so — and so does every row

96.2% is not 100%. Over a long sweep you should expect roughly one slice in twenty-six to fail even after its retries, and a lost 14-day slice is two weeks of Norway's bankruptcies missing. So the actor never lets a partial crawl pass itself off as a complete one. Every row carries two fields beyond the window you asked for:

Field	Meaning
searchWindowFrom / searchWindowTo	the window you asked for
searchWindowComplete	true only when every slice returned
searchWindowMissingRanges	the dd.mm.yyyy–dd.mm.yyyy ranges that were never read, so you can re-crawl exactly the gap

and the run log leads with a matching INCOMPLETE WINDOW warning naming the same ranges.

Measured by inducing the failure (requestTimeoutSecs: 10, maxRequestRetries: 0, windowDays: 31 over 01.01–08.04.2026 — the three 31-day slices time out, the short tail slice survives): the run stays SUCCEEDED, but the rows say searchWindowComplete: false with the three lost ranges listed. On the default settings of a normal run all slices return and the field is simply true (control run rePiGBx9H6BLM7NRH, 532 rows, searchWindowComplete: true on all 532).

The same check guards the empty answer. If slices are lost and the ones that did return happened to be genuinely empty, the actor will not tell you the register published nothing — it says it never read part of the window and names the ranges to re-run.

(Fixed 2026-09-07, build 0.1.8. Before it, a failed slice left one mid-log warning while every delivered row still stamped the full requested range — asserting coverage the crawl never had.)

Transport: plain HTTP through the Apify datacenter proxy. Datacenter, Norwegian residential and US residential all returned byte-identical pages, so residential is not needed and is not the default. No browser, no cookies, no login.

---

👤 Personal bankruptcies are excluded by default

About 3% of gazette notices concern a natural person, not a company — measured 15 of 547 notices in a 14-day country-wide window (run mAm4h1bQSKiKHc3eA, 2026-09-05). The identifier the register prints in the organisation-number column for those rows is the person's 6-digit date of birth in DDMMYY, not an org number. Norwegian D-numbers add 40 to the day, so 530778 reads as 13.07.1978.

This actor detects those rows, never writes that value into orgNumber (it stays null, and brregEntityUrl stays null too), tags them subjectType: "person", and excludes them by default. They are not business leads.

If you switch Include personal bankruptcies on, be clear about what you are opting into. The register's own key is still emitted verbatim, so on those rows:

• registryId contains the individual's date of birth — e.g.

  "companyName": "LOUKATOS ALEXANDROS"
  with "registryId": "051180". Every person row in the measured window carried one (15 of 15).
• detailUrl contains it too, as the sokeverdi= query parameter, because that is how the register addresses the notice.
• companyName holds the individual's full name.

A name plus a date of birth is personal data under GDPR, and you become the controller for it. If you want the notices without that, leave the toggle off — which is the default.

---

💵 Pricing

Event	Price	What it covers
Per notice returned	$0.002	Each notice delivered: company, org number, notice type and date, county, official link
Per notice detail	$0.004	Court, case number, trustee name + e-mail + address, claim deadline, fristdag, creditors' meeting, industry

You are charged only for rows you actually receive. Filtered-out notices and anything beyond your Maximum notices cap are never billed, and detail is charged only for delivered rows — reading a notice's detail page to decide whether it matches your filter is never billed. On an ordinary sweep Maximum detail fetches caps the enrichment charge separately; when a detail-reading filter is on it does not apply (see above) and Maximum notices to return is the cap that bounds the bill.

The comparable lane — European insolvency-gazette scrapers — prices list rows at a median of $0.004 and full-notice tiers from $0.004 to $0.030. Both events here sit at or below the cheap end.

A typical month of nationwide notices with full enrichment (~1,200 notices) costs about $7.20.

---

🚀 Quick start

Everything that went bankrupt in Norway last week, with trustee contact details:

{ "lastNDays": 7, "onlyNoticesWithTrustee": true, "maxItems": 0 }

(The trustee filter reads every candidate's detail page automatically — Maximum detail fetches does not apply to it. maxItems: 0 lifts the 50-row default cap.)

Construction-company bankruptcies in Vestland last month:

{
  "datoFra": "01.08.2026", "datoTil": "31.08.2026",
  "region": "300", "county": "46",
  "industrySection": "70",
  "noticeTypes": ["56"]
}

A daily monitor that only ever reports what is new:

{ "lastNDays": 3, "onlyNew": true, "seenStoreName": "my-konkurs-watch", "maxItems": 0 }

Watch a customer portfolio for insolvency:

{ "lastNDays": 30, "orgNumbers": ["916363281", "924566876"], "maxItems": 0 }

Estates you can still file a claim against:

{ "lastNDays": 45, "claimDeadlineAfter": "2026-09-20", "sortBy": "claimDeadline", "sortOrder": "asc" }

Measured exactly as printed, 2026-09-05 (run 85pqyvFQekDxmjkar): 1,156 notices crawled, all 1,127 company candidates detail-read, 281 estates still open to claims, the soonest-deadline 50 delivered under the default maxItems. Raise maxItems to take all 281; the run takes about three minutes because it reads every candidate notice.

---

❓ FAQ

Do I need an account or login? No. The gazette is a public statutory publication. No login, no cookies, no API key.

How far back does the archive go? Years. A 2021 case number surfaced in an August 2026 amendment notice. Use datoFra/datoTil and keep windowDays at 14 for a long sweep.

Can I get the notices in English? Yes. Set Notice language to en and the register returns its own official English translation, with English field labels. The parser reads both languages, and the company names, dates, org numbers and case numbers are identical either way — verified field by field on the same notices in both languages.

Classification is language-independent: noticeTypeCode, isBankruptcyOpening and the Exclude notice sub-types filter behave identically in nb and en. Verified on the same 547-notice window parsed in both languages — identical code mix (52 × 28, 54 × 262, 56 × 163, 60 × 10, 73 × 84) — and live on run 8rj6eu8unwzTBp5qq (en, excludeNoticeTypes: [52, 54]), which dropped 140 rows and delivered 20 carrying real codes. One deliberate exception: noticeTypeName is the register's canonical Norwegian sub-type name in both languages, because it is the stable machine label for noticeTypeCode. The English display label is in noticeType, and the notice's own English headline is in noticeTypeFull.

Fixed 2026-09-07 (build 0.1.8). On builds up to 0.1.7 language: "en" silently nulled noticeTypeCode and noticeTypeName, forced isBankruptcyOpening to false, and turned excludeNoticeTypes into a no-op that still billed you for the notices you excluded (run UxM06nd2BluAG3ps7: 12 of 20 charged rows were the excluded types 52/54). If you ran this actor in English before that date, re-run — the type fields in that output are wrong.

What is the difference between the notice types? Konkursåpning (56) = bankruptcy opened, the richest row. Tvangsoppløsning (73) and Tvangsavvikling (60) = the court forced the company into dissolution or liquidation, also with a trustee. Innstilling av bobehandling (54) = proceedings stopped because the estate cannot fund them. Avslutning av bobehandling (52) = estate closed, sometimes with a dividend percentage.

What is openedAfter: "Oppbud"? The company petitioned for its own bankruptcy rather than being pushed into it by a creditor. It appeared on 89.4% of opening notices (76 of 85) in the measured week above, and is a meaningfully different credit signal from a creditor-forced bankruptcy.

How many columns will I get? 65 on a list-only sweep, 65–66 on the default input, 67 with the free company-register join, and 69 with all three optional blocks (entity, noticeText, rawNoticeHtml) switched on. Measured run by run in the table above — 69 is the maximum, not the default.

Does the dataset ever contain personal data? Two things. The trustee's name, e-mail and postal address — a professional the register publishes precisely so creditors can reach them. And, only if you opt in to personal bankruptcies, the individual's full name in companyName plus their date of birth in registryId (and in detailUrl). Personal bankruptcies are off by default. See the personal-data section below.

What is the fristdag / cut-off date? The reference date used to decide which of the debtor's transactions can be reversed. It is often months before the bankruptcy opened, and it matters a great deal to anyone who traded with the company recently.

How do I deduplicate against my own database? Use kid, the register's own notice id. It is unique per notice and stable. Do not use orgNumber — one company legitimately receives several notices (opening, stopped, closed) across the life of its case.

Why do some rows have no trustee or claim deadline? Because the register does not publish one for that notice type. See the fill-rate table above.

Can I run this on a schedule? Yes — that is what lastNDays + onlyNew are for. onlyNew keeps its memory in a named key-value store, so it genuinely persists between runs instead of reporting everything as new each time.

Will a run ever fail on me? Only when something is actually wrong. A genuinely empty result (a rare sub-type, a narrow filter) exits cleanly with an empty dataset. The actor fails loudly only when the register reports hits that the parser could not read, when every request failed, or when your filter codes are invalid — and in that last case it tells you exactly which values are valid.

---

📤 Output sample

{
  "kid": "20260000691757",
  "companyName": "ROSENHOLM ANLEGG AS",
  "orgNumber": "916363281",
  "brregEntityUrl": "https://virksomhet.brreg.no/oppslag/enheter/916363281",
  "noticeDate": "14.08.2026",
  "noticeDateIso": "2026-08-14",
  "noticeType": "Konkursåpning",
  "noticeTypeCode": 56,
  "noticeTypeFull": "Konkurs - åpning",
  "isBankruptcyOpening": true,
  "county": "Oslo",
  "regionName": "Østlandet",
  "addressStreet": "Rosenholmveien 17",
  "postalCode": "1252",
  "city": "OSLO",
  "court": "OSLO TINGRETT",
  "caseNumber": "26-112296KON-TOSL/08",
  "openedDate": "14.08.2026",
  "claimDeadline": "18.09.2026",
  "claimDeadlineIso": "2026-09-18",
  "daysUntilClaimDeadline": 14,
  "cutOffDate": "03.07.2026",
  "firstMeetingDate": "05.10.2026",
  "firstMeetingTime": "09:20",
  "firstMeetingVenue": "Oslo tingrett, sal 617",
  "industry": "Annen spesialisert bygge- og anleggsvirksomhet ikke nevnt annet sted",
  "previousNames": "MILJØ MUR OG BETONG AS",
  "trusteeName": "Adv. Audun Mørk Kleppestø",
  "trusteeEmail": "aukl@bull.no",
  "trusteeAddress": "Postboks 6604 St.Olavs Plass, 0129 OSLO",
  "hasTrusteeContact": true,
  "publishedByRegister": "Konkursregisteret",
  "publishedDate": "14.08.2026",
  "entity": {
    "naceCode": "43.990",
    "organisasjonsform": "Aksjeselskap",
    "registeredDate": "2015-12-09",
    "foundedDate": "2015-12-04",
    "vatRegistered": false,
    "bankruptFlag": true
  },
  "detailUrl": "https://w2.brreg.no/kunngjoring/hent_en.jsp?kid=20260000691757&sokeverdi=916363281&spraak=nb"
}

---

⚖️ Legal, robots and personal data

robots.txt: w2.brreg.no serves no robots.txt at all — the path returns 404 (verified 2026-09-04).

Robots meta tag: the results page carries, verbatim:

<meta name='ROBOTS' content='NOINDEX, NOFOLLOW'>

That directive governs search-engine indexing of the results page. This actor does not build a search index; it reads a statutory publication that the Brønnøysund Register Centre is legally required to publish, at ordinary human speed, without a login and without circumventing any access control.

Personal data. Two things in this dataset are personal data under GDPR:

1. Trustee contact details. trusteeName, trusteeEmails and trusteeAddress identify a named individual — an advokat acting in a professional capacity, published by the register precisely so creditors can contact them. Downstream use is the buyer's responsibility as data controller: contacting a trustee about the estate is what the register published them for; adding them to an unrelated marketing list is not.
2. Personal bankruptcies. Excluded by default (see above). Enabling them is a deliberate choice with a deliberate consequence, and the consequence is field-level: companyName carries the individual's full name, and registryId carries their 6-digit date of birth (DDMMYY), which also appears inside detailUrl as sokeverdi=. orgNumber and brregEntityUrl stay null — the birth date is never laundered into a company field — but it is present in the row, and you are the controller for it. Measured: 15 of 547 notices in a 14-day country-wide window.

Nothing here bypasses authentication, a CAPTCHA, or a rate limit. No login is used or required. You are responsible for how you use the data, including under GDPR and the Norwegian Personal Data Act.

---

Data source: Konkursregisteret / Brønnøysundregistrene. This actor is not affiliated with or endorsed by the Brønnøysund Register Centre.