ERP ohne API anbinden: Dateiaustausch, Datenbankzugriff, RPA oder Ablösung?

Auch ohne moderne API lassen sich bestimmte Abläufe eines älteren ERP-Systems anbinden. Prüfen Sie zuerst unterstützte Dateiimporte und -exporte, lizenzierbare Integrationsmodule und freigegebene Datenzugriffe mit reinen Leserechten. Middleware kann diese Schnittstellen koordinieren. UI-Automatisierung kommt infrage, wenn Betriebsumgebung und Fehlerbehandlung tragfähig sind; eine Ablösung, wenn sich das erforderliche Geschäftsergebnis nicht sicher unterstützen lässt.

Entscheidend ist nicht, ob jemand einmal Daten übertragen kann. Entscheidend ist, ob das Unternehmen angenommene, abgelehnte, doppelte und noch ungeklärte Vorgänge unterscheiden kann. Das muss auch nach einem ERP-Update oder einem fehlgeschlagenen Nachtlauf funktionieren.

Dieser Leitfaden behandelt die Entscheidung „ERP ohne API anbinden“, nicht Connector-Preise oder eine allgemeine ERP-Auswahl. Die Produktdokumentation wurde am 29. September 2026 geprüft. Genannte Systeme veranschaulichen konkrete Schnittstellengrenzen. Daraus folgt weder, dass diese Produkte keine APIs besitzen, noch dass Ihre installierte Version dieselben Funktionen bietet. Empfehlungen und Szenarien bilden unseren Bewertungsrahmen ab, keine Ergebnisse eines praktischen ERP-Produktvergleichs.

Was bedeutet „ERP ohne API“ tatsächlich?

Erfassen Sie Produkt, Edition, genaue Version, Hostingmodell und Supportpartner, bevor Sie eine Technologie wählen. Bedeutet „keine API“: kein REST-Endpunkt, keine lizenzierte Nutzung, fehlende Dokumentation, keine Netzwerkerreichbarkeit oder keine Schnittstelle für den konkreten Geschäftsvorgang? Das sind unterschiedliche Machbarkeitsfragen.

Fragen Sie den Hersteller nach einem unterstützten SDK, SOAP-Dienst, EDI-Verfahren, geplanten Bericht, Kommandozeilenimport oder dokumentierten Staging-Verfahren. Ein kostenpflichtiges Modul kann das Problem sauberer lösen als Bildschirmsteuerung. Prüfen Sie unterstützte Objekte und laufende Nutzungsrechte, bevor Sie eine Broschüre oder Partnerdemo als Nachweis behandeln.

Trennen Sie Lesen, Schreiben und Buchen oder Freigeben. Ein Lagerbestand im Dashboard reserviert keine Ware. Ein angelegter Auftragsentwurf ist noch nicht freigegeben. Exportierte Rechnungszeilen belegen keine Zahlungszuordnung. Beschreiben Sie den akzeptierten fachlichen Endzustand und wer ihn herbeiführen darf.

Für Systeme mit vorhandener API behandelt unser Leitfaden zu Odoo-API-Integrationsgrenzen eine andere Fragestellung: die Architektur innerhalb einer verfügbaren Schnittstelle. Hier ist das erste Ergebnis ein belegtes Verzeichnis nutzbarer Zugänge, nicht ein neues Backend.

Dateiaustausch, Datenbank, Middleware, RPA oder Ablösung?

Wählen Sie den Zugang pro Vorgang, nicht eine Technologie für das gesamte Unternehmen. Ein sinnvoller Entwurf kann einen lesenden Reporting-Datenstrom, einen unterstützten Auftragsimport und eine manuell bearbeitete Ausnahmequeue kombinieren.

Das ist enger gefasst als die allgemeine Entscheidung Individualsoftware oder Standardsoftware. Eine Integrationsprüfung darf ausdrücklich empfehlen, das ERP zu behalten, ein vorhandenes Modul zu kaufen oder einen manuellen Schritt beizubehalten.

Wann unterstützter Dateiaustausch genügt

