Firmendaten im CRM aktuell halten

Warum Handarbeit hier verliert

Niemand pflegt Daten schlecht, weil er schlampig ist. Er pflegt sie schlecht, weil die Eingabemaske im Moment der Erfassung nichts weiß. Jemand hört einen Firmennamen am Telefon, tippt ihn ein und rät den Rest: Rechtsform, Adresse, Schreibweise. Aus „Mayr“, „Mayer“ und „Maier Bau GmbH“ werden drei Datensätze, die technisch verschieden und fachlich identisch sind.

In jeder CRM-Datenbank ab etwa fünf Jahren Laufzeit finden sich dieselben vier Muster:

• Dubletten ohne gemeinsamen Schlüssel. Dedupliziert wird über den Firmennamen — die instabilste Eigenschaft eines Unternehmens.
• Falsche Rechtsformen. Aus „GmbH & Co KG“ wird „GmbH“, und die Rechnung geht an die falsche juristische Person.
• Veraltete Organe. Der Ansprechpartner ist seit zwei Jahren nicht mehr Geschäftsführer, zeichnet aber weiter Angebote ab.
• Tote Adressen. Sitzverlegungen werden im Firmenbuch eingetragen und in keinem CRM der Welt automatisch nachgezogen.

Der Schaden ist unspektakulär und dauerhaft: Retouren, Mahnungen an die falsche Anschrift, doppelte Betreuung durch zwei Außendienstler, Auswertungen, die dieselbe Firmengruppe zweimal zählen.

Wenn eine Prüfpflicht dazukommt

Sobald Stammdaten Teil einer KYC- oder Geldwäscheprüfung werden, wird aus dem Ärgernis ein Risiko. Drei Punkte fallen im Alltag auf:

• Zeichnungsberechtigung. Unterschreibt diese Person überhaupt allein rechtswirksam? Das steht im Firmenbuch und in keinem CRM-Freitextfeld.
• Insolvenz und Scheinunternehmen. Ediktsdatei und die BMF-Liste sind öffentlich. Wer sie nicht abgleicht, erfährt davon aus der Buchhaltung.
• Nachweisbarkeit. Eine Prüfung ohne Stand und Quelle ist im Anlassfall keine Prüfung. Deshalb gehört zu jedem übernommenen Feld der Registerstand in den Datensatz.

Welche Register vor einem neuen Geschäft sonst noch zählen, zeigt die Checkliste zur Prüfung von Geschäftspartnern.

Der Schlüssel ist die Firmenbuchnummer

Alles Weitere hängt an einer Entscheidung: Die Firmenbuchnummer wird zum Schlüssel, nicht der Name. Sie bleibt stabil, wenn Name, Adresse und Geschäftsführung wechseln, und macht aus einer Namenssuche einen belastbaren Join — über CRM, ERP und jede spätere Anreicherung hinweg.

Für den Bestand, der noch keine FN hat, gibt es einen eigenen Endpunkt: POST /companies/resolve nimmt mehrere Einträge auf einmal mit Name und optionalen Identifikatoren entgegen. Das Ergebnis unterscheidet eindeutige Treffer, mehrdeutige Kandidaten und Einträge ohne Treffer. Nur eindeutige Treffer dürfen automatisch verknüpft werden; Kandidaten brauchen eine Prüfung. Speichere die zurückgegebene Firmenakte-ID neben der Firmenbuchnummer.

Ein Abgleich, konkret

Neue Integrationen verwenden die v2-API. Eine Firmenbuchnummer wird als Alias aufgelöst; im Ergebnis steht die stabile Firmenakte-ID. Bestehende v1-Integrationen bleiben unterstützt, die Dokumentation beschreibt die Übergangsfrist. Das Profil und die ersten Seiten der Personen und Gewerbeberechtigungen liest du so:

curl "https://api.firmenakte.at/api/v2/companies/fnr:688398a?include=people,licenses" \
  -H "x-api-key: $KEY"

Die Antwort enthält unter anderem id, name, legalForm, seat, isDeleted, insolvency, identifiers und die angeforderten Sammlungen people und licenses. Sammlungen können einen nextCursor haben; weitere Seiten werden über die jeweiligen Unterrouten gelesen. Fehlende Angaben sind keine bestätigten Leerwerte.

Speichere die Firmenakte-ID als Referenz und protokolliere den Abrufzeitpunkt. Er ist der Zeitpunkt deines Abgleichs, nicht das Datum einer Registerveröffentlichung. Für Änderungsbelege unterscheidet der Feed recordedAt und occurredDate.

Disziplin beim Schreiben

Der Nachtlauf geht über dieselbe Route und schreibt nur, was sich tatsächlich geändert hat. Die Regel, die den Unterschied macht: Felder aus dem Register werden überschrieben, händisch gepflegte Felder bleiben unberührt, und jede Übernahme bekommt ihren Stand mit.

