🇦🇹 Austria Insolvency Scraper — Ediktsdatei Konkurs + Masseverwalter

Scrape Austria's official insolvency register — the Insolvenzdatei inside the Justiz Ediktsdatei (edikte.justiz.gv.at) — and get newly opened company insolvencies as clean lead rows: Firmenbuchnummer, court, case number, address, the Masseverwalter's name, e-mail and phone, the creditor claims deadline, and every scheduled hearing.

No login, no API key, no cookie. Public court data, published by the Republic of Austria.

---

🤔 What does this actor do?

It runs the register's own search, opens each case document, and gives you one row per case:

• 🏢 Company — name, Firmenbuchnummer (the join key to Austria's company register), street, postcode, town
• ⚖️ Court — Dienststelle, its register code, the Bundesland, and the Aktenzeichen
• 📋 Proceeding — Konkursverfahren · Sanierungsverfahren mit/ohne Eigenverwaltung · Konkurseröffnungsverfahren
• 👤 The administrator — Masseverwalter / Sanierungsverwalter name, e-mail, phone, fax and practice address, plus the deputy where one was appointed
• ⏰ The deadlines — opening effective date, Anmeldungsfrist (creditor claims deadline) and days remaining
• 📅 The hearings — every Tagsatzung with date, time, courtroom and purpose, with superseded ones flagged
• 🚦 Case state — business continued or ordered shut, main proceeding under the EU regulation, self-administration, refused for lack of funds, estate insufficient, legally final, appeal lodged, proceeding closed
• 📈 Restructuring plan — the offered quota (%) and its terms, when there is one
• 🗂️ The whole document — every labelled section verbatim, plus the case's full publication history

Filter by date window, Bundesland, court district, individual court, proceeding type, debtor name, postcode, claims-deadline window, and whether the administrator published an e-mail.

---

🎯 Who buys this data

Buyer	What they do with the row
Inkasso / debt-collection agencies	An open Anmeldungsfrist is a hard deadline. They file claims for creditors — and the person they file with is the Masseverwalter.
Turnaround & restructuring advisers	A Sanierungsverfahren with the business still running is a live mandate. business_status tells them which.
Industrial auctioneers & liquidators	"Die Schließung des Unternehmens wird angeordnet" means an estate is about to be sold. The administrator decides who sells it.
Credit-risk & B2B data teams	The Firmenbuchnummer joins straight onto their existing Austrian company master data.
Insolvency law firms	The Tagsatzung calendar, the claims deadlines and who was appointed on what.
Journalists & researchers	A complete, dated corporate-insolvency time series with the court's own wording.

The common thread: nobody in this list contacts the bankrupt company. They contact the administrator. That is the field this actor exists to deliver.

---

📊 Measured field fill rates

Measured on a corpus of 745 real case documents — every insolvency edict registered between 01.08.2026 and 07.09.2026, downloaded through the Apify datacenter proxy and re-parsed offline. On the default settings (companies only, newly opened proceedings only, KV/SVOE/SVME) that corpus produces 226 delivered rows. These are the numbers on those 226 rows:

Field	Fill
company_register_number (Firmenbuchnummer)	100%	226/226 — it is the gate, so it cannot be otherwise
company_name, street_address, postal_code, city	100%	226/226
court, court_code, federal_state, case_number	100%	226/226
proceeding_type + proceeding_type_code	100%	226/226
administrator_name	100%	226/226
administrator_email	99.6%	225/226 — 164 distinct chambers in 5.5 weeks
administrator_phone	100%	226/226
administrator_fax	81.4%	184/226
claims_deadline (Anmeldungsfrist)	100%	226/226
opening_effective_date	100%	226/226
next_hearing_date + next_hearing_location	99.1% / 100%	224/226 have a live hearing; every hearing has a courtroom
is_main_proceeding (EU Insolvency Regulation)	52.2%	118/226
business_status (continued vs ordered shut)	36.7%	83/226
administrator_deputy_name	22.6%	51/226
restructuring_plan_quota_pct	7.1%	16/226 — a Sanierungsplan usually arrives after the opening edict
participants (AKV / KSV1870 / ÖVC, debtor representatives)	4.9%	11/226

Structural counts, same corpus: 745 documents → 745 distinct (court, case number) pairs, zero duplicates. 49 distinct courts. Hearings per case: 188 with one, 37 with two, 1 with three. Edicts per case: 121 with one, 90 with two, 11 with three, 4 with four. The lag between the opening decision and its publication was 0 days on 223 of 226 cases and 1 day on the other 3 — this is a same-day trigger feed, not an archive.

The company gate is doing real work. Across all 745 documents in the corpus only 388 (52.1%) carry a Firmenbuchnummer; within the three default proceeding types (KV / SVOE / SVME, 379 documents) it is 262 (69.1%). Either way, without the gate a large minority of what you receive is not a registered company — and regdata's competing actor states plainly that its debtor field holds a "person or company".

---

🗓️ The one thing to understand: the date window is a first-appearance filter

The register's date field, [DATBMA], is the day the CASE first appeared in the Insolvenzdatei — not the date of its most recent edict. This is measured, not assumed:

• a 01–31.07.2026 search returned 2,107 documents and a 01–31.08.2026 search returned 1,263, with zero overlap;
• five sampled July cases that each gained a fresh August edict were still absent from the August search;
• a case registered 03.08 with later edicts on 07.08 and 04.09 matched [DATBMA]=03.08.2026 and neither of the other two dates.

Three consequences, all of them good, and all of them visible in the output:

1. A lookbackDays: 7 run is a clean new-case feed. You are not wading through status updates on cases from 2018.
2. last_edict_date can legitimately fall after your window. A case registered on 3 August whose closure was ordered on 4 September is a 3 August row carrying a 4 September last edict. registered_date is what the window filtered on; last_edict_date is the case's current state. Both are in every row.
3. newOpeningsOnly still has work to do. Not every case's first edict is an opening: some are refusals for lack of funds (Kostendeckung), some are mere applications. On the default 7-day scope, 65 candidate edicts became 41 rows — 18 dropped as non-companies, 6 as non-openings.

Because one case is one document that the court edits in place, unid is a stable primary key and onlyNew gives you exact once-only delivery across scheduled runs.

---

🧱 The 4,998-hit ceiling — and why this actor never reports a false empty window

The register refuses to list more than 4,998 hits, and it does not do so by truncating. It returns HTTP 200 with ZERO rows, no result table, no hit count, and one sentence:

Ihre Suche … hat mehr als 4998 Einträge gefunden. Bitte verfeinern Sie Ihre Suche!

Measured: a plain 01.06.2026–31.08.2026 request comes back with 0 rows and 16,601 bytes. A crawler that only looks for rows would report an empty quarter for one of the busiest windows of the year. SearchMax=0, 9999, 50000 and 100000 all clamp to the same 4,998 — it cannot be raised.

So this actor:

• crawls in 1-day slices by default (the busiest single day in the last 120 had 127 edicts — 39× under the ceiling; the 120-day census cost 22.9 s in total);
• detects the ceiling notice explicitly and splits any offending slice in half, recursively, down to a single day. Verified live: a 243-day slice (01.01–31.08.2026, all proceeding types) tripped the ceiling, split into 01.01–02.05 and 03.05–31.08, and came back with 2,602 + 2,593 = 5,195 rows from 3 searches — where an undetected ceiling would have returned nothing at all;
• if even a single day is over the ceiling, sets search_complete: false on every row, lists the date in search_missing_ranges, and says so in the log.

The same honesty applies to every other way a run can come up short — see below.

---

✅ search_complete — what the run actually read, not what it asked for

Every row carries search_window_from / search_window_to (what you asked for) and:

Field	Meaning
search_complete	false the moment anything truncated the read
search_incomplete_reasons	failed_date_slices · server_hit_ceiling · partial_result_list · max_items_cap · charge_cap · max_detail_fetches · run_timeout · unreadable_documents
search_missing_ranges	the exact dd.mm.yyyy–dd.mm.yyyy ranges never read, so you can re-run precisely the gap

A sort or a filter that ran over a truncated read is a partial answer, and the row says so rather than looking complete. A run that returns zero rows names the actual cause — your filters, an empty window, the ceiling, a failed slice, or your own maxTotalChargeUsd / maxItems / run timeout — and never blames the register for something the run did. Set maxTotalChargeUsd below $0.003 and the run tells you the budget bought zero rows; it does not report a scraping failure.

---

🚦 Reliability — measured, not asserted

All through the standard Apify datacenter proxy (auto), no residential, no browser:

Test	Result
Search requests	5/5 HTTP 200, byte-identical responses, 0.8–4.4 s
Detail documents, concurrency 8	745/745 (100%) in 106 s (7 req/s)
Detail documents, concurrency 6	149/150 first attempt (99.3%), 150/150 within 2 retries
120 single-day searches, concurrency 8	120/120 in 22.9 s
Full default 7-day run on the Apify platform at 256 MB	17.7 s and 31.1 s on two runs, 41 rows each
Anti-bot challenges encountered in ~1,700 requests	none

There is nothing here for a browser to do, so the actor runs at 256 MB. Residential-Austria proxies also work and are pointless — they would only add proxy bytes to your bill.

The only failures observed were transient connection resets that recovered on the first retry. Each retry rotates the proxy session.

---

🚫 What this actor will not return

Schuldenregulierungsverfahren (consumer debt settlement) — never, at any setting. The same database view carries them: 117 of 286 edicts in a sample week were private individuals' debt settlements, with full name, home address and date of birth (100% of them carry a birth date). They are not company insolvencies, and this actor does not ask the register for them — SRV is not an accepted value for proceedingTypes, and the request that goes to the server never includes it.

Dates of birth — off by default. This is the part that a Firmenbuchnummer filter alone does not solve, so it is worth stating exactly:

• 83 of 388 company documents (21.4%) print a natural person's date of birth inside the company's own Schuldner field — "vertreten durch den GF: <name>, geb. 31.05.1977, <private street>, <postcode town>" — or as a sole trader's Gebdat: line. Some appear inside the company name itself.
• 20 of the 226 default rows (8.8%) are Firmenbuch-registered sole traders (e.U.) who carry one.

With includeBirthDates off (the default), debtor_birth_date is null and every string in the row is passed through a redaction pass that removes the date of birth and the private address trailing it. Verified across the whole 745-document corpus: 0 documents leak a date of birth. Turn it on only if you have a lawful basis for processing it.

companiesOnly: false widens to corporate-type proceedings opened against natural persons — sole traders and entrepreneurs. It does not open the consumer debt-settlement stream, and birth dates stay redacted unless you also switch includeBirthDates on.

---

💵 Pricing

Pay per event — one event, $0.003 per insolvency row delivered. No per-run charge, no per-dataset-item surcharge. Both Apify auto-events are removed.

You are never charged for:

• a row dropped by the company gate, the new-openings gate, or any filter;
• a case document opened only to test a filter;
• a row your maxItems cap excluded;
• anything, when a run legitimately returns zero rows.

Delivery is budget-aware: rows are pushed and charged atomically, so a run that hits a maxTotalChargeUsd cap cannot hand you rows you were not charged for — and it tells you the cap was the cause.

The cap is read before the crawl, not at delivery, so the run does not pay to read documents it cannot deliver. Measured on the same input (21-day window, maxTotalChargeUsd $0.02): the old behaviour opened 217 case documents to deliver 6 rows in 82 s; reading the cap up front does it in 15 documents and 22 s, with the same 6 rows delivered and charged and every row carrying search_complete: false with reason charge_cap.

What you want	Cost
A daily monitor, all of Austria (41 rows on the measured 7-day run; ~51/week at the 2025 rate)	~$0.12–0.15 / week ≈ $6–8 / year
One month of new company openings (~220 rows at the 2025 rate)	~$0.66
Every company opening in the whole archive (~7,900 rows)	~$24
Every company edict in the whole archive (~9,100 rows)	~$27

The archive figures come from a full month-by-month census of the register (282 searches, 59 s): 76,703 live edicts, of which 13,179 are Konkurs- or Sanierungsverfahren. Applying the company and opening shares measured on the 745-document corpus (69.1% carry a Firmenbuchnummer, 59.6% are openings) gives the two totals above.

For comparison, read live on 2026-09-08: the one other actor on this exact site charges $0.005 per run start plus $0.004 per dataset item; European insolvency actors elsewhere run $0.01–$0.05 per record.

---

🚀 Quick start

A daily new-openings monitor for the whole country (this is also the default — an empty input does exactly this):

{ "lookbackDays": 7, "onlyNew": true }

Schedule it daily. The 7-day window covers weekends and public holidays; onlyNew remembers every case already delivered (by unid, in a named key-value store) so you are never charged twice for the same company.

Vienna commercial court only, biggest cases:

{ "lookbackDays": 30, "courtCodes": ["007"], "sortBy": "claims_deadline", "sortOrder": "asc" }

Claims deadlines still open next month, anywhere in Austria:

{ "lookbackDays": 60, "claimsDeadlineFrom": "2026-10-01", "claimsDeadlineTo": "2026-10-31" }

Construction companies in Styria:

{ "lookbackDays": 90, "courtDistricts": ["638", "609"], "debtorNameQuery": "*bau*" }

Full historical backfill of company openings:

{ "publishedFrom": "01.01.2024", "publishedTo": "31.12.2025", "sliceDays": 1 }

Everything, including refusals and applications, with the full text:

{ "lookbackDays": 7, "newOpeningsOnly": false, "proceedingTypes": ["KV", "SVOE", "SVME", "KEV"], "includeFullText": true }

---

⚖️ Court codes

courtDistricts takes a Gerichtshofsprengel — a Landesgericht and every Bezirksgericht under it. courtCodes takes a single Dienststelle. Measured on one week: [GH]=638 returned 31 hits where [Ger]=638 (the LGZ Graz itself) returned 17.

Code	Court	Bundesland
007	Wien, HG — the Vienna commercial court, where Vienna's corporate insolvencies go	Wien
003	Wien, LGZ	Wien
638	Graz, LGZ	Steiermark
609	Leoben, LG	Steiermark
458	Linz, LG	Oberösterreich
469	Ried im Innkreis, LG	Oberösterreich
499	Steyr, LG	Oberösterreich
519	Wels, LG	Oberösterreich
569	Salzburg, LG	Salzburg
818	Innsbruck, LG	Tirol
929	Feldkirch, LG	Vorarlberg
729	Klagenfurt, LG	Kärnten
309	Eisenstadt, LG	Burgenland
119	Korneuburg, LG	Niederösterreich
129	Krems an der Donau, LG	Niederösterreich
199	St. Pölten, LG	Niederösterreich
239	Wiener Neustadt, LG	Niederösterreich

All 211 Dienststelle codes from the register's own advanced-search form are accepted by courtCodes, including Bezirksgerichte; an unknown code is rejected at input time rather than silently returning nothing.

Volume by Bundesland, measured across 5 quarterly windows (2025-07-01 → 2026-09-07, ~20,400 edicts of every type): Wien 7,028 · Niederösterreich 3,212 · Oberösterreich 2,883 · Steiermark 2,311 · Tirol 1,390 · Kärnten 1,308 · Salzburg 976 · Vorarlberg 836 · Burgenland 439.

The federal_state on every row comes from that same calibration — 130 distinct courts resolved, zero assigned to two different Bundesländer — not from guessing at postal codes.

---

📤 Output sample

{
  "unid": "285b7e54c343fc4ec1258e6b0073b1db",
  "case_url": "https://edikte.justiz.gv.at/edikte/id/idedi8.nsf/0/285b7e54c343fc4ec1258e6b0073b1db!OpenDocument",
  "court": "HG Wien",
  "court_code": "007",
  "federal_state": "Wien",
  "federal_state_code": "0",
  "case_number": "2 S 125/26h",
  "proceeding_type": "Konkursverfahren",
  "proceeding_type_code": "KV",
  "debtor_type": "company",
  "company_name": "A&A Elektrotechnik GmbH",
  "company_register_number": "621689z",
  "firmenbuch_url": "https://justizonline.gv.at/jop/web/firmenbuchabfrage?fbnr=621689z",
  "street_address": "Odoakergasse 22/2",
  "postal_code": "1160",
  "city": "Wien",
  "registered_date": "2026-09-07",
  "last_edict_date": "2026-09-07",
  "opening_effective_date": "2026-09-08",
  "claims_deadline": "2026-10-20",
  "days_until_claims_deadline": 42,
  "is_new_opening": true,
  "administrator_role": "Masseverwalter",
  "administrator_name": "DALLINGER Klemens Dr.",
  "administrator_email": "dallinger@anwaltsteam.at",
  "administrator_phone": "513 28 33",
  "administrator_fax": "513 28 33-22",
  "administrator_address": "Schulerstraße 18, 1010 Wien",
  "hearings": [
    {
      "date": "2026-11-03", "time": "10:15", "location": "Zimmer 1605, 16.Stock",
      "purposes": ["Berichtstagsatzung", "Prüfungstagsatzung"],
      "source": "Tagsatzung", "superseded": false, "published_date": "2026-09-07"
    }
  ],
  "next_hearing_date": "2026-11-03",
  "next_hearing_location": "Zimmer 1605, 16.Stock",
  "self_administration": false,
  "is_main_proceeding": false,
  "no_cost_coverage": false,
  "proceeding_closed": false,
  "edict_count": 1,
  "publications": [
    { "published_date": "2026-09-07", "decision_date": "2026-09-07",
      "section_labels": ["Firmenbuchnummer", "Schuldner", "Masseverwalter", "Eröffnung", "Eigenverwaltung", "Tagsatzung"] }
  ],
  "sections": {
    "Masseverwalter": ["DALLINGER Klemens Dr.\nSchulerstraße 18\n1010 Wien\nTel.: 513 28 33, Fax: 513 28 33-22\nE-Mail: dallinger@anwaltsteam.at"],
    "Eröffnung": ["Beginn der Wirkungen der Eröffnung: 08.09.2026\nAnmeldungsfrist: 20.10.2026"]
  },
  "search_window_from": "2026-09-02",
  "search_window_to": "2026-09-08",
  "search_complete": true,
  "search_incomplete_reasons": [],
  "search_missing_ranges": [],
  "scraped_at": "2026-09-08T03:33:40.830Z"
}

---

❓ FAQ

How fresh is the data? Same day. On 226 measured cases the opening decision was published on the day it was made (223) or the next day (3). Edicts appear during the working day, so a morning run picks up yesterday's.

How far back does the archive go? To 2015 — but the register prunes old years, so the early ones are thin. Measured by a full month-by-month census on 2026-09-08 (282 searches, 59 s), 76,703 live edicts in total:

Year	All edicts	Konkurs / Sanierung	Busiest month
2015	244	56	33
2016	298	67	34
2017	347	80	51
2018	2,050	137	261
2019	3,558	195	372
2020	5,274	210	619
2021	4,547	233	569
2022	6,546	483	695
2023	10,391	1,339	1,130
2024	14,658	3,012	1,418
2025	16,445	4,440	1,518
2026 (to 08.09)	12,345	2,927	2,107
Total	76,703	13,179

No month in twelve years reaches the 4,998-hit ceiling — the busiest was July 2026 at 2,107, which is why 31-day slices are safe today and 1-day slices are safe with 39× headroom.

Why is last_edict_date after my date window? Because the window filters on registered_date — the day the case first appeared. See the date window is a first-appearance filter above. It is the register's behaviour, not a parsing bug.

Can I look up whether one specific company is insolvent? Not with this actor. The register does support it ([FN]=484188t returns exactly one row), but "screen 5,000 company numbers" is a different function with an inverted cost profile — thousands of searches for a handful of rows — and it belongs in its own actor.

Do I get the creditors' claim amounts? No. Austrian insolvency edicts do not publish claim amounts or a list of creditors. What is published is what you get: the debtor, the administrator, the deadlines, the hearings and the court's own findings.

What about Exekutionen (foreclosures) and Firmenbuch announcements? Different databases inside the same Ediktsdatei, and deliberately out of scope. One site, one function, one actor.

Does onlyNew survive between scheduled runs? Yes — it uses a named key-value store (seenStoreName, default edikte-insolvency-at-seen), so it persists. Point two schedules at two different store names to run independent monitors.

Why is the default sliceDays: 1? Two reasons, both measured: it keeps every request 39× under the register's zero-rows-at-4,998 ceiling, and it tells the crawler each case's registered date before it pays to open anything, so a maxItems cap keeps the newest cases instead of an arbitrary middle. 120 day-searches cost 22.9 s. Bigger slices are safe — up to 366 days — because a slice that trips the ceiling is halved automatically: a live 243-day slice split into two and returned 2,602 + 2,593 = 5,195 rows from 3 searches, where an undetected ceiling would have returned zero.

Why is KEV off by default? A Konkurseröffnungsverfahren is an application for a proceeding, not an opening. 0 of the 366 KEV documents in the test corpus carried an Eröffnung section, so with newOpeningsOnly on every KEV page fetched is read and discarded. The actor warns you if you select both.

The run said search_complete: false. What now? Read search_incomplete_reasons. If it is max_items_cap or max_detail_fetches, raise the cap; if it is charge_cap, raise maxTotalChargeUsd (the crawl stops at the number of rows your budget covers, so nothing you were not charged for was read). If it is failed_date_slices, server_hit_ceiling or partial_result_list, search_missing_ranges gives you the exact dates to re-run — narrow the scope for those.

Do I need residential proxies? No. 745/745 documents and every search came back through the plain Apify datacenter proxy. The site has no anti-bot challenge.

---

⚖️ Legal, robots and personal data

• The source is official public court data. The Ediktsdatei is the Republic of Austria's statutory publication channel for insolvency proceedings, published under the Insolvenzordnung so that creditors can find out about them. Access is free (gebührenfrei), needs no account, and carries no terms-of-use gate.
• robots.txt. https://edikte.justiz.gv.at/robots.txt returns HTTP 200 with Content-Type: text/html — it is the Domino database's own welcome page, and it contains zero User-agent and zero Disallow directives. There is no robots directive to observe on this host.
• Page-level meta tags, quoted verbatim. Case documents carry: <meta name="robots" content="noindex">, <meta name="robots" content="nofollow">, <meta name="robots" content="noarchive">, <meta name="googlebot" content="nosnippet">, <meta name="robots" content="noimageindex,nomediaindex">. These are search-engine indexing directives, not access controls, and they are why these edicts do not show up in Google. This actor reads the pages; it does not index or republish them.
• A licensed feed also exists. The Republic offers an official machine-to-machine data feed that requires an IWG government licence and a formal application. This actor uses the free public web interface instead. If your use case needs the licensed feed's guarantees, apply for it.
• Personal data. Read What this actor will not return above before you run this at scale. Consumer debt-settlement proceedings are never requested; dates of birth are redacted out of every field by default; the administrator's e-mail and phone are a named lawyer's professional contact details, published by the court under a statutory transparency mandate.
• Rate. The actor runs at concurrency 6 by default (≈5 requests/second) and a full 7-day run makes about 70 requests. Please do not raise the concurrency above 8 — the register is a public service, and 8 already reads 745 documents in 106 seconds.

You are responsible for how you use the output, including compliance with the GDPR and with Austrian law.