Warum Ihr ERP Ihre extrahierte
Excel ablehnt: 5 häufige Ursachen & Lösungen

Dies ist einer der frustrierendsten Momente in der AP-Automatisierung: Die Extraktion hat funktioniert, aber der Import ist fehlgeschlagen. Das Problem liegt fast nie an falsch extrahierten Daten. Das Problem ist ein Formatkonflikt zwischen dem, was Ihr Extraktionstool ausgibt, und dem, was Ihr ERP erwartet. Jedes ERP – SAP, Oracle NetSuite, Microsoft Dynamics 365, Oracle Cloud ERP – hat eigene Vorgaben für Datumsformat, Betragsformat, Feldlängen für Codes, Lieferantenidentifikation und Pflichtfelder. Ihre Datenextraktionsausgabe weiß nicht, welches Sie verwenden, es sei denn, Sie teilen es ihr mit.

Dieser Leitfaden behandelt die fünf Gründe, warum Ihr ERP Extraktionsergebnisse ablehnt, und wie Sie jedes Problem beheben, bevor Sie auf "Importieren" klicken.

1 Ursache 1: Das Datumsformat stimmt nicht mit den ERP-Vorgaben überein

Die Symptome

Ihr Import schlägt mit Fehlern fehl wie "Ungültiger Datumswert im Feld Rechnungsdatum" (SAP), "Datumfeld nicht im bevorzugten Datumsformat" (NetSuite) oder "Die Quelldaten haben nicht das erforderliche Format" (Dynamics 365). Oder schlimmer: Der Import gelingt, aber eine Rechnung vom 7. März wird als 3. Juli verbucht, weil das ERP 03/07/2026 anders interpretiert hat als Sie.

Warum das passiert

Jedes ERP speichert Daten intern in einem eigenen Format und erwartet, dass Ihre Importdatei einem bestimmten Datumslayout entspricht:

Die eigentliche Falle ist die automatische Datumsbehandlung von Excel. Wenn Sie eine CSV mit 07/03/2026 öffnen, interpretiert Excel dies je nach Systemgebietsschema möglicherweise als Seriennummer (eine Zahl wie 46142). Diese Seriennummer sieht beim Blick auf die Zelle korrekt aus (Excel zeigt sie als Datum an), aber der tatsächliche Wert in der Zelle ist eine Zahl. Wenn das ERP die CSV liest, sieht es 46142, kein Datum – und lehnt die Zeile ab. Dieses Excel-Seriendatum-Problem ist eine der häufigsten versteckten Ursachen für Importfehler.

Die Lösung

Die zuverlässigste Lösung ist, Daten als Text zu exportieren. Geben Sie in der Spaltenkonfiguration Ihres Extraktionstools das genaue Ausgabeformat an. Nennen Sie Ihre Spalte bei SAP Rechnungsdatum (Ausgabe als JJJJMMTT-Text). Bei NetSuite Rechnungsdatum (Ausgabe als MM/TT/JJJJ-Text, nullenaufgefüllt). In ImageToTable.ai erfolgt dies über den Spaltennamen oder die Regelformatierung – fügen Sie einfach die Formatanweisung ein.

Stellen Sie vor dem Import sicher, dass Datumsspalten in Ihrer Tabelle als Text formatiert sind, nicht als Datum. Öffnen Sie CSV-Dateien nicht per Doppelklick in Excel – verwenden Sie den Textimport-Assistenten oder Power Query, wo Sie den Datentyp jeder Spalte explizit festlegen können.

2 Ursache 2: Währungssymbole und Tausendertrennzeichen in Betragsfeldern

Die Symptome

Die Fehlermeldung lautet "Bitte geben Sie eine gültige Zahl ein" oder "Die Spalte 'Betrag' enthält ungültige Zeichen." Oder der Import gelingt, aber die Beträge erscheinen als Nullen – weil das ERP die nicht-numerischen Zeichen entfernt hat und nichts mehr übrig war, was es parsen konnte.

Warum das passiert

Extraktionstools bewahren, was sie sehen: $1.234,56 oder € 2.500,00. Aber ERPs erwarten rohe Zahlenwerte:

