CSV-, XML- und SFTP-Schnittstellen fürs ERP – wann Datei-Import besser ist als API

Wenn über moderne ERP-Integration gesprochen wird, fällt fast zuerst das Wort API. APIs klingen sauber, modern und versprechen Echtzeit. Das stimmt oft. Im Mittelstand ist es aber nur die halbe Wahrheit.

Viele ERP-Systeme, Warenwirtschaften, Logistiklösungen und Partnerportale arbeiten zuverlässig mit Dateien: CSV-Exporte, XML-Strukturen, Excel-Listen, EDI-nahe Formate. Der Austausch läuft über SFTP, Importordner, Netzlaufwerke oder Middleware. Auf den ersten Blick wirkt das altmodisch.

In der Praxis ist Datei-Import häufig der schnellere, stabilere und wirtschaftlichere Weg. Besonders dann, wenn Prozesse keine Echtzeit brauchen, das ERP keine gute API bietet oder externe Partner ohnehin nur strukturierte Dateien liefern.

Die entscheidende Frage lautet deshalb nicht: „Wie bekommen wir eine API?" Sondern: Welche Integrationsform passt zum Prozess, zum ERP und zum Risiko?

CSV, XML und SFTP – drei Begriffe, die ständig vermischt werden

Bei ERP-Projekten werden CSV, XML und SFTP gern in einem Atemzug genannt. Technisch beschreiben sie aber unterschiedliche Dinge.

CSV ist ein tabellarisches Dateiformat. Geeignet für flache Listen: Artikel, Preise, Kunden, Lagerbestände, Buchungszeilen.

XML ist ein strukturiertes Markup-Format. Geeignet für verschachtelte Daten: Bestellungen mit Kopf, Positionen, Lieferadresse, Steuerinformationen.

SFTP ist kein Datenformat. SFTP ist ein Transportweg – der Briefträger, nicht der Brief. Über SFTP können CSV-, XML-, TXT- oder PDF-Dateien sicher zwischen Systemen übertragen werden.

Eine Anforderung wie „Wir brauchen eine SFTP-Schnittstelle" reicht deshalb nicht. Sie beantwortet nur, wie die Datei transportiert wird. Sie sagt nichts darüber, welches Format sie hat, welche Felder enthalten sind, welche Validierung gilt und wie das ERP den Import verarbeitet.

Eine saubere Spezifikation trennt deshalb immer drei Ebenen:

Ebene	Frage	Beispiele
Format	Wie sind die Daten in der Datei strukturiert?	CSV, XML, JSON, TXT, EDI
Transport	Wie kommt die Datei von A nach B?	SFTP, Importordner, Netzlaufwerk, E-Mail, API-Upload
Verarbeitung	Was passiert nach Eingang?	Validierung, Mapping, ERP-Import, Fehlerprotokoll, Rückmeldung

Ein CSV-Import per SFTP ohne Monitoring ist etwas anderes als eine automatisierte Pipeline mit Validierung, Fehlerstatus und Wiederholungslogik. Beides läuft über SFTP. Nur eines davon ist eine Schnittstelle.

Wann Datei-Import die bessere Entscheidung ist

Datei-Schnittstellen haben ein Imageproblem. Viele verbinden damit manuelle Exporte, Excel-Chaos, nächtliche Batchjobs und kryptische Importfehler. Diese Probleme gibt es. Sie entstehen aber nicht, weil Dateien grundsätzlich schlecht sind. Sie entstehen, weil Datei-Schnittstellen oft ohne Architektur gebaut werden.

Eine gut gebaute Datei-Schnittstelle ist besonders stark in fünf Situationen.

1. Der Prozess braucht keine echte Echtzeit

Viele ERP-Prozesse wirken zeitkritischer, als sie sind. Eine Preisliste wird einmal pro Nacht aktualisiert. Bestellungen werden stündlich übernommen. Artikelstammdaten werden morgens importiert. Buchungsdaten gehen am Tagesende an die Finanzbuchhaltung.

Wenn der fachliche Nutzen von Echtzeit gering ist, ist eine API nicht automatisch besser. Die richtige Frage lautet: Wie aktuell müssen die Daten wirklich sein? Nicht: Wie modern klingt die Schnittstelle?

2. Das ERP hat bereits einen stabilen Import

Viele ERP-Systeme haben über Jahre gereifte Importfunktionen. In diesen Importen steckt mehr fachliche Logik, als externe Entwickler erwarten: Pflichtfeldprüfung, Kundenzuordnung, Preisfindung, Steuerlogik, Mengeneinheiten, Lagerregeln, Sperrkennzeichen.

