Bestelldaten mit Ihrem Inventarsystem verbinden
Ohne Entwickler

Die eigentliche Lücke zwischen extrahierten Bestelldaten und Ihrem Warenwirtschaftssystem ist keine Technologiefrage – es ist die Formatübersetzung

Fragen Sie einen Einkaufsleiter, was passiert, nachdem das KI-Tool die Bestellfelder in eine Tabelle extrahiert hat, und Sie erhalten branchenübergreifend dieselbe Antwort: „Ich öffne die Datei, benenne die Hälfte der Spalten um, damit sie dem entsprechen, was das Warenwirtschaftssystem erwartet, korrigiere das Datumsformat, suche die interne Lieferanten-ID, teile die Daten in Kopf- und Positionsdaten auf, falls das System dies verlangt, und speichere sie erneut als CSV." Das ist keine Integration. Das ist Neuformatierung – und das kostet jedes Mal 15–30 Minuten pro Import.

Dieser Schritt existiert, weil Bestelldaten in der Sprache des Lieferanten ankommen – „Bestelldatum", „Lieferant", „Artikel-Nr." – und Ihr Warenwirtschaftssystem seine eigene spricht: „Belegdatum", „Lieferantenname", „Artikelnummer". Die Übersetzungsarbeit zwischen beiden fällt demjenigen zu, der den Upload durchführt. Die meisten Teams betrachten dies als unvermeidlich. Ist es aber nicht.

Das Problem wird durch die Formatvielfalt noch verschärft. Ein Hersteller, der von 30 Lieferanten kauft, erhält Bestellungen in 30 Layouts. Selbst nach der Extraktion der Daten in eine saubere Tabelle – mit einem Tool wie der KI-gestützten Bestellfeldextraktion – entspricht die für Menschen lesbare Struktur (nach Lieferant gruppiert, mit beschreibenden Spaltenüberschriften) selten dem, was die Importschnittstelle eines Warenwirtschaftssystems akzeptiert. Die Lösung erfordert das Verständnis dessen, was das Zielsystem tatsächlich erwartet, nicht nur dessen, was richtig aussieht.

Ihr nachgelagerter Workflow ändert sich nicht – und das ist der Punkt

Wenn Teams zögern, eine neue Dateneingabemethode einzuführen, liegt das selten daran, dass sie Dateneingabe lieben. Sondern daran, dass sie eine fragile, aber funktionale Pipeline darum herum aufgebaut haben, und jede Änderung lässt sie fragen: „Wird der Wareneingang dadurch gestört? Funktioniert die Einlagerung noch? Was passiert mit den Inventurzählungen?" Die Antwort bei einem richtig eingerichteten Extraktions-zu-Warenwirtschafts-Fluss lautet: Nichts davon ändert sich.

So bleibt alles in Ihrem Workflow unverändert:

• Wareneingang — die Lagermitarbeiter prüfen die eingehende Ware weiterhin anhand der Bestellung im Bestandssystem, genau wie bisher. Die Bestellung ist bei Eintreffen der Lieferung bereits im System vorhanden.
• Einlagerung — Behälterplätze, Gangzuweisungen und Scan-Workflows bleiben unberührt. Der Bestandseintrag wurde durch den Import erstellt, genau wie bei manueller Erfassung.
• Inventurzählungen und körperliche Inventur — diese vergleichen den physischen Bestand mit den Systemdaten. Die Quelle dieser Daten (manuelle Eingabe oder Import) spielt für den Zählprozess keine Rolle.
• Lieferantenabstimmung — Ihre Kreditorenbuchhaltung gleicht weiterhin Rechnungen mit den Bestellungen im System ab. Die Bestelldaten sind vorhanden. Die Abgleichlogik ist unabhängig von deren Herkunft.
• Nachbestellauslöser — Mindestbestände, Lieferzeiten und Meldebestände arbeiten alle mit Systemdaten, unabhängig von deren Ursprung.

