> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Unternehmensregister-API: Automatische KYB-Extraktion > Didit bietet Registerabfragen, Statusprüfung und Datenextraktion in 220+ Ländern. Ab $2.00 pro Prüfung nach Land und Stufe, ohne Verträge. Wenn eine Sitzung zur Unternehmensverifizierung (KYB) startet, fragt Didit offizielle Unternehmensregister ab, um Unternehmensinformationen abzurufen und zu validieren. Diese automatisierte Abfrage bildet die Grundlage für den gesamten Unternehmensverifizierungsprozess. ## Registry-Suche Didit verbindet sich in den unterstützten Ländern mit Unternehmensregistern, um offizielle Daten abzurufen. Im gehosteten Ablauf wählt der Benutzer das Land der Gründung und gibt den Firmennamen, die Registernummer oder beides ein. Mindestens eines dieser Felder ist erforderlich. Registernummern werden dort normalisiert, wo das Register es verlangt (zum Beispiel werden britische Firmennummern auf acht Stellen mit führenden Nullen aufgefüllt). Wenn beide Kennungen angegeben werden, kombiniert die Registersuche sie. ### Suche mit `expected_details` vorausfüllen Wenn Sie das Unternehmen bereits kennen, übergeben Sie `expected_details` (`company_name`, `registry_country`, `registration_number`) beim [Erstellen der Sitzung](https://docs.didit.me/de/sessions-api/create-session.md). Der gehostete Ablauf wählt das Land (bei Registern auf Bundesstaatsebene wie `US-CA` auch den Bundesstaat) vor und sperrt es. Er füllt die passenden Suchfelder aus und startet die angegebene Suche automatisch. Der Benutzer landet so direkt bei dem Ergebnis seines Unternehmens. Beide Felder bleiben bearbeitbar, sodass der Benutzer eine falsche Angabe korrigieren kann. Die Angaben dienen nur zur Vorausfüllung: Wenn ein anderes Unternehmen als angegeben ausgewählt wird, erscheint keine Warnung. ### Suchtypen Registersuchen unterstützen zwei Modi: | Modus | Beschreibung | | - | - | | **Genau** | Findet den Firmennamen oder die Registernummer exakt | | **Enthält** | Findet Unternehmen, deren Name den Suchbegriff enthält. Nützlich, wenn der exakte amtliche Firmenname unbekannt ist | ### Ablauf der Suche Die Registersuche folgt einem asynchronen Ablauf: **1. Suche** Didit fragt das Register mit dem ausgewählten Land und den angegebenen Kennungen ab, also dem Firmennamen, der Registernummer oder beidem in Kombination. Das Feld `searched_by` der Antwort zeigt an, wie die Ergebnisse zugeordnet wurden (`name`, `registration_number` oder `registration_number_and_name`). Die gehostete Oberfläche bietet bei Ergebnissen aus einer Registernummernsuche außerdem die Option „Stattdessen nach Firmenname suchen“ mit einem Tipp an. Die Suche läuft asynchron. **2. Ergebnisse abfragen** Fragen Sie den Suchstatus ab, bis die Ergebnisse vorliegen. Große Register können einige Sekunden brauchen, bis sie Ergebnisse liefern. **3. Unternehmen auswählen** Prüfen Sie die gefundenen Unternehmen und wählen Sie die richtige Übereinstimmung aus. Didit verknüpft das ausgewählte Unternehmen mit der KYB-Prüfung und füllt alle verfügbaren Daten aus. **4. Bestätigen und fortfahren** Bestätigen oder korrigieren Sie die Unternehmensdaten und fahren Sie mit dem nächsten konfigurierten Schritt fort. Manche Register liefern das Unternehmensprofil, bevor der Eigentümerbericht fertig ist. Dieser Bericht wird im Hintergrund weiterbearbeitet, während der Antragsteller unabhängige Schritte erledigt, etwa das Hochladen von Dokumenten. Die Vorausfüllung aus dem Register blockiert das Formular für Schlüsselpersonen nicht. Der Antragsteller kann Personen manuell eingeben, und verfügbare Personen aus dem Register erscheinen vor dem Absenden, sobald der Bericht eintrifft. Benutzerdefinierte Entscheidungen, die vom Bericht abhängen, warten auf den Bericht, statt ihr Ergebnis vorwegzunehmen. Ihre Korrekturen bleiben erhalten, wenn der Bericht eintrifft. Ein ausstehender Bericht gilt weder als abgeschlossene Registerprüfung noch als automatische Genehmigung. Die Abrechnung der Registerprüfung richtet sich nach der tatsächlich gelieferten Stufe. **5. Manuelle Übermittlung** Wenn das Unternehmen im Register nicht gefunden wird, übermitteln Sie die Unternehmensdaten manuell. Die Sitzung wird mit den übermittelten Daten fortgesetzt, und `is_from_registry` wird auf `false` gesetzt. ### Abgerufene Daten | Feld | Beschreibung | | - | - | | `company_name` | Amtlich eingetragener Firmenname bei der Behörde | | `registration_number` | Offizielle Registernummer bzw. Gründungsnummer des Unternehmens | | `country_code` | Land der Gründung (ISO 3166-1 alpha-3) | | `company_type` | Rechtsform (Ltd, LLC, PLC, SA, GmbH, SL usw.) | | `registry_status` | Aktueller Unternehmensstatus laut Register (`active`, `dissolved`, `struck_off` usw.) | | `incorporation_date` | Datum der ursprünglichen Eintragung des Unternehmens | | `registered_address` | Offizieller Sitz laut Register | | `tax_number` | Steuernummer, sofern verfügbar | | `alternative_names` | Handelsnamen, DBAs, frühere Firmennamen oder Namen in der Originalsprache als Textwert | | `legal_entity_identifier` | LEI, für Finanzinstitute und börsennotierte Unternehmen | | `nature_of_business` | Kurzbeschreibung der Geschäftstätigkeit (in der Sprache des Registers) | | `registered_capital` | Genehmigtes bzw. ausgegebenes Kapital als Objekt `{amount, currency}` | | `location_of_registration` | Stadt bzw. Verwaltungseinheit des maßgeblichen Registers | | `control_scheme` | Kontroll- bzw. Governance-Struktur, sofern das Register sie ausweist | | `website`, `email`, `phone` | Kontaktdaten, die im Register hinterlegt sind | | `addresses[]` | Zusätzliche Sitz- oder Geschäftsadressen | | `industries[]` | Branchenklassifikationscodes (SIC, NACE oder lokale Entsprechungen) | | `accounts` | Angegebene Einreichungsdaten, einschließlich `last_annual_return_date` und `last_agm_date`. Jahresmeldungen und Hauptversammlungen sind von Jahresabschlüssen zu unterscheiden. | | `financial_summary` | Finanzielle Kurzdaten, sofern das Register sie veröffentlicht (Umsatz, Mitarbeiterzahl, Einreichungsstatus) | | `confirmed_by_user_at` | Zeitstempel, zu dem der Endbenutzer die Registerdaten bestätigt oder bearbeitet hat | | `last_console_edit_at` | Zeitstempel der letzten Bearbeitung durch einen Analysten in der Konsole | | `is_editable` | `true`, solange der Endbenutzer die aus dem Register stammenden Daten im gehosteten Ablauf noch bearbeiten kann | | `is_from_registry` | `true` für Unternehmen aus dem Register, `false` für manuelle Eingaben | | `fetch_status` | `pending`, `resolved` oder `failed`. Status der Registersuche | | `verification_status` | `verified`, `failed` oder `unknown` | ### Unternehmensstatus | Status | Beschreibung | | - | - | | **Aktiv** | Das Unternehmen ist derzeit aktiv und in ordnungsgemäßem Status | | **Aufgelöst** | Das Unternehmen wurde formell aufgelöst | | **Aus dem Register gelöscht** | Das Unternehmen wurde aus dem Register entfernt (z. B. wegen Nichteinhaltung von Vorschriften) | | **In Liquidation** | Das Unternehmen wird gerade abgewickelt | | **Ruhend** | Eingetragen, betreibt aber derzeit keinen Geschäftsbetrieb | > [!WARNING] > > Unternehmen mit einem anderen Status als **Aktiv** können je nach Ihrer Workflow-Konfiguration automatisch markiert oder abgelehnt werden. ### Kennzeichen der Datenquelle Jeder Unternehmensdatensatz enthält ein `is_from_registry`-Flag: * **`true`**: Die Daten wurden aus einem offiziellen Unternehmensregister abgerufen. * **`false`**: Die Daten wurden manuell übermittelt, weil das Unternehmen im Register nicht gefunden wurde. Das Feld `fetch_status` zeigt an, ob die Registerabfrage abgeschlossen, fehlgeschlagen oder noch in Bearbeitung ist. ## Stufen und Preise Im gehosteten Ablauf fällt die Registergebühr an, sobald ein Unternehmen ausgewählt wird, auch wenn der Antragsteller die Angaben nicht bestätigt oder die Verifizierung nicht abschließt. Ist der Bericht bei der Auswahl bereits verfügbar, wird die gelieferte Stufe sofort berechnet. Ist die Eigentümerstruktur noch ausstehend, wird Lite bei der Auswahl berechnet, und nur die Preisdifferenz wird fällig, wenn eine höhere Stufe geliefert wird. Ist die Eigentümerstruktur nicht verfügbar, fällt kein Aufschlag für die Eigentümerstruktur an. Die Summe basiert auf den bei der Auswahl angegebenen Preisen und überschreitet niemals den Preis der angeforderten Stufe. Die Auswahl und eine spätere Anpassung der Eigentümerstruktur zählen als eine Registerabfrage. Das Lesen des gekauften Berichts oder das Bestätigen der Angaben berechnet sie nicht erneut. Bestehende Pauschalverträge verbuchen bei der Auswahl eine Registerabfrage, ohne eine zweite Vertragseinheit für die spätere Lieferung der Eigentümerstruktur. Bei Suchen im gehosteten Workflow fällt keine gesonderte Suchgebühr an. Bei eigenständigen API-Suchen können pro erfolgreicher Anfrage **\$0.50** anfallen; siehe [Abrechnung der Suche](https://docs.didit.me/de/standalone-apis/kyb-registry-search.md). Die vollständige Preistabelle nach Land finden Sie unter [KYB-Registerpreise](https://docs.didit.me/de/getting-started/kyb-registry-pricing.md). | Stufe | Was Sie erhalten | | - | - | | **Lite** | Die oben genannten Felder: Unternehmensprofil, Kennungen, Status, eingetragene Adresse, Tätigkeit und Organmitglieder | | **Gesellschafter** | Lite plus die direkten Gesellschafter (natürliche Personen und juristische Personen) mit ihren Anteilsbändern | | **UBOs** | Gesellschafter plus die über die Beteiligungskette ermittelten wirtschaftlich Berechtigten | Ein gehosteter Workflow wählt die Stufe pro Land unter *Workflows → KYB Registry Check → Countries* aus. Gibt es im Register keinen Eigentümerdatensatz für ein Unternehmen, wird eine Anfrage für Gesellschafter oder UBOs auf der höchsten Stufe geliefert und berechnet, die die Register des Landes liefern können, in der Regel Lite. Ein Unternehmen, das nicht gefunden und manuell erfasst wird (`is_from_registry: false`), wird mit einer Pauschale von **\$0.75** berechnet, weil die Suche durchgeführt wurde, auch wenn kein Registerdatensatz zurückgegeben wurde. > [accordion] Beispiel: Antwort der Stufe Lite > > Lite liefert nur das Unternehmensprofil, ohne Gesellschafter, UBOs oder Eigentümerstruktur: > > ```json theme={null} > { > "company_name": "ACME HOLDINGS PTY LTD", > "registration_number": "094447122", > "country_code": "AU", > "registry_status": "active", > "incorporation_date": "2000-09-12", > "company_type": "Proprietary Limited", > "registered_address": "Sydney, NSW, 2000", > "tax_number": null, > "vat_number": null, > "website": null, > "is_from_registry": true > } > ``` > > Die Stufe Gesellschafter ergänzt `ownership_structure` und Gesellschafter-Einträge sowie Geschäftsführer und Organmitglieder. Die Stufe UBOs ermittelt zusätzlich die wirtschaftlich Berechtigten mit Eigentumsprozentsätzen. Siehe [Eigentümerstruktur](https://docs.didit.me/de/business-verification/ownership.md) und [Organmitglieder und Geschäftsführer](https://docs.didit.me/de/business-verification/officers.md). ## Registerdaten im Vergleich zu vom Benutzer angegebenen Daten Didit speichert die vom Register zurückgegebenen Daten und die vom Benutzer bestätigten Daten als **getrennte Audit-Datensätze**. Für nachgelagerte Prüfungen wird eine zusammengeführte, maßgebliche Ansicht verwendet. Jeder Unternehmensdatensatz enthält drei zusammenhängende Blöcke: | Feld | Beschreibung | | - | - | | `registry_data` | Die normalisierten Registerdetails von Didit: das Ergebnis zur Eigentümerstruktur (`ownership_error`, `section_errors`, `ubo_resolution`), die Korrekturen aus [update-data](https://docs.didit.me/de/sessions-api/update-data.md) und Registerangaben ohne eigenes Feld. Die Schlüssel variieren je nach Unternehmen und sind kein stabiler Vertrag. | | `user_provided_data` | Was der Endbenutzer im Schritt der Registerbestätigung im gehosteten Ablauf bestätigt oder bearbeitet hat. | | Maßgebliche Felder auf oberster Ebene (`company_name`, `registration_number`, `country_code`, `incorporation_date` usw.) | Die zusammengeführten Angaben: die vom Benutzer bestätigten Daten, sofern vorhanden, andernfalls die Registerdaten als Fallback. Nachgelagerte Funktionen (Abgleich mit der OCR-Auswertung von Dokumenten, AML-Screening, Risikobewertung) arbeiten mit der maßgeblichen Ansicht. | Der Zeitstempel `confirmed_by_user_at` markiert den Zeitpunkt, zu dem der Endbenutzer die Registerdaten bestätigt oder bearbeitet hat. Solange dieser Zeitstempel noch null ist und `is_editable` den Wert `true` hat, kann der Endbenutzer Felder im gehosteten Ablauf weiterhin ändern. Bei **manuell erfassten Unternehmen** (`is_from_registry: false`) ist `user_provided_data` die einzige Quelle, und `is_editable` wird nach dem Absenden durch den Benutzer auf `false` gesetzt. Analysten können beide Quellen in der [Business Console](https://docs.didit.me/de/business-verification/console.md) bei der Sitzungsprüfung nebeneinander einsehen und vergleichen, was das Register angegeben hat und was der Benutzer bestätigt hat. ## Konfigurierbare Felder des Registrierungsformulars Sie legen fest, welche Unternehmensdaten der gehostete Verifizierungsablauf im Schritt der Registerbestätigung abfragt. Konfigurieren Sie die Felder in der Business Console: Öffnen Sie den Workflow-Editor, wählen Sie den Knoten **KYB Registry check** aus und wechseln Sie zum Tab **Felder**. Jedes Feld hat einen von drei Zuständen: | Zustand | Verhalten | | - | - | | **Verborgen** | Das Feld wird im gehosteten Ablauf nicht angezeigt und nicht erfasst. | | **Optional** | Das Feld wird angezeigt; der Benutzer kann es leer lassen. | | **Erforderlich** | Das Feld wird angezeigt und muss ausgefüllt sein, bevor der Benutzer absenden kann. | Drei Felder werden immer angezeigt und sind immer erforderlich. Sie identifizieren das Unternehmen und lassen sich nicht konfigurieren: `company_name`, `country_code` und `region` (Bundesstaat bzw. Region, sofern das Register regional geführt wird). Die 16 konfigurierbaren Felder: `registration_number`, `incorporation_date`, `legal_address`, `vat_number`, `alternative_names`, `tax_number`, `company_type`, `legal_entity_identifier`, `location_of_registration`, `nature_of_business`, `registered_capital_amount`, `registered_capital_currency`, `website`, `email`, `phone`, `control_scheme` Standardmäßig, und zwar auch für alle bestehenden Workflows, ist nur `incorporation_date` **Erforderlich**. Jedes andere konfigurierbare Feld ist **Optional**. So verhält sich das Formular genau wie vor dieser Einstellung. Die Pflichtfeldprüfung wird serverseitig erzwungen: Wird das Registrierungsformular mit einem leeren Pflichtfeld abgeschickt, gibt die Anfrage eine `400`-Antwort mit Fehlermeldungen für die einzelnen Felder zurück, und die gehostete Oberfläche zeigt nur die aktivierten Felder an. In der Workflow-API ist die Einstellung das Objekt `kyb_registry_fields_config` am KYB-Registry-Knoten. Den Aufbau finden Sie unter [Feature-Konfigurationen](https://docs.didit.me/de/management-api/workflows/feature-configs.md#kyb-register). > [!NOTE] > > `vat_number` mit dem Zustand **Erforderlich** wird nur für Unternehmen erzwungen, die in einem EU-Land mit Umsatzsteuerpflicht eingetragen sind (siehe unten). Für alle anderen Länder wird das Feld auch dann als optional behandelt, wenn es auf **Erforderlich** steht, da dort keine EU-USt-IdNr. erhoben werden kann. Deren `tax_number` wird, sofern angegeben, weiterhin geprüft. ## Umsatzsteuer-ID- und Steuernummernprüfung Beim Absenden des Registerschritts prüft Didit die `vat_number` des Unternehmens gegen die amtliche Quelle seines Landes. Hat ein Unternehmen keine `vat_number`, wird stattdessen seine `tax_number` geprüft. Die Nummer kann mit oder ohne Ländervorwahl und mit beliebigen Trennzeichen übermittelt werden. `DE 123 456 789`, `DE123456789` und `123456789` sind für ein deutsches Unternehmen gleichwertig. **Amtliche Register.** In diesen Ländern wird die Nummer live gegen das staatliche oder amtliche Unternehmensregister geprüft. Dieses liefert auch den eingetragenen Namen und in den meisten Fällen die Adresse: | Land | Quelle | | - | - | | 27 EU-Mitgliedstaaten und Nordirland (`XI`) | Europäische Kommission [VIES](https://ec.europa.eu/taxation_customs/vies/) | | Polen | VIES, danach das Register der Umsatzsteuerpflichtigen des Finanzministeriums (die „Weiße Liste“) für ein Unternehmen, das VIES nicht führt | | Norwegen | Brønnøysund Register Centre (Zentrales Koordinierungsregister für juristische Personen) | | Schweiz | UID-Register des Bundesamts für Statistik | | Brasilien | CNPJ-Register der Receita Federal | | Kolumbien | RUES, das einheitliche Unternehmens- und Sozialregister der Handelskammern | | Costa Rica | Register der Steuerpflichtigen des Finanzministeriums (Hacienda) | | Ecuador | Register der Steuerpflichtigen der Steuerbehörde (SRI) | | Paraguay | RUC-Register der nationalen Steuerdirektion (DNIT) | Eine französische SIREN- oder SIRET-Nummer, eine niederländische RSIN oder eine vollständige ungarische Steuernummer wird, wenn sie als USt-IdNr. übermittelt wird, vor der Prüfung in die passende USt-IdNr. umgewandelt. Griechische USt-IdNrn. werden automatisch unter dem Präfix `EL` geprüft. **Prüfziffernregeln.** In diesen Ländern kann kein Register abgefragt werden. Die Nummer wird daher gegen das amtliche Format und die Prüfziffernregeln des Landes geprüft: Albanien, Andorra, Argentinien, Australien, Aserbaidschan, Belarus, Kanada, Chile, China, Dominikanische Republik, Ägypten, El Salvador, Ghana, Guatemala, Island, Indien, Indonesien, Israel, Japan, Kenia, Liechtenstein, Mexiko, Moldau, Monaco, Montenegro, Marokko, Mosambik, Neuseeland, Nordmazedonien, Peru, Russland, San Marino, Serbien, Singapur, Südafrika, Südkorea, Taiwan, Thailand, Tunesien, Türkei, Ukraine, Vereinigtes Königreich, Vereinigte Staaten, Uruguay, Venezuela und Vietnam. Diese Regeln gelten auch in der EU, wenn eine `tax_number` eine nationale Steuernummer ist, für die keine USt-IdNr. zu prüfen ist, etwa eine deutsche Steuernummer. Eine `tax_number` belegt nur eine Steuerkennung, keine Umsatzsteuerregistrierung. Wenn VIES sie nicht führt, greifen daher diese Regeln, anstatt dass das Ergebnis `invalid` lautet. Unternehmen aus allen anderen Ländern erhalten `vat_validation_status: "not_applicable"`. Dasselbe gilt für Sandbox-Sitzungen, die nie ein Steuerregister abfragen. Das Ergebnis wird am Unternehmen gespeichert und in der [KYB-Entscheidungs-Payload](https://docs.didit.me/de/business-verification/response-schema.md#block-company) ausgegeben: | Feld | Beschreibung | | - | - | | `vat_number` | Die übermittelte USt-IdNr. | | `vat_validation_status` | `valid`, `invalid`, `format_valid`, `invalid_format`, `could_not_validate` oder `not_applicable` | | `vat_validated_number` | Die geprüfte Nummer, so wie die Quelle sie kennt (etwa die aus einer SIREN abgeleitete USt-IdNr.) | | `vat_validation_source` | Die Quelle, die den Status festgelegt hat (siehe unten) | | `vat_validated_name` | Bei der Quelle registrierter Name, sofern diese ihn angibt | | `vat_validated_address` | Bei der Quelle registrierte Adresse, sofern diese sie angibt | | `vat_checked_at` | Zeitstempel der Prüfung | | Status | Bedeutung | | - | - | | `valid` | Das amtliche Register bestätigt, dass die Nummer eingetragen und aktiv ist | | `invalid` | Das amtliche Register hat keine aktive Eintragung für die Nummer. In der EU führt VIES nur Unternehmen, die für den innergemeinschaftlichen Handel registriert sind | | `format_valid` | Die Nummer erfüllt das Format und die Prüfziffernregeln des Landes. Kein Register wurde abgefragt | | `invalid_format` | Die Nummer erfüllt das Format oder die Prüfziffernregeln des Landes nicht | | `could_not_validate` | Das Register war nicht erreichbar, daher konnte die Nummer nicht geprüft werden. Sie wird beim nächsten Lauf der Registerprüfung erneut geprüft | | `not_applicable` | Es wurde keine USt-IdNr. oder Steuernummer übermittelt, das Land hat kein Register und keine Regeln, oder die Sitzung ist eine Sandbox-Sitzung | `vat_validation_source` ist einer der Werte `eu_vies`, `pl_vat_white_list`, `no_brreg`, `ch_uid_register`, `br_receita_federal`, `co_rues`, `cr_hacienda`, `ec_sri`, `py_dnit` oder `format_rules`. Sobald eine Nummer den Status `valid`, `invalid`, `format_valid` oder `invalid_format` hat, wird das Ergebnis für die restliche Sitzung beibehalten. Das Register wird nur erneut abgefragt, wenn sich die Nummer ändert. **Namensabgleich.** Ist die Nummer `valid` und gibt die Quelle den eingetragenen Namen an, vergleicht Didit ihn unscharf mit dem übermittelten Unternehmensnamen. Eine erhebliche Abweichung löst die Warnung `KYB_COMPANY_VAT_NAME_MISMATCH` aus, ohne den Sitzungsstatus zu ändern. Sie ist ein weiches Signal für Prüfer. Ihr `additional_data` enthält `registry_name`, `registry_source` und `submitted_name`, bei VIES zusätzlich `vies_name`. Einige EU-Mitgliedstaaten geben weder Name noch Adresse preis. Dann bleiben die Felder leer und es findet kein Vergleich statt. **Konfigurierbare Aktionen.** Zwei Einstellungen im Knoten KYB-Registerprüfung legen fest, was eine nicht erfolgreiche Prüfung mit der Sitzung macht (Werte `REVIEW`, `DECLINE`, `NO_ACTION`): | Einstellung | Wird ausgelöst, wenn | Standardwert | | - | - | - | | `kyb_vat_invalid_action` | `vat_validation_status` den Wert `invalid` hat oder eine `vat_number` `invalid_format` ist | `REVIEW`, die Sitzung wechselt in „In Prüfung“ | | `kyb_vat_unverified_action` | `vat_validation_status` den Wert `could_not_validate` hat | `NO_ACTION`, keine Auswirkung auf die Sitzung | Eine `tax_number`, die `invalid_format` ist, wird in der Payload ausgegeben, löst aber keine Aktion aus, weil das Freitextfeld für die Steuernummer oft eine andere Unternehmenskennung enthält. Jedes Ergebnis löst außerdem die passende Warnung (`KYB_COMPANY_VAT_INVALID`, `KYB_COMPANY_VAT_COULD_NOT_VALIDATE`) bei der Registerprüfung aus. Siehe [Warnungen zur Unternehmensverifizierung (KYB)](https://docs.didit.me/de/business-verification/warnings.md#kyb-warnungen-zum-unternehmensregister). ## Datenabgleich Didit vergleicht automatisch die vom Nutzer angegebenen bzw. die kanonischen Daten mit den Daten, die das Register zurückgibt, sowie mit OCR-Daten, die aus hochgeladenen Dokumenten extrahiert wurden: * **Firmenname**: Unscharfer Abgleich, der Abkürzungen und Formatierungsunterschiede berücksichtigt * **Registrierungsnummer**: Exakte Übereinstimmungsprüfung * **Land**: Konsistenzprüfung zwischen dem angegebenen Land und dem Land laut Register * **Adresse**: Geocodierung und Normalisierung für den Vergleich Inkonsistenzen werden in der Sitzung als Warnungen markiert und sind für Analysten in der Konsole sichtbar. ## Finanzübersicht Sofern verfügbar, ruft Didit zusammenfassende Finanzdaten aus dem Register ab: * Umsatzerlöse oder Umsatz * Anzahl der Mitarbeiter * SIC/NACE-Branchencodes * Einreichungsdaten und Compliance-Status ## Zusätzliche Registerfelder Je nach Abdeckung der Jurisdiktion kann die Registerantwort außerdem Folgendes enthalten: * `alternative_names`: Handelsnamen, DBAs, frühere Firmennamen * `legal_entity_identifier` (LEI): für Finanzinstitute und börsennotierte Unternehmen * `website`, `email`, `phone`: Kontaktdaten, die beim Register hinterlegt sind * `nature_of_business`: Kurze Beschreibung (in der Sprache des Registers) * `registered_capital`: Genehmigtes bzw. ausgegebenes Kapital als `{amount, currency}`-Objekt Alle Felder werden im [`business`](https://docs.didit.me/de/business-verification/response-schema)-Block der KYB-Entscheidung abgelegt. ## Konfidenz und Verifizierungsstatus Jede Registerantwort enthält einen `verification_status`: | Wert | Bedeutung | | - | - | | `VERIFIED` | Das Register hat eine Übereinstimmung geliefert und die Daten wurden abgerufen. | | `FAILED` | Das Register hat eine Übereinstimmung geliefert, der Datenabruf ist jedoch fehlgeschlagen (z. B. bei einer unvollständigen Antwort). | | `UNKNOWN` | Das Unternehmen konnte in keinem Register gefunden werden. | Kombinieren Sie das Feld mit `is_from_registry`, um Ihre eigene nachgelagerte Logik zu steuern: | `is_from_registry` | `verification_status` | Bedeutung | | - | - | - | | true | VERIFIED | Vollständig gegen das amtliche Register verifiziert | | true | FAILED | Teilweise: Einige Felder sind möglicherweise veraltet oder fehlen | | false | UNKNOWN | Nur vom Nutzer angegebene Daten; keine Übereinstimmung im Register | ## Ausgaben des Datenabgleichs Jeder Abgleich wird pro Feld ausgeführt und liefert einen der folgenden Werte: * `MATCH`: Die angegebenen Daten stimmen mit dem Register überein. * `MISMATCH`: Erhebliche Abweichung. Wird als Warnung markiert. * `NO_DATA`: Eine Seite war leer; kein Vergleich möglich. Abweichungen sind pro Feld in der Sitzungsprüfung in der Konsole sichtbar. ## Was das Ergebnis bestimmt Unternehmensstatus, Gründungsland, AML-Ergebnisse und die Übereinstimmung mit den angegebenen Daten fließen als Warnungs-Tags für den Registerabgleich und das AML-Screening in die Entscheidung ein. Ihr Workflow legt fest, ob jede Warnung genehmigt, geprüft oder abgelehnt wird. Die Signale und die Workflow-Schlüssel, die sie steuern, finden Sie unter [Risikobewertung](https://docs.didit.me/de/business-verification/risk-assessment.md). ## Unterstützte Länder Die Abdeckung variiert je nach Land. Die Aufschlüsselung nach Stufen und Regionen finden Sie unter [Unterstützte Länder](https://docs.didit.me/de/business-verification/supported-countries.md). ## Nächste Schritte > [card] [Eigentümerstruktur](https://docs.didit.me/de/business-verification/ownership.md) > > UBO-Identifikation und Eigentümerketten. > [card] [Antwortschema](https://docs.didit.me/de/business-verification/response-schema.md) > > Wo jedes Feld im Payload erscheint. > [card] [Unterstützte Länder](https://docs.didit.me/de/business-verification/supported-countries.md) > > Abdeckung nach Region. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.