insol is a longitudinal research database of German firm insolvency proceedings and the official filings associated with them. It is a product of TRR 266 "Accounting for Transparency" and based on the Insolvenzbekanntmachungen published at https://insolvenzbekanntmachungen.de. It covers firms and other registered economic entities that can be identified through German register identifiers.
insol preserves the underlying filings and links them into insolvency cases and firms. The database is intended to support research on the occurrence, development, and resolution of insolvency proceedings and on the firms involved in them.
This ZIP archive contains one release of the insol database. The data are provided by the TRR 266 “Accounting for Transparency”.
The database is updated nightly after each business day. Through the API from which this release was downloaded, users can also access releases from other dates. Each release is a stable, versioned snapshot of the data as produced by the code and source data available at that time and is designed to be reproducible. New releases affect how filings are assigned to insolvency cases and how cases are linked to firms. As a result, a later release may revise classifications relating to earlier periods while earlier releases remain available unchanged as historical snapshots.
Conditions of use
The underlying Insolvenzbekanntmachungen contain personal data, including, for example, names and addresses of managing directors, insolvency administrators, and other natural persons. For this reason, the insol data cannot be made openly available. Access is restricted to authorised users, including members of the TRR 266 and researchers who have entered into a separate data access agreement.
The insol data are provided without warranty as to completeness, accuracy, fitness for a particular purpose, or continued availability. All personal information contained in the data must be treated as strictly confidential. Personal data may not be the subject of dedicated analysis and may not be linked to external data sources. Commercial and other non-academic use is prohibited. The data, extracts that permit reconstruction of the data, and access credentials may not be shared with third parties.
Research results based on insol may be reported or published provided that they do not disclose personal information or otherwise enable the identification of natural persons.
The insol data also contain Bureau van Dijk identifiers for many, but not all, firms. These matches vary in quality; the relevant match-quality variables should therefore be taken into account when using them. Bureau van Dijk identifiers and related link tables may only be used by users who hold a current licence or subscription to the relevant Bureau van Dijk / Orbis product and only to the extent permitted under that licence or subscription.
Codebook for the normalized insolvency data
Scope
This codebook describes the following seven tables that together structure the 'insol' data:
documentscasescases_firmscases_firms_alternativefirmsfirms_alternativefirms_bvd_ids_alternative
Data layout
The core observation of the data is a document filing. Document filings are stored in documents together with metadata. Each document is defined by its document_id. We use an algorithmic process on the filed document metadata to allocate each document to exactly one case. For this we use the Insolvenzaktenzeichen (insol_court + insol_id) and information on the affected firm(s). As insolvency cases can have multiple Insolvenzaktenzeichen and also the metadata on the affected firm might change over time for various reasons, there is no unambiguous way to assign documents to cases.
Our relation cases and the underlying n:1 link from documents to cases via documents.case_id is an automated best guess. A case can span multiple Insolvenzaktenzeichen, so the cases relation has the primary keys insol_court and insol_id with case_id not being unique. We generally identify cases by merging Insolvenzaktenzeichen that relate to the same firm. In a next step, we check whether our cases can be separated by splitting them into temporal groups with disjoint (sets of) Insolvenzaktenzeichen. We split cases whenever the filing gap between two groups is at least 360 days.
Each case conceptually can be traced back to one firm while a firm can be subject to multiple cases. We implement this via a 1:1 relation cases_firms. We select the firm for this relation by identifying the firm that is most often referenced by the case's documents, with recency breaking any ties. Firms that are also mentioned in case documents besides the main firm are included in cases_firms_alternative. Please note that, while these could be different firms than the one listed in the cases_firms relation, often they reflect misspellings of firm metadata. Similarly, firms_alternative and firms_bvd_ids_alternative contain alternative metadata and BvD IDs for firms, identified by their firm_id. To make our case and firm identifiers human-readable, we use the most frequent Insolvenzaktenzeichen and Handelsregisternummer, respectively, to identify cases and firms.
Identifiers and links
document_iduniquely identifies a row indocuments.insol_courtandinsol_iduniquely identify a row incases.case_idlinksdocuments,cases,cases_firms, andcases_firms_alternative. It is unique incases_firms, but can occur more than once incaseswhen several Insolvenzaktenzeichen are grouped into one case.firm_idlinksdocuments,cases_firms,cases_firms_alternative,firms,firms_alternative, andfirms_bvd_ids_alternative. It uniquely identifies a firm.- The pair
firm_idandalternative_iduniquely identifies a row infirms_alternative. The data infirms_alternativerepresent alternative metadata for an identified firm, potentially also including alternative Handelsregisternummern. - The pair
firm_idandbvd_iduniquely identifies a row infirms_bvd_ids_alternative. Its data constitute an alternative BvD ID that was matched on the alternative firm metadata.
The firm_id stored in documents is the main firm selected for the document's case. To include every possible firm link, join through both cases_firms and cases_firms_alternative.
The bvd_id stored in firms is the main selected Moody's/Bureau van Dijk identifier for the firm. To include every possible BvD link identified by the matching process, join also through firms_bvd_ids_alternative.
Data dimensions
The following table reflects the number of documents, cases and firms included.
| Statistic | Value |
|---|---|
| Snapshot | 2026-11-11 |
| Schema version | v0.2.0 |
| Number of documents | 1,114,204 |
| Number of cases | 223,861 |
| Number of firms | 220,048 |
| % of cases with unique Insolvenzaktenzeichen | 92.7% |
| % of cases with unique firms | 98.4% |
| % of firms assigned to more than one case | 3.2% |
| % of firms with unique metadata | 85.6% |
| % of firms with unique BvD ID | 92.7% |
| % of firms without BvD ID | 6.7% |
The schema of the insol data is under active development and might change without prior notice. Its version number identifies the structure of the published data, meaning the set of tables, their columns and their primary keys.
- The patch level (v0.1.x) is incremented when we add a field derived from data we already publish. Code written against an earlier release keeps working.
- The minor level (v0.x.0) changes when something is renamed or dropped, or when tables are added or removed. Code written against an earlier release may need adjusting.
- The major level (vx.0.0) is reserved for releases that widen what the data covers, so that it answers questions it could not answer before. This is about the analytical scope of the data rather than the mechanics of the change, so a major release may well be one that only adds fields.
You can use the insol API to pull snapshots for older schema versions. Its versions endpoint lists every schema version that has been published, the releases over which each was in force, and the tables and columns it contained.
documents
One row represents one retained insolvency notice.
| Field | Type | Description |
|---|---|---|
source |
character | Source of the filing: insolvex, inregold, or inregnew. These are internal identifiers of different data origins. Not required for uniqueness as document_id does not overlap across origins. |
document_id |
character | Unique document identifier. Historical Insolvex identifiers are numerical strings. Identifiers created by us start with TRR_. The old scraping approach (inregold) used increasing numbering and the current scraping approach (inregnew) uses the filing data and a document hash. |
date_retrieved |
date | Date on which the source obtained or collected the notice. |
date_filed |
date | Filing date reported by the register. This is missing for the historical Insolvex data. |
insol_court |
character | Standardized name of the insolvency court. |
insol_id |
character | Cleaned insolvency case number. The format is "YY/running number" with the year reflecting the year in which the Insolvenzantrag was filed. |
case_id |
character | Identifier for the algorithmically identified insolvency case. |
firm_id |
character | Main firm linked to the case. This is a cleaned trade register identifier. |
insol_id_as_filed |
character | Insolvenzaktenzeichen as filed by the register with the respective document. |
firm_hr_id_as_filed |
character | Handelsregisternummer as filed by the register with the respective document. |
firm_name_as_filed |
character | Firm name as filed by the register with the respective document. |
firm_city_as_filed |
character | Firm location as filed by the register with the respective document. |
content_as_filed |
character | Classification of the filed document as supplied by the register. Courts do not always use these categories consistently. |
content_insolvex |
character | Document category assigned by Insolvex. For documents scraped later, we have classified the respective document text into the Insolvex Categories by using a classifier trained on the historical Insolvex data. Use this classification with care. |
document_html |
character | Scraped HTML. Only available for the data scraped by us. |
document_text |
character | Text extracted from the scraped HTML. A small number of retained records have no text. |
status |
character | Internally used identifier to separate rescrapes from regularly scraped data. Safe to ignore. |
cases
One row represents a cleaned Insolvenzaktenzeichen. Several rows can share a case_id when the processing code concludes that the filed documents refer to the same case.
| Field | Type | Description |
|---|---|---|
case_id |
character | Case identifier (the predominant Insolvenzaktenzeichen). |
insol_court |
character | Standardized insolvency court name. |
insol_id |
character | Cleaned insolvency case number used by that court. |
The pair insol_court and insol_id is unique. As a case can have multiple Insolvenzaktenzeichen, case_id is not unique in this table.
cases_firms
One row gives the main firm selected for each case.
| Field | Type | Description |
|---|---|---|
case_id |
character | Case identifier; unique in this table. |
firm_id |
character | Main firm linked to the case. |
When several firms are recorded for a case, the main firm is the one appearing in the largest number of document filings. If counts are equal, the firm with the most recent filing is selected.
cases_firms_alternative
One row represents an additional firm linked to a case. A case can have no alternative, one alternative, or several alternative firms.
| Field | Type | Description |
|---|---|---|
case_id |
character | Case identifier. |
firm_id |
character | Additional firm recorded for the case. |
These links can reflect a case involving several legal entities, a change of registration, or an incorrect trade register number in a document filing. They should not automatically be treated as confirmed case-firm links.
firms
One row represents one cleaned trade register identifier and attributed firm metadata. The firm_id identifies an observation/firm.
| Field | Type | Description |
|---|---|---|
firm_id |
character | Unique cleaned Handelsregisternummer. It combines court, register type, number, and any location code. |
firm_name |
character | Main recorded firm name. |
firm_city |
character | Main recorded firm location. |
firm_hr_court |
character | Standardized trade register court. |
firm_hr_type |
character | Register type: HRA, HRB, GnR, GsR, PR, or VR. |
firm_hr_number |
character | Numeric part of the trade register number, stored as text. |
firm_hr_okz |
character | Optional location code attached to the register number. |
bvd_id |
character | Main selected Moody's/Bureau van Dijk identifier. Missing when no match is found. |
bvd_match_type |
character | Rule that produced the selected BvD match, or No match when no BvD identifier is assigned. We consider matching quality to decrease along Exact HR ID match and exact city and name match, Exact HR ID match and fuzzy name match, HR ID match without OKZ and exact city and name match, HR ID match without OKZ and fuzzy name match, Exact city and name match, Exact city and fuzzy name match with the first indicating the highest quality match. |
bvd_match_name_jw_dist |
numeric | Jaro-Winkler distance between the standardized insol firm name and the standardized BvD firm name of the selected match. Larger values indicate poorer matches. The current cutoff for a match to be recorded is 0.1 |
A firm in this table need not appear as the main firm in documents: firms that occur only as alternative case links are also included.
The following table details the quality of the BvD ID matching.
| Match Type | N | % |
|---|---|---|
| Exact HR ID match and exact city and name match | 133,272 | 60.6% |
| Exact HR ID match and fuzzy name match | 41,226 | 18.7% |
| HR ID match without OKZ and exact city and name match | 17,984 | 8.2% |
| HR ID match without OKZ and fuzzy name match | 4,172 | 1.9% |
| Exact city and name match | 7,909 | 3.6% |
| Exact city and fuzzy name match | 840 | 0.4% |
| No match | 14,645 | 6.7% |
| Total | 220,048 | 100.0% |
firms_alternative
One row represents another set of name or location details recorded for a firm_id. Only firms with varying recorded details occur in this table.
| Field | Type | Description |
|---|---|---|
firm_id |
character | Firm identifier linking to firms. |
alternative_id |
integer | Sequence number for the alternative detail row within a firm. Together with firm_id, this uniquely identifies the row. |
firm_name |
character | Alternative recorded name. |
firm_city |
character | Alternative recorded location. |
firm_hr_court |
character | Standardized trade register court. |
firm_hr_type |
character | Register type. |
firm_hr_number |
character | Numeric register number, stored as text. |
firm_hr_okz |
character | Optional location code. |
firms_bvd_ids_alternative
One row represents an additional Moody's/Bureau van Dijk identifier linked to a firm_id. Only matched firms with more than one identified BvD identifier occur in this table.
| Field | Type | Description |
|---|---|---|
firm_id |
character | Firm identifier linking to firms. |
bvd_id |
character | Additional Moody's/Bureau van Dijk identifier linked to the firm. |
bvd_match_type |
character | Rule that produced the additional BvD match, defined as in firms. |
bvd_match_name_jw_dist |
numeric | Jaro-Winkler distance between the standardized insol firm name and the standardized BvD firm name of this match, defined as in firms. |
These rows are alternative candidate links from the automated matching process. They should not automatically be treated as confirmed identifiers for the firm.
Additional information on data cleaning
1. Cleaning of Insolvenzaktenzeichen
Insolvency court names are matched to a lookup table based on official court spelling so that spelling and naming variants are eliminated.
Insolvency case numbers are converted to upper case, repeated spacing is removed, known escaped characters are repaired, and common punctuation and format variants are standardized. The code recognizes the registers IN, IE, and IK, treats N as IN, and standardizes the number and two-digit year separated by /. It also checks optional prefixes and suffixes. Values that do not pass these checks are set to missing.
2. Cleaning of Handelsregisternummern
Handelsregisternummern are split into court, register type, number, and an optional location code. Court spelling variants are eliminated by matching to a court lookup table based on official court spellings. Register types are limited to HRA, HRB, GnR, GsR, PR, and VR. Non-numeric characters and leading zeroes are removed from the number, and location codes are checked against a lookup table.
An identifier is set to missing if its court, type, or number cannot be parsed and checked.
3. Removing repeated and unusable document filings
We remove:
- duplicated filings by keeping the first,
- filings without a valid cleaned Insolvenzaktenzeichen, and
- filings without a valid cleaned Handelsregisternummer.
Data limitations
- The source website (insolvenzbekanntmachungen.de) regularly takes down filings and might also apply changes to filings. While we have not identified any evidence for the latter and try to address the former by scraping regularly with overlap, the data provided should be assumed to have no full coverage of all insolvency filings.
- All filed metadata (firm names and locations, Insolvenzaktenzeichen and Handelsregisternummern) can contain source errors that our automated cleaning rules might fail to resolve.
- Case and firm grouping and the choice of a main firm are based on observed identifiers and frequency rules. They are not unambiguous.
content_as_filedis supplied by individual courts and is not used consistently.content_insolvexis a historical third-party classification and is generally unavailable for newer notices.- Firm matching to Moody's/Bureau van Dijk identifiers is automated and can produce false positives or unresolved alternatives, especially for fuzzy name matches and firms with shared or changing metadata.