Der einzige Schritt, der sich ändert, ist die Art, wie Bestelldaten ins System gelangen. Statt dass jemand ein PDF liest und Felder in die Bestandsoberfläche tippt (oder in eine Tabelle kopiert und dann importiert), fließen die Daten von der Extraktion → strukturierte Ausgabe → Import. Ein Schritt ersetzt die manuelle Eingabe. Alles nachgelagerte bleibt unverändert.

Der neue Schritt (KI-Extraktion → strukturierte Ausgabe) ersetzt die manuelle Dateneingabe. Alles nach dem Import ist identisch.

Extraktionsspalten nach dem Zielsystem benennen, nicht nach dem Quelldokument

Dies ist die Integrationstechnik, die den Umformatierungsschritt komplett überflüssig macht. Statt Bestelldaten mit Spaltenüberschriften zu extrahieren, die das Lieferantendokument widerspiegeln ("Bestell-Nr.", "Lieferant", "Artikelcode") und diese dann manuell umzubenennen, benennen Sie die Extraktionsspalten so, dass sie exakt dem entsprechen, was Ihr Inventarsystem beim Import erwartet.

Das ermöglicht die Spaltennamenextraktion: Sie legen die gewünschten Datenfelder fest – „PONum“, „VendorName“, „PartNumber“ – und die KI findet die zugehörigen Werte überall im Dokument, indem sie die semantische Bedeutung jedes Feldes versteht. Dabei spielt es keine Rolle, wie der Lieferant diese Felder nennt. „Order Reference“, „PO #“ oder „Document No.“ – alles wird auf „PONum“ abgebildet, weil die KI die Bedeutung und nicht die Bezeichnung liest.

Das kehrt den herkömmlichen Arbeitsablauf um. Normalerweise extrahieren Sie zuerst Daten (mit beliebig wirkenden Spaltennamen), exportieren sie in eine Tabelle, vergleichen sie mit der Importvorlage des Bestandssystems, benennen Spalten um, formatieren Daten neu und importieren dann. Der Ansatz der Spaltennamen-Angleichung vereint Extraktion und Formatierung in einem Durchlauf: Die Ausgabedatei ist bereits für das Zielsystem strukturiert.

Für Bestellungen mit fehlenden Feldern – ein Lieferant gibt kein Lieferdatum pro Position an, aber Ihr Bestandssystem benötigt eines – können Sie berechnete Spalten nutzen, um die Lücke während der Extraktion zu schließen. Wenn das Lieferdatum nur im Bestellkopf steht, kann eine berechnete Spalte es für jede Positionszeile ableiten. Fehlt der Stückpreis, sind aber Positionssumme und Menge vorhanden, füllt eine einfache Summe ÷ Menge-Berechnung ihn aus. Die Extraktions-Engine findet sowohl vorhandene Daten als auch leitet implizite Daten ab.

Wenn Sie mehrere Bestellungen auf einmal verarbeiten – etwa einen Stapel von 50 PDFs verschiedener Lieferanten –, wendet die Stapelerfassung dieselbe Spaltenzuordnung auf alle Dateien in einem Durchgang an. Das Ergebnis ist eine einzige strukturierte Datei, die für den Import bereit ist – unabhängig davon, wie viele verschiedene Lieferantenformate im Stapel enthalten waren.

Wie fünf Inventarsysteme tatsächlich Bestelldaten empfangen – und wie Ihre Extraktionsausgabe dazu passen muss

Jedes Inventarsystem hat ein spezifisches Importformat. Die Unterschiede sind klein, aber folgenreich – ein falsches Detail und der gesamte Import schlägt fehl. Hier erfahren Sie, was jedes System laut offizieller Dokumentation erwartet und wie Sie Ihre Extraktionsausgabe entsprechend strukturieren.

Fishbowl Inventory

Fishbowl wird häufig in der nordamerikanischen Fertigungs- und Großhandelsbranche eingesetzt. Der CSV-Import für Bestellungen verwendet ein Zwei-Zeilen-Typ-System:

• Zeilentyp 1 – Bestellkopf: Die erste Spalte enthält den Text „PO". Felder umfassen PONum, Status (numerisch: 10=Angebotsanfrage, 15=Ausstehende Genehmigung, 20=Ausgestellt, 95=Historisch), VendorName (Groß-/Kleinschreibung wird ignoriert, wird bei Nichtfinden automatisch angelegt), RemitToName, ShipToName, CarrierName und Datumsfelder.
• Zeilentyp 2 – Artikelzeile: Die erste Spalte enthält den Text „Item". Felder umfassen POItemTypeID (numerisch: 10=Einkauf, 20=Gutschrift-Rückgabe, 30=Fremdvergabe, 40=Versand), PartNumber (muss mit einer vorhandenen Fishbowl-Teilenummer übereinstimmen), VendorPartNumber, PartQuantity und UnitCost.

Flag,PONum,Status,VendorName,RemitToName,...
PO,PO-2026-0423,20,Acme Industrial,Acme Industrial,...
Item,10,PART-8842,VP8842-A,250,14.75,...
Item,10,PART-7721,VP7721-B,100,22.30,...

Zoho Inventory

Zoho Inventory bietet einen Standard-CSV-Import mit Feldzuordnung. Anders als Fishbowls Flag-System verwendet Zoho eine flache Struktur, bei der jede Zeile einen Positionsartikel darstellt und felder auf Kopfebene sich über Zeilen wiederholen:

• Laden Sie die Beispiel-Importvorlage von Zohos Importseite herunter – sie enthält die exakten Spaltenüberschriften und die erwartete Reihenfolge.
• Während des Imports können Sie Ihre CSV-Spalten interaktiv Zoho-Feldern zuordnen. Das bedeutet, Ihre Spaltennamen müssen nicht perfekt mit Zohos Feldnamen übereinstimmen – Sie können sie während des Upload-Schritts angleichen.
• Pflichtfelder sind Lieferantenname, Artikelname, Menge und Preis. Lieferant und Artikel müssen vor dem Import in Zoho vorhanden sein.

Lieferantenname,Artikelname,Menge,Preis,Bestellnummer,Lieferdatum
Acme Industrial,PART-8842,250,14.75,PO-2026-0423,2026-05-15
Acme Industrial,PART-7721,100,22.30,PO-2026-0423,2026-05-15

Cin7 Core

Cin7 Core (ehemals DEAR Inventory) verwendet eine RecordType-basierte CSV-Struktur, die komplexer ist als die meisten. Die erste Spalte jeder Zeile bestimmt, um welchen Datentyp es sich handelt, gemäß der offiziellen Importdokumentation:

• RecordType-Werte: header, invoice_lines, stock_received, additional_costs, payments, credit_notes, refunds, unstock.
• Die Kopfzeile (Spaltennamen) ist Pflicht – Cin7 validiert den CSV-Typ anhand der Kopfzeile.
• Mehrere Bestellvorgänge können in einer Datei enthalten sein (bis zu 100 Vorgänge pro Import).
• Wichtige Einschränkung: Sie können bestehende Bestellzeilen nicht per CSV bearbeiten – der Import dient nur zum Erstellen neuer Vorgänge. Vorhandene Zeilen müssen über die API verwaltet werden.

RecordType,Supplier,OrderNumber,OrderDate,...
header,Acme Industrial,PO-2026-0423,2026-05-10,...
invoice_lines,ITEM-8842,250,14.75,...
invoice_lines,ITEM-7721,100,22.30,...

Katana MRP

Katana verfolgt einen anderen Ansatz als die oben genannten CSV-zentrierten Systeme. Die primäre Integrationsmethode ist eine REST-API, kein CSV-Import. Das ist sowohl leistungsfähiger als auch für nicht-technische Benutzer zunächst einschüchternder:

• Native Integrationen bestehen mit QuickBooks Online, Xero, Shopify, HubSpot, BigCommerce und WooCommerce.
• Die API unterstützt das Erstellen von Produkten/Varianten, Kunden/Lieferanten, Verkaufsaufträgen, Bestellungen, Bestandsanpassungen und Bestandstransfers.
• Webhooks benachrichtigen externe Systeme über Änderungen im Auftragslebenszyklus (erstellt, aktualisiert, gelöscht).
• Katanas Partnerverzeichnis listet Integrationspartner auf, die benutzerdefinierte Workflows erstellen können.

