PDF und E-Mail → EDIFACT
PDF-Bestellung in EDIFACT umwandeln
Die meisten Kunden bestellen nicht per EDI, sondern mit einem PDF im Anhang oder einer formlosen E-Mail. every-edi liest diese Bestellungen aus, lässt sie von einem Menschen prüfen und gibt sie als EDIFACT ORDERS D96A aus: beim ersten Mal mit KI, danach mit einem gelernten Profil ohne KI.
Auf einen Blick
- Eingang
- PDF mit Text (Anhang oder Upload), E-Mail-Text
- Ausgabe
- EDIFACT ORDERS D96A; alternativ cXML, openTRANS 2.1, JSON
- Erste Datei eines Absenders
- Einmalige Analyse mit KI, Prüfung durch einen Menschen
- Folgebestellungen
- Gelerntes Profil, ohne KI
- Freigabe
- Nach Prüfung im Dashboard; automatisch nur bei bekanntem Profil und hoher Sicherheit
Warum PDF-Bestellungen ein eigenes Problem sind
Für Menschen ist ein PDF eindeutig, für ein ERP ist es nur Text an bestimmten Stellen einer Seite. Jeder Kunde hat sein eigenes Layout: Die Bestellnummer steht mal oben rechts, mal im Betreff; Positionen kommen als Tabelle oder als Fließtext; der Liefertermin als Datum oder als „KW 42“. Klassische EDI-Anbieter haben dafür keine Lösung, denn sie binden nur Kunden an, die schon strukturierte Daten senden.
Deshalb tippt in vielen Betrieben jemand diese Bestellungen ab. Bei wenigen Bestellungen geht das. Bei Hunderten im Monat kostet es Personalstunden und erzeugt Tippfehler, die erst bei der Lieferung auffallen.
So läuft die Umwandlung
- Eingang. Die Bestellung kommt wie bisher: per E-Mail in ein überwachtes Postfach, über einen Ordner oder per Upload. Ihr Kunde ändert nichts.
- Erster Kontakt: Auslesen mit KI. Kennt every-edi das Layout dieses Kunden noch nicht, liest ein Sprachmodell Kopf- und Positionsdaten aus. Auf Wunsch läuft dieses Modell lokal auf Ihrer eigenen Infrastruktur.
- Prüfung durch einen Menschen. Die erkannten Felder stehen im Prüf-Dashboard neben dem Original. Sie korrigieren, was nicht stimmt, und geben frei.
- Profil gelernt. Aus der freigegebenen Bestellung entsteht ein Profil für das Layout dieses Kunden. Ab der nächsten Bestellung dieses Absenders liest das Profil die Daten: regelbasiert, reproduzierbar, ohne KI und in Sekunden.
- Freigabe. Bestellungen werden vor der Freigabe geprüft. Automatisch freigegeben wird nur, wenn das Profil bekannt ist und die Erkennung sehr sicher ist; alles andere geht in die Prüfung.
- Ausgabe als EDI. Die Bestellung wird als EDIFACT ORDERS D96A erzeugt und dorthin übergeben, wo Ihr ERP sie abholt.
Beispiel
Oben die Bestellung eines fiktiven Kunden, wie sie als PDF ankommt (hier als Text dargestellt), darunter die daraus erzeugte EDIFACT-Nachricht ohne Übertragungskopf. Die Tabelle zeigt, welche Angabe wohin wandert und was dabei übersetzt werden muss.
Beispiel Haustechnik GmbH · Am Hafen 12 · 28217 Bremen
BESTELLUNG Nr. B-26-0815 Datum: 08.10.2026
Kunden-Nr. bei Ihnen: 10042 Liefertermin: KW 42
Lieferanschrift: Lager Nord, Tor 3, Hafenstraße 40, 28217 Bremen
Pos Art.-Nr. Bezeichnung Menge Einh. Preis/Einh.
1 ART-7720 Hydraulikzylinder HZ-200/100 4 Stk 285,00 €
2 ART-3381 Dichtungsset DS-200 4 Satz 42,50 €
3 ART-9910 Hydraulikschlauch 2m DN10 10 m 18,90 €
Summe netto: 1.499,00 €UNH+1+ORDERS:D:96A:UN'
BGM+220+B-26-0815+9'
DTM+137:20261008:102'
DTM+2:20261012-20261016:718'
NAD+BY+4012345000009::9'
NAD+DP+4012345000016::9'
CUX+2:EUR:9'
LIN+1++ART-7720:SA'
IMD+F++:::Hydraulikzylinder HZ-200/100'
QTY+21:4:PCE'
PRI+AAA:285.00'
LIN+2++ART-3381:SA'
IMD+F++:::Dichtungsset DS-200'
QTY+21:4:SET'
PRI+AAA:42.50'
LIN+3++ART-9910:SA'
IMD+F++:::Hydraulikschlauch 2m DN10'
QTY+21:10:MTR'
PRI+AAA:18.90'
UNS+S'
MOA+79:1499.00'
UNT+22+1'Alle Namen, Nummern und GLNs im Beispiel sind fiktiv.
| Im PDF | In EDIFACT | Was dabei passiert |
|---|---|---|
| Bestellung Nr. B-26-0815 | BGM+220+B-26-0815+9 | Bestellnummer des Kunden; 220 = Bestellung. |
| Datum: 08.10.2026 | DTM+137:20261008:102 | Das deutsche Datum wird zu JJJJMMTT. |
| Liefertermin: KW 42 | DTM+2:20261012-20261016:718 | Eine Kalenderwoche ist kein Datum. Hier wird sie als Zeitraum Montag bis Freitag ausgegeben (Format 718). Erwartet Ihr ERP ein einzelnes Datum, muss diese Regel vor dem Start feststehen. |
| Kunden-Nr. bei Ihnen: 10042 | NAD+BY+4012345000009::9 | Die Kundennummer allein reicht dem EDI nicht: Der Besteller erscheint als Partei mit eindeutiger Kennung, hier einer GLN. |
| Lager Nord, Tor 3, … | NAD+DP+4012345000016::9 | Die Lieferadresse wird eine eigene Partei (DP), getrennt vom Besteller. |
| 4 Stk · 4 Satz · 10 m | QTY+21:4:PCE · SET · MTR | Hauseinheiten wie „Stk“, „Satz“ und „m“ werden zu Codes. |
| 285,00 € | PRI+AAA:285.00 · CUX+2:EUR:9 | Aus dem Komma wird ein Punkt, aus dem Eurozeichen die Währungsangabe. |
| Summe netto: 1.499,00 € | MOA+79:1499.00 | Die Summe dient als Kontrollwert: Sie muss zu den Positionen passen. |
Typische Stolperfallen
-
Jeder Kunde hat sein eigenes Layout
Starre Vorlagen pro Kunde brechen, sobald der Kunde sein Formular ändert. Wichtig ist, dass ein solcher Fall erkannt wird: Eine Bestellung, die nicht mehr zum bekannten Layout passt, gehört in die Prüfung und nicht mit falschen Werten ins ERP.
-
Kundennummer ist nicht GLN
Auf dem PDF steht Ihre Kundennummer, manchmal auch gar keine. Das EDI für Ihr ERP oder Ihren EDI-Dienstleister braucht aber eindeutige Partnerkennungen. Ohne Zuordnung über die Stammdaten ist auch die beste Extraktion wertlos.
-
Zahlen und Daten im deutschen Format
„1.499,00“ ist für ein Programm zunächst etwas anderes als „1,499.00“. „KW 42“, „Mitte Oktober“ oder „schnellstmöglich“ sind keine Datumswerte. Für jede dieser Angaben braucht es eine feste Regel.
-
Einheiten und Packungsgrößen
„1 Karton“ kann 12 Stück bedeuten, und „Satz“ ist kein Standardcode. Die Umrechnung auf die Einheiten Ihres Artikelstamms muss eindeutig sein, sonst liefern Sie die zwölffache Menge.
-
Gescannte PDFs und Faxe
Ein gescanntes PDF ist ein Bild ohne Text. Solche Dateien verarbeitet every-edi noch nicht, denn eine Texterkennung (OCR) gibt es bisher nicht. Das System erkennt sie und bittet um ein PDF mit Text, statt zu raten.
-
Formlose E-Mails
„Bitte wie letzte Woche, nur 20 statt 10 Schläuche“: Bezüge auf frühere Bestellungen lassen sich nicht sicher automatisch auflösen. Solche Bestellungen gehören in die Prüfung, nicht direkt ins ERP.
Was every-edi damit macht
- Überwachtes Postfach und Eingangsordner: Bestellungen werden verarbeitet, sobald sie ankommen.
- KI nur bei der ersten Datei eines Absenders; ein Mensch prüft das Ergebnis, danach verarbeitet das gelernte Profil seine Bestellungen ohne KI.
- Auf Wunsch mit lokalem Modell: Ihre Bestelldaten verlassen dann nie Ihre Infrastruktur.
- Prüf-Dashboard mit Original und erkannten Feldern nebeneinander, Korrektur per Klick. Automatische Freigabe nur bei bekanntem Profil und hoher Sicherheit.
- Ausgabe als EDIFACT ORDERS D96A oder als cXML, openTRANS 2.1, JSON oder CSV, je nachdem, was Ihr ERP versteht.
Was (noch) nicht dazugehört
Gescannte PDFs und reine Bild-PDFs werden noch nicht verarbeitet, weil es keine Texterkennung (OCR) gibt; every-edi erkennt sie und bittet um ein PDF mit Text. Außerdem wandelt every-edi nur Bestellungen um: Rechnungen, Lieferscheine und Auftragsbestätigungen aus PDFs gehören derzeit nicht zum Umfang, ebenso wenig die Erzeugung von E-Rechnungen wie XRechnung oder ZUGFeRD.
Weitere Formate
Außerdem verarbeitet every-edi GEVIS-XML (GEVISEDI01), CSV mit Kopf- und Positionszeilen (HDR/POS), frei aufgebaute CSV-Tabellen über gelernte CSV-Profile sowie JSON über eine REST-Schnittstelle.
Schicken Sie uns eine echte Datei.
Ob every-edi zu Ihren Kunden passt, klären wir am schnellsten an echten Beispielen: drei Bestellungen und, falls vorhanden, die Spezifikation Ihres Partners. Sie bekommen das Ergebnis im Zielformat zurück.
Demo anfragen