import os, httpx
from datetime import datetime, timezone

BASE = "https://api.firmenakte.at/api/v2"
HEAD = {"x-api-key": os.environ["FA_KEY"]}

# Was dem Register gehoert. Alles andere gehoert dem CRM.
REGISTERFELDER = ("name", "legalForm", "seat", "isDeleted")

for konto in crm.accounts(has_fn=True):
    r = httpx.get(f"{BASE}/companies/fnr:{konto.fn}", headers=HEAD, timeout=15)
    if r.status_code == 404:
        crm.flag(konto, "fn_unbekannt")   # zur Klaerung, nicht loeschen
        continue
    r.raise_for_status()
    firma = r.json()

    delta = {f: firma[f] for f in REGISTERFELDER if f in firma and firma[f] != konto.get(f)}
    if delta:
        delta["firmenakte_id"] = firma["id"]
        delta["abgerufen_am"] = datetime.now(timezone.utc).isoformat()
        crm.update(konto, delta)          # nur echte Aenderungen

Wer nicht jede Nacht den ganzen Bestand durchgehen will, dreht es um: GET /changes liefert die Registeränderungen nach der zuletzt verarbeiteten Sequenz (after). Die Quelle lässt sich über register eingrenzen. Dedupliziere Ereignisse über ihre id und speichere nextCursor nach erfolgreicher Verarbeitung als neuen after-Wert, auch für leere Seiten. Das betroffene Profil liest du anhand von subject.id erneut.

Wo das CRM oder ERP andockt

Eine API nützt nichts, wenn sie neben dem System steht, in dem gearbeitet wird. Angebunden wird an genau zwei Stellen: bei der Neuanlage und im Bestandsabgleich. Alles andere ist Kür.

Bei der Neuanlage zahlt sich die Abfrage sofort aus: Der Vertrieb tippt zwei Wörter, wählt die Firma aus der Trefferliste, und Name, Rechtsform, Sitzadresse, Firmenbuchnummer und die vertretungsbefugten Organe stehen im Formular.

Die UID-Nummer steht nicht im Firmenbuch. Firmenakte prüft sie über VIES, wie im Artikel UID-Nummer automatisch prüfen beschrieben. Das Firmenprofil liefert den korrekten Firmenwortlaut, die Rechtsform und die Sitzadresse, also das, worauf sich die UID-Prüfung bezieht.

Wer selbst Software entwickelt und die Firmensuche direkt ins Produkt einbauen will, findet die Bausteine im Artikel Firmendaten in die eigene Software integrieren.

Die Einführung in drei Schritten

1. Bestand vermessen. Wie viele Datensätze haben überhaupt eine FN? Dieser Anteil ist die Startlinie, und er ist am Anfang meist niedriger als erwartet. POST /companies/resolve liefert eindeutige Zuordnungen oder Kandidaten zur Prüfung.
2. Neuanlage zuerst anbinden. So werden geprüfte Registerdaten bereits bei der Anlage übernommen. Größter Hebel, kleinster Eingriff.
3. Bestand nachziehen und beobachten. Erst der einmalige Abgleich, danach der laufende über den Änderungsfeed.

Häufige Fragen

Wie halte ich Firmendaten im CRM automatisch aktuell?

Über eine Schnittstelle zum Firmenbuch: Bei der Neuanlage übernimmt das CRM die Registerdaten, danach meldet ein Änderungsfeed neue Eintragungen. Firmenakte liefert beides über die Firmenbuch-API.

Warum ist die Firmenbuchnummer der bessere Schlüssel als der Firmenname?

Weil sie stabil bleibt, wenn sich Name, Adresse oder Geschäftsführung ändern. Über den Namen entstehen Dubletten, über die Firmenbuchnummer nicht.

Wie verknüpfe ich bestehende Kunden mit dem Firmenbuch?

Mit einem einmaligen Abgleich über POST /companies/resolve. Eindeutige Treffer werden automatisch verknüpft, mehrdeutige Kandidaten prüfst du von Hand.

Steht die UID-Nummer im Firmenbuch?

Nein. Die UID vergibt das Finanzamt. Ihre Gültigkeit prüfst du über VIES oder das Bestätigungsverfahren in FinanzOnline.

Welche CRM-Systeme lassen sich anbinden?

Jedes System, das HTTP-Aufrufe absetzen kann, etwa Salesforce, HubSpot, Dynamics 365, BMD, SAP oder Odoo. Auch Automatisierungen mit n8n, Make oder Zapier funktionieren.

Fazit

Stammdaten altern von selbst. Kein Pflegeprozess hält dagegen, solange die Quelle ein Telefonat und die Prüfung ein Bauchgefühl ist. Die Firmenbuch-API dreht das um: Das Register liefert, das System übernimmt, und der Mensch entscheidet nur noch dort, wo wirklich zu entscheiden ist.