• NetSuite: Keine Währungssymbole, keine Kommas, keine Tausendertrennzeichen. Negative Beträge müssen mit Minuszeichen oder Klammern angegeben werden.
• SAP: In den meisten Konfigurationen Punkt als Dezimaltrennzeichen. Tausendertrennzeichen sind nicht erlaubt.
• Dynamics 365 F&O: Saubere Dezimalwerte erforderlich. Die DMF-Pipeline geht von vorformatierten Daten aus.

Das Komma-gegen-Punkt-Problem ist tückisch. Ein europäischer Betrag von € 2.500,00 (Punkt als Tausendertrennzeichen, Komma als Dezimaltrennzeichen) wird in einem US-konfigurierten ERP, das den Punkt als Dezimaltrennzeichen liest, zu 2,5. Der Unterschied zwischen 2.500,00 und 2,500.00 beträgt den Faktor Tausend – weshalb Probleme mit Währungssymbolen und Dezimaltrennzeichen in OCR-Ausgaben zu schwer diagnostizierbaren Importfehlern führen.

Die Lösung

Konfigurieren Sie Ihre Extraktionsausgabe so, dass Symbole und Trennzeichen entfernt werden. Geben Sie an: "Ausgabe als reine Zahl mit zwei Dezimalstellen, ohne Währungssymbol, ohne Tausendertrennzeichen, Punkt als Dezimaltrennzeichen". Wenn Ihr ERP das Komma als Dezimaltrennzeichen verwendet (üblich in europäischen SAP-Implementierungen), geben Sie dies explizit an. ImageToTable.ai's Nachbearbeitung unterstützt beide Konventionen – Sie müssen nur mitteilen, welche verwendet werden soll.

3 Ursache 3: Code-Felder verlieren führende Nullen oder haben das falsche Format

Die Symptome

Ihr ERP hat einen Lieferantencode 0000000123, aber die extrahierte Datei enthält 123. Oder die Bestellnummer lautet PO-00123, während das System 00123 erwartet. Der Import schlägt fehl mit "Datensatz existiert nicht" oder – schlimmer – das ERP erstellt einen neuen Lieferantendatensatz, weil der Code nicht zugeordnet werden konnte.

Warum das passiert

Hier treffen zwei Probleme aufeinander. Erstens: Excel entfernt führende Nullen bei allem, was es für eine Zahl hält – aus 0000000123 wird 123, sobald die CSV geöffnet wird. Zweitens: Die Extraktion gibt wörtlich wieder, was auf dem Dokument steht: Zeigt die Rechnung PO-00123, gibt das Tool PO-00123 aus, aber das ERP erwartet nur 00123 oder ein anderes Präfixformat.

Die Lösung

Verwenden Sie das Textformat für Code-Spalten. Stellen Sie vor dem Speichern Ihrer CSV oder dem Öffnen in Excel sicher, dass alle Code-Felder – Lieferantencodes, Bestellnummern, Rechnungsnummern – explizit als Text formatiert sind. In Excel bedeutet das: Spalte markieren, Zellen formatieren > Text wählen und die Werte erneut eingeben. Geben Sie in Ihrem Extraktionstool an, dass Code-Felder als Text mit führenden Nullen ausgegeben werden sollen – genau wie beim Extrahieren von Rechnungsfeldern für die direkte ERP-Nutzung.

Geben Sie für Systeme wie SAP, die 10-stellige Lieferantenkontonummern verwenden, Folgendes an: "Lieferantencode: Ausgabe als 10-stellige Zeichenkette, links mit Nullen aufgefüllt". Definieren Sie die Auffüllung und Präfixentfernung als Formatregeln in Ihrem Extraktionstool, damit dies automatisch in jedem Batch geschieht. Wenn Ihr Tool keine Formatregeln unterstützt, verwenden Sie =TEXT(A1; "0000000000") in Excel vor dem Speichern der CSV.

4 Ursache 4: Lieferantenname oder -code stimmt nicht mit Ihren ERP-Stammdaten überein

Die Symptome

NetSuite meldet "Invalid entity reference key". SAP wirft "Vendor 123 not defined in company code." Sage 300 sagt "Vendor cannot be blank." Der Lieferant existiert im ERP – das System kann nur keinen Abgleich zwischen Ihrer Importdatei und dem Stammsatz herstellen.