Verwerfen Sie CSV oder XML nicht wegen der vermeintlich alten Übertragungstechnik. Microsoft dokumentiert im Datenaustauschframework von Business Central Feldzuordnungen, Transformationen und Validierungsmöglichkeiten. Microsoft: Dateimapping und Validierung Das belegt strukturierte Dateiverarbeitung, aber keinen unbeaufsichtigten Import für jeden Belegtyp und jede Installation.

Beschaffen Sie die tatsächliche Spezifikation sowie angenommene und abgelehnte Beispieldateien. Prüfen Sie Zeichencodierung, Datums- und Dezimalformate, Währung, Einheiten, führende Nullen, Leerwerte, Mandantenkennungen und erforderliche Stammdaten. Wird ein mehrzeiliger Beleg vollständig übernommen oder kann ein Teilzustand entstehen? Ein Bankdateiimport ist nicht automatisch eine Auftragsschnittstelle.

Definieren Sie den Übergabevertrag: unveränderliche Batch-Kennung, einzelne Quellreferenzen, Schemaversion, Datensatzanzahl, Integritätsprüfung und ein eindeutiges Fertigsignal. Unvollständige Uploads dürfen nicht verarbeitet werden. WinSCP dokumentiert für binäre SFTP-Übertragungen temporäre Dateinamen mit anschließendem Umbenennen. WinSCP: Übergabe abgeschlossener Uploads Prüfen Sie das Verhalten des gewählten Servers und schließen Sie temporäre Dateien vom Import aus. Nicht jedes FTP- oder Netzlaufwerk-Setup besitzt dieselben Eigenschaften.

Unterscheiden Sie anschließend Empfang und fachliche Annahme. Laut NetSuite-Dokumentation kann ein afterSubmit-Fehler auftreten, obwohl ein Datensatz bereits angelegt oder aktualisiert wurde; dafür soll nicht der gesamte Import wiederholt werden. Oracle: NetSuite-Importergebnisse Die Bezeichnung „Fehler“ reicht somit nicht als Wiederholungsregel.

Ein betriebsfähiger Dateiablauf muss zeigen, welche Quellobjekte welchen ERP-Belegen entsprechen, welche die Validierung nicht bestanden haben und welche noch untersucht werden müssen. Vereinbaren Sie Aufbewahrungsfristen für Dateien und Nachweise und minimieren Sie sensible Felder. Berücksichtigen Sie Scheduler, Zugangsdaten, Speicher, Überwachung und manuelle Ausnahmen im Betriebsaufwand. Wer täglich eine Datei hochlädt, bleibt Bestandteil des Prozesses, solange unbeaufsichtigte Ausführung nicht tatsächlich unterstützt und getestet ist.

Was freigegebener Datenbankzugriff mit Leserechten leistet

Fragen Sie zuerst nach dokumentierten Reporting-Views, einem unterstützten Abfragedienst oder einer freigegebenen Replik. Verlangen Sie nicht sofort unbeschränkte Zugangsdaten zur Produktivdatenbank. SuiteAnalytics Connect von NetSuite ist beispielsweise ausdrücklich lesend und kann NetSuite-Daten nicht verändern. Oracle: Lesegrenze von Connect Ein unterstützter Abfragezugang ist nicht mit direktem Zugriff auf physische Anwendungstabellen gleichzusetzen.

Aus einem Leseprojekt darf kein undokumentiertes Schreiben in ERP-Transaktionstabellen werden. Die SAP-Business-One-Dokumentation zum SDK-Objekt Recordset erlaubt DML für Benutzertabellen, warnt jedoch vor nicht unterstützten Systemtabellenänderungen und Datenkorruption. SAP: Supportgrenzen von Recordset Das ist eine konkrete SAP-Schnittstellenregel, keine pauschale Aussage über jeden ERP-Vertrag. Herstellerseitig freigegebene Staging-Tabellen oder dokumentierte Geschäftsobjektschnittstellen sind gesondert zu prüfen.

Lassen Sie sich bei einer Extraktion die fachliche Bedeutung der Felder erläutern. Bezeichnet „Menge“ physischen, verfügbaren oder reservierten Bestand? Enthält ein Betrag Steuern? Zu welchem Mandanten und Belegstatus gehört eine Zeile? Join-Schlüssel und Zeitstempel ergeben noch keinen Datenvertrag.