Eine API müsste diese Logik entweder ebenfalls auslösen oder nachbauen. Wenn der vorhandene ERP-Import zuverlässig funktioniert, ist es meist klüger, ihn kontrolliert zu füttern, statt eine neue Integrationsschicht um ihn herum zu bauen. Welche Wege bei einem Legacy-System konkret realistisch bleiben, zeigt der Artikel Altes ERP ohne API anbinden.

3. Externe Partner liefern ohnehin Dateien

Lieferanten, Speditionen, Marktplätze und Branchenportale arbeiten in der Realität nicht alle mit APIs. Sie stellen Daten als CSV, XML, Excel oder festes Textformat bereit. Manchmal vertraglich, manchmal branchenseitig standardisiert, manchmal schlicht aus Pragmatik.

Dann bringt es wenig, intern eine API einzufordern, wenn die Eingangsdaten als Datei kommen. Sie merken das daran, dass jemand im Einkauf Excel-Listen vom Lieferanten manuell ins ERP überträgt – und sich Dienstagvormittag ärgert, wenn der Header sich am Wochenende geändert hat.

4. Große Datenmengen werden gebündelt übertragen

APIs sind stark bei Einzelvorgängen. Bei großen Datenmengen werden sie unnötig komplex. 100.000 Artikel, 50.000 Preise oder ein vollständiger Lagerabzug laufen als Datei effizienter. Komprimieren, validieren, wiederholen – alles ist auf der Datei einfacher als auf einer API mit Pagination, Rate Limits, Teilabbrüchen und inkonsistenten Zwischenständen. Machbar, aber nicht immer nötig.

5. Direkte API-Zugriffe sind sicherheitstechnisch unerwünscht

Nicht jedes ERP sollte direkt aus dem Internet erreichbar sein. Gerade ältere Systeme oder sensible Finanzsysteme liegen bewusst in geschützten Netzbereichen. Eine API nach außen zu öffnen, erzeugt zusätzliche Sicherheits-, Netzwerk- und Betriebsfragen.

SFTP ist nicht automatisch sicherer als eine API – beides kann sicher oder unsicher betrieben werden. Aber ein SFTP-Austausch mit dediziertem Nutzer pro Partner, getrennten Verzeichnissen, SSH-Schlüsseln und IP-Restriktionen ist in vielen IT-Landschaften einfacher freizugeben als eine direkt erreichbare ERP-API.

Wann eine API trotzdem die bessere Wahl ist

Datei-Import ist nicht immer die richtige Lösung. Eine API ist meist überlegen, wenn ein Nutzer im Portal sofort wissen muss, ob ein Artikel verfügbar ist; wenn Status, Preise oder Liefertermine live abgefragt werden müssen; wenn Vorgänge wirklich transaktional sind (Zahlung autorisieren, Reservierung bestätigen); oder wenn das Zielsystem eine stabile, dokumentierte API mit Webhooks anbietet, die Sie sich nicht durch eine Dateischicht verstellen wollen.

Für die interaktive Oberfläche eines B2B-Portals braucht es eine API. Für den nächtlichen Preislistenimport reicht CSV. Hybride Architekturen sind die Regel, nicht die Ausnahme: API für Live-Abfragen, Datei für die Massenübergabe.

Wie eine robuste Datei-Schnittstelle aufgebaut ist

Ein stabiler Datei-Import ist mehr als ein Ordner und ein Skript. Er besteht aus klar getrennten Schritten, die jeder für sich einzeln scheitern dürfen, ohne den ganzen Prozess zu reißen.

Diese Trennung klingt nach bürokratischem Protokollkram. Genau das verhindert den Anruf vom Kunden, der schon bezahlt hat, dessen Bestellung aber im ERP nie angekommen ist – weil die Datei nachts in einem Fehlerordner liegen geblieben ist und niemand das Logfile öffnet.

Validierung gehört vor das ERP, nicht hinter den ERP-Import

Der größte Fehler bei Datei-Schnittstellen ist, Dateien zu spät zu prüfen. Daten laufen direkt ins ERP, das ERP wirft eine kryptische Meldung zurück, der Innendienst korrigiert nachträglich. Damit wird die Schnittstelle zum Verstärker für Datenqualitätsprobleme, statt sie zu reduzieren.

Eine vorgelagerte Validierung beantwortet drei Fragen:

1. Ist die Datei technisch korrekt? Lesbar, richtige Kodierung, Spalten vorhanden, XML wohlgeformt, Datentypen passen.
2. Sind die Daten fachlich plausibel? Kunde existiert, Artikelnummer bekannt, Menge größer null, Lieferdatum nicht in der Vergangenheit, keine gesperrten Kunden, keine doppelte Bestellnummer.
3. Darf dieser Datensatz automatisch ins ERP? Drei sinnvolle Zustände sind sauber: automatisch verarbeiten, zur Prüfung stellen, blockieren.

