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.

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 /businesses/resolve-names nimmt eine Liste von Firmennamen und gibt zurück, welche Firmenbuchnummer dazu passt. Das ist der Einstieg — einmal durch den Bestand, danach ist der Schlüssel da.

Ein Abgleich, konkret

Die Anreicherung eines bestehenden Datensatzes ist ein einziger Aufruf über die Firmenbuchnummer:

curl https://api.firmenakte.at/api/v1/businesses/688398a \
  -H "x-api-key: $KEY"

{
  "fnr": "688398a",
  "name": "Gemeindeguru GmbH",
  "legalForm": { "text": "Gesellschaft mit beschränkter Haftung" },
  "court": { "text": "Wien" },
  "isActive": true,
  "isScheinunternehmen": false,
  "inInsolvency": false,
  "addresses": [ ... ],
  "assignments": [ ... ],     // Geschäftsführung, Prokura, Vertretungsbefugnis
  "gisaLicenses": [ ... ],    // Gewerbeberechtigungen
  "latestKeyFigures": { ... },
  "lastCrawledAt": "2026-09-20T05:12:04Z"
}

Drei Felder verdienen Aufmerksamkeit. fnr ist der Join-Schlüssel. assignments enthält, wer vertreten darf und wie — die Angabe, die im CRM am schnellsten veraltet. lastCrawledAt gehört mit in den Datensatz, damit später nachvollziehbar bleibt, auf welchen Registerstand sich eine Angabe bezieht.

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

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

# Was dem Register gehoert. Alles andere gehoert dem CRM.
AMTLICH = ("name", "legalForm", "addresses", "isActive")

for konto in crm.accounts(has_fn=True):
    r = httpx.get(f"{BASE}/businesses/{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 AMTLICH if firma[f] != konto.get(f)}
    if delta:
        delta["register_stand"] = firma["lastCrawledAt"]
        crm.update(konto, delta)          # nur echte Aenderungen

Wer nicht jede Nacht den ganzen Bestand durchgehen will, dreht es um: GET /businesses/changes liefert mit einem Cursor nur die Firmen, an denen sich seit dem letzten Lauf etwas getan hat. Parallel dazu gibt es Feeds für Edikte, Gewerbe und Dokumente.

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. Sie gehört über das Bestätigungsverfahren des BMF geprüft. Was die API liefert, ist der korrekte Firmenwortlaut, die Rechtsform und die Sitzadresse — also das, worauf sich die UID-Prüfung dann bezieht.

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. resolve-names schließt die Lücke.
2. Neuanlage zuerst anbinden. Ab diesem Tag entstehen keine neuen Fehler mehr. Größter Hebel, kleinster Eingriff.
3. Bestand nachziehen und beobachten. Erst der einmalige Abgleich, danach der laufende über den Änderungsfeed.

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.