Lesend bedeutet weder betrieblich folgenlos noch automatisch konsistent. Microsoft warnt, dass SQL Server mit NOLOCK/READUNCOMMITTED unbestätigte Daten sowie doppelte oder fehlende Datensätze liefern kann. Microsoft: Warnungen zur SQL-Lesekonsistenz Empfehlen Sie diesen Hinweis nicht pauschal gegen Integrationslast. Der DBA muss Konsistenzstrategie, Zeitlimits, Ausführungsplan und Lastfenster freigeben; testen Sie bei repräsentativer ERP-Nutzung.

Belegen Sie bei inkrementeller Extraktion, wie Änderungen, Löschungen und Korrekturen erkannt werden. SQL Server Change Tracking verlangt die Prüfung der noch verfügbaren Mindestversion; ein veralteter Synchronisationsstand erfordert eine Neuinitialisierung. Microsoft: Wiederaufnahme von Change Tracking Change Tracking oder CDC zu aktivieren ist eine eigene Administrations- und Supportentscheidung, kein automatisches Recht aus einem Lesezugang. Ein Änderungsdatumsfilter beweist nicht, dass Löschungen oder verspätete Korrekturen erfasst werden.

Definieren Sie einen initialen Datenstand, eine wiederherstellbare Synchronisationsposition und regelmäßige Abgleiche mit dem maßgeblichen ERP-Bestand. Legen Sie auch fest, was nachgelagerte Nutzer bei veralteten Daten sehen. Eine Reporting-Kopie darf nicht unbemerkt zum führenden System für Reservierungen oder Buchungen werden.

Was Middleware ergänzt und was sie nicht erzeugen kann

Middleware kann Mapping, Zeitplanung, Queues, Zugangsdaten, Kennungen und Ausnahmezuordnung übernehmen. Sie kann einem neuen Portal eine API bereitstellen und im Hintergrund Dateien oder freigegebene Abfragen verwenden. Diese Portal-API ist dann Ihr Integrationsvertrag, keine nachträglich ins ERP gezauberte Transaktionsschnittstelle.

Netzwerkerreichbarkeit ist eine weitere, eigenständige Frage. Microsofts lokales Datengateway nutzt ausgehende Verbindungen statt erforderlicher eingehender Ports. Microsoft: Verbindungsmodell des Gateways Dieses Bereitstellungsmodell erteilt keine Datenbankberechtigung und ergänzt keinen fehlenden Geschäftsvorgang. Prüfen Sie unterstützte Quellen, Zuständigkeit und Aktualisierungspflichten des gewählten Gateways.

Führen Sie pro Geschäftsobjekt einen dauerhaften Nachweis: Quellsystem und Mandant, Quellkennung, Operation, Nutzdatenversion oder Hash, ERP-Kennung, beobachteter Zustand und nächste erlaubte Aktion. Trennen Sie empfangen, validiert, übermittelt, bestätigt, abgelehnt und Ausgang unbekannt. Zeigen Sie nicht „synchronisiert“ an, nur weil eine Datei übertragen oder ein Job eingereiht wurde.

Die AWS-Erläuterung zur Idempotenz unterscheidet Anfrageidentität von gleichem Inhalt und begründet die notwendige Atomizität zwischen Duplikaterkennung und Zustandsänderung. AWS: Anfrageidentität und sichere Wiederholungen Unsere Schlussfolgerung für Altanwendungen ist begrenzt: Ein Middleware-Protokoll allein garantiert keine genau einmalige Wirkung im ERP. Ein Absturz kann nach dem Commit im ERP, aber vor dem Erfolgseintrag im Protokoll auftreten.

Belegen Sie vor Wiederholungen eine unterstützte Suche anhand stabiler Referenzen oder einen anderen verlässlichen Ergebnisnachweis. Prüfen Sie, sofern verfügbar, Eindeutigkeit im Zielsystem bei parallelen Einreichungen. Dieselbe Kennung mit geändertem Inhalt muss einen ausdrücklichen Konflikt oder einen freigegebenen Änderungsprozess auslösen, nicht stillschweigend einen zweiten Auftrag. Wo Gewissheit fehlt, wird untersucht statt aus einem unbekannten Ergebnis ein Duplikat zu machen.

Wann UI-Automatisierung eine vertretbare Grenze bildet

Bewerten Sie UI-Automatisierung für einen konkreten Ablauf, nicht als Standardantwort auf ein ERP ohne API. UiPath dokumentiert Selektoren auf Basis von Elementattributen statt bloßer Koordinaten; wechselnde Layouts und dynamische Attribute bleiben relevant. UiPath: Verhalten von Selektoren Testen Sie den tatsächlichen Altclient, nicht eine moderne Demoanwendung.

Die Betriebsumgebung zählt. Die Dokumentation zu unbeaufsichtigten Power-Automate-Läufen nennt Sitzungsbeschränkungen und mögliche Unterschiede der Bildschirmauflösung gegenüber der Entwicklungssitzung. Microsoft: Grenzen unbeaufsichtigter Sitzungen Ein Ablauf, den ein Entwickler erfolgreich beobachtet, belegt keinen tragfähigen Nachtbetrieb.

Virtuelle Desktops brauchen eine eigene Prüfung. Microsoft setzt für unterstützte Remote-Automatisierung den Power-Automate-Agenten für virtuelle Desktops voraus und nennt Plattformgrenzen. Microsoft: Anforderungen virtueller Desktops Prüfen Sie die konkrete RDP- oder Citrix-Konfiguration, Installationsfreigaben und Versionskompatibilität. Fernzugriff auf einen Bildschirm bietet nicht automatisch dieselbe Elementsteuerung wie eine lokale Installation.

Unsere vorgeschlagenen Freigabebedingungen sind ausdrückliche Eingabeprüfung, freigegebene Identitäten, ein zulässiges Sitzungsmodell, Kontrolle von ausgewähltem Mandanten und Datensatz sowie eine maßgebliche Ergebniskontrolle. Behalten Sie bei entsprechendem Geschäftsrisiko eine menschliche Freigabe bei. Deaktivieren Sie nicht MFA, Endgeräteschutz oder Updates, nur damit ein Bot weiterläuft.

Messen Sie realistischen Durchsatz einschließlich Anmeldung, Wartezeiten, Validierungsdialogen und Ausnahmebearbeitung. Testen Sie gleichzeitige menschliche Nutzung, Zeitüberschreitungen, abgelaufene Zugangsdaten, geänderte Beschriftungen, gesperrte Datensätze und Rechnerneustarts. Benennen Sie einen Verantwortlichen für Fehlläufe und den maximal zulässigen Rückstau.

Computer-Use-Modelle heben diese Abnahmebedingungen nicht auf. Auch ein vom Modell gewählter Klick benötigt Berechtigung, begrenzte Eingaben und einen Nachweis des fachlichen Ergebnisses. Bei sensiblen Buchungen oder Zahlungen genügt ein scheinbar erfolgreicher Screenshot nicht als Grundlage für automatische Wiederholung oder Freigabe. Eine sinnvolle Lösung kann die beaufsichtigte Belegvorbereitung sein, während ein Mitarbeiter die abschließende Entscheidung trifft.

Fehlerbehandlung: 120 Übermittlungen sind nicht 120 abgeschlossene Vorgänge

Illustratives Szenario, kein Kundenergebnis: Ein Batch enthält 120 Quellaufträge. Die Integration bestätigt 117 ERP-Belege, erhält zwei eindeutige Validierungsablehnungen und verliert bei einer Übermittlung die Antwort. Der Abgleich lautet 120 = 117 bestätigt + 2 abgelehnt + 1 Ausgang unbekannt, nicht „drei Fehler erneut ausführen“.

Behalten Sie die 117 bestätigten Zuordnungen von Quelle zu ERP. Korrigieren Sie die beiden abgelehnten Aufträge und übermitteln Sie erst erneut, wenn feststeht, dass kein Geschäftsbeleg angelegt wurde. Suchen Sie den ungeklärten Vorgang über den freigegebenen Zugang anhand seiner stabilen Referenz und prüfen Sie den Zustand. Wiederholen Sie nicht blind den gesamten Batch. Ohne verlässliche Aufklärung eines unbekannten Ergebnisses besteht die unbeaufsichtigte Übermittlung eine wichtige Machbarkeitsprüfung nicht.