Für Teams ohne API-Entwicklungsressourcen ist der praktische Weg: Bestelldaten in eine Tabelle exportieren, dann mit Katana's Produktimport (CSV-kompatibel) neue Materialien anlegen, gefolgt von manueller Bestellerstellung oder einem vorgefertigten QuickBooks/Xero-Abgleich. Ist Katana mit QuickBooks Online verbunden, fließt eine dort erstellte Bestellung automatisch in Katana ein.

NetSuite

NetSuites CSV-Import für Bestellungen ist strukturell der anspruchsvollste der fünf hier behandelten Systeme. Wichtige Anforderungen:

• Zwei separate Dateien – eine für Bestellköpfe, eine für Positionen. Sie werden über ein externes ID-Feld verknüpft, das in beiden Dateien vorhanden sein und exakt übereinstimmen muss.
• Lieferantenreferenzen müssen die interne ID oder externe ID verwenden – Lieferantennamen als Text führen zu Validierungsfehlern. Vor dem Erstellen der Importdatei muss die numerische Lieferanten-ID aus NetSuites Lieferantenstamm ermittelt werden.
• Datumsformat: M/T/JJJJ ohne führende Nullen (3/5/2026, nicht 03/05/2026).
• Dieselbe Bestellnummer wiederholt sich im Einzeldateiformat über Kopf und alle zugehörigen Positionszeilen. Im Zweidateiformat verknüpft die externe ID sie.
• Direktlieferungs-Bestellungen erfordern einen separaten Import-Job mit einem anderen benutzerdefinierten Formular.

Externe ID,Bestell-Nr.,Lieferant,Lieferanten-ID,Belegdatum
EXT-0423-001,PO-2026-0423,Acme Industrial,8842,5.3.2026

Externe ID,Artikel,Artikel-ID,Menge,Preis,Betrag
EXT-0423-001,PART-8842,4421,250,14,75,3687,50
EXT-0423-001,PART-7721,3398,100,22,30,2230,00

Google Sheets als Brücke – für Teams, die CSV-Dateien lieber ganz vermeiden

Nicht jedes Team möchte CSV-Dateien verwalten – besonders wenn mehrere Personen sehen müssen, was bereits verarbeitet wurde und was noch aussteht. Für kleinere Beschaffungsteams (die 20–50 Bestellungen pro Woche bearbeiten) können Google Sheets in Kombination mit einer No-Code-Integrationsplattform den CSV-Import durch eine automatisierte Pipeline ersetzen.

Der Aufbau erfolgt in drei Schichten:

1. Extraktion in Google Sheets. Statt extrahierte Daten als CSV herunterzuladen, senden Sie sie direkt in ein Google Sheet. ImageToTable.ai bietet ein Google Sheets-Add-on – eine Seitenleiste in Sheets, in die Sie PDFs oder Bilder hochladen, die gewünschten Spaltennamen angeben und die strukturierten Daten direkt in Ihre Tabelle einfügen lassen. Kein Datei-Download, keine Formatkonvertierung zwischen den Schritten.
2. Formatierungsebene. Ein eigener Tab im selben Sheet enthält die Referenztabellen: Lieferanten-IDs, Artikelnummern-Zuordnungen, Statuscode-Übersetzungen. Eine einfache SVERWEIS- oder INDEX/VERGLEICH-Formel zieht die systemspezifischen Werte in die Extraktionsausgabe. Wenn die Extraktion in der Lieferantenspalte „Acme Industrial“ liefert, gibt die Formel in der nächsten Spalte die NetSuite-Lieferanten-ID „8842“ zurück. Dieser Nachschlage-Tab wird einmal gepflegt, nicht pro Import.
3. Übergabe an das Inventarsystem. Plattformen wie Zapier und Make verbinden Google Sheets mit Inventarsystemen. Ein Zap überwacht neue Zeilen, transformiert die Daten bei Bedarf und erstellt den entsprechenden Bestellungsdatensatz im Inventarsystem. Für Systeme ohne direkten Connector übernimmt Skyvia den Google-Sheets-zu-Inventar-CSV-Import als geplanten Job.