Warum das passiert

Der Lieferantenabgleich ist einer der häufigsten und frustrierendsten Fehlerquellen beim Import. Die Ursachen sind subtil:

• Nachgestellte Leerzeichen: Ihre Extraktion enthält "Acme Corp " (mit einem Leerzeichen am Ende), der Lieferanteneintrag lautet aber "Acme Corp". Der Zeichenfolgenabgleich im ERP ist exakt und groß-/kleinschreibungssensitiv.
• Abkürzungskonflikt: Die Rechnung nennt "Acme Corp", der ERP-Eintrag lautet "Acme Corporation".
• Interne ID erforderlich: NetSuite und einige andere ERPs können nach Lieferantenname importieren, aber sie gleichen schneller und zuverlässiger mit der internen ID des Lieferanten ab (einem numerischen Schlüssel, der sich nie ändert).
• Lieferant existiert noch nicht: Der Lieferanteneintrag wurde noch nicht im ERP angelegt. Keine noch so gute Formatierung behebt das.
• Konflikt zwischen verschiedenen Rechtseinheiten: In Dynamics 365 F&O muss der Lieferant in der spezifischen Rechtseinheit existieren, in die Sie importieren – nicht nur irgendwo im Mandanten.

Die Lösung

Der zuverlässigste Ansatz ist die Verwendung interner IDs anstelle von Namen. Exportieren Sie eine Lieferantenliste aus Ihrem ERP, erstellen Sie eine Nachschlagetabelle und konfigurieren Sie Ihr Extraktionstool so, dass es die interne ID direkt ausgibt. Fügen Sie in ImageToTable.ai eine abgeleitete Spalte hinzu: "Lieferanten-ID: Lieferantennamen anhand der beigefügten Lieferantenliste nachschlagen und die interne ID ausgeben".

Falls interne IDs keine Option sind, implementieren Sie einen unscharfen Abgleich gegen eine Referenzliste. Dadurch werden Probleme mit nachgestellten Leerzeichen und Abkürzungen beseitigt, bevor sie das ERP erreichen.

Wenn der Lieferant noch nicht existiert, wird der Import immer fehlschlagen – die Lösung ist, den Lieferanteneintrag zuerst anzulegen.

5 Ursache 5: Ein Pflichtfeld fehlt in Ihren extrahierten Daten

Die Symptome

"Bitte geben Sie einen Wert für Betrag ein." "Feld Sachkonto ist erforderlich." "Steuercode muss angegeben werden." Diese Fehler bedeuten, dass das ERP ein Feld erwartet, das in Ihren extrahierten Daten schlichtweg nicht vorhanden ist.

Warum das passiert

Nicht jedes Pflichtfeld im Datenmodell Ihres ERPs ist auf dem Beleg aufgedruckt. Eine Rechnung zeigt möglicherweise nicht das Sachkonto an. Das Fälligkeitsdatum fehlt vielleicht, ist aber im Kreditorenrechnungsbuch von Dynamics 365 zwingend erforderlich. Für die SAP-Buchung benötigte Steuercodes sind auf der Lieferantenrechnung unter Umständen nicht aufgeführt.

Extraktionstools extrahieren, was sichtbar ist. Fehlt ein Pflichtfeld auf dem Beleg, bleibt die Ausgabe leer – und das ERP weist die Zeile zurück. Dies tritt häufig bei Rechnungen auf, die Sachkonten oder Fälligkeitsdaten auslassen – ein Problem, das effektive Kreditorenbuchhaltungs-Automatisierung durch Vorkonfiguration von Standardwerten adressiert.

Die Lösung

Hier werden abgeleitete Spalten und Standardwerte unverzichtbar. Eine abgeleitete Spalte teilt der KI mit: "Wenn dieses Feld nicht auf dem Beleg ist, verwende diesen Standard – oder leite es aus dem Kontext ab."

In ImageToTable.ai können Sie Spalten wie diese hinzufügen:

• Sachkonto (Standard: 4010, falls nicht auf Beleg)
• Steuercode (aus Lieferland ableiten)
• Fälligkeitsdatum (falls nicht gedruckt, berechnen als Rechnungsdatum + 30 Tage)
• Währung (aus Belegkontext ableiten)