Anzahlen sind nur der erste Abgleich. Vergleichen Sie Geschäftskennungen, Mandant, Belegstatus, Positionsmengen, Währung und relevante Summen. Testen Sie Änderungen, Stornos und vertauschte Reihenfolgen. Gleiche Summen können eine falsche Belegzuordnung verdecken. Bewahren Sie deshalb objektbezogene Nachweise auf statt nur einer grünen Dashboardzahl.

Wiederherstellung ist nicht immer ein technisches Rollback. Microsoft beschreibt Kompensation als fachlich spezifisch und gegebenenfalls auf manuelle Eingriffe angewiesen. Microsoft: fachliche Kompensation Vereinbaren Sie bei ERP-Integrationen mit dem Fachverantwortlichen unterstützte Storno-, Korrektur- oder Gegenbuchungswege. Löschen Sie keine Transaktionszeilen und setzen Sie nicht wegen eines einzelnen Duplikats die gesamte Produktivdatenbank zurück.

Definieren Sie, wer unbekannte Ergebnisse untersucht, wer Korrekturen freigeben darf, wie nachgelagerte Arbeit pausiert und wann eskaliert wird. Üben Sie das Betriebshandbuch mit Fehlerfällen. Ein Wiederholungszähler ohne fachlichen Verantwortlichen ist kein Wiederherstellungsprozess.

Was eine bezahlte Integrations-Machbarkeitsprüfung klären sollte

Beauftragen Sie zunächst eine belastbare Entscheidung statt sofort die Umsetzung. Beginnen Sie mit einem repräsentativen Ablauf und dessen Erfolgskriterien und prüfen Sie die folgenreichste Unsicherheit. Stellen Sie anonymisierte Beispiele, Schnittstellendokumentation, Betriebsdetails, relevante Lizenzbedingungen und einen autorisierten ERP-Ansprechpartner bereit. Gewähren Sie Zugang über einen freigegebenen Prozess, nicht per Passwort im E-Mail-Anhang.

Kennzeichnen Sie Nachweise ehrlich: vom Hersteller dokumentiert, in der geprüften Umgebung bestätigt, nur im Test demonstriert, vorgeschlagen, blockiert oder nicht getestet. Ein Prototyp belegt nur Beobachtungen unter seinen genannten Bedingungen. Er beweist für sich weder Produktionszuverlässigkeit noch Updateverträglichkeit oder dauerhaften Spitzendurchsatz.

Eine Prüfung beseitigt keine ungelöste Herstellerabhängigkeit. Fehlende Dokumentation oder Zugänge können eine abschließende Aufwandsschätzung verhindern. Ein nützliches bezahltes Ergebnis darf den Blocker und die für eine Neubewertung benötigten Nachweise benennen, statt auf einer Annahme einen festen Umsetzungspreis zu versprechen.

Welche Fehlerfälle sollte der Auftraggeber testen lassen?

Verwenden Sie die folgenden Fälle als vorgeschlagenes Abnahmepaket. Vereinbaren Sie Kriterien und Zuständigkeiten vor der Demo und bewahren Sie je relevantem Fall Nachweise auf. „Nicht anwendbar“ braucht eine Begründung; „nicht getestet“ ist kein bestandener Test.

Drei illustrative Entscheidungen mit unterschiedlichen sinnvollen Ergebnissen

Ein Händler benötigt den Abgleich am nächsten Morgen

Angenommen, das installierte ERP bietet einen unterstützten Auftragsimport, geplanten Bestandsexport und objektbezogene Ergebnisse. Das Unternehmen akzeptiert nächtliche Verarbeitung. Beginnen Sie mit diesen Dateien und nur der notwendigen Koordination für Validierung, sichere Übertragung und Ausnahmen. Eine Komplettablösung oder ein UI-Bot ist nicht allein deshalb sinnvoll, weil REST moderner wirkt. Prüfen Sie zuerst Wiederholungsverhalten und Teilannahme.

Ein Hersteller benötigt Reporting statt Transaktionserfassung

Angenommen, eine freigegebene Reporting-View enthält die benötigten Daten und der DBA akzeptiert die Extraktionslast. Verwenden Sie lesende Extraktion mit definierter Aktualitätsanzeige und Abstimmung. Reservierungen und Buchungen bleiben im ERP. Eine spätere Forderung nach sofortigen Bestandszusagen verändert den Umfang und benötigt einen unterstützten Schreibweg. Sie ist keine kleine Ergänzung des Reporting-Datenstroms.

Ein kleiner Ablauf ist nur über die Oberfläche zugänglich

Angenommen, der Hersteller erlaubt den geplanten Zugriff, die konkrete Oberfläche ist automatisierbar und ein Mitarbeiter muss den endgültigen Beleg freigeben. Beaufsichtigte Vorbereitung kann genügen. Verlangt das Unternehmen stattdessen unbeaufsichtigte irreversible Buchungen, fehlen aber verlässliche Ergebnissuche oder ein unterstütztes Sitzungsmodell, wird dieser Entwurf nicht unverändert umgesetzt. Prüfen Sie ein Herstellermodul, eine kontrollierte manuelle Grenze oder eine Ablösung.

Diese Entscheidungsszenarien sind erfunden, keine Projektschätzungen. Sie belegen weder einen universell günstigsten Ansatz noch Lieferdauer oder Kapitalrendite. Kalkulieren Sie den akzeptierten Ablauf und die laufenden Verantwortlichkeiten einschließlich fachlicher Ausnahmebearbeitung gegenüber dem tatsächlichen Ausgangsprozess.

Wann Ablösung, Aufschub oder ein No-Go angemessen sind

Stoppen Sie den geplanten Ansatz, wenn er nicht freigegebenen Zugriff, nicht unterstützte Transaktionsänderungen, das Umgehen von Sicherheitskontrollen oder die Wiederholung irreversibler Aktionen mit unbekanntem Ergebnis voraussetzt. Dasselbe gilt, wenn geforderte Aktualität die beobachtbare Quellaktualisierung übersteigt oder niemand den Betrieb verantwortet.

Ein gestoppter Entwurf bedeutet nicht automatisch eine ERP-Komplettablösung. Begrenzen Sie den Umfang auf lesendes Reporting, behalten Sie einen beaufsichtigten Import, beschaffen Sie ein freigegebenes Modul oder verschieben Sie den Ablauf bis zu geänderten Supportbedingungen. Unterscheiden Sie eine lästige Einschränkung von einer geschäftskritischen Unmöglichkeit.

Microsoft beschreibt mit Strangler Fig eine schrittweise Migration, nennt aber Grenzen bei nicht abfangbaren Anfragen oder nicht veränderbarem Quellcode. Microsoft: Grenzen schrittweiser Migration Setzen Sie nicht voraus, dass sich vor ein geschlossenes Desktop-ERP einfach eine transparente API-Fassade setzen lässt und das Altsystem anschließend schrittweise verschwindet.

Belegen Sie trennbare fachliche Grenzen, bestimmen Sie das führende System während des Parallelbetriebs und planen Sie historischen Datenzugriff, Abstimmung, Umstellung und Support. Schrittweise Migration ist ein Architekturvorschlag, kein Versprechen störungsfreien Betriebs. Alte und neue Betriebskosten können parallel anfallen, bis eine echte Abhängigkeit entfällt.

Eine bezahlte Integrations-Machbarkeitsprüfung abgrenzen

Bringen Sie einen Ablauf, ERP und Version, ein bereinigtes Beispiel, vorhandene Schnittstellendokumentation, erforderliche Zeitfenster und typische Ausnahmen mit. Der Prüfauftrag sollte Zugriffsfreigabe, Fehlerbehandlung, Supportfähigkeit und eine Go/No-Go-Empfehlung ausdrücklich enthalten. Vereinbaren Sie Honorar und Ergebnisse getrennt von einer möglichen Umsetzung.

Wavects individuelle Softwareentwicklung ist die Anlaufstelle für abgegrenzte Integrationsprojekte. Die MyMerch-Fallstudie zur Prozessautomatisierung liefert angrenzenden Umsetzungskontext, aber keinen Nachweis einer ERP-Integration ohne API oder der Kompatibilität mit Ihrem System.

Fragen Sie eine bezahlte Machbarkeitsprüfung für Ihre ERP-Anbindung an, bevor Sie die Gesamtlösung beauftragen. Das Folgeangebot sollte den Nachweisen folgen: Konfiguration, kleiner Adapter, beaufsichtigte Automatisierung oder keine Umsetzung.