Eine ERP-Integration wird oft mit einer technischen Frage gestartet: Gibt es bereits einen Konnektor? Die wichtigere Frage lautet jedoch: Welche Informationen müssen zwischen ERP und HubSpot tatsächlich synchronisiert werden – und welches System ist für welches Datum führend?
Gerade im Mittelstand entstehen Probleme nicht, weil eine Verbindung grundsätzlich unmöglich wäre. Sie entstehen, weil Kontakte, Unternehmen, Aufträge, Produkte oder Serviceinformationen ohne klares Datenmodell in beide Richtungen übertragen werden. Das Ergebnis sind überschreibende Updates, doppelte Datensätze und Prozesse, die niemand mehr sicher erklären kann.
HubSpot und ERP verfolgen unterschiedliche Aufgaben. HubSpot unterstützt kundennahe Prozesse in Marketing, Sales und Service. Das ERP bildet häufig kaufmännische und operative Abläufe ab – etwa Aufträge, Rechnungen, Lieferstatus, Artikel oder Vertragsdaten.
Beide Systeme können daher dieselbe Organisation kennen, aber nicht dieselbe Verantwortung tragen. Ein Unternehmen kann in HubSpot als Vertriebsaccount relevant sein, während das ERP zusätzlich Debitorennummer, Zahlungsbedingungen und Lieferadressen verwaltet. Diese Informationen sollten nicht automatisch gleich behandelt werden.
Eine belastbare Integration beginnt deshalb mit einer fachlichen Zuordnung:
Für jedes synchronisierte Feld sollte ein führendes System definiert werden. Das kann je nach Feld unterschiedlich sein. Beispielsweise kann das ERP die Kundennummer und den Rechnungsstatus führen, während HubSpot für Lifecycle-Status, Vertriebszuständigkeit oder Marketing-Einwilligung verantwortlich ist.
Eine pauschale Zwei-Wege-Synchronisation klingt zunächst bequem, erhöht aber die Komplexität. Wenn beide Systeme denselben Wert ändern dürfen, braucht es klare Regeln für Konflikte. Sonst wird aus einer Integration ein unvorhersehbarer Wettbewerb zwischen zwei Datenquellen.
In der Praxis ist eine asymmetrische Architektur oft robuster:
Wichtig ist, diese Regeln nicht nur technisch zu dokumentieren. Vertrieb, Marketing, Service und Finance müssen verstehen, welche Änderung wo vorgenommen werden darf.
Bei Kontakten und Unternehmen ist weniger oft mehr. Für kundennahe Prozesse können Name, E-Mail-Adresse, Telefonnummer, Unternehmenszuordnung, Rolle, Region und relevante Einwilligungen ausreichen. Das ERP kann zusätzlich eine externe Kunden-ID liefern, die als stabiler Abgleichsschlüssel dient.
Auftragsdaten sollten nicht einfach als Freitext in ein Kontaktfeld geschrieben werden. Je nach Anwendungsfall sind Deals, Orders, Invoices, Line Items oder ein eigenes Objekt fachlich geeigneter. Die Entscheidung hängt davon ab, ob der Datensatz einen Vertriebsprozess, einen konkreten Kauf, eine Rechnung oder eine wiederkehrende Beziehung repräsentiert.
Eine sinnvolle Prüfung lautet: Muss ein Team diesen Datensatz in HubSpot filtern, automatisieren, reporten oder in einer Timeline nachvollziehen können? Wenn ja, sollte er als strukturiertes Objekt oder mit klar definierten Eigenschaften abgebildet werden. Wenn die Information nur für einen seltenen Abgleich benötigt wird, gehört sie möglicherweise gar nicht in HubSpot.
Eine Integration kann alle relevanten Felder übertragen und trotzdem fachlich unbrauchbar bleiben, wenn die Beziehungen zwischen Datensätzen fehlen. Ein Kontakt muss beispielsweise mit dem richtigen Unternehmen verbunden sein. Ein Auftrag muss dem richtigen Unternehmen, Kontakt oder Deal zugeordnet werden. Bei mehreren Rollen können Association Labels zusätzliche Bedeutung schaffen.
HubSpot unterscheidet zwischen Objekten, Eigenschaften und Associations. Die Associations API kann Beziehungen zwischen Datensätzen verwalten; dabei sind sowohl unbeschriftete als auch beschriftete Beziehungen möglich. Für eine individuelle Integration müssen die zulässigen Beziehungstypen und die Richtung der Association vorab geprüft werden.
Besonders kritisch ist die Zuordnung über stabile IDs. Namen oder E-Mail-Adressen sind nicht für jeden Objekttyp ausreichend. Die externe ERP-ID sollte in HubSpot als eindeutiges Identifikationsmerkmal vorgesehen werden, damit Updates nicht versehentlich neue Datensätze erzeugen.
Eine native Data-Sync-Verbindung ist sinnvoll, wenn die beteiligten Objekte, Feldtypen und Synchronisationsregeln zum Standard der Anwendung passen. Sie reduziert den Entwicklungsaufwand und bietet eine überschaubare Konfiguration für Richtung, Feldmapping und Konfliktverhalten.
Die Grenzen liegen dort, wo Geschäftslogik, komplexe Abhängigkeiten oder besondere ERP-Objekte ins Spiel kommen. Custom Objects können in bestimmten Data-Sync-Szenarien unterstützt werden, sind aber an konkrete Produkt- und App-Voraussetzungen gebunden. Außerdem werden Associations bei Custom-Object-Synchronisationen nicht in jedem Fall automatisch erhalten und müssen gegebenenfalls separat abgebildet werden.
Eine individuelle API-Integration ist meist die bessere Wahl, wenn:
Private Apps ermöglichen den API-Zugriff mit gezielt vergebenen Berechtigungen. Für ereignisbasierte Integrationen können Webhooks eingesetzt werden, damit nicht ständig Änderungen abgefragt werden müssen. Das reduziert unnötige Abfragen, ersetzt aber nicht die Notwendigkeit einer belastbaren Fehler-, Wiederholungs- und Protokollierungslogik.
Der häufigste Fehler ist die Synchronisation nach dem Gießkannenprinzip. Jede verfügbare Eigenschaft wird übertragen, obwohl niemand sie im Zielsystem benötigt. Das erhöht die Abhängigkeiten und erschwert spätere Änderungen.
Ebenso problematisch ist eine unklare Synchronisationsrichtung. Wenn ein Status aus dem ERP nach HubSpot kommt, darf ein Workflow ihn nicht unkontrolliert überschreiben. Auch fehlende Association-Logik führt dazu, dass Teams zwar Datensätze sehen, aber keine verlässlichen Kundenbeziehungen nachvollziehen können.
Ein weiterer Fehler ist der fehlende Betriebsprozess. Integrationen brauchen Verantwortliche, Monitoring, dokumentierte Mapping-Regeln und einen Plan für Token, Berechtigungen und Änderungen an Feldern. Eine Verbindung ist kein einmaliges IT-Projekt, sondern ein dauerhaft zu betreibender Prozess.
Plane eine HubSpot-ERP-Integration nicht vom vorhandenen Konnektor aus, sondern vom gewünschten Unternehmensprozess. Starte mit einem begrenzten, klar messbaren Use Case – beispielsweise der Anzeige von Auftragsstatus im Sales-Prozess oder der Übergabe qualifizierter Kundendaten an das ERP.
Definiere zunächst Datenverantwortung, externe Schlüssel und Associations. Erst danach sollte entschieden werden, ob eine native Synchronisation genügt oder eine individuelle API-Architektur erforderlich ist. Für mittelständische Unternehmen ist diese Reihenfolge entscheidend: Sie verhindert, dass technische Möglichkeiten den Prozess bestimmen, statt ihn zuverlässig zu unterstützen.
Stand: Oktober 2026. Produktverfügbarkeit, Berechtigungen und Funktionsumfang können je nach HubSpot-Abonnement, angebundener Anwendung und konkreter Konfiguration variieren.