Die KI liest den Beleg, extrahiert, was sie findet, füllt die Lücken mit Ihren Regeln oder Standardwerten, und die Ausgabe kommt mit allen gefüllten Pflichtfeldern an.

Entscheidend ist zu wissen, welche Felder Ihr ERP als Pflichtfelder betrachtet. Laden Sie dessen Importvorlage herunter, ordnen Sie Pflichtspalten Ihrer Extraktionskonfiguration zu und legen Sie Standardwerte für alles fest, was nicht auf dem Beleg gedruckt ist.

Der intelligentere Weg: ERP-fähige Exportvorlagen erstellen

Jede Ursache einzeln zu beheben funktioniert, ist aber reaktiv. Der intelligentere Ansatz ist eine ERP-fähige Exportvorlage – eine einzige Extraktionskonfiguration, die Daten genau in der Form ausgibt, die Ihr ERP erwartet.

Eine ERP-fähige Vorlage umfasst:

1. Spaltenüberschriften, die exakt der Importvorlage Ihres ERPs entsprechen. Erwartet Dynamics 365 VENDORACCOUNT, ist das Ihre Spaltenüberschrift.
2. Codefelder als Text mit führenden Nullen. Bestellnummern, Lieferantencodes und Rechnungsnummern erscheinen in der exakten Länge, die Ihr ERP verwendet.
3. Betragsfelder als reine Zahlen. Keine Symbole, keine Kommas, Punkt als Dezimaltrennzeichen.
4. Alle Pflichtfelder vorhanden. Fehlende Felder werden mit Standardwerten oder abgeleiteten Werten gefüllt.
5. Daten als Textzeichenfolgen. Keine Excel-Seriennummern, keine sprachabhängigen Interpretationen.

Nach der Einrichtung gibt jeder Batch automatisch importbereite Daten aus. Der manuelle Bereinigungsschritt – in dem die meisten Fehler auftreten – entfällt vollständig.

Wann Sie eskalieren sollten: Formatprobleme erkennen, die außerhalb Ihrer Kontrolle liegen

Die meisten ERP-Importfehler aus extrahierten Daten fallen unter die fünf oben genannten Ursachen, und die meisten sind mit der richtigen Konfiguration behebbar. Aber manchmal ist das Format nicht das eigentliche Problem:

• Komplexe Validierungslogik. Die Kombination aus Sachkonto, Steuercode und juristischer Person kann Validierungsregeln nicht bestehen – ein ERP-Konfigurationsproblem, kein Datenproblem.
• Workflow und Genehmigungen. Wenn der Import erfolgreich ist, die Rechnung aber in „Ausstehende Genehmigung" hängen bleibt, liegt das Problem im Workflow-Design.
• Der Fehler ändert sich ständig. Wenn Sie einen Fehler beheben und ein neuer auftaucht, kann die Ursache unvollständige Stammdaten sein.

Beheben Sie zuerst das Datenformat – es ist am einfachsten auszuschließen – und eskalieren Sie verbleibende Probleme an Ihren ERP-Administrator.

Häufig gestellte Fragen

Hör auf zu reparieren, fang an zu verhindern

Das Muster ist immer gleich: extrahieren → importieren → Fehler → ein Feld korrigieren → neu importieren → nächster Fehler. Jeder Zyklus kostet 15 bis 30 Minuten, und wenn Sie Dutzende von Rechnungen pro Batch verarbeiten, summieren sich die verlorenen Stunden schnell.

Die fünf Ursachen in dieser Anleitung decken etwa 90 % der ERP-Importfehler aus extrahierten Daten ab. Beheben Sie sie einmal in Ihrer Extraktionskonfiguration, und jeder weitere Batch ist importbereit. Der Engpass verschiebt sich von der Formatkompatibilität dorthin, wo er hingehört: Daten aus dem Dokument in Ihr System zu bekommen.

Testen Sie Ihre Vorlage mit dem nächsten Batch. Bleiben die Fehler aus, ist alles erledigt. Wenn nicht, liegt das verbleibende Problem wahrscheinlich an einer ERP-Validierungsregel – nicht an den Daten.