Anfragenautomatisierung mit LLMs: Parsing, Artikelabgleich und menschliche Prüfung

RFQ-Automatisierung mit großen Sprachmodellen bedeutet, eine eingehende Angebotsanfrage, ob E-Mail-Text, PDF, Tabelle oder Portal-Export, in einen Angebotsentwurf zu verwandeln: extrahierte Positionen, zugeordnete Artikel, Preise aus Ihren Verträgen und eine Konfidenz pro Position, die der prüfenden Person zeigt, wo sie hinschauen muss. Die Person gibt frei, und erst dann verlässt ein Angebot das Unternehmen.

Dieser Artikel behandelt die Pipeline Stufe für Stufe, das Lesen unordentlicher Anfragedokumente, den Abgleich von Positionen mit Artikeln, ohne dem Modell zu sehr zu vertrauen, eine deterministische Preisfindung, das Design der Prüfwarteschlange und was der Business Case ehrlich behaupten kann. Das Angebot als versioniertes Workflow-Objekt und die Preis-Engine selbst sind eigene Themen; dieser Beitrag nutzt beide.

Was ändert RFQ-Automatisierung tatsächlich?

Sie automatisiert die Vorbereitung, nie das Angebot. Positionen abtippen, Artikelnummern suchen und Vertragspreise prüfen kostet den Innendienst die Zeit, und genau diese Schritte schafft eine Pipeline in Sekunden. Was angeboten wird, entscheidet weiterhin ein Mensch.

Die Fehlerkosten sind asymmetrisch. Eine nicht zugeordnete Position, die eine Person in zwanzig Sekunden löst, ist Normalbetrieb. Ein falscher Artikel zum falschen Preis in einem versendeten Angebot ist der einzige Fehler, der wirklich zählt, weil der Kunde es annehmen kann. Richten Sie alles an dieser Asymmetrie aus. Seien Sie auch klar darüber, was Automatisierung nicht löst: fehlende Vertragspreise, Artikel, die Sie nicht führen, und schlechte Kundenstammdaten bleiben Probleme, auch wenn die Pipeline läuft.

Die Pipeline vom Posteingang zum Angebotsentwurf

Die Pipeline hat sechs Stufen, und jede erzeugt ein Ergebnis, das eine prüfende Person einsehen kann: das Originaldokument, geparsten Text mit Positionen, ein typisiertes Array von Positionen, einen Treffer pro Position mit seinem Weg, einen Preis pro Position mit Quelle und den Angebotsentwurf mit Konfidenz pro Position.

Bei der Extraktion in ein typisiertes Array helfen Structured Outputs, und dort enden sie auch. Strikte Modi akzeptieren nur eine Teilmenge von JSON Schema. Die Azure-OpenAI-Dokumentation etwa verlangt, dass jedes Feld required ist, braucht additionalProperties: false, unterstützt weder pattern noch minimum noch maxItems und begrenzt Schemas auf 100 Eigenschaften und fünf Verschachtelungsebenen (Microsoft Learn). Mengenbereiche, Mengeneinheiten und Artikelnummernformate werden deshalb nach der Extraktion im Code geprüft, wie in Structured Outputs mit JSON Schema beschrieben.

Wie liest man das Anfragedokument?

Leiten Sie jedes Dokument nach seiner Art, denn der günstigste verlässliche Weg unterscheidet sich je Format. Was tatsächlich ankommt, ist gemischt: E-Mail-Texte mit hineinkopierter Tabelle, Excel-Dateien, gescannte PDFs einer alten Tabelle, Portal-Exporte und gelegentlich eine strukturierte Bestellnachricht.

Die Peppol-Bestelldokumente sind ein nützliches Zielformat, auch wenn niemand sie sendet: Ihre Codelisten unterscheiden Käufer-, Lieferanten- und Herstellerkennungen, nutzen Mengeneinheiten nach UN/ECE-Empfehlung 20 und Währungen nach ISO 4217 (Peppol BIS). Normalisieren Sie jeden Weg auf dieses Format. Die Preise in der Tabelle stammen von den Preisseiten von Google, AWS und Mistral, Stand Oktober 2026, und die Modelle wechseln: Mistral hat OCR 4.0 am 29. September 2026 abgekündigt und einen Tag später abgeschaltet (Mistral); halten Sie die Extraktionsschicht austauschbar. Die allgemeinen Parsing-Abwägungen stehen in PDF-Parsing für RAG.

Deutsche Anfragen bringen ihren eigenen Long Tail mit: „Stk.“ und „VE“ als Einheiten, „Lfd. Nr.“ als Positionsspalte, Dezimalkommas und zusammengesetzte Substantive in Beschreibungen. Das ist ein Normalisierungsproblem, kein Übersetzungsproblem, und es gehört in einen kleinen, getesteten Regelsatz statt in den Prompt.

Wie gleicht man Anfragepositionen mit Artikeln ab?

Nutzen Sie eine Kaskade: zuerst exakte Kennungen, dann eine Kunden-Querverweistabelle, dann semantische Suche, und halten Sie fest, welcher Weg jeden Treffer erzeugt hat. Der Weg bestimmt, wie viel Prüfung die Position braucht; ein semantischer Treffer darf daher nie die Konfidenz eines exakten tragen.

• Je Kennungstyp normalisieren. Käufer-, Lieferanten- und Herstellerartikelnummern sind verschiedene Kennungstypen; normalisieren Sie Groß- und Kleinschreibung, Leerzeichen und Trennzeichen je Typ und suchen Sie in einem eigenen Kennungsindex, nicht in der Produktsuche des Shops.
• Querverweise als Bestand behandeln. Eine Tabelle, die die Artikelnummer des Kunden Ihrer Artikelnummer zuordnet, wächst mit jeder menschlichen Korrektur und verschiebt Positionen mit der Zeit vom teuren auf den günstigen Weg.
• Semantische Suche schlägt vor, sie entscheidet nicht. Hybrides Retrieval mit Reranking, wie in semantischer Produktsuche im B2B, liefert der prüfenden Person eine Kandidatenliste, keine Antwort.
• Kataloge nur mit Beschreibungen brauchen Attribute. Hat keine Seite stabile Kennungen, gleichen Sie über klassifizierte Merkmale ab, etwa ETIM, dessen neueste Modellversion 10.0 ist, oder ECLASS, derzeit Release 16.0 (ETIM, ECLASS), und rechnen Sie mit niedrigen Automatikquoten.

// Match waterfall (sketch): exact identifiers first, semantic last, never the same confidence
type MatchPath = 'exact' | 'xref' | 'semantic'
type Match = { sku: string | null; path: MatchPath; review: 'optional' | 'light' | 'required'; evidence: unknown }

// normalize(id) applies per-type rules: case, spaces and separators for supplier numbers, etc.

async function matchLine(line: RfqLine, customer: string): Promise<Match> {
  for (const id of line.identifiers) {                      // buyer, supplier, manufacturer numbers
    const hit = await idIndex.get(id.type, normalize(id))      // dedicated identifier index, not the shop search
    if (hit) return { sku: hit.sku, path: 'exact', review: 'optional', evidence: id }
  }
  const xref = line.buyerPartNo && await crossRef.get(customer, line.buyerPartNo)
  if (xref) return { sku: xref.sku, path: 'xref', review: 'light', evidence: xref }

  const candidates = await hybridSearch(line.description, { rerank: true, k: 5 })
  return { sku: candidates[0]?.sku ?? null, path: 'semantic', review: 'required', evidence: candidates }
}

Woher kommen die Preise?

Aus demselben Weg, den der Shop nutzt, nie aus dem Modell. Jede zugeordnete Position wird vom Preisdienst oder dem ERP mit den Vertragspreisen, Staffeln, der Währung und der Gültigkeit des Kunden bepreist, und der Entwurf speichert Quelle und Zeitstempel jedes Preises.

Eine Position hat zwei legitime Zustände: bepreist, mit Quelle, oder Preis auf Anfrage. Der zweite ist ein normaler Geschäftszustand und sollte in der Prüfwarteschlange auch so aussehen. Zeigen Sie die Sonderfälle ausdrücklich: Vertragspreise, die vor Ende der Angebotsgültigkeit auslaufen, Mindestmengen und Verpackungseinheiten, die die angefragte Menge ändern, nicht lieferbare Artikel und Positionen, die einen Querverweis treffen, aber keinen verkäuflichen Artikel mehr. Konfigurierte Produkte sind ein Regelproblem; geben Sie sie an den Konfigurator, wie in Headless-Produktkonfiguratoren im B2B beschrieben.

Wie sollte die Prüfwarteschlange funktionieren?

Behandeln Sie die Prüfwarteschlange als das eigentliche Produkt, denn Prüfminuten pro Position sind der Hauptkostenblock. Teilen Sie Fehler in zwei Gruppen. Gefährliche: falscher Artikel, falscher Preis, erfundene Position. Harmlose: nicht zugeordnete Position, unklare Einheit, fehlender Liefertermin, Tippfehler in der Artikelnummer des Kunden. Die Warteschlange soll die erste Gruppe unversendbar und die zweite schnell behebbar machen.

• Konfidenz aus Signalen, nicht nur vom Modell. Kombinieren Sie Abgleichsweg, Kennungsprüfung und Retrieval-Score. Verbalisierte Modellkonfidenz eignet sich zum Sortieren; Tian et al. fanden sie bei RLHF-Modellen besser kalibriert als Token-Wahrscheinlichkeiten (EMNLP 2023), aber sie bleibt keine Wahrscheinlichkeit, die man blind als Schwelle nutzen kann.
• Beleg neben der Position. Zeigen Sie die Quellzelle aus dem Dokument, den zugeordneten Artikel und die Preisherkunft nebeneinander, damit Prüfen Kontrollieren heißt und nicht Suchen.
• Tastatur zuerst, pro Position. Jede Position mit einer Taste übernehmen, korrigieren oder ablehnen; Sammelübernahme nur für Positionen mit exakter Kennung.
• Korrekturen schreiben zurück. Jede Korrektur auf dem semantischen Weg wird zur Querverweiszeile für diesen Kunden.

Dieselbe Idee steckt hinter meinem jev-decide-Skill: Jedes Element bekommt eine ausdrückliche Entscheidung mit Konfidenz, und niedrige Konfidenz geht an einen Menschen statt an einen globalen Ein-Aus-Schalter für die KI. Für die Warteschlange würde ich zusätzlich einen End-to-End-Test mit Playwright MCP bauen, der eine anonymisierte historische Anfrage lädt, Positionszahl und Treffer prüft und sicherstellt, dass ohne ausdrücklichen Klick nichts versendet wird.

Was ist RFQ-Automatisierung wert?

Sie ist die Bearbeitungsminuten wert, die sie einspart, und die Antwortzeit, die sie verkürzt, und beides muss an Ihren eigenen Daten gemessen werden. Eine begutachtete oder sonst primäre Studie, die die Antwortzeit auf Anfragen mit der Abschlussquote verbindet, wurde nicht gefunden, und dieser Artikel leiht sich keine.

Die nächstliegende veröffentlichte Evidenz betrifft Vertriebs-Leads, nicht Anfragen. Die Harvard Business Review prüfte 2.241 US-Unternehmen und fand eine durchschnittliche Reaktionszeit von 42 Stunden bei denen, die innerhalb von 30 Tagen antworteten; in einem zweiten Datensatz von 1,25 Millionen Leads qualifizierten Firmen, die innerhalb einer Stunde Kontakt aufnahmen, den Lead fast siebenmal so oft wie jene, die eine Stunde länger warteten, und mehr als 60-mal so oft wie jene, die 24 Stunden oder länger warteten (HBR, März 2011). Diese Daten sind auf Lead-Ebene, überwiegend B2C und fünfzehn Jahre alt; sie stützen die Richtung, keine Zahl.

Die Kostenseite lässt sich berechnen. Extraktion ist pro Seite günstig, Arbeitszeit nicht. Als Bezugspunkt für den Lohnanteil dient der US-Medianlohn für Auftragssachbearbeiter, laut O*NET 22,20 US-Dollar pro Stunde im Jahr 2025, also rund 0,37 US-Dollar pro Minute ohne Gemeinkosten. Setzen Sie Ihre eigenen Vollkosten ein:

cost per RFQ = pages × OCR price per page
             + LLM tokens × token price
             + review minutes × loaded cost per minute

illustration, not a benchmark (as of October 2026):
  3 pages × $0.004 (Mistral OCR 4.1)           = $0.012
  review minutes × $0.37 (US order clerk median wage $22.20/h, unloaded)
  → staff time dominates; measure your own minutes before and after

Für eine Vertriebsleitung oder einen COO bei einem Großhändler lautet die passende Formulierung „Angebotsdurchlaufzeit verkürzen“, und die beiden Leitkennzahlen sind Prüfminuten pro Position und die Quote falscher Zuordnungen, die einen Kunden erreichen, die die menschliche Prüfung bei null hält.

Wann lohnt sich RFQ-Automatisierung nicht?

Verzichten Sie darauf, wenn das Anfragevolumen klein ist, weil die Prüfoberfläche mehr kostet, als sie spart; wenn Ihr Katalog überhaupt keine stabilen Kennungen hat; wenn Vertragspreise für kein System erreichbar sind, weil der Entwurf dann geraten wäre; und in jedem Ablauf, in dem ein falsches Angebot ohne Menschen dazwischen bindend würde.

Eine Checkliste für einen RFQ-Automatisierungspilot

1. Ein Referenzset aus 50 bis 200 historischen Anfragen mit bekannten korrekten Positionen, Artikeln und Preisen aufbauen.
2. Bearbeitungsminuten pro Anfrage vor dem Pilot messen.
3. Übernahme pro Position berichten, getrennt nach Abgleichsweg: exakt, Querverweis, semantisch.
4. Einheiten, Mengen und Artikelnummernformate nach der Extraktion im Code prüfen.
5. Nur über den Vertrags- und ERP-Weg bepreisen; den Rest als Preis auf Anfrage markieren.
6. Jedes versendete Angebot bis zur Quellstelle im Dokument und zum Preisdatensatz rückverfolgbar machen.
7. Korrekturen in die Querverweistabelle zurückführen.
8. Die Version des Extraktionsmodells festschreiben und das Referenzset bei jedem Wechsel erneut laufen lassen.

Nach mehr als zehn Jahren B2B-Commerce- und PIM-Arbeit ist meine Erfahrung, dass die PIM-Seite meist sauber ist und die eingehenden Kundendokumente nicht; ich würde in einem Pilot deshalb mehr Zeit in den Eingang und die Prüfwarteschlange stecken als in das Modell. Ein Pilot mit festem Umfang auf einigen hundert historischen Anfragen ist der ehrliche Weg zu den Zahlen; wenn Sie einen planen möchten, sehen Sie sich meine B2B-E-Commerce-Arbeit an.

Quellen

1. Harvard Business Review: The Short Life of Online Sales Leads (March 2011)
2. Mistral AI: OCR 4.1 model card
3. Mistral AI: models overview and deprecations
4. Google Cloud: Document AI pricing
5. Google Cloud: Document AI deprecations
6. Amazon Textract pricing
7. Microsoft Learn: Azure OpenAI structured outputs
8. Tian et al.: Just Ask for Calibration (EMNLP 2023)
9. Peppol BIS Upgrade 3: ordering profiles and code lists
10. ETIM International: model releases
11. ECLASS: classification standard
12. O*NET OnLine: Order Clerks (43-4151.00)