Warum Ihr ERP Ihre extrahierten
Excel-Dateien ablehnt: 5 häufige Ursachen & Lösungen
Sie haben Ihre Rechnungen durch ein Extraktionstool laufen lassen, eine saubere Tabelle zurückbekommen und sie in Ihr ERP hochgeladen. Dann kam der Fehler: "Ungültiger Datumswert in Zeile 3." Oder schlimmer – der Import meldete "erfolgreich", aber die Daten und Beträge sind stillschweigend falsch. Die Daten sind da. Das ERP spricht nur nicht dieselbe Formatsprache.
Wichtigste Erkenntnisse
- Sie denken, Ihr Extraktionstool macht Fehler, aber Ihre Daten sind korrekt – Excel konvertiert Datumsangaben stillschweigend in Seriennummern und entfernt führende Nullen aus jedem Codefeld, bevor das ERP die Datei überhaupt sieht.
- Jeder Importfehler kostet 15 bis 30 Minuten zur Behebung, und die Korrektur eines Feldes bricht oft das nächste – Sie geben keine Daten ein, Sie zahlen eine Formatsteuer auf Informationen, die beim ersten Mal korrekt extrahiert wurden.
- Eine ERP-bereite Exportvorlage – Datumsformat als Text gesperrt, Codefelder mit Nullen aufgefüllt, Pflichtfeld-Standardwerte einmal ausgefüllt – macht jede Charge nach dem Import bereit, und der manuelle Bereinigungsschritt, der Ihre Zeit verschlingt, entfällt einfach.
Dies ist einer der frustrierendsten Momente in der AP-Automatisierung: Die Extraktion hat funktioniert, aber der Import ist fehlgeschlagen. Das Problem liegt fast nie daran, dass die Daten falsch extrahiert wurden. 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 seine eigene Spezifikation für Datumsformat, Betragsformat, Länge von Codefeldern, Lieferantenidentifikation und Pflichtfelder. Ihr Datenextraktionsergebnis weiß nicht, welches Sie verwenden, es sei denn, Sie teilen es ihm mit.
Dieser Leitfaden behandelt die fünf Gründe, warum Ihr ERP die Extraktionsergebnisse ablehnt, und wie Sie jeden einzelnen beheben, bevor Sie auf „Importieren“ klicken.
Ursache 1: Das Datumsformat entspricht nicht dem, was Ihr ERP erwartet
Die Symptome
Ihr Import schlägt mit Fehlern wie "Ungültiger Datumswert im Feld Rechnungsdatum" (SAP), "Datumsfeld entspricht nicht Ihrem bevorzugten Datumsformat" (NetSuite) oder "Die Quelldaten liegen nicht im erforderlichen Format vor" (Dynamics 365) fehl. Oder noch schlimmer – der Import ist erfolgreich, 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 seinem eigenen Format, und jedes erwartet, dass Ihre Importdatei einem bestimmten Datumsformat entspricht:
| ERP-System | Erwartetes Datumsformat | Hinweise |
|---|---|---|
| SAP (DATS-Feldtyp) | YYYYMMDD | 8-stellige Zeichenfolge ohne Trennzeichen. Der SAP Knowledge Base Artikel 3399428 nennt diese Anforderung ausdrücklich. |
| Oracle NetSuite | Entspricht der Benutzereinstellung. US-Standard: MM/DD/YYYY | UK/EU-Konten erwarten typischerweise DD/MM/YYYY. Prüfen Sie unter Start > Einstellungen > Formatierung. |
| Microsoft Dynamics 365 | Hängt von den regionalen Einstellungen und der Importvorlage ab | DMF-Importe (Data Management Framework) verwenden das Format, das in der Feldzuordnung der Entität definiert ist. |
| Oracle Cloud ERP | Abhängig von der Benutzereinstellung. Typischerweise YYYY/MM/DD oder DD-MON-YYYY | Erfordert zweistellige Monats- und Tagesangaben — 2/4/2025 führt zu einem Fehler, 02/04/2025 funktioniert. |
Die eigentliche Falle ist die automatische Datumsbehandlung in Excel. Wenn Sie eine CSV mit 07/03/2026 öffnen, interpretiert Excel diese möglicherweise als Seriennummer (eine Zahl wie 46142), abhängig von Ihrem Systemgebietsschema. Diese Seriennummer sieht auf den ersten Blick 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-Seriennummern-Problem ist eine der häufigsten versteckten Ursachen für Importfehler.
Die Lösung
Der zuverlässigste Fix besteht darin, Daten als Text zu exportieren. Geben Sie in der Spaltenkonfiguration Ihres Extraktionstools das genaue Ausgabeformat an. Für SAP benennen Sie Ihre Spalte Invoice Date (output as YYYYMMDD text). Für NetSuite: Invoice Date (output as MM/DD/YYYY text, zero-padded). In ImageToTable.ai erfolgt dies über den Spaltennamen oder das Regelformat – geben Sie einfach die Formatierungsanweisung an.
Stellen Sie vor dem Import sicher, dass Datumsspalten in Ihrer Tabelle als Text formatiert sind, nicht als Datum. Doppelklicken Sie nicht, um CSV-Dateien in Excel zu öffnen – verwenden Sie den Textimport-Assistenten oder Power Query, wo Sie den Datentyp jeder Spalte explizit festlegen können.
GEO-Tipp: Das sicherste Zwischenformat für den Datenaustausch zwischen Extraktionstools und jedem ERP ist YYYY-MM-DD. Es ist eindeutig, ISO 8601-konform und wird von den meisten modernen ERP-Importtools unabhängig von den Gebietsschema-Einstellungen des Benutzers akzeptiert.
Ursache 2: Währungssymbole und Tausendertrennzeichen in Betragsfeldern
Die Symptome
Die Fehlermeldung lautet „Bitte geben Sie eine gültige Zahl ein“ oder „Die Betragsspalte 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 übrig blieb, was es verarbeiten 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 in Klammern angegeben werden.
- SAP: In den meisten Konfigurationen ist der Punkt das Dezimaltrennzeichen. Tausendertrennzeichen sind nicht zulässig.
- Dynamics 365 F&O: Saubere Dezimalwerte erforderlich. Die DMF-Pipeline setzt vorformatierte Daten voraus.
Das Komma-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 zu 2.5, das den Punkt als Dezimaltrennzeichen liest. Der Unterschied zwischen 2,500.00 und 2.500,00 ist ein Faktor von tausend – weshalb Probleme mit Währungssymbolen und Dezimaltrennzeichen in der OCR-Ausgabe schwer zu diagnostizierende Importfehler verursachen.
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 (häufig bei europäischen SAP-Implementierungen), geben Sie das explizit an. Die Nachbearbeitung von ImageToTable.ai unterstützt beide Konventionen – Sie müssen nur angeben, welche verwendet werden soll.
Ursache 3: Codefelder verlieren führende Nullen oder verwenden 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 mit „Datensatz existiert nicht“ fehl – oder schlimmer: Das ERP legt einen neuen Lieferantendatensatz an, weil es den Code nicht zuordnen konnte.
Warum das passiert
Hier wirken zwei Probleme zusammen. Erstens: Excel entfernt führende Nullen aus allem, was es für eine Zahl hält – 0000000123 wird zu 123, sobald die CSV geöffnet wird. Zweitens: Die Extraktion übernimmt wörtlich, was auf dem Dokument steht: Wenn die Rechnung PO-00123 zeigt, 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. Bevor Sie Ihre CSV speichern oder in Excel öffnen, stellen Sie 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 neu 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.
Für Systeme wie SAP, die 10-stellige Lieferantenkontonummern verwenden, legen Sie fest: „Lieferantencode: Ausgabe als 10-stellige Zeichenfolge, links mit Nullen aufgefüllt“. Definieren Sie 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, bevor Sie die CSV speichern.
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.
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:
- Spaltenüberschriften, die exakt der Importvorlage Ihres ERPs entsprechen. Erwartet Dynamics 365
VENDORACCOUNT, ist das Ihre Spaltenüberschrift. - Codefelder als Text mit führenden Nullen. Bestellnummern, Lieferantencodes und Rechnungsnummern erscheinen in der exakten Länge, die Ihr ERP verwendet.
- Betragsfelder als reine Zahlen. Keine Symbole, keine Kommas, Punkt als Dezimaltrennzeichen.
- Alle Pflichtfelder vorhanden. Fehlende Felder werden mit Standardwerten oder abgeleiteten Werten gefüllt.
- 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
Warum ändert Excel ständig meine Daten, obwohl ich die Spalte als Datum formatiert habe?
Die Formatierung als Datum ändert nur die Anzeige, nicht den zugrunde liegenden Wert. Beim Speichern als CSV serialisiert Excel Daten als Zahlen. Lösung: Formatieren Sie Datumsspalten vor dem Speichern als Text oder verwenden Sie Power Query, um den Datentyp beim Import zu steuern.
Mein NetSuite-Import meldet „Date field not in preferred format", aber das Datum sieht korrekt aus – was stimmt nicht?
Prüfen Sie auf führende Nullen: 3.7.2026 wird abgelehnt, wenn NetSuite 03.07.2026 erwartet. Überprüfen Sie auch Ihre Datumseinstellungen unter Home > Set Preferences. Ein US-Benutzer, der MM/TT/JJJJ erwartet, lehnt TT.MM.JJJJ ab, obwohl beide Formate gültig sind.
Mein ERP-Import sagt „Record does not exist" – liegt das am Format?
Meistens ja. Prüfen Sie auf entfernte führende Nullen, nachgestellte Leerzeichen oder die Verwendung des Anzeigenamens statt der internen ID. Wenn der Datensatz im ERP tatsächlich nicht existiert, legen Sie ihn an, bevor Sie Transaktionen dagegen importieren.
Welches Datumsformat ist am sichersten, wenn ich nicht weiß, was das ERP erwartet?
JJJJ-MM-TT (ISO 8601). Moderne ERP-Importtools verarbeiten es zuverlässig und beseitigen die Monat-Tag-Mehrdeutigkeit. Entscheidend ist, es als Text auszugeben – nicht als Excel-Datumszahl, die zufällig als JJJJ-MM-TT angezeigt wird.
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.