Ein zu strenger Prozess blockiert zu viel, ein zu lockerer erzeugt Fehler im ERP. Eine gute Schnittstelle findet den Mittelweg – und macht ihn sichtbar.

Eine Schnittstelle spart nur dann Arbeit, wenn sie nicht gleichzeitig neue Kontrollarbeit erzeugt. Wenn der Innendienst jeden importierten Auftrag nachträglich prüfen muss, wurde der Aufwand nur verschoben. Das Ziel ist nicht, dass alle Daten irgendwie ins ERP kommen. Das Ziel ist, dass gute Daten automatisch verarbeitet werden und problematische früh sichtbar werden.

SFTP, Dateinamen und Idempotenz – die Details, die alles entscheiden

Datei-Schnittstellen scheitern selten am großen Konzept. Sie scheitern an Wiederholungen.

Was passiert, wenn dieselbe Datei zweimal hochgeladen wird? Wenn der Importjob abbricht und neu gestartet wird? Wenn ein Partner eine korrigierte Datei mit gleichem Namen sendet? Wenn der Importjob eine Datei liest, während sie noch übertragen wird?

Diese Fragen klingen klein. In der Praxis entscheiden sie über Stabilität.

Eindeutige Dateinamen. Nicht orders.csv, sondern customerportal_orders_2026-05-04_103000_run-1842.xml. Quellsystem, Datentyp, Datum, Uhrzeit, Lauf-ID, optional Version. Sonst werden Historie, Dublettenprüfung und Fehleranalyse unnötig schwer.

Atomare Ablage. Datei zunächst mit .tmp-Endung hochladen, nach vollständigem Upload umbenennen auf .csv oder .xml. Der Importjob verarbeitet nur fertige Endungen. Wer das überspringt, liest irgendwann eine halb hochgeladene Datei mit fehlenden Positionen.

Externe Referenzen. Jede fachliche Einheit braucht eine eindeutige Kennung – Kundenbestellnummer, externe Auftrags-ID, Lieferantenbelegnummer. Vor jedem Schreiben prüft die Schnittstelle, ob der Vorgang schon verarbeitet wurde. Sonst entstehen drei Aufträge für eine Bestellung, und niemand weiß, welcher gilt.

SFTP-Aufbau mit getrennten Ordnern. /inbox für Eingang, /processing für laufende Verarbeitung, /archive für erfolgreich verarbeitete Dateien, /error für fehlerhafte, /outbox für Rückmeldungen. Plus Schlüssel statt Passwörter, IP-Restriktionen, getrennte Nutzer pro Partner.

Ich habe das schon gesehen – ein Partner hat über zwei Monate dieselbe bestellungen.csv jeden Morgen neu hochgeladen. Der Importjob hat sie jeden Morgen frisch verarbeitet. Aufgefallen ist es bei der ersten Mahnungsrunde, als Kunden plötzlich 60-fach beliefert worden waren.

CSV oder XML – das Format folgt der Datenstruktur

CSV und XML werden oft als austauschbare Alternativen genannt. Sie erfüllen unterschiedliche Aufgaben.

CSV passt, wenn die Daten flach und tabellarisch sind: Artikellisten, Preislisten, Lagerbestände, Adressen, Buchungszeilen, Reporting-Exporte. CSV ist einfach zu erzeugen und von vielen Systemen lesbar. Die Grenzen liegen in der Verschachtelung, in der unklaren Behandlung leerer Werte, in Trennzeichen-Konflikten und in den ewigen Unterschieden zwischen deutschen und englischen Zahlen- und Datumsformaten.

XML passt, wenn die Daten hierarchisch sind: eine Bestellung mit Kopfdaten, Positionen, Lieferadresse, Konditionen und Steuerinformationen. Eine Rechnung mit Steuerzeilen und Zahlungsinformationen. Produktdaten mit Varianten und Attributen. XML kann mit einem Schema validiert werden – das macht den Vertrag zwischen Sender und Empfänger explizit. Nachteil: größere Dateien, mehr Parser-Komplexität, manchmal Namespace-Streit.

Die richtige Frage ist nicht „CSV oder XML?", sondern: Welches Format bildet die fachliche Struktur sauber ab und kann von allen beteiligten Systemen zuverlässig verarbeitet werden? Eine Bestellung mit Positionen in CSV zu pressen, indem man Kopf- und Positionsdaten in zwei Dateien aufteilt, geht. Es ist nur selten die ehrlichere Lösung.

JSON ist im API-Umfeld verbreitet und kann auch dateibasiert übertragen werden. Für klassische ERP-Importe ist es weniger üblich als CSV oder XML – die Entscheidung sollte vom Zielsystem her getroffen werden, nicht ideologisch.

Datei-Import, API, EDI oder Middleware – die nüchterne Entscheidung

In vielen Projekten wird zu früh über Technik entschieden. Besser ist eine Bewertung anhand fachlicher Kriterien.

Kriterium	Datei-Import	API	EDI	Middleware
Echtzeitbedarf	niedrig bis mittel	hoch	mittel	abhängig vom Setup
Datenmengen	gut für große Pakete	komplex bei Massen	gut für Standardfälle	gut für mehrere Quellen
Partnerfähigkeit	sehr gut, wenn Partner Dateien liefern	gut, wenn Partner API-fähig sind	sehr gut bei B2B-Standards	sehr gut bei heterogenen Setups
Legacy-ERP	häufig sehr gut	abhängig von API-Qualität	abhängig von EDI-Gateway	gut als Übersetzungsschicht
Implementierungskosten	oft niedriger	mittel bis hoch	mittel bis hoch	mittel bis hoch
Betrieb	braucht Datei-Monitoring	braucht API-Monitoring	braucht EDI-Monitoring	braucht Plattformbetrieb

In der Praxis sind hybride Lösungen die Regel: SFTP empfängt Lieferantendateien, eine Middleware validiert und mappt, das ERP wird über die Importfunktion befüllt, ein Portal nutzt zusätzlich eine API für Live-Status. Das ist keine technische Schwäche, sondern die realistische Architektur. Wer einen Schritt weiter zurücktritt – welche Schnittstelle für welches Geld unter welchen Bedingungen entsteht – findet die Einordnung in ERP-Schnittstelle programmieren lassen – Kosten, Ablauf, Risiken.

Typische Fehler bei CSV-, XML- und SFTP-Schnittstellen

Datei-Integrationen scheitern selten an der Technik. Sie scheitern an einer Handvoll wiederkehrender Annahmen.

Ein realistischer Pilot für den Mittelstand

Ein dateibasierter Schnittstellen-Pilot beantwortet eine konkrete Frage: Können wir einen wiederkehrenden Datenfluss zuverlässig automatisieren und Fehler vor dem ERP sichtbar machen?

Wichtig ist, nicht alle Datenarten, Partner und Sonderfälle gleichzeitig abzubilden. Gute Pilotkandidaten sind klar geschnittene Datenflüsse mit Volumen: wiederkehrende Bestellungen eines großen Kunden, der tägliche Preislistenexport, der Artikeldatenimport in einen Shop, die Versanddatenübergabe an die Logistiksoftware, der Lieferantenkatalog-Import.

Aus der Praxis zwei Punkte, die häufig unterschätzt werden:

Der Pilot muss gegen echte historische Dateien getestet werden, nicht nur gegen Idealbeispiele. Fehlerhafte, doppelte, alte und unvollständige Dateien zeigen, was die Validierung wirklich braucht. Testdaten reichen nicht.

Vor Go-live müssen Verantwortlichkeiten geklärt sein: Wer sieht Fehler? Wer korrigiert das Mapping, wenn ein Partner sein Format ändert? Wer kontaktiert den Partner? Wer startet ein Reprocessing? Eine Schnittstelle ohne Betriebskonzept ist nur ein halbes Projekt.

Fazit

CSV-, XML- und SFTP-Schnittstellen sind nicht altmodisch. Sie sind oft der pragmatischste Weg, Systeme zuverlässig zu verbinden – wenn Prozesse batchorientiert sind, Partner Dateien liefern, das ERP stabile Importfunktionen anbietet oder eine direkte API-Anbindung zu teuer, riskant oder schlicht unnötig wäre.

Eine API ist stark, wenn Echtzeit, interaktive Rückmeldung und transaktionale Vorgänge wichtig sind. Datei-Import ist stark, wenn strukturierte Datenpakete sicher, wiederholbar und kontrolliert verarbeitet werden sollen.

Der Unterschied zwischen guter und schlechter Datei-Schnittstelle liegt nicht im Format. Er liegt in Spezifikation, Validierung, Mapping, Idempotenz und Monitoring. Wer Datei-Import als „CSV in einen Ordner legen" versteht, baut ein Risiko. Wer ihn als kontrollierte Integrationspipeline versteht, automatisiert wirtschaftlich – und gerade im Mittelstand oft schneller als ein API-Großprojekt.

FAQ zu CSV-, XML- und SFTP-Schnittstellen