Dieser Ansatz erfordert mehr Einrichtungszeit (Formeln und Zap konfigurieren), eliminiert aber die wiederkehrende manuelle Arbeit des Herunterladens, Öffnens, Prüfens und Hochladens von Dateien. Für ein Team, das 30 Bestellungen pro Woche bearbeitet, spart das etwa 5–7 Stunden Dateiverwaltung pro Monat – bei einem einmaligen Einrichtungsaufwand von 2 Stunden.

Der Kompromiss ist real: Der Google-Sheets-Pfad fügt eine Abhängigkeit hinzu (der Zap muss aktiv bleiben, die Formeln müssen korrekt sein) im Austausch für Transparenz (jedes Teammitglied kann die Tabelle einsehen, um zu prüfen, was verarbeitet wurde). Für Teams, in denen der Einkauf von einer Person erledigt wird, ist der direkte CSV-Import einfacher. Für Teams, in denen mehrere Personen mit Bestelldaten arbeiten, rechtfertigt die gemeinsame Transparenz einer Google-Sheets-Brücke die zusätzlichen Komponenten.

Die 60-Sekunden-Checkliste vor dem Import

Unabhängig davon, für welchen Pfad Sie sich entscheiden – direkter CSV-Import oder Google-Sheets-Brücke – vier Dinge können einen Import stillschweigend zum Scheitern bringen, wenn sie falsch sind. Überprüfen Sie diese vor jedem Upload:

Ein weiterer stiller Fehler, den Sie kennen sollten: Kodierungsfehler. Ein Lieferantenname mit Sonderzeichen (das ™-Symbol in einer Teilebeschreibung, ein akzentuierter Vokal in einem europäischen Lieferantennamen) kann die Extraktion intakt überstehen, aber beim CSV-Speichern brechen, wenn die Kodierung von UTF-8 auf ASCII wechselt. Das ist schwer zu erkennen, weil die beschädigten Zeichen in einer Tabellenvorschau manchmal korrekt aussehen, aber den String-Vergleich der Import-Engine fehlschlagen lassen. Die Lösung ist einfach: Speichern Sie immer als UTF-8-CSV, und wenn Ihr Tool eine Kodierungsoption bietet, wählen Sie nie etwas anderes.

Häufig gestellte Fragen

Muss ich meine Lieferanten bitten, ihre Bestellungen umzustellen, damit das funktioniert?

Nein. Die Spaltennamenextraktion erfasst die Bedeutung von Feldern unabhängig vom Format – das ist der Mechanismus, der Änderungen auf Lieferantenseite überflüssig macht. Ob ein Lieferant eine PDF, einen E-Mail-Anhang, einen Portalscreenshot oder ein gescanntes Bild sendet, die KI findet die von Ihnen angegebenen Daten. Sie müssen nicht verlangen, dass Lieferanten eine Standardvorlage, ein Portal oder ein neues Verhalten übernehmen. Dies ist der wesentliche architektonische Unterschied zwischen vorlagenbasierter Extraktion (die bei Formatabweichungen versagt) und semantischer Extraktion (die das nicht tut).

Was ist, wenn mein Inventarsystem nicht in den fünf hier aufgeführten ist?

Das Prinzip der Spaltennamenzuordnung funktioniert mit jedem System, das CSV-Import unterstützt. Prüfen Sie die Importdokumentation Ihres Systems (suchen Sie nach „[Systemname] CSV-Import“ oder „[Systemname] Bestellungen importieren“) nach den genauen Spaltenüberschriften, die es erwartet, und verwenden Sie diese als Ihre Extraktionsspaltennamen. Der Zuordnungsschritt ist derselbe; nur die spezifischen Feldnamen unterscheiden sich. Wenn Ihr System einen API-basierten Import verwendet (wie Katana) und Sie Entwicklerzugriff haben, listet die API-Dokumentation die JSON-Feldnamen auf – verwenden Sie diese anstelle von CSV-Headern als Ihre Extraktionsspaltennamen.

Wie gehe ich mit Bestellungen um, die nicht alle Felder enthalten, die mein Inventarsystem benötigt?

Drei Ansätze, nach Aufwand sortiert. Erstens: Verwenden Sie berechnete Spalten während der Extraktion. Wenn Ihr System ein Lieferdatum pro Position benötigt, die Bestellung es aber nur im Kopf enthält, kann eine berechnete Spalte den Kopfwert jeder Zeile zuweisen. Fehlt der Stückpreis, sind aber Positionssumme und Menge vorhanden, füllt Gesamt ÷ Menge ihn aus. Zweitens: Pflegen Sie eine kleine Nachschlagetabelle für Werte, die sich pro Bestellung nicht ändern – Zahlungsbedingungen, Versandart, Standardlagerort – und führen Sie sie nach der Extraktion in die Ausgabe zusammen. Drittens: Konfigurieren Sie den Import des Inventarsystems so, dass Standardwerte für bestimmte Felder akzeptiert werden (der Import-Assistent von NetSuite unterstützt dies über die Feldzuordnungsseite).

Funktioniert das, wenn ich Bestellungen von 30 verschiedenen Lieferanten in 30 verschiedenen Formaten verarbeite?

Ja – und hier bietet der Ansatz der Spaltennamen-Angleichung die größte Zeitersparnis gegenüber vorlagenbasierten Methoden. Beim vorlagenbasierten Import erfordern 30 Lieferantenformate 30 Importvorlagen, und jede Formatänderung eines Lieferanten erfordert eine Vorlagenaktualisierung. Bei der semantischen Extraktion definieren Sie die Spaltennamen einmal (passend zu den erwarteten Feldern Ihres Inventarsystems), und die KI übernimmt die Formatvariation auf Lieferantenseite. Stapelverarbeitung ermöglicht es Ihnen, alle 30 Bestellungen in einem Durchgang zu verarbeiten – die Extraktion läuft für jede Datei unabhängig, wendet dieselbe Spaltennamenszuordnung an und führt die Ergebnisse in einer einzigen Ausgabedatei zusammen, die für den Import Ihres Inventarsystems strukturiert ist.

Was passiert, wenn die Extraktion ein Feld falsch ermittelt?

Der Import wird fehlschlagen – und das ist besser, als stillschweigend falsche Daten zu importieren. Die meisten Bestandssysteme prüfen Referenzschlüssel, bevor sie eine Datei akzeptieren. Stimmt ein Lieferantenname oder eine Artikelnummer nicht mit einem vorhandenen Datensatz überein, wird die Zeile zurückgewiesen und ein Fehler gemeldet. So können Sie die Extraktion korrigieren, bevor die Daten in Ihr System gelangen. Kein Bestandssystem führt eine „bestmögliche Übereinstimmung" bei Referenzdaten durch – entweder der Schlüssel stimmt exakt überein oder die Zeile wird abgelehnt. Zu häufigen Extraktionsfehlermustern und wie Sie diese vor dem Import erkennen, lesen Sie unter sechs Kategorien von ERP-Importfehlern und wie Sie diese an der Quelle beheben.

Ein Schritt zwischen Extraktion und Ihrem Bestandssystem

Die Lücke zwischen „Bestelldaten wurden extrahiert" und „sie sind in meinem Bestandssystem" ist kein Technologieproblem, das ein IT-Projekt erfordert. Es ist ein Formatabstimmungsproblem, das eine Spaltennamenzuordnung benötigt. Sobald Sie wissen, was Ihr Bestandssystem erwartet – die genauen Feldnamen, den Referenzschlüsseltyp, das Datumsformat – können Sie Ihre Extraktion so konfigurieren, dass sie direkt in diese Struktur ausgibt. Der manuelle Neuformatierungsschritt entfällt.

Wenn Sie Bestellungen in Excel verarbeiten und dann in Ihr Bestandssystem übertragen, ersetzt der Ansatz der Spaltenausrichtung beide Schritte durch einen Durchlauf: Extrahieren Sie direkt in das Importformat des Systems und laden Sie hoch.