Onboarding von Partnerdaten und Schema-/EDI-Mapping

Jeder neue Kunde, Lieferant oder jede neue Tochtergesellschaft liefert Daten in einem eigenen Layout: andere Spaltennamen, Einheiten, Datumsformate, Codelisten und EDI-Dialekte. Diese auf Ihr Schema abzubilden, ist langsame Expertenarbeit, die sich mit jedem Partner wiederholt. KI schlägt das Mapping vor, erzeugt und testet die Transformation, markiert fehlerhafte Zeilen und merkt sich jede Korrektur. So wird aus dem Onboarding ein Projekt eine Prüfaufgabe.

Problem & Nutzen

• Heute: SaaS-Anbieter bauen einmalige CSV-Importer, und Support-Mitarbeitende korrigieren Dateien von Hand. B2B-Integrationsteams erstellen EDI-Maps je Handelspartner von Hand aus PDF-Implementierungsleitfäden. Die Übernahme von Katalogen und Preislisten läuft über Excel-Makros und ETL-Jobs, die brechen, sobald ein Lieferant eine Spalte hinzufügt.
• Nutzen durch KI: semantischer Abgleich von Spaltenköpfen und Beispielwerten (nicht nur von Namen), Entwürfe für Transformationscode, automatische Validierung gegen das Zielschema und ein Mapping-Gedächtnis, das mit jedem Partner besser wird. Menschen genehmigen, statt zu bauen.
• Abgrenzung: Einmalige Migrationen und oberflächengesteuerte Erfassung sind AGENT-021; die Erzeugung von Konnektorcode ist CODE-012; Deduplizierung von Datensätzen und Golden Records sind DATA-003. Dieser Anwendungsfall ist die wiederkehrende, partnerbezogene Schicht für Mapping und Validierung, meist eingebettet in ein Produkt oder eine Integrationsplattform.

Varianten

• Datenimport in SaaS-Produkten: Endkunden laden CSV/Excel in Ihr Produkt hoch; ein eingebetteter Importer ordnet zu und validiert direkt in der Sitzung.
• B2B-/EDI-Partner-Onboarding: Händler, Spediteure und Hersteller bilden Bestellungen, Lieferavis (ASN/Despatch Advice) und Rechnungen (X12, EDIFACT, VDA, Odette, Peppol UBL) je Partner ab.
• Übernahme von Katalogen und Preislisten: Produktdateien von Lieferanten in ein PIM/ERP, kombiniert mit Klassifikation (DATA-010).

So funktioniert es

1. Partnerdatei / EDI-Nachricht / API-Payload
2. Parsen + Profilieren (Typen, Formate, Verteilungen, Trennzeichen, Kodierung)
3. Kandidaten-Abgleich (Embeddings von Kopfzeile + Beispielwerten, LLM-Bewertung, frühere Mappings, Standardwörterbücher)
4. Transformationsentwurf (Umbenennen, Aufteilen/Zusammenführen, Einheiten- und Datumsnormalisierung, Codelisten-Nachschlagen, abgeleitete Felder als Code/JSONata/XSLT)
5. Validierung (Schema, Geschäftsregeln, referenzielle Prüfungen, Probelauf mit Stichprobe)
6. menschliche Prüfung (nebeneinander, Konfidenz, Diff zur letzten Version)
7. Partner-Mapping veröffentlichen (versioniert)
8. Produktivläufe mit Monitoring
9. Korrekturen fließen in das Mapping-Gedächtnis

• Zuordnung: Kombinieren Sie deterministische Signale (exakte Namen, Synonyme, Datentypen, Regex-Profile) mit Embeddings und einem LLM, das den Spaltenkopf, einige maskierte Beispielwerte und die Beschreibungen der Zielfelder sieht. Das Ergebnis ist ein nach Konfidenz sortierter Vorschlag, nie ein stilles Schreiben.
• Transformation: Das LLM schreibt die Regel in einer eingeschränkten, testbaren Sprache (JSONata, SQL, eine Mapping-DSL) und führt sie auf Stichproben aus. Erzeugte Regeln werden getestet, nicht blind übernommen.
• EDI: X12/EDIFACT mit einem deterministischen Parser in JSON überführen, dann JSON mit LLM-Unterstützung auf Ihr kanonisches Modell abbilden, gestützt auf den Implementierungsleitfaden des Partners (RAG über PDFs, siehe DOC-014).
• Mensch-in-der-Schleife (Human-in-the-Loop): Felder mit niedriger Konfidenz, jede Regel, die Beträge, Mengen oder Einheiten verändert, und der erste Produktivlauf je Partner brauchen eine Person. Genehmigte Mappings laufen danach deterministisch, ohne LLM.

Datenaufbereitung

Die Eingaben sind Partnerdateien (CSV, Excel, XML, JSON) und EDI-Nachrichten, die per E-Mail, SFTP, Portalen oder als Anhänge eintreffen, dazu Ihr Zielschema aus ERP, PIM oder Datenbank. Typische Lücken: undokumentierte Spalten, gemischte Zeichenkodierungen und Dezimalformate, je Partner abweichende Einheiten und Codelisten, veraltete Implementierungsleitfäden als PDF und frühere Mappings, die nur in jemandes Kopf oder in einem Skript existieren.

Schritte der Aufbereitung: (1) das Zielschema mit Feldbeschreibungen, Einheiten, erlaubten Werten und Beispielen dokumentieren (PREP-012); (2) je Partner eine Handvoll echter Dateien samt genehmigtem Ergebnis als Gold-Beispiele sammeln (PREP-016, PREP-020); (3) Codelisten, Einheiten und Synonyme festhalten (PREP-015); (4) Implementierungsleitfäden in durchsuchbaren Text umwandeln (PREP-006, DOC-014); (5) Beispielwerte maskieren, bevor sie an ein externes Modell gehen (PREP-022); (6) festlegen, wer ein Mapping genehmigt (PREP-004). Werkzeuge: Python mit pandas, DuckDB oder OpenRefine zum Profiling; ein EDI-Parser für X12 und EDIFACT.

Der Aufwandsanteil ist moderat, etwa 30-40 Prozent: Das Zielschema und die ersten genehmigten Mappings zählen am meisten, spätere Partner werden günstiger. Zu verwandten Schritten der Bereinigung und Konvertierung siehe DATA-003, DATA-007 und DATA-008.

Umsetzungswege

Welcher Weg für wen

• KMU (A): Gängige Formate und vorhandene Konnektoren decken EU-EDI-Anbieter (Lobster, SEEBURGER, Babelway) oder eingebettete Importer zu Preisen je Partner ab; eine eigene Mapping-Engine lohnt sich nicht.
• Großunternehmen (B): Viele Partner, eigene kanonische Modelle und ERP-Landschaften sprechen für einen hauseigenen Dienst auf Cloud-APIs (oder die bestehende iPaaS) mit einem versionierten Mapping-Gedächtnis.
• Entwickler (C): Open-Weight-Modelle und ein deterministischer Parser laufen auf HW2 und halten Partnerdateien in Ihrer eigenen Umgebung, was zu Produktanbietern passt, die einen Importer einbetten.

Weg A — Kaufen (empfohlen für KMU)

• Eingebettete Importer: Flatfile, OneSchema, CSVBox, Dromo (mehrere mit Hosting-Optionen in der EU; prüfen Sie Region und Unterauftragsverarbeiter). Passend, wenn Kunden Dateien in Ihr SaaS hochladen.
• B2B / EDI: Stedi (API-first-EDI mit Mapping-Werkzeugen und KI-gestütztem Mapping), Orderful, SPS Commerce sowie Anbieter mit EU-Wurzeln wie Lobster (DE), SEEBURGER (DE), Cleo, Babelway (BE) und OpenText B2B. Passend, wenn viele Handelspartner angebunden werden.
• Enterprise-iPaaS mit ML-Mapping: SAP Integration Suite (Integration Advisor mit ML-gestützten Mapping-Vorschlägen, SAP ist ein EU-Anbieter), Boomi AI, Informatica CLAIRE, MuleSoft, Azure Logic Apps mit Copilot-Unterstützung.
• Wählen Sie A, wenn: die Formate gängig sind und ein Konnektor existiert; der Entwicklungsaufwand soll ins Produkt fließen, nicht in Mapping-Engines.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Frontier-LLMs mit strukturierten Ausgaben (Claude, Gemini, GPT, Mistral in EU-Regionen oder von einem EU-Anbieter) erzeugen das Mapping als JSON gegen Ihr Schema; Embedding-Modelle (zum Beispiel Mistral Embed, Text-Embedding-Modelle in EU-Regionen) ordnen die Kandidatenfelder nach Rang.
• Orchestrieren Sie mit n8n, Temporal oder Ihrem Backend; halten Sie Mappings als versionierte Konfiguration in Git oder einer Datenbank; führen Sie Transformationen mit deterministischen Engines aus (JSONata, DuckDB-SQL, dbt).
• Wählen Sie B, wenn der Importer ein Alleinstellungsmerkmal Ihres Produkts ist oder die Formate ungewöhnlich sind.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Modelle für Zuordnung und Regelentwurf: Qwen3-Familie, Llama, Mistral Small / Devstral, bereitgestellt über vLLM oder Ollama; Embeddings wie BGE-M3 oder multilingual-e5.
• Werkzeuge für Schema-Matching und ETL: Valentine (Experimente zum Schema-Matching), Airbyte, dbt, DuckDB, Apache Camel / Apache NiFi, Smooks und offene EDI-Parser (zum Beispiel EDIReader, Bots, pyx12).
• Hardware: HW1 für die Zuordnung mit kleinen Modellen und Parsern; HW2 für ein Modell mit 14–30 Mrd. Parametern, das Transformationscode entwirft.

Weg D — Eigenes Training

Lohnt sich nur für eine einzelne Branche mit Tausenden historischer, genehmigter Mappings (zum Beispiel eine Logistikplattform mit vielen Frachtführerformaten). Ein kleines Modell auf Tripeln (Quellprofil, Zielschema, genehmigtes Mapping) feintunen; die Korrekturen der Prüfenden sind die Trainingsdaten. Beginnen Sie mit Few-Shot-Retrieval früherer Mappings, das meist den größten Teil des Gewinns bringt.

Stand der Technik (2026)

• LLM-Schema-Matching ist bei semantischen Spaltenköpfen und mehrsprachigen Dateien klar besser als namensbasierte Matcher, und die akademische Arbeit zu LLM-basiertem Schema- und Entity-Matching ist aktiv, doch die Genauigkeit sinkt bei kryptischen Spaltennamen, Codes ohne Beschreibung und Ableitungen aus mehreren Spalten. Betrachten Sie Genauigkeitsangaben von Anbietern als Marketing, bis sie auf Ihren Daten gemessen sind.
• Lernen aus Korrekturen (Mapping-Gedächtnis, Few-Shot-Retrieval früherer Partner) ist der wichtigste praktische Unterschied zum einmaligen Matching.
• Mappings per Codeerzeugung (das Modell schreibt die Regel, ein Test führt sie aus) sind zuverlässiger, als ein Modell Zeilen direkt transformieren zu lassen, und bei großen Mengen günstiger.
• EDI verlagert sich zu API-/JSON-basierten Werkzeugen, bei denen KI Maps aus Implementierungsleitfäden entwirft; komplexe partnerspezifische Regeln (bedingte Segmente, Semantik von Qualifiern) brauchen aber weiterhin die Prüfung durch EDI-Fachleute.
• Fehlerbilder: plausible, aber falsche Mappings (vertauschte Tage und Monate, Verwechslung von Einheiten, Währungs- oder Dezimaltrennzeichen), stilles Abschneiden von Werten, Drift, wenn ein Partner das Layout unangekündigt ändert, und Prompt Injection über Zellinhalte in hochgeladenen Dateien.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: llm-general + embedding-text + workflow-automation mit DATA-003 (Matching und Golden Records), DATA-007 (Katalog und Glossar als Beschreibungen der Zielfelder), DATA-010 (Produktklassifikation bei der Katalogübernahme) und CODE-012 (Erzeugung von Konnektoren).
• Nachgelagert: DATA-008 überwacht die eingehenden Feeds auf Schema-Drift und Qualität; DOC-006 liefert strukturierte Logistikdokumente, die als Papier oder PDF statt per EDI eintreffen; DATA-015 nutzt bereinigte Lieferantendaten für Ausgabenanalysen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preis je Importer, je Nachricht oder je Partneranbindung.
• Weg B: 1–3 Monate für Zuordnung, Prüfoberfläche, Validierung und Monitoring; die LLM-Kosten sind gering, weil nur Spaltenköpfe und Stichproben gesendet werden.
• Weg C: 2–4 Monate plus Betrieb.
• Kennzahlen: Zeit von der ersten Datei bis zum Produktivbetrieb je Partner, Anteil der Felder, die ohne Korrektur zugeordnet wurden, Validierungsfehlerquote je Lauf, abgelehnte oder manuell korrigierte Zeilen, Support-Tickets je Import, Mapping-Regressionen nach Änderungen beim Partner.

Menschen & Veränderung

Beziehen Sie die Abteilungsleitung (Logistik, Einkauf oder Kunden-Onboarding) als Prozessverantwortliche ein sowie die Endanwender, die Dateien heute von Hand zuordnen: Sie prüfen die Vorschläge und kennen die Eigenheiten der Partner. IT und IT-Sicherheit kümmern sich um SFTP, Konten, Validierungsregeln und die Frage, welche Felder das Unternehmen verlassen dürfen. Die Datenverantwortlichen des Zielsystems genehmigen das Schema. Lieferanten und Kunden sollten informiert werden, wenn sich Formate oder Testläufe ändern.

Betriebsrat: In der Regel nicht erforderlich, da das Werkzeug Geschäftsdaten abbildet und keine Beschäftigten überwacht (§ 87 Abs. 1 Nr. 6 BetrVG). Werden Prüfaktionen je Person protokolliert, besprechen Sie das kurz mit dem Betriebsrat; die Informationspflicht nach § 90 Abs. 1 Nr. 3 gilt, wenn sich Arbeitsabläufe ändern. Personenbezogene Daten (Ansprechpersonen, Fahrer- oder Mitarbeiterdaten in Dateien) können vorkommen: Beziehen Sie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten ein, schließen Sie mit jedem Cloud-Auftragsverarbeiter einen AVV (Art. 28 DSGVO) und maskieren Sie Stichproben.

KI-Kompetenz: eine kurze Einweisung, wie man Konfidenzwerte liest und zugeordnete Beträge prüft (GUIDE-006). Starten Sie mit zwei Partnern unterschiedlicher Schwierigkeit als Pilot. Typische Sorge: „Die KI ändert unsere Zahlen.“ Antwort: Regeln werden an Stichproben getestet, von einer Person genehmigt und laufen danach deterministisch. Siehe GUIDE-008, GUIDE-009 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; das System verarbeitet Geschäftsdaten und trifft keine Entscheidungen über Personen. Die KI-Kompetenz (Art. 4) gilt. Speist das Mapping Daten in ein Hochrisikosystem (zum Beispiel Personalwesen oder Bonitätsbewertung), liegen die Pflichten nach Anhang III beim nachgelagerten System, die Daten-Governance (Art. 10) ist aber zu berücksichtigen.
• DSGVO: Partnerdateien enthalten oft personenbezogene Daten (Ansprechpersonen, Beschäftigte, Kunden, Einzelunternehmer). Senden Sie nur maskierte Stichproben an externe Modelle, schließen Sie AVVs ab, bevorzugen Sie EU-Regionen oder den Selbstbetrieb, wenden Sie Datenminimierung und Aufbewahrungsfristen an und halten Sie die Datenherkunft fest.
• Data Act (Verordnung 2023/2854): gibt Nutzern vernetzter Produkte Rechte auf Datenzugang und verlangt Interoperabilität; das erhöht die Nachfrage nach standardisiertem Mapping und Austausch.
• Sicherheit: Behandeln Sie hochgeladene Dateien als nicht vertrauenswürdig (CSV-/Formel-Injection, bösartiges XML, Prompt Injection in Zellen); validieren Sie mit Schemata, führen Sie erzeugten Code in einer Sandbox aus und protokollieren Sie alle Mapping-Änderungen.

Erste Schritte

1. Wählen Sie die 5–10 schwierigsten Partner-Feeds und messen Sie die aktuelle Onboarding-Dauer und Fehlerquote.
2. Schreiben Sie das Zielschema mit Feldbeschreibungen, Einheiten, erlaubten Werten und Beispielen; das ist die wertvollste Eingabe für jeden Matcher.
3. Testen Sie ein Werkzeug nach Weg A und einen LLM-Prototyp (Spaltenköpfe plus maskierte Stichproben) an diesen Feeds; bewerten Sie die Genauigkeit auf Feldebene.
4. Machen Sie das Mapping zu einem versionierten Artefakt mit Tests, einem Prüfschritt und Drift-Warnungen.
5. Spielen Sie jede Korrektur der Prüfenden in das Mapping-Gedächtnis zurück und verfolgen Sie den Anteil unveränderter Vorschläge.

Quellen

1. Flatfile documentation — https://flatfile.com/docs/
2. OneSchema documentation — https://docs.oneschema.co/
3. Stedi documentation (EDI, mappings, guides) — https://www.stedi.com/docs
4. SAP Integration Suite — https://help.sap.com/docs/integration-suite
5. Boomi documentation — https://help.boomi.com/
6. Valentine schema matching (open source) — https://github.com/delftdata/valentine
7. UN/EDIFACT standards (UNECE) — https://unece.org/trade/uncefact/introducing-unedifact
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
10. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj