Warum sinkt die Genauigkeit meiner mehrsprachigen Extraktion?
3 Szenarien & spezifische Lösungen

Das Muster ist immer gleich: Sie testen mit englischen Dokumenten, erzielen magische Ergebnisse, wechseln dann zu Ihrer echten Dokumentenmischung – Rechnungen von Lieferanten aus drei Ländern, Versandetiketten mit Adressen in zwei Schriften, Verträge, die mitten im Satz die Sprache wechseln – und die Genauigkeit sinkt. Nicht katastrophal, aber genug, dass Sie sich fragen, ob das Tool überhaupt funktioniert.

Es funktioniert. Die Frage ist, was Sie von ihm verlangen. Eine einzelne englische Rechnung ist eine einheitliche Eingabe: eine Sprache, eine Schrift, eine Leserichtung. Eine deutsche Rechnung mit französischen Positionen und spanischen Zahlungsbedingungen ist nicht dieselbe Problemkategorie – und die Genauigkeit spiegelt das wider. Zu verstehen, welches von drei verschiedenen Szenarien vorliegt, ist der Unterschied zwischen zu wissen, was zu beheben ist, und dem Beschuldigen der falschen Sache.

Dieser Leitfaden behandelt die drei häufigsten Szenarien für Genauigkeitseinbußen, wie Sie erkennen, welches auf Ihre Dokumente zutrifft, und was Sie dagegen tun können. Für einen breiteren Überblick darüber, wie Vision-KI mehrere Sprachen auf architektonischer Ebene verarbeitet, siehe Kann KI mehrere Sprachen in einem Dokument lesen? – dieser Artikel setzt dieses Hintergrundwissen voraus und konzentriert sich auf die Fehlerbehebung.

Szenario 1: Ein Dokument, mehrere Sprachen

Dies ist die häufigste Ursache für Genauigkeitseinbußen – und die, die Benutzer meist nicht erkennen. Ihr Dokument ist „auf Deutsch" – aber der Kopf ist auf Englisch (Firmenname und Adresse), die Positionen mischen deutsche Produktbeschreibungen mit französischen Zutaten, und die Fußzeile enthält rechtliche Standardklauseln in der Sprache, die die Rechtsabteilung letztes Quartal gewählt hat.

Die meisten KI-Vision-Modelle verarbeiten die gesamte Seite als einen einzigen visuellen Kontext. Sie „wechseln" nicht die Sprache wie herkömmliche OCR – sie lesen alles auf einmal und ermitteln die Schrift jedes Zeichens im selben Inferenzdurchlauf. Das ist ein Vorteil gegenüber OCR-Engines, die ein vorgewähltes Sprachpaket benötigen, erzeugt aber ein subtiles Problem: Wenn Text in verschiedenen Sprachen im selben Sichtfeld erscheint, sinkt die Zeichenkonfidenz des Modells, weil es gleichzeitig Schriftgrenzen, Sonderzeichen (é, ü, ñ, ß) und kontextabhängige Buchstabenformen auflösen muss.

So sieht das in der Praxis bei einer einzigen mehrsprachigen Rechnung aus:

• Englischer Kopf (Firmenname, Adresse) – 96 % Genauigkeit. Das Modell ist in seinem stärksten Bereich.
• Deutscher Textkörper (Artikelbeschreibungen mit Umlauten, „€"-Währung, deutsches Datumsformat) – 88–91 % Genauigkeit. Umlaute (ä, ö, ü) werden weggelassen oder ersetzt; „14.03.2026" wird mit englischem „03/14/2026" verwechselt.
• Französische Positionen (Akzentzeichen: é, è, ê, œ) – 85–88 % Genauigkeit. Akzente auf Zeilen mit gemischten Glyphen häufen Fehler an; ein Wort wie „générique" wird zu „generique" oder „g6n6rique".
• Spanische Zahlungsbedingungen (ñ und umgekehrte Satzzeichen) – 82–87 % Genauigkeit. Das Modell hat sein Zeichenauflösungsbudget bereits für die deutschen und französischen Abschnitte verbraucht, bevor es die Fußzeile erreicht.

Dies sind keine Worst-Case-Zahlen. Sie sind typisch für ein Dokument, das zwischen drei lateinischen Schriften wechselt – alle mit demselben Alphabet, aber unterschiedlich bei Sonderzeichen, Datumsformaten und Währungsnotationen.

Diagnose: Wenn Ihre Genauigkeit pro Feld innerhalb desselben Dokuments variiert – Daten zuverlässiger sind als Lieferantennamen oder Zahlen sauber sind, während Akzentzeichen verstümmelt werden –, liegt wahrscheinlich Szenario 1 vor.

Lösung: Verwenden Sie benutzerdefinierte Spaltenextraktion anstelle einer vollständigen OCR. Wenn Sie bestimmte Ausgabespalten definieren (z. B. „Lieferantenname“, „Rechnungsdatum“, „Gesamtbetrag“), konzentriert sich die KI darauf, diese Werte anhand ihrer semantischen Bedeutung zu finden, anstatt jedes Zeichen auf der Seite gleichmäßig zu verarbeiten. Eine Spalte namens „Gesamtbetrag (EUR)“ teilt dem Modell mit, dass es nach einer Zahl in der Nähe eines Währungssymbols suchen soll – unabhängig davon, ob der umgebende Text Deutsch, Französisch oder Spanisch ist. Für einen tieferen Einblick, wie spaltenbasierte Extraktion über Dokumenttypen hinweg funktioniert, lesen Sie wie KI-Dokumentenextraktion funktioniert und warum Spaltendefinition wichtig ist.

Szenario 2: Schriftunterschiede – Lateinisch vs. CJK vs. Arabisch

Hier überschreitet der Genauigkeitsverlust die Grenze von „lästig“ zu „workflow-zerstörend“. Eine englische Rechnung wird mit 96 % extrahiert, eine japanische mit 82 % – nicht weil das japanische Dokument von geringerer Qualität ist, sondern weil die Schriftfamilien grundlegend unterschiedlich darin sind, wie sie Vision-Modelle herausfordern.

Lateinische Schriften (Englisch, Französisch, Deutsch, Spanisch, Portugiesisch, Italienisch, Niederländisch) teilen ein 26-Zeichen-Alphabet, eine Leserichtung von links nach rechts und reichlich Trainingsdaten. Sie sind ein gelöstes Problem für moderne Vision-KI – die Genauigkeit bei sauberem gedrucktem lateinischem Text liegt konstant bei 95–99 %.

CJK-Schriften (Chinesisch, Japanisch, Koreanisch) sind eine andere Schwierigkeitsstufe. Ein einziger japanischer Satz kann Kanji (tausende chinesischstämmige Zeichen), Hiragana (46 phonetische Zeichen), Katakana (46 phonetische Zeichen für Lehnwörter), lateinische Zeichen für englische Begriffe und arabische Ziffern enthalten – alles in einer Zeile. Der gleiche semantische Inhalt auf Japanisch verbraucht etwa 2× die Token seines englischen Äquivalents, was bedeutet, dass das Modell seinen Kontextfenster bei CJK-Dokumenten schneller füllt und pro Feld weniger Informationen zur Verfügung hat. Ein praktisches Beispiel für dieses Dichteproblem finden Sie in unserer Abhandlung über Extraktion japanischer Kassenzetteldaten in Excel.

Arabisch und Hebräisch fügen die Herausforderung der Rechts-nach-Links-Richtung hinzu. Das Modell muss erkennen, dass sich die Leserichtung umkehrt, sie korrekt pro Textblock anwenden und die vier Positionen der arabischen Buchstabenformen handhaben (ein Buchstabe ändert seine Form je nachdem, ob er am Anfang, in der Mitte, am Ende oder isoliert in einem Wort erscheint). Die Genauigkeit bei gedruckten arabischen Dokumenten liegt zwischen 75–85 % – nicht weil das Modell speziell bei arabischen Zeichen schwach ist, sondern weil die RTL-typografischen Konventionen ein anderes visuelles Parsing-Problem als links-nach-rechts-Schriften darstellen.

Diagnose: Wenn Ihre englischen Dokumente mit 95 %+ extrahiert werden und nicht-lateinische Dokumente konstant 10–20 % niedriger liegen – über verschiedene Dokumente hinweg, nicht nur bei einem – befinden Sie sich in Szenario 2.

Lösung: Zwei Ansätze sind hier möglich. Prüfen Sie zunächst, ob das Tool die jeweilige Schriftart Ihres Dokuments unterstützt. Nicht alle Tools, die „Unterstützung für über 100 Sprachen“ versprechen, sind für alle Schriften gleich gut trainiert. Manche Bilderkennungsmodelle sind überwiegend mit lateinischen Daten trainiert, während CJK und Arabisch nur einen kleineren Teil des Trainingskorpus ausmachen. Fragen Sie gezielt nach, ob die Trainingsdaten des Modells die benötigte Schriftfamilie enthalten. Zweitens: Testen Sie mit einer repräsentativen Stichprobe Ihrer tatsächlichen Dokumente, nicht mit den Demobildern des Anbieters. Eine japanische Demo-Rechnung des Anbieters ist ein sauberes, digital erstelltes Bild mit perfektem Kontrast – Ihre gescannte japanische Rechnung von 2019 mit einem verblassten Stempel über dem Lieferantennamen ist ein völlig anderes Erkennungsproblem.

Szenario 3: Gemischte Schriften im selben Feld

Dies ist der schwierigste Fall – und der, den die meisten Dokumentationen auslassen. Ein einzelnes Feld in Ihrem Dokument enthält Zeichen aus mehreren Schriften. Eine Teilenummer wie „ABC-1234-안전밸브“ (englische Buchstaben, arabische Ziffern, koreanisches Hangul). Ein Lieferantenname wie „株式会社Yamada (Osaka Branch)“. Ein Datumsfeld wie „2026年03月14日“ – arabische Ziffern eingebettet in CJK-Text.

Bilderkennungsmodelle verarbeiten Felder mit gemischten Schriften, indem sie jede Zeichengruppe unabhängig erkennen und zu einer kohärenten Zeichenfolge zusammensetzen. Dieser Prozess führt jedoch zu mehreren Fehlermodi, die spezifisch für gemischte Schriften sind:

• Fehlerkennung von Schriftgrenzen: Das Modell erkennt falsch, wo eine Schrift endet und eine andere beginnt. Ein koreanisches Hangul-Zeichen, das einem CJK-Ideogramm ähnelt, wird möglicherweise der falschen Schriftgruppe zugeordnet, sodass die folgenden Zeichen mit dem falschen Erkennungskontext analysiert werden.
• Zeichensubstitution: Ähnlich aussehende Zeichen aus verschiedenen Schriften werden vertauscht. Der lateinische Buchstabe „A“, das kyrillische „А“ und das griechische „Α“ sind visuell nahezu identisch, aber unterschiedliche Unicode-Zeichen. Ein Produktcode mit lateinischem „A“ könnte als kyrillisches „А“ ausgegeben werden – visuell identisch, semantisch falsch und bei einer Stichprobenprüfung nicht erkennbar, da es korrekt aussieht.
• Richtungsverwirrung bei gemischten LTR/RTL-Feldern: Ein arabischer Firmenname gefolgt von einer englischen Registrierungsnummer in Klammern erzeugt eine bidirektionale Zeichenfolge, die das Modell korrekt anordnen muss. Eine Ausgabe wie „(ABC-1234 شركة“) anstelle von „شركة (ABC-1234)“ ist häufig – beide Zeichen sind vorhanden, aber die Lesereihenfolge ist vertauscht.

Diagnose: Wenn Ihre extrahierten Daten visuell plausibel aussehen, aber nicht mit einer bekannten Referenz übereinstimmen – eine Teilenummer, die alle richtigen Zeichen zu haben scheint, aber nicht mit Ihrem ERP-System übereinstimmt, oder ein Lieferantenname, der beim menschlichen Überfliegen korrekt wirkt, aber eine Lookup-Fehler verursacht – dann ist Szenario 3 die wahrscheinliche Ursache.

Lösung: Vorverarbeitung mit Sprachhinweisen reduziert Fehler bei gemischten Schriften erheblich. Während die meisten Bilderkennungsmodelle die Sprache automatisch erkennen, hilft eine explizite Angabe des Extraktionskontexts. In Tools, die dies unterstützen, teilt ein Hinweis wie „Die primäre Sprache dieses Dokuments ist Koreanisch mit eingebetteten englischen Produktcodes“ dem Modell mit, dass Schriftgrenzen zu erwarten sind, anstatt sie als Erkennungsfehler zu behandeln. Für Felder, bei denen Genauigkeit entscheidend ist – Steuer-IDs, Teilenummern, Registrierungscodes – ist eine sprachspezifische Stichprobenvalidierung die zuverlässigste Absicherung: Extrahieren Sie die Daten und überprüfen Sie den nicht-lateinischen Teil getrennt vom lateinischen Teil. Wenn Sie eine Referenzdatenbank (ERP, CRM, Lieferantenliste) haben, deckt der Abgleich extrahierter Werte Zeichensubstitutionsfehler auf, die keine noch so genaue visuelle Inspektion finden wird.

So diagnostizieren Sie Ihr Szenario

Wenn Sie bei mehrsprachigen Dokumenten einen Abfall der Genauigkeit bemerken, gehen Sie diese drei Diagnosefragen durch, bevor Sie etwas ändern:

1. Ist der Genauigkeitsabfall sprachübergreifend konsistent, aber innerhalb desselben Dokuments? Wenn Ihre englischen Felder stets sauber sind und Ihre französischen/Umlaut-Felder im selben Dokument durchgängig schlechter abschneiden → Szenario 1. Versuchen Sie spaltenbasierte Extraktion mit semantischen Felddefinitionen.
2. Ist der Abfall sprachfamilienübergreifend über ganze Dokumente hinweg konsistent? Wenn jedes japanische Dokument schlechter extrahiert wird als jedes englische Dokument, unabhängig vom Inhalt → Szenario 2. Überprüfen Sie die Abdeckung der Trainingsdaten des Tools für die jeweilige Schrift.
3. Ist der Abfall auf bestimmte Felder mit gemischtsprachigem Inhalt beschränkt? Wenn Lieferantennamen in Ordnung sind, aber Teilenummern mit eingebettetem Kanji oder Arabisch fehleranfällig sind → Szenario 3. Fügen Sie sprachliche Hinweise in der Vorverarbeitung hinzu und implementieren Sie feldübergreifende Querverweise.

Diese drei Szenarien überschneiden sich oft – ein Dokument kann mehrere Sprachen (Szenario 1) in verschiedenen Schriften (Szenario 2) mit gemischtsprachigen Feldern (Szenario 3) auf derselben Seite enthalten. Die Diagnosefrage zeigt Ihnen, welche Ebene Sie zuerst beheben müssen, denn die falsche Ebene zu korrigieren, kostet Zeit. Wenn Sie sich in Szenario 2 befinden, wird keine noch so gute Spaltenverfeinerung (Szenario 1-Lösung) die Genauigkeitslücke schließen – das Modell benötigt eine andere Trainingsabdeckung, nicht einen besseren Prompt.

Prävention: Drei Gewohnheiten gegen Genauigkeitsverluste bei Mehrsprachigkeit

Wenn Sie Ihr Szenario identifiziert haben, verhindern diese Praktiken, dass dasselbe Problem bei neuen Dokumenttypen und Sprachen erneut auftritt:

1. Trennen Sie Dokumente nach Möglichkeit nach Schriftfamilien. Wenn Sie täglich 200 Rechnungen verarbeiten – 150 in lateinischen Schriften und 50 in CJK – erhalten Sie durch separate Stapel zwei unabhängige Genauigkeitsbaselines. Sie wissen, dass die Extraktion lateinischer Schriften bei über 95 % und CJK bei 82 % liegt. Fällt ein CJK-Stapel plötzlich auf 70 %, bemerken Sie das sofort. In einem gemischten Stapel könnte der Gesamtdurchschnitt von 93 % auf 90 % fallen, und niemand würde Alarm schlagen.

2. Pflegen Sie sprachspezifische Verifikationsstichproben. Wählen Sie 5–10 repräsentative Dokumente für jede von Ihnen verarbeitete Sprachfamilie aus. Führen Sie bei jeder Aktualisierung Ihres Extraktionsworkflows oder Tool-Wechsel den Verifikationssatz durch und vergleichen Sie die Genauigkeit pro Sprache. So erkennen Sie Regressionen, bevor sie in die Produktion gelangen. Ein Tool, das die lateinische Genauigkeit um 2 % verbessert, aber die CJK-Genauigkeit um 8 % verschlechtert, ist für einen mehrsprachigen Workflow keine Nettoverbesserung.

3. Verwenden Sie feldspezifische Konfidenzschwellen, die je nach Sprache variieren. Wenden Sie nicht dieselbe Regel „Akzeptieren, wenn Konfidenz > 90 %“ auf englische und arabische Felder desselben Dokuments an. Eine 90 %-Konfidenzschwelle für Englisch könnte zu streng sein (alles besteht), während dieselbe Schwelle für Arabisch jede Extraktion ablehnen könnte. Legen Sie sprachspezifische Schwellen fest, die auf Ihren Verifikationsstichprobenergebnissen basieren – Arabisch 75 %, Latein 90 %, CJK 80 % – und leiten Sie alles unterhalb der Schwelle zur manuellen Überprüfung weiter, anstatt es stillschweigend zu akzeptieren.

Wann eskaliert werden muss – was weiterhin manuell bearbeitet werden sollte

Ehrlichkeit ist hier wichtiger als an jeder anderen Stelle dieses Artikels. Vision AI ist bemerkenswert leistungsfähig über Sprachen hinweg, aber es gibt Randbedingungen, bei denen keine noch so gute Prompt-Optimierung oder Vorverarbeitung die Genauigkeitslücke zum Produktionsniveau schließen kann.

• Dokumente mit vier oder mehr Sprachen aus unterschiedlichen Schriftsystemen. Ein Dokument, das Englisch (Lateinisch), Arabisch (RTL), Japanisch (CJK vertikal + horizontal) und Koreanisch (CJK horizontal) enthält – alles auf derselben Seite – befindet sich am Rande der aktuellen Fähigkeiten von Bildverarbeitungsmodellen. Erwarten Sie einen Genauigkeitsabfall von 5–15 % gegenüber dem einsprachigen Basiswert.
• Gemischte RTL/LTR innerhalb desselben Satzes oder derselben Tabellenzelle. Wenn Arabisch und Englisch in derselben Zeile mit einer parenthetischen Beziehung vorkommen (z. B. "البند (Item) 4.2" in einer Vertragsklausel), erzeugt die bidirektionale Analyse strukturelle Fehler, die Vorverarbeitungshinweise nur teilweise beheben.
• Handschriftlicher Inhalt in einer nicht-lateinischen Schrift. Handschrift allein senkt die Genauigkeit um 15–30 % im Vergleich zu gedrucktem Text. Kommt eine zweite Sprache hinzu – handschriftliche arabische Ziffern in handschriftlichem Japanisch – und der kumulative Effekt bringt die meisten Extraktionen unter die Nutzbarkeitsschwelle. Diese Dokumente profitieren weiterhin von der KI-Extraktion für die gedruckten Teile, aber die handschriftlichen Felder sollten als Standard-Workflow und nicht als Ausnahme für die manuelle Eingabe vorgesehen werden.
• Paarungen mit Sprachen mit geringen Ressourcen. Thai/Arabisch, Swahili/Kyrillisch, Birmanisch/Englisch – Paare, bei denen keine der beiden Sprachen einzeln über hohe Ressourcen für das Training von Bildverarbeitungsmodellen verfügt. Die Genauigkeitsuntergrenze für diese Dokumente ist niedriger als für gut abgedeckte Paarungen wie Englisch/Spanisch oder Englisch/Chinesisch.

Der praktische Workflow: Die KI-Extraktion verarbeitet 80–90 % der mehrsprachigen Daten automatisch. Die verbleibenden 10–20 % – risikoreiche Felder in Dokumenten mit gemischten Schriften, kritische Zahlenfelder in gemischtem RTL/LTR-Text und handschriftliche nicht-lateinische Einträge – werden an einen menschlichen Prüfschritt weitergeleitet, der schneller ist als eine vollständige manuelle Eingabe und zuverlässiger, als sich bei den schwierigsten Fällen auf die KI zu verlassen.

FAQ

Warum funktioniert mein KI-Extraktionstool bei englischen Rechnungen gut, aber bei deutschen oder französischen schlechter?

Das ist typischerweise Szenario 1. Das englische Dokument ist eine einsprachige Eingabe ohne Skript-Mehrdeutigkeit. Das deutsche oder französische Dokument enthält wahrscheinlich Sonderzeichen (Umlaute, Akzente), die das Vision-Modell als Variationen von Standard-Lateinbuchstaben behandelt – und diese Variationen haben eine geringere Konfidenz, da sie in den Trainingsdaten seltener vorkommen als unakzentuierte Zeichen. Die Genauigkeitslücke zwischen Englisch und anderen lateinischen Schriften beträgt normalerweise 5–8 % – spürbar, aber behebbar mit spaltenbasierter Extraktion, die das Modell auf bestimmte Felder statt auf eine Ganzseiten-OCR fokussiert.

Kann ich die Genauigkeit der mehrsprachigen Extraktion verbessern, indem ich Dokumente zuerst in eine einzige Sprache konvertiere?

Nicht zuverlässig. Maschinelle Übersetzung vor der Extraktion fügt eine separate Fehlerebene hinzu – Sie extrahieren nun aus übersetztem Text, der Feldbezeichnungen, Zahlenformate und Dokumentstruktur verlieren kann. Das Originaldokument enthält das beabsichtigte Layout und die Daten des Autors. Die Extraktion funktioniert am besten, wenn sie das Original liest, nicht eine übersetzte Version. Der bessere Ansatz ist, aus dem Originaldokument mit semantischen Spaltendefinitionen zu extrahieren und dann die extrahierten Daten gegen die Sprache zu validieren, die Ihr nachgelagertes System benötigt.

Muss die KI vor der Verarbeitung wissen, welche Sprachen im Dokument enthalten sind?

Nein für die Erkennung – moderne Vision-Modelle erkennen Schriften und Sprachen automatisch beim Lesen der Seite. Aber ja für den Kontext – wenn Ihr Dokument eine seltene Sprachkombination oder gemischte Schriftfelder enthält, verbessert ein Sprachhinweis (z. B. „dieses Dokument enthält Koreanisch und Englisch mit eingebetteten arabischen Ziffern“) die Genauigkeit um 3–7 % bei den sekundären Sprachteilen, da das Modell Erkennungsressourcen effizienter zuweist.

Wie groß ist der erwartete Genauigkeitsunterschied zwischen lateinischen und CJK-Dokumenten beim selben Tool?

Bei sauberen Druckdokumenten ähnlicher Qualität ist mit einer 8–15 % niedrigeren CJK-Genauigkeit im Vergleich zu lateinischen Texten zu rechnen. Dies ist kein Qualitätsproblem des Tools – es spiegelt den grundlegenden Unterschied im Zeichenvorrat (26 vs. Tausende), Token-Verbrauch (2× pro semantischer Einheit) und Trainingsdatenvolumen wider. Ein Tool, das bei Englisch 97 % erreicht, aber bei Japanisch nur 83 %, arbeitet für den aktuellen Stand der Bild-KI normal.

Sollte ich für verschiedene Sprachen unterschiedliche KI-Extraktionstools verwenden?

Wenn Ihr Dokumentenmix mehrere Schriftsysteme umfasst (nicht nur mehrere Sprachen innerhalb desselben Schriftsystems), können Sie durch den Einsatz von Tools, die für bestimmte regionale Schriften optimiert sind, eine höhere sprachspezifische Genauigkeit erzielen. PaddleOCR beispielsweise liefert bei CJK-Dokumenten bessere Ergebnisse als universelle Bildmodelle, da seine Trainingsdaten überwiegend aus CJK bestehen. Die Verwaltung mehrerer Tools bringt jedoch Workflow-Komplexität mit sich, die den Genauigkeitsgewinn für die meisten Teams überwiegen kann. Ein bewährter Ansatz: Verwenden Sie ein universelles Bild-KI-Tool als primären Extraktor für alle Sprachen und leiten Sie Dokumente in bestimmten Schriften nur dann an spezialisierte Fallback-Engines weiter, wenn die Konfidenz des primären Tools unter einen Schwellenwert fällt.

Der Genauigkeitsabfall zwischen einem einzelnen lateinischen Dokument und einem mehrsprachigen Dokument ist kein Technologieversagen – es ist eine vorhersehbare, diagnostizierbare und weitgehend behebbare Lücke. Beginnen Sie mit der diagnostischen Frage, wenden Sie die Lösung für Ihr Szenario an und reservieren Sie die manuelle Prüfung für die Randfälle, bei denen aktuelle Bildmodelle noch lernen. Testen Sie an Ihren eigenen mehrsprachigen Dokumenten und sehen Sie, welches Szenario auf Ihren Workflow zutrifft.