Verwaltung (nur Administratoren)

Die Verwaltung ist in der Navigation auf zwei Menüpunkte aufgeteilt, beide nur für Administratoren sichtbar. Die Leitregel in einem Satz: Was verändert, wie das System künftig arbeitet, gehört nach Einstellungen; was zeigt, was gerade passiert oder passiert ist, und erlaubt, direkt einzugreifen, gehört nach Betrieb. Beide Bereiche teilen sich dieselbe Bedienung – links eine durchgehend sichtbare Kategorie-Leiste, rechts der zugehörige Inhaltsbereich; ein Klick auf eine Kategorie tauscht nur den Inhaltsbereich aus. Bestehende Lesezeichen auf einzelne Verwaltungsseiten bleiben nach dieser Zusammenführung gültig.

Einstellungen – Kategorien (die Kategorie-Leiste gliedert sie in die Gruppen Einrichtung, Dokumentfluss, Zugang und System):

• Übersicht – Konfigurationskennzahlen: Anzahl Dokumentenarten und aktive Eingangsquellen.
• Eingang & Quellen – Manueller Upload, GetMyInvoices, E-Mail-Postfach und Eingangsordner konfigurieren.
• Dokumentenarten – zentrale Übersicht aller Dokumentenarten mit KI-Pipeline-Status und Workflow-Zuweisung.
• Erkennung & KI – KI-Zugänge (KI-Profile, Chat-KI), Dokumentenerkennung (Feld-Mapping, KI-Assistent, E-Rechnungen) und Volltext & OCR (OCR-Vervollständigung).
• Workflow – Aufgaben-Tab, Abschluss, Automatisierung und Buchungsvorlagen.
• Suche & Index – Ähnlichkeitssuche und Fuzzy-Einstellungen des Suchindex.
• Benutzer & Rollen – Benutzerverwaltung, Rollen und Berechtigungen.
• Partnerportal – Portalzugänge anlegen, konfigurieren und verwalten.
• API-Schlüssel – Zugangsschlüssel für externe Anwendungen (Service-Accounts).
• Mandanten – Mandanten-Freischaltung; Unterpunkt Berechtigungsabgleich (Berechtigungsprofile von Stammdaten auf zugeordnete Archivdokumente übertragen).
• Protokolle & Aufbewahrung – Aufbewahrungsfrist des Verarbeitungsprotokolls, Feldprotokoll und Protokollumfang des Audit-Logs.
• Kommunikation & Branding – Login-Logo, Chat-Aktivierung, Feedback-Funktion und E-Mail-Versand (SMTP).
• System – Mobile WinLine und Sitzungsdauer.

Betrieb – Bereiche:

• Systemstatus – Zustand der Hintergrunddienste und Durchsatz-Kennzahlen der Dokumentverarbeitung.
• KI-Jobs & Verbrauch – laufende Analysen sowie die Token-Auswertung (je Tag und je Aufruf, mit Modell und Provider). Zeitraum, Tagesübersicht und Uhrzeiten richten sich nach der Ortszeit Ihres Browsers – ein Aufruf um 00:30 Uhr zählt zum neuen Tag. Die Aufrufliste nennt getrennt den Zweck (wofür das Modell gerufen wurde – Feldextraktion, Beschreibung, Buchungstext …) und die Eingabe (womit – OCR-Text, Bild oder das Erkennungsergebnis der Dokumentenerkennung). Die Spalte Eingang nennt den Eingang, in dessen Verarbeitung der Aufruf lief; weil die Dokumenterkennung vor der Archivierung läuft, zeigt DokId dann die Nummer, die das Dokument inzwischen hat. Mit dem Recht für das Verarbeitungsprotokoll öffnet die Lupe neben der Eingangsnummer den ganzen Lauf.
• Antwortzeiten – wie lange der Server für jede Funktion braucht: je Endpunkt Anzahl der Aufrufe, Mittelwert, Median, die Werte für 95 % und 99 % der Aufrufe, Maximum, Fehler und Abbrüche (der Browser hat nach 60 Sekunden nicht mehr gewartet). Darunter die langsamsten Einzelaufrufe mit ihren Phasen (wo die Zeit verbraucht wurde – Treffer ermitteln, Trefferzahl zählen, Kopfdaten laden, Bezeichnungen auflösen, Suchindex) und Merkmalen (Anzahl der Kriterien, Schlagwortnummern, Suche mit Platzhalter, Blättern, Trefferzahl – ohne Suchbegriffe, aber mit Benutzernummer); diese Liste führt Suche, Explorer und Dashboard-Zahlen, Downloads und Uploads stehen nur in der Tabelle je Funktion. Als Datei speichern gibt den Bericht als JSON-Datei für den Support aus, Zurücksetzen beginnt die Erfassung neu, etwa für einen Vorher-nachher-Vergleich nach dem Anlegen von Datenbank-Indizes. Die Werte liegen nur im Arbeitsspeicher und beginnen nach einem Neustart von vorn.
• Suchindex – Indexstand, Neuaufbau und Diagnose.
• Sitzungen – alle aktuell angemeldeten Benutzer.
• Sperren – aktive Dokument- und Fall-Sperren.
• Audit-Log – das Nachvollziehbarkeits-Protokoll sicherheitsrelevanter Vorgänge.

Das Verarbeitungsprotokoll ist kein Betrieb-Bereich mehr, sondern ein eigener Menüpunkt Verarbeitung im Arbeitsbereich – sichtbar für jeden internen Benutzer mit dem entsprechenden Recht, auch ohne Administratorrechte und auch ohne das WebArchiv-Produkt (siehe Verarbeitungsprotokoll).

Benutzerverwaltung

Die Seite Benutzerverwaltung (Verwaltung → Einstellungen → Benutzer & Rollen) listet alle WinLine-Benutzer mit Nummer, Benutzername, Anzeigename, E-Mail, Typ (Intern/Portal), Status, Kontonummer, WinLine-Gruppen, Rollen, MFA-Status und Mandanten; Bearbeiten öffnet den Benutzer. Oben stehen + Rolle anlegen, Rollen verwalten und Vordefinierte Rollen anlegen.

In der Detailansicht eines Benutzers lässt sich außerdem dessen Profilbild ändern oder entfernen (PNG, JPEG, GIF, BMP oder WEBP, max. 8 MB). Vor dem Hochladen lässt sich der quadratische Bildausschnitt per Rahmen verschieben und in der Größe ändern (runde Live-Vorschau); ohne Anpassung wird die Bildmitte verwendet. Das Bild wird auf das WinLine-Format skaliert, in der WinLine-Systemdatenbank abgelegt und damit auch in WinLine angezeigt; nach dem Entfernen erscheinen wieder die Initialen.

Rollen und Berechtigungen:

• Rollen erstellen und bearbeiten (Dialog Rolle „…“ bearbeiten: Name, Beschreibung, Standardrolle, Portal-Optionen, WinLine-Benutzergruppen, Mandanten-Zugriff und die nach Kategorien gruppierten Berechtigungen, z. B. Archiv-Funktionen, Anmerkungen)
• Für Portal-Benutzer verfügbar: Kontrollkästchen legt fest, ob eine Rolle Portal-Benutzern zugewiesen werden darf
• Benutzer einer oder mehreren Rollen zuordnen
• Verfügbare Berechtigungen: Archiv-Suche, Hochladen, Workflow, Verwaltung, Portal u. a.
• Autoarchivierte Belege ohne Dokumentenart anzeigen (WinLine-Belegdruck): Spool-Belegdrucke aus dem WinLine-Autoarchiv (z. B. FAKTURA….SPL) haben keine Dokumentenart und erscheinen nur für Benutzer mit dieser Berechtigung – in Suche, Explorer, Dashboard, Export, beim Direktzugriff, beim Teilen und im KI-Assistenten. Standard: aus. Die Berechtigung gibt dabei nur den Schalter Belegdrucke anzeigen in den Schnelloptionen der Suche frei – auch Berechtigte (einschließlich Administratoren) müssen ihn erst einschalten, um die Belege zu sehen (Standard: aus, Einstellung pro Benutzer, wirkt auf alle Lesepfade inklusive der Zähler). Portal-Benutzer sind ausgenommen (ihr Zugriff auf Belegdrucke läuft über die Portal-Einschränkungen; der Schalter erscheint für sie nicht).

Standard-Rolle:

Eine als Standard markierte Rolle gilt automatisch für alle internen Benutzer, die weder direkt noch über eine Benutzergruppe einer Rolle zugewiesen sind – auch für künftig angelegte Benutzer. Sie wirkt als Fallback, nicht additiv: Sobald ein Benutzer eine eigene Rolle hat, greift die Standard-Rolle für ihn nicht mehr. Ohne Standard-Rolle haben interne Benutzer ohne Rollenzuweisung keinerlei Berechtigungen (Ausnahme: WinLine-Administratoren). Zwei bewusste Grenzen des Fallbacks: Portal-Benutzer erreicht er nie – Geschäftspartner erhalten Rollen ausschließlich durch Zuweisung (automatisch bei der Portal-Aktivierung über die Option Neuen Geschäftspartnern bei Portal-Aktivierung zuweisen oder manuell); ihre Grundfunktionen (Suchen, Vorschau, Herunterladen, Explorer) sind unabhängig davon immer gewährleistet. Und eine Mandanten-Einschränkung der Standard-Rolle wirkt nicht über den Fallback: Mandanten-Einschränkungen greifen nur für Benutzer, denen die Rolle tatsächlich zugewiesen ist – sonst würde eine eingeschränkte Standard-Rolle allen rollenlosen internen Benutzern (auch Administratoren) still Mandanten aus der Mandanten-Auswahl nehmen.

Portal-Startrolle:

Über die Option Neuen Geschäftspartnern bei Portal-Aktivierung zuweisen (nur wählbar bei Rollen, die für Portal-Benutzer verfügbar sind) wird eine Rolle jedem neu aktivierten Portalzugang fest zugewiesen – als echte, in der Benutzerverwaltung sichtbare Zuweisung. Das ersetzt die frühere Doppelbedeutung der Standard-Rolle: „Standardrolle“ betrifft nur noch interne Benutzer, die Portal-Startrolle nur noch neue Geschäftspartner. Beim Update wird eine Rolle, die bisher beides war (Standard und für Portal-Benutzer verfügbar), automatisch als Portal-Startrolle markiert – ihr Standard-Kennzeichen behält sie; ob es weiterhin gewollt ist (die Rolle gilt damit auch als Fallback für interne Benutzer), zeigt das Kennzeichen „Standardrolle (intern)“ in der Rollenverwaltung. Bestehende Portalzugänge behalten ihre bereits zugewiesenen Rollen; Portalzugänge ohne Rollenzuweisung erhalten über den Fallback keine Rechte mehr – sie behalten die Grundfunktionen und bekommen bei Bedarf die Rolle Portal manuell zugewiesen.

Eine fertige Grundrolle „WebArchiv-Standard“ (Suchen, Vorschau, Herunterladen, Explorer) kann per SQL-Script docs/sql/webarchiv-standard-rolle.sql angelegt werden – bewusst manuell statt automatisch, weil damit alle bislang rollenlosen Benutzer diese Rechte erhalten.

Vordefinierte Rollen anlegen:

Die Schaltfläche Vordefinierte Rollen anlegen in der Benutzerverwaltung legt vier wohldefinierte Rollen an bzw. zieht sie nach:

• Mitarbeiter – Standard-Rolle mit Basisrechten für interne Benutzer (Suchen, Vorschau, Explorer, Herunterladen, Hochladen, Workflow-Basis). Portal-Benutzer erreicht die Standard-Rolle nicht – der Fallback gilt nur für interne Benutzer
• Portal – Basisrechte für Geschäftspartner (Suchen, Vorschau, Herunterladen, Explorer), für Portal-Benutzer verfügbar und als Portal-Startrolle markiert: neue Portalzugänge erhalten sie bei der Aktivierung automatisch zugewiesen
• WebArchiv-Administration und WebArchiv-Systemadministration – die delegierten Admin-Rollen (siehe Administration delegieren), falls sie gelöscht wurden

Die Funktion ist gefahrlos mehrfach ausführbar: An erkannten vordefinierten Rollen werden nur fehlende Berechtigungen ergänzt; kundeneigene Rollen mit gleichem Namen werden übersprungen und nie verändert, ebenso bleiben entfernte Rechte, Flags, Mandanten- und Gruppenzuweisungen unangetastet. Der Ergebnis-Dialog zeigt je Rolle den Status (angelegt, ergänzt, unverändert, übersprungen) und warnt, wenn eine bestehende Standard-Rolle eine Mandanten-Einschränkung trägt. Die Ausführung wird im Audit-Log protokolliert. Keine der vordefinierten Rollen trägt eine Mandanten-Einschränkung oder Benutzergruppen-Bindung – das bleibt bewusste, sichtbare eigene Konfiguration.

Einzelnen internen Benutzergruppen mehr Rechte geben: Die Standard-Rolle unterscheidet intern und Portal bereits von selbst – sie greift nur für interne Benutzer. Für Abstufungen innerhalb der internen Benutzer (z. B. eine Abteilung soll zusätzlich das Dashboard sehen) ist eine zweite Standard-Rolle aber nicht geeignet – mehrere Standard-Rollen addieren sich für jeden rollenlosen internen Benutzer. Der richtige Weg ist die Benutzergruppen-Zuordnung bei der Rollenbearbeitung: Eine eigene Rolle (z. B. „WebArchiv-Anwender-Intern“ mit den Standard-Rechten plus Dashboard) anlegen und dort den tatsächlichen internen WinLine-Benutzergruppen des Betriebs zuordnen (nicht den Gruppen für Interessenten/Debitoren, die für Portalzugänge reserviert sind). Diese Rolle gilt dann automatisch für alle Mitglieder der zugeordneten Gruppen, zusätzlich zu eventuell bestehenden anderen Rollen.

Workflow-Berechtigungen

Der Zugriff auf Workflow-Funktionen kann über die Rollenverwaltung gesteuert werden:

• Verknüpfte Aufgaben anzeigen – Steuert, ob im Dokumentendetail verknüpfte Workflow-Aufgaben angezeigt werden.
• Meine Aufgaben – Steuert den Zugriff auf den Bereich „Meine Aufgaben“ in der Navigation.
• BelegPro in Aufgaben – Steuert, ob der BelegPro-Bereich (Rechnungsprüfung) in Aufgaben sichtbar ist. Nur für interne Benutzer – Portal-Geschäftspartnern lässt sich das Recht nicht zuweisen.
• Eingangsrechnungsprüfung – Zeigt in Aufgaben den Bereich Verknüpfte Belege und den Rechnungsabgleich: Bestellungen und Lieferscheine suchen, verknüpfen und lösen. Zusammen mit „Bestellung aus einer Aufgabe anlegen“ auch Bestellung und Lieferschein anlegen, samt Suche nach Artikel, Kostenstelle, Kostenträger und Konto. Unabhängig von „BelegPro in Aufgaben“ – der Rucksack und KI prüfen im Rechnungsabgleich bleiben an jenem Recht. Portal-Geschäftspartner sind davon immer ausgeschlossen.
• Rechnung vorbereiten – Den Rechnungsentwurf einer Aufgabe mit Buchungsweg ExIm bearbeiten und verwerfen (Dialog Rechnung vorbereiten); zum Ansehen genügt „Eingangsrechnungsprüfung“. Portal-Geschäftspartner sind davon immer ausgeschlossen.
• BelegPro-Art wechseln – Zusatzrecht zu „BelegPro in Aufgaben“. Erlaubt das Umstellen der BelegPro-Art (FIBU/FAKT/keine) und der Belegweiterverarbeitung einer offenen Aufgabe, einzeln und als Mehrfachauswahl. Prüfende ohne dieses Recht sehen die aktuelle Art, können sie aber nicht ändern. Portal-Geschäftspartner sind davon immer ausgeschlossen.
• Stammdaten anlegen – Erlaubt, aus Aufgabendetail und Dokumentdetail ein neues Personenkonto (Lieferant oder – je nach Dokumentenart – Kunde) oder einen Ansprechpartner in WinLine anzulegen. Portal-Geschäftspartner sind davon immer ausgeschlossen.
• Bestellung aus einer Aufgabe anlegen – Zusatzrecht zu „Eingangsrechnungsprüfung“ für die Bestell- und Lieferscheinanlage. Portal-Geschäftspartner sind davon immer ausgeschlossen.

Administratoren haben immer Zugriff auf alle Workflow-Funktionen. Für andere Benutzer müssen die Berechtigungen explizit über eine Rolle zugewiesen werden.

Bestandsinstallationen: Beim ersten Start nach dem Update erhalten alle Rollen, die „BelegPro in Aufgaben“ besitzen, automatisch „BelegPro-Art wechseln“ und „Eingangsrechnungsprüfung“, alle Rollen mit „Bestellung aus einer Aufgabe anlegen“ das Recht „Rechnung vorbereiten“ und alle Rollen mit „Dokumentenerkennung“ das Recht „Stammdaten anlegen“ – es geht keine Funktion verloren. Wer die Rechte trennen will (z. B. eine reine Prüfer-Rolle), nimmt sie in der Rollenverwaltung heraus.

Benutzerliste:

• Benutzer vorübergehend sperren oder entsperren (gilt auch für Portal-Benutzer)
• Zwei-Faktor-Einrichtung eines Benutzers zurücksetzen
• Zwei-Faktor-Authentifizierung als Pflicht festlegen (alternativ für ganze Benutzergruppen über die Rollen-Berechtigung Zwei-Faktor-Authentifizierung verpflichtend)
• Benutzer auf bestimmte Mandanten einschränken
• Bei Portal-Benutzern erscheint im Bearbeitungsdialog ein zusätzlicher Abschnitt mit Einschränkungen. Dokumentenarten können auf zwei Ebenen gefiltert werden: Erlaubte Formulare bestimmen, welche Anhangs-Dokumentenarten der Partner einsehen darf, während Erlaubte Upload-Dokumentenarten steuern, welche Dokumentenarten der Partner hochladen darf – unabhängig vom Sichtbarkeits-Filter. Weitere Einschränkungen: Zeitraum, Kennwort-Verwaltung und MFA-Pflicht

Administration delegieren

Einzelne Verwaltungsbereiche lassen sich über die Rollenverwaltung an Benutzer delegieren, ohne dass diese WinLine-Administrator sein müssen. WinLine-Administratoren haben davon unabhängig immer vollen Zugriff auf alle Bereiche.

Wer gilt als WinLine-Administrator? Nur wer in WinLine mindestens eines der Rechte Archiv-Administration, Benutzer-Administration oder System-Administrator besitzt. Andere WinLine-Administrationsrechte – etwa Formular-Administrator, Daten-Administration, CTK-Administrator oder Vorlagen bearbeiten – wirken sich auf MESO WebArchiv nicht aus: für diese Benutzer gilt ausschließlich ihre zugewiesene Rolle. Im Profil erscheint das Kennzeichen Admin entsprechend nur bei den drei erstgenannten Rechten.

Delegierbare Bereiche:

Bereich	Berechtigung	Umfasst
System	System	SMTP-Versand, Login-Logo, System-Status, Hintergrunddienste, Suchindex, Texterkennung nachträglich erzeugen, Feedback-Funktion, Sitzungsdauer
Mandanten	Mandanten-Verwaltung	Mandanten-Freischaltung und mandantenspezifische Einstellungen
KI	KI-Grundkonfiguration	Dokumentenerkennung, KI-Profile, Feld-Mapping, ExIm-Vorlagen
GMI	GMI-Konfiguration	GetMyInvoices-Anbindung
E-Rechnung	E-Rechnung-Einstellungen	E-Rechnung-XML-Profile
Verarbeitungsprotokoll	Verarbeitungsprotokoll	Verarbeitungsprotokoll und Dokumentenarten-Übersicht einsehen (nur lesend)
Feldprotokoll-Einsicht	Feldprotokoll einsehen	Feldprotokoll im Verarbeitungsprotokoll ansehen (nur lesend, zeigt Feldwerte aus Dokumentinhalten)
Feldprotokoll-Konfiguration	Feldprotokoll konfigurieren	Feldprotokoll-Erfassung (An/Aus, Dokumentenart-Whitelist) und Aufbewahrung festlegen
Partnerportal	Portalverwaltung	Partnerportal-Zugänge und -Konfiguration
Rollen	Rollenverwaltung	Rollen anlegen/bearbeiten, Berechtigungen zuweisen, Benutzer zu Rollen zuweisen
Audit-Einsicht	Audit-Log einsehen	Protokollierte Benutzeraktionen ansehen (nur lesend)
Audit-Konfiguration	Audit konfigurieren	Umfang (Ereignisarten, Dokumentenarten-Whitelist) und Aufbewahrung des Audit-Logs festlegen
Berechtigungsabgleich	Berechtigungsabgleich	Berechtigungsprofile von Artikeln, Personen- und Sachkonten (optional auch aus dem Arbeitnehmerstamm) auf zugeordnete Archivdokumente übertragen (Vorschau + Anwenden); die Vorschau zeigt dazu alle Dokumente des Mandanten unabhängig vom eigenen Berechtigungsprofil

Der Suchindex lässt sich zusätzlich feiner als über das Bereichsrecht System delegieren – siehe die zwei eigenständigen Rechte im Abschnitt Suchindex.

Die Berechtigung Rollenverwaltung lässt sich eigenständig vergeben, ohne volle Benutzerverwaltung (Sperren, Zwei-Faktor-Zurücksetzen, Mandanten-Einschränkung) mitzugeben – z. B. für jemanden, der nur Rollen pflegen und Benutzer zu Rollen zuweisen, aber keine Konten sperren oder MFA zurücksetzen darf. Volle Benutzerverwaltung schließt Rollenverwaltung weiterhin automatisch mit ein.

Vordefinierte Rollen:

Zwei fertige Admin-Rollen werden automatisch angelegt und müssen nur noch zugewiesen werden:

• WebArchiv-Administration – Wartung der Archiv-, Workflow- und KI-Einstellungen: Dokumentenarten & KI-Pipelines, KI-Profile, Workflow-Konfiguration, GMI, E-Rechnung, Mail-Postfächer inkl. Quarantäne, Verarbeitungsprotokoll, Mandanten-Einstellungen und Dashboard/Statistiken. Ohne Systemverwaltung.
• WebArchiv-Systemadministration – zusätzlich Systemverwaltung (SMTP, Logo, Texterkennung, Hintergrunddienste, Suchindex, Sitzungsdauer), Einsicht in aktive Sitzungen sowie Audit-Log-Einsicht und -Konfiguration.

Benutzer-, Rollen- und Portalverwaltung sind in beiden Rollen bewusst nicht enthalten – sie bleiben den WinLine-Administratoren vorbehalten, können aber über eine eigene Rolle delegiert werden.

Rolle mit delegierten Rechten anlegen (Schritt für Schritt):

1. Unter Verwaltung → Einstellungen → Benutzer & Rollen über + Rolle anlegen (bzw. Rollen verwalten) eine neue Rolle anlegen, z. B. „KI-Administrator“.
2. In der Berechtigungs-Kategorie Administration die gewünschten Bereiche aus der Tabelle oben aktivieren (z. B. KI + Verarbeitungsprotokoll für eine reine KI-Rolle).
3. Die Rolle einem Benutzer oder einer Benutzergruppe zuweisen.

Danach zeigt die Navigation dem zugewiesenen Benutzer automatisch nur die Bereiche, für die eine Berechtigung besteht – die übrigen Verwaltungsbereiche bleiben ausgeblendet. Mehrere delegierte Rollen können parallel bestehen, z. B. eine eigenständige „KI-Administrator“- und eine getrennte „GMI-Administrator“-Rolle.

Die Ersteinrichtung der delegierten Rollen erfolgt einmalig durch einen WinLine-Administrator. Danach kann der jeweilige Bereich selbstständig verwaltet werden, ohne dass ein WinLine-Administratorkennwort bekannt sein muss.

Partnerportal

Schnellzugriff für Portal-Benutzer. Die detaillierte Verwaltung (Einschränkungen, Kennwort, Sperren) erfolgt über die Benutzerverwaltung.

• Zugang anlegen: Über + Zugang anlegen einem WinLine-Konto (Debitor/Kreditor) einen Portalzugang mit E-Mail-Adresse und Kennwort zuweisen. Die Liste zeigt Kontonummer, Kontoname, Login, Anzeigename, Status und Einschränkungen.
• Mandantenbindung: Ein neu aktivierter Zugang gilt für den Mandanten des gewählten Kontos. Anlegen, Ändern, Sperren, Kennwort-Setzen, Rollen-Zuweisen und das Zurücksetzen der Zwei-Faktor-Anmeldung sind nur für Portalzugänge von Mandanten möglich, für die eine Berechtigung besteht – die Liste zeigt entsprechend nur diese Zugänge. Zugänge ohne Mandantenbindung lassen sich nur von uneingeschränkt berechtigten Anwendern verwalten. Belege und Dokumente zeigt das Portal einem solchen Zugang erst, wenn er einem Mandanten zugeordnet ist.
• Multi-Login: Pro Kontonummer können mehrere Portalzugänge angelegt werden (z. B. für verschiedene Ansprechpartner).
• Bearbeiten: Öffnet den Portal-Benutzer in der Benutzerverwaltung mit dem Portal-spezifischen Bearbeitungsbereich.
• Deaktivieren/Reaktivieren: Zugang vorübergehend deaktivieren oder wieder freigeben; Kennwort setzt ein neues Kennwort.

Portalbenutzer sehen nach der Anmeldung nur Dokumente, die ihrem Konto und den freigegebenen Dokumentenarten entsprechen.

Freigabe-Verwaltung (Workflow)

Workflow ist eine Kategorie unter Verwaltung → Einstellungen und in die Bereiche Aufgaben-Tab, Abschluss, Automatisierung und Buchungsvorlagen gegliedert; die KI-bezogenen Workflow-Einstellungen liegen in der Kategorie Erkennung & KI. Der Wechsel zwischen den Bereichen erfolgt wie in den übrigen Einstellungen über die linke Kategorie-Leiste, die sich über den Umschalter am unteren Ende auf eine Symbolspalte einklappen lässt. Ältere Lesezeichen auf die frühere eigenständige „Workflow-Administration“ (z. B. #/workflow-admin/abschluss) bleiben gültig und öffnen direkt den passenden Bereich.

• Relevante Workflows: Den Bereich Meine Aufgaben auf bestimmte Workflows oder Schritte einschränken. Ein Startschritt steht für den ganzen Workflow – dessen Fälle bleiben sichtbar, auch wenn sie in Folgeschritte weiterlaufen. Jeder andere Schritt lässt nur Fälle durch, die gerade dort stehen. Angehakte Schritte gelten sofort, ohne OK im Aufklappfeld; gespeichert wird mit Speichern. Leer = keine Einschränkung.

• WinLine-Filter (Vorgabe): Ein in WinLine definierter Filter (Filter-Assistent) als Standard für den Aufgaben-Tab aller Benutzer – global sowie optional als Override je Workflow. Der Override-Wert „kein Filter“ lässt einen Workflow bewusst ungefiltert, auch wenn eine globale Vorgabe existiert. Zur Auswahl stehen nur globale (nicht persönliche) Filter; eine eigene Auswahl des Benutzers im Aufgaben-Filter-Dialog übersteuert die Vorgabe vollständig, inklusive deren Sortierung.

• Nur Fälle mit Archiveinträgen anzeigen: Vorgabe für das Kontrollkästchen Nur mit Archiv unter Meine Aufgaben; Benutzer können sie dort für sich überschreiben.

• Nur zuständige Aufgaben anzeigen: Steuert pro Mandant, welche Fälle unter Meine Aufgaben erscheinen (Standard: aktiv). Aktiv zeigt nur direkt an den Benutzer oder eine seiner Benutzergruppen delegierte Fälle; deaktiviert erscheinen zusätzlich undelegierte Fälle, deren Bearbeiter der Benutzer ist.

• Abschluss-Schritte: Festlegen, welche Schritte einen Vorgang abschließen.

• Ausschluss-Begriffe: Begriffe, die bei der automatischen Zuordnung ignoriert werden.

• Schnellaktionen (Mobilansicht): Allgemeine Zuordnung der Schritte für Freigabe, Rückfrage, Ablehnung und Sichtung in der vereinfachten Mobilansicht. Die konfigurierten Schnellaktionen werden im Aufgaben-Bereich (Mobilkarte, Karussell, Mehrfachauswahl) nur angezeigt, wenn der jeweilige Schritt laut Workflow-Definition vom aktuellen Stand des Falls aus zulässig ist. Über die Option „Schnellaktionen immer anzeigen“ kann diese Prüfung pro Mandant deaktiviert werden – die Schaltflächen erscheinen dann unabhängig von der Workflow-Definition.

• Workflow-spezifische Zuordnungen (Schnellaktionen, Rechnungsprüfung): Eigene Karte unterhalb von „Schnellaktionen (Mobilansicht)“ – über Workflow-Zuordnung hinzufügen legen Sie einen Eintrag je Workflow an (erkannt am Startschritt des Workflows). Eine Zuordnung überschreibt die allgemeine Schnellaktions-Zuordnung für diesen Workflow; leer gelassene Felder fallen auf die allgemeine Zuordnung bzw. den Standard zurück. Im unteren Abschnitt „Rechnungsprüfung“ des Eintrags stehen Buchungsweg, Bestellpflicht, „Keine Rechnungsprüfung“ und die Vorlagen.

  • Buchungsweg der Rechnung: nicht klassifiziert (Verhalten wie bisher), Beleg Pro, ExIm oder manuell in WinLine. Bei ExIm und manuell steuert der Schalter Bestellpflicht, ob eine Rechnung nur zu einem Lieferschein entstehen darf (Standard: an). Optional trägt die Zuordnung eigene WinLine-Vorlagen für Rechnung, Bestellung und Lieferschein – leer gelassen gilt die Vorlage des Mandanten (Bereich Automatisierung, Karte „ExIm-Vorlagen“). Nach dem Speichern prüft WebArchiv den Freigabe-Schritt des Workflows: Löst er beim Buchungsweg ExIm zusätzlich einen Beleg-Pro-Import aus, erscheint eine Warnung (die Workflow-Aktion am Freigabe-Schritt in WinLine entfernen); fehlt beim Buchungsweg Beleg Pro die Import-Aktion, ein Hinweis. Ebenso meldet WebArchiv dort eine eingetragene Vorlage, die es in WinLine nicht als Beleg-Vorlage mit WebService-Schema gibt – sonst fiele ein Tippfehler erst bei der Anlage auf. Beim Buchungsweg ExIm bereitet der Anwender die Rechnung in der Aufgabe vor, die Freigabe bucht sie (Rechnung vorbereiten).
  • Keine Rechnungsprüfung: Für Workflows mit Ausgangsrechnungen oder Gutschriften. In der Aufgabe entfallen Rechnungsabgleich, Positionszuordnung, Bestellvorschlag sowie Bestell-, Lieferschein- und Rechnungsanlage; verknüpfte Belege bleiben sichtbar. Ein gespeicherter Buchungsweg wird ignoriert. Auch ohne diesen Schalter entfallen Rechnungsabgleich und Einkaufskette, wenn nur Verkaufsbelege verknüpft sind oder – ohne verknüpften Beleg – der Geschäftspartner ein Kunde ist; ein verknüpfter Einkaufsbeleg zeigt sie immer.
  • Workflow umklassifizieren, während Aufgaben laufen: Buchungsweg, Bestellpflicht und „Keine Rechnungsprüfung“ gelten sofort für alle offenen Aufgaben dieses Workflows – auch für eine bereits vorbereitete oder fehlgeschlagene Rechnung. Der gespeicherte Rechnungsentwurf bleibt zwar in der Datenbank erhalten, ist danach aber nicht mehr sichtbar und wird nicht mehr gebucht; die Freigabe schreibt dann nur noch den Folgeschritt, ohne eine Rechnung zu buchen. Einen Workflow deshalb nur umstellen, solange keine Aufgaben dieses Workflows offen sind.

  

• Fallanlage-Einstellung: Festlegen, bei welcher Dokumentenart nach dem Archivieren automatisch ein Freigabefall angelegt wird.

• „Rechnung eingetroffen“-Schritt: Workflow-Schritt, den der Pipeline-Schritt Vorgang-Suche bei einer erfolgreichen Bestell-Zuordnung am bestehenden Fall schreibt (sofern im Pipeline-Schritt keine eigene Workflow-Nummer hinterlegt ist). Leer = keine automatische Bestell-Zuordnung, es wird regulär ein neuer Fall angelegt.

• Einstellungen übernehmen: Im Aufgaben-Tab kann ein Administrator die Einstellungen ausgewählter Bereiche (Schnellaktionen, Delegation, Fall-Auswahl inkl. Abschluss-/Ausschluss-Listen, Formulare & Vorlagen, Bestellung/KI, KI-Extraktion/Dokumentenarten, E-Rechnung) von einem anderen Mandanten in den aktuellen Mandanten übernehmen. Dazu Quell-Mandant und gewünschte Bereiche wählen und bestätigen – die bestehenden Werte dieser Bereiche im aktuellen Mandanten werden dabei überschrieben. Praktisch bei der Einrichtung eines neuen oder ähnlich konfigurierten Mandanten, um nicht jede Einstellung erneut von Hand pflegen zu müssen.

KI-Prüfung konfigurieren

Verwaltung → Einstellungen → Workflow → Automatisierung, Karte KI-Prüfung. Die Prüfung hat drei Achsen:

Achse	Bedeutung	Auswahl
Prüfgegenstand	Was geprüft wird	Datenblöcke: Dokumenttext, BelegPro-Rucksack, Erkennungsfelder, E-Rechnungs-XML, Vorbelege — dazu ein freier Text mit Platzhaltern ({Mail.Betreff}, {KiBeschreibung}, {Vorgang.Bestellnummer})
Vergleichsgrundlage	Wogegen geprüft wird	dieselben Blöcke; bei „Vorbelege“ zusätzlich die Belegstufen (leer = alle). Leer = reine Plausibilitätsprüfung
Prüfauftrag	Nach welchen Regeln	Freitext mit den Variablen {Toleranz.RundungEuro}, {Toleranz.PruefenAbProzent}, {Toleranz.AblehnenAbProzent}; leer = eingebauter Standard („Standard-Auftrag einsetzen“ zeigt ihn)

Dazu Toleranzen (Rundungstoleranz in Euro, Prüf- und Ablehnschwelle in Prozent), das Token-Limit und optional ein LLM-Profil (leer = Profil des KI-Assistenten; ein E-Rechnungs-XML braucht kein Bild-Modell, ein Scan vielleicht ein stärkeres). Das Token-Limit steht auf 800. Reasoning-Modelle verbrauchen einen Teil davon für ihre Überlegung und brauchen eher 2.000 bis 4.000; bricht das Modell am Limit ab, nennt das Ergebnis genau das als Grund. Die Profilauswahl braucht das Recht admin.ki – ohne dieses Recht zeigt der Editor nur, welches Profil gilt, statt einer Auswahlliste. Ein gespeicherter Datenblock oder eine Belegstufe, die dem aktuellen Katalog nicht mehr bekannt ist, bleibt im Editor als angehakter Eintrag mit dem Zusatz „(nicht im Katalog)“ sichtbar und wird beim Speichern nicht entfernt.

Vorgabe und Workflow: Die Vorgabe gilt für alle Workflows des Mandanten. „Workflow hinzufügen“ legt eine Abweichung für einen Startschritt an (z.B. Rechnungseingang anders als Gutschrift). Ein Workflow-Eintrag ersetzt die Vorgabe vollständig — es gibt keine Feld-Vererbung, damit im Editor immer sichtbar ist, was gilt. Ohne Vorgabe und ohne Workflow-Eintrag gilt der eingebaute Standard: Erkennungsfelder, Rucksack und Dokumenttext gegen die verknüpften Angebote, Bestellungen und Lieferscheine mit den Toleranzen 0,05 € Rundung und 5 % Ablehnung. Die gebuchte Rechnung selbst gehört nicht zur Vergleichsgrundlage – sie hängt nach dem Buchen ebenfalls am Fall und würde sonst mit sich selbst verglichen.

Beispiele (nur Konfiguration, kein neuer Baustein):

• Rechnung gegen Bestellung und Lieferschein — der Standard.
• Auftragsbestätigung gegen Bestellung — Prüfgegenstand Erkennungsfelder + Dokumenttext, Vergleichsgrundlage Vorbelege mit Belegstufe „Bestellung“.
• Mail-Text gegen Anhang — Prüfgegenstand Text Absender: {Mail.Absender} / Betreff: {Mail.Betreff} / {Mail.Body}, Vergleichsgrundlage Dokumenttext.

Die Einstellungen sind mandantenspezifisch und werden mit dem Bereich „Bestellung / KI“ zwischen Mandanten kopiert.

KI-Prüfung in der Pipeline

Der Pipeline-Schritt KI-Prüfung (Verwaltung → Einstellungen → Erkennung & KI → Dokumentenerkennung → Pipeline der Dokumentenart) führt dieselbe Prüfung automatisch bei der Verarbeitung aus. Die Konfiguration mit denselben drei Achsen steht direkt am Schritt (leer = eingebauter Standard); Vorgabe und Workflow-Einträge gelten nur für den Button. Das Ergebnis steht als Pool-Felder bereit: KiPruefung.Empfehlung (ok, pruefen, ablehnen), KiPruefung.Begruendung, KiPruefung.Details, KiPruefung.Zusammenfassung (fertiger Text für eine Bemerkung) und KiPruefung.Gekuerzt; bei mehreren Instanzen zusätzlich {Instanzname}.Empfehlung usw. Jedes Ergebnis wird am Fall abgelegt und im Rechnungsabgleich als letzte Prüfung angezeigt.

Damit lässt sich eine Rechnungspipeline verzweigen:

Schritt	Instanz	Bedingung	Wirkung
Vorgang-Suche → Bestellpositionen zuordnen → Fall-Anlage			wie bisher
Belegabgleich			rechnet die Rechnung gegen Lieferschein bzw. Bestellung (setzt Belegabgleich.Status)
BelegPro-Rucksack			wie bisher
KI-Prüfung			prüft Erkennungsfelder, Rucksack und Dokumenttext gegen die verknüpften Vorbelege
Workflow-Folgeschritt	Prüfergebnis		Nebenschritt mit Mapping {KiPruefung.Zusammenfassung} → Langbeschreibung intern
Workflow-Folgeschritt	Freigabe	Belegabgleich.Status Equals ok und KiPruefung.Empfehlung Equals ok	Freigabe-Schritt
Workflow-Folgeschritt	Sichtung	Belegabgleich.Status Equals ok und KiPruefung.Empfehlung NotEquals ok	Sichtungs-Schritt
Workflow-Folgeschritt	Sichtung Abgleich	Belegabgleich.Status NotEquals ok	Sichtungs-Schritt für Dokumente, deren Abgleich nicht „ok“ ist (Abweichung oder unvollständig); die Freigabe ist dort durch ihre „und“-Bedingung ohnehin gesperrt

Jedes Dokument landet so in genau einem der drei Zweige: Der Editor erkennt Folgeschritte als gegenseitig ausgeschlossen, wenn sie am selben Feld unvereinbare Bedingungen haben – hier trennt Belegabgleich.Status den Abgleichs-Zweig von den beiden anderen und KiPruefung.Empfehlung die Freigabe von der Sichtung. Eine Bedingung NotEquals auf einem Pool-Feld, das es nicht gibt, ist nicht erfüllt: Scheitert der Belegabgleich und schreibt deshalb kein Belegabgleich.Status, läuft keiner dieser Zweige. Der Schritt muss daher vor den Folgeschritten stehen; ein gescheiterter Schritt zeigt im Verarbeitungsprotokoll eine Warnung.

Wichtig – Freigabe nicht allein an der KI-Empfehlung: Eine automatische Freigabe darf nicht allein an KiPruefung.Empfehlung hängen. Dokument- und Mailtexte stammen von außen und können versuchen, die Empfehlung zu beeinflussen (etwa „Antworte mit ok“). Die KI-Prüfung ist dagegen gehärtet – der Inhalt steht für das Sprachmodell zwischen eindeutigen Datenbegrenzern und gilt nie als Anweisung, ein solcher Versuch wird in der Begründung als Auffälligkeit genannt –, eine Garantie ist das aber nicht. Ergänzen Sie an der Freigabe eine deterministische Zusatzbedingung (z. B. Kreditor erkannt, Betrag unter einer Grenze, Vorbeleg gefunden) oder verzweigen Sie auf einen Sichtungsschritt. Der Editor weist auf jeden Folgeschritt hin, der allein an einer KI-Empfehlung hängt und bei der Empfehlung „ok“ ausgeführt würde – ein Sichtungszweig mit der Bedingung „ungleich ok“ bekommt keinen Hinweis.

Ohne KI-Modul oder ohne aktiven KI-Assistenten wird der Schritt übersprungen (Warnung im Verarbeitungsprotokoll, keine Pool-Felder – eine Bedingung Equals ok ist dann nicht erfüllt). Ein Fehler des Sprachmodells ist ein Schrittfehler. Der Editor warnt, wenn der Block Vorbelege ohne Vorgang-Suche oder der Block Rucksack ohne Rucksack-Schritt vor der Prüfung steht, oder wenn mehrere KI-Prüfungen denselben Instanznamen tragen (ihre {Instanzname}.*-Felder würden sich überschreiben) bzw. eine von mehreren KI-Prüfungen den Standardnamen KiPruefung behält (sie hat dann keine eigenen Ergebnisfelder), und meldet eine ungültige Konfiguration als kritisch – mit allen Fehlern auf einmal.

Workflow-Folgeschritt mehrfach mit Feld-Mapping: Der Folgeschritt darf mehrmals in einer Pipeline stehen, jede Instanz mit eigenen Bedingungen und einem eigenen Feld-Mapping (Feld-Mapping bearbeiten am Schritt) auf die Felder der CRM-Vorlage – Kurzbeschreibung, Bemerkung, Kostenträger usw. Standard-Mapping laden schlägt die Zusammenfassung der KI-Prüfung als Bemerkung vor. Fall-Id und Schrittnummer setzt der Schritt selbst; ein Mapping auf diese Felder wird verworfen. Beim Umbenennen der Instanz zieht das Mapping mit; ein Name, den bereits eine andere Instanz desselben Schritts trägt, wird abgelehnt (zwei gleichnamige Instanzen teilten sich sonst ein Mapping – auch darauf weist der Editor hin). Ein Wert ohne passendes Feld in der Vorlage wird von WinLine verworfen und im Verarbeitungsprotokoll als Warnung genannt. Treffen zwei Instanzen gleichzeitig zu, schreiben sie nacheinander je einen Schritt – der Editor warnt beim Speichern. Pipeline kopieren nimmt die Instanz-Mappings der kopierten Schritte mit; Override löschen im Feld-Mapping der Dokumentenart leert nur die übrigen Zuordnungen, die Instanz-Mappings der Folgeschritte bleiben erhalten. Gehört ein Instanz-Mapping zu keinem Schritt mehr (Schritt außerhalb des Editors umbenannt oder entfernt, etwa über einen Entwurf des KI-Assistenten), nennt der Editor es als verwaist.

Löschschritt je Workflow

Verwaltung → Einstellungen → Workflow → Automatisierung, Karte Löschschritt je Workflow. Je Workflow lässt sich ein Nebenschritt hinterlegen, der in WinLine die Folgeaktion Fall löschen trägt. Der Eintrag legt fest, über welchen Schritt Administratoren Fälle löschen können, und lässt die Sammelaktion in der Board-Ansicht vor diesem Schritt nachfragen.

WinLine löscht den Fall bei jedem Schritt mit der Folgeaktion Fall löschen – auch ohne Eintrag hier; WebArchiv löst danach in jedem Fall die Verweise auf Analyse, KI-Prüfungen, Verarbeitungsprotokoll und Rechnungsentwürfe, damit ein neuer Fall gleicher Nummer nichts erbt. Das Protokoll nennt danach „Fall n (gelöscht)“. Die Archivdokumente bleiben erhalten.

Der Eintrag gilt je Mandant und wird mit „Einstellungen übernehmen“ nicht kopiert (Schrittnummern unterscheiden sich je Mandant) – im Ziel-Mandanten neu eintragen. Verwaiste Fall-Verweise prüfen zeigt Verweise auf Fälle, die direkt in WinLine gelöscht wurden, und bereinigt sie auf Wunsch (höchstens 500 Fälle je Durchgang).

Dokumentenerkennung einrichten

Konfiguration der automatischen Dokumentenanalyse unter Verwaltung → Einstellungen → Erkennung & KI → Dokumentenerkennung, Abschnitt Dokumenten-KI:

• Erkennungs-Provider: Legt fest, welcher Dienst ein Dokument liest. OCR-Provider bestimmt, wie der Text gewonnen wird: Auto (Vorgabe) wählt je Dokument – Office-, Mail- und Textdateien direkt, digitale PDFs über ihre Textebene, Scans lokal per Tesseract (falls installiert), sonst über Azure; DirectText liest lokal nur die Textebene digitaler PDFs; Tesseract erkennt zusätzlich Scans lokal, ohne Kosten je Seite; Azure Document Intelligence erkennt Text in der Cloud und ist bei schlechten Scans, Fotos und Handschrift am stärksten. Extraktions-Provider bestimmt, wer die Felder erkennt (Azure Document Intelligence, LLM oder Dokumentmodell (Vision), Einsatzzwecke siehe Dokumentenerkennung). Azure und das Dokumentmodell lesen das Dokument selbst – die OCR-Einstellung wirkt dann nur für Dokumentenarten, deren Extraktion auf LLM umgestellt ist. Unter beiden Auswahllisten steht der Einsatzzweck der gewählten Option. Beides ist der Standard für die gesamte Installation und lässt sich je Dokumentenart im Pipeline-Editor überschreiben – dort zeigt die Auswahlliste in Klammern, welcher Provider bei „Global“ gilt. Felder ohne Wirkung für den gewählten Extraktions-Provider sperrt der Editor als „nicht verwendet“ (OCR-Provider bei Azure und Dokumentmodell, Azure-Modell bei allem außer Azure); das LLM-Profil bleibt wählbar, weil es auch für die KI-Schritte der Dokumentenart gilt. Welcher Provider für ein einzelnes Dokument tatsächlich gelaufen ist, steht im Verarbeitungsprotokoll im Schritt Extraktion.

• Azure Document Intelligence: Endpunkt und API-Key der Azure-Ressource (Einrichtung der Ressource: Installationsanleitung).

• Standard-Modell: Voreingestelltes Erkennungsmodell (z. B. prebuilt-invoice für Rechnungen oder ein eigenes Modell).

• KI-Profile: Konfigurierbare LLM-Provider (OpenAI, Azure OpenAI, Ollama u. a.) mit Modellauswahl und Fallback-Logik – die zentrale und einzige Ablage aller KI-Zugangsdaten; KI-Assistent und Chat-KI wählen nur noch ein Profil statt eigener Zugangsdaten-Felder. Bei Fehler oder unzureichender Konfidenz kann automatisch auf ein alternatives Profil zurückgefallen werden. Die API-Schlüssel der Profile werden verschlüsselt gespeichert und nie wieder angezeigt; ein bestehender Schlüssel bleibt beim Bearbeiten erhalten, solange nichts Neues eingegeben wird. Die Markierung „API-Key neu hinterlegen“ an einem Profil bedeutet, dass der gespeicherte Schlüssel nicht mehr entschlüsselt werden konnte und einmalig neu einzugeben ist. Mit „Verbindung testen“ im Bearbeiten-Dialog lässt sich ein Profil sofort prüfen: Der Test sendet eine minimale Anfrage an den Anbieter und meldet Erfolg mit Laufzeit oder dessen Fehlermeldung – auch für ein noch nicht gespeichertes Profil, sodass Tippfehler in Endpunkt, Modellname oder Schlüssel nicht erst beim nächsten Analyselauf auffallen. Der gespeicherte Schlüssel wird dabei nur ergänzt, solange Anbieter und Endpunkt unverändert sind; bei geänderter Verbindung ist er einzutragen – dieselbe Regel gilt beim Speichern eines Profils. Der Test ist auf zehn Aufrufe je Minute und Absender-Adresse begrenzt und wird im Audit-Protokoll vermerkt. Mit „Temperatur nicht senden“ wird die Temperatur für dieses Profil gar nicht übermittelt – nötig bei Modellen der GPT-5-Generation, die nur ihren Vorgabewert akzeptieren. Über das Feld „Token-Limit-Feld“ wird eingestellt, wie das Token-Limit im Aufruf heißt: max_tokens (Vorbelegung, bis zur GPT-4-Generation) oder max_completion_tokens (ab der GPT-5-Generation, die max_tokens ablehnt). Scheitert der Verbindungstest daran, nennt die Meldung das Feld und den richtigen Wert.

• WinLine-Benutzer: Wird beim Anlegen von Freigabefällen verwendet – und als anlegender Benutzer, wenn die Pipeline Stammdaten neu anlegt.

• ExIm-Vorlagen je Konto-Art: Globale WinLine-Vorlagen für die automatische Stammdaten-Neuanlage – je ein Slot für Kreditor (Lieferant), Debitor (Kunde), Interessent, Anfragelieferant und Ansprechpartner. Die gewählte Personenkonto-Vorlage setzt das Kontenstamm-Kennzeichen der Konto-Art; deshalb gibt es bewusst keinen Rückgriff auf die Vorlage einer anderen Konto-Art. Pro Pipeline-Schritt kann eine abweichende Import-Vorlage gewählt werden. Bereits hinterlegte Vorlagen aus früheren Programmversionen (Kreditor, Debitor, Ansprechpartner) bleiben erhalten und werden in den neuen Slots angezeigt. Die Vorlagen müssen in WinLine unter ExIm → Importvorlagen angelegt und freigegeben sein; der konfigurierte WinLine-Benutzer braucht dort Schreibzugriff.

• Einstellung je Dokumentenart: Für jede Dokumentenart kann das Modell und die Folgeaktion festgelegt werden:

  • Nur Erkennung: Felder werden erkannt und angezeigt.
  • Finanzbuchhaltung: Nach Bestätigung wird ein Buchungsfall angelegt.
  • Fakturierung: Nach Bestätigung wird ein Belegfall angelegt.

  Ist für die Dokumentenart bereits eine Pipeline mit Schritten hinterlegt, steuern allein diese Schritte die Verarbeitung. Die Spalte Aktion zeigt dann „Pipeline (n Schritte) – im Pipeline-Editor verwalten“ und lässt sich nicht mehr ändern: Sie hätte dort keine Wirkung. Abschalten oder Ändern erfolgt im Pipeline-Editor, indem Schritte deaktiviert oder entfernt werden.

• KI-Buchungstext: Automatische Erzeugung eines Buchungstexts per KI mit konfigurierbarem Textstil.

• KI-Rückfall bei schwacher Erkennung: Rückfall aktiv schaltet ihn ein – ab Werk ist er aus, weil er je betroffenem Dokument einen zusätzlichen KI-Aufruf kostet; ohne den Schalter sind Schwelle und Pflichtfelder wirkungslos. Liefert der Erkennungs-Provider eine Gesamt-Konfidenz unter der Konfidenz-Schwelle (Standard 0,6; 0 schaltet den Auslöser ab) oder fehlt eines der ausgewählten Pflichtfelder (Rechnungsnummer, LieferantName, GesamtbetragBrutto, Belegdatum; leer = Prüfung aus), läuft das Sprachmodell als zweiter Durchgang nach und ergänzt nur die fehlenden Felder – bereits erkannte Werte bleiben unangetastet. Bewertet wird dabei nicht die Konfidenz des Providers allein, sondern eine Plausibilitätsprüfung des Ergebnisses gegen den erkannten Text (Beträge, IBAN-Prüfziffer, Datumsfolge); die Basis unterscheidet sich daher je Dokumentenart und Provider – den Wert am besten am Verarbeitungsprotokoll echter Belege ausrichten. Optional ein eigenes KI-Profil für den Rückfall; ohne Auswahl gilt das reguläre Extraktions-Profil der Dokumentenart. Der zweite Durchgang nutzt bewusst den regulären Extraktions-Prompt statt eines eigenen Freitext-Prompts, damit Steuer- und Positionsdaten wie gewohnt weiterverarbeitet werden. Im Verarbeitungsprotokoll erscheint der Rückfall als Zusatz „+LLM (schwache Konfidenz)“ an der Provider-Angabe, der Schritt Extraktion nennt dort die ergänzten Felder; unter Verwaltung → Betrieb → KI-Jobs & Verbrauch steht der zusätzliche Aufruf mit dem Zweck „Rückfall bei schwacher Konfidenz“.

• Semantisches Artikel-Matching: Zugänge für eine zusätzliche Zuordnungsstufe der Stammdaten-Suche (Typ Artikel). Sie findet Artikel auch dann, wenn die Bezeichnung auf dem Beleg anders formuliert ist als im Artikelstamm („Sechskantschraube M8 × 40 verzinkt“ ↔ „Schraube 6-kt M8x40 galv. verzinkt“): Kandidaten werden über Embedding-Ähnlichkeit gesucht und optional von einem Sprachmodell nachbewertet. Einzutragen sind Embedding-Endpunkt (Basis-URL eines OpenAI-kompatiblen Dienstes, z. B. https://api.openai.com/v1), Embedding-Schlüssel, Embedding-Modell (z. B. text-embedding-3-small) und optional ein KI-Profil für die Nachbewertung; Azure-OpenAI-Profile stehen dafür nicht zur Verfügung. Der Schlüssel wird verschlüsselt gespeichert und nie wieder angezeigt – ein leer gelassenes Feld behält den gespeicherten Wert. Die Einstellung gilt installationsweit, nicht je Mandant. Eingeschaltet wird die Stufe je Pipeline-Schritt über den Parameter Semantisches Matching am Schritt Stammdaten-Suche; fehlen die Zugänge, läuft die Zuordnung ohne Semantik weiter und der Schritt meldet eine Warnung im Verarbeitungsprotokoll.

• Laufende Analysen (unter Verwaltung → Betrieb → KI-Jobs & Verbrauch): Übersicht aller aktuell laufenden oder fehlgeschlagenen Erkennungs-Aufträge mit Fehlgeschlagene neu starten; darunter die Token-Auswertung (Zeitraum wählen, Auswerten).

Welches KI-Modell für welchen Zweck?

Ein Modell für alles ist entweder zu teuer oder zu ungenau. MESO WebArchiv ruft die KI an Stellen mit sehr unterschiedlichen Ansprüchen – vom Auslesen eines Rechnungsbetrags bis zum Vorschlag eines Buchungstexts. Deshalb lässt sich jedem Pipeline-Schritt ein eigenes KI-Profil zuordnen. Die Auflösung erfolgt in dieser Reihenfolge: Pipeline-Schritt vor Dokumentenart vor globalem Standardprofil. Genauigkeit muss also nur dort bezahlt werden, wo Fehler wehtun.

Zuerst die Datenfrage, dann die Modellfrage. Wo die Dokumente verarbeitet werden dürfen, schränkt die Auswahl stärker ein als jedes technische Kriterium:

Betriebsart	Was das bedeutet	Geeignet für
Eigener Cloud-Mandant (Azure OpenAI / Microsoft Foundry)	Verarbeitung im eigenen Abonnement, Region und Aufbewahrung selbst gewählt	Der Normalfall für die meisten Betriebe
Direkt beim Anbieter (OpenAI, Anthropic, Mistral, IONOS u. a.)	Schnell eingerichtet, Verarbeitung in der Infrastruktur des Anbieters	Erprobung, kleine Installationen
Im eigenen Haus (Ollama)	Das Dokument verlässt das Netz nicht	Strenge Datenschutz-Vorgaben – bei deutlich schwächerer Belegerkennung und eigener GPU-Hardware

Bei Cloud-Angeboten zusätzlich prüfen, in welcher Region verarbeitet wird: bei Azure unterscheiden sich die Bereitstellungsarten „Global Standard“, „Data Zone“ und regionale Bereitstellung genau darin. Das ist eine Datenschutz-Entscheidung, keine technische.

Drei Modellklassen genügen zur Orientierung. Die Anbieter benennen ihre Modelle unterschiedlich, aber jedes lässt sich einer dieser Klassen zuordnen – meist über den Preis:

Klasse	Erkennbar an	Stärke	Schwäche
Klein	Zusatz wie „mini“, „nano“, „flash“, „haiku“; günstigster Preis	Schnell und billig, ausreichend für kurze Entscheidungen	Übersieht Ungewöhnliches, verwechselt ähnliche Felder
Mittel	Das Standardmodell der jeweiligen Generation	Bester Kompromiss aus Genauigkeit und Preis	–
Groß	Zusatz wie „opus“, „pro“; teuerstes Modell, oft mit Reasoning	Belastbar bei Abwägungen und langen Belegen	Teuer und langsam; bei einfachen Aufgaben kein Mehrwert

Welche Aufgabe welche Klasse braucht:

Aufgabe im WebArchiv	Klasse	Warum
Belegfelder erkennen (Extraktion)	Mittel	Ein falscher Betrag oder eine falsche Rechnungsnummer landet in der Buchhaltung
Dokumentenart, Belegkategorie, Buchungstext, Schlagworte	Klein	Kurze Entscheidung aus wenig Text; ein Fehler ist im Dialog sofort sichtbar und korrigierbar
Gegenkonto ermitteln, KI-Prüfung	Mittel bis groß	Abwägung mit Vorwissen (Kontenhistorie, Bestellung) statt bloßem Ablesen; das Modell ist je Prüfung in der Konfiguration wählbar
KI-Chat und KI-Assistent	Mittel	Muss Werkzeuge aufrufen und mehrschrittig arbeiten
KI-Beschreibung (Zusammenfassung für die Suche)	Klein	Dient dem Volltextindex, nicht der Buchung

Vier Fragen, die ein Modell ausschließen – in dieser Reihenfolge zu prüfen, weil jede folgende nur bei bestandener vorheriger sinnvoll ist:

1. Spricht es das Chat-Format? Nur Modelle mit einer Chat-Schnittstelle (chat/completions bzw. /v1/messages) sind verwendbar. Reine Vervollständigungs-, Bild- und Embedding-Modelle nicht – sie erscheinen im Modellkatalog der Anbieter gleichberechtigt daneben.
2. Kann es Werkzeuge aufrufen? Pflicht für den KI-Chat. Ohne Werkzeug-Unterstützung antwortet das Modell, kann aber nicht im Archiv suchen.
3. Akzeptiert es die Profil-Einstellungen? Modelle der GPT-5-Generation lehnen das Feld max_tokens und eine eingestellte Temperatur ab. Dafür gibt es im Profil die Schalter „Token-Limit-Feld“ und „Temperatur nicht senden“ (siehe Dokumentenerkennung einrichten). Der Verbindungstest nennt in diesem Fall Feld und richtigen Wert.
4. Denkt es vor der Antwort? Denkmodelle wie qwen3.5 über Ollama überlegen vor jeder Antwort und verbrauchen dabei das Token-Budget – im Extremfall minutenlang, ohne zu antworten. Die Einstellung „Denkstufe“ im Profil begrenzt das: none schaltet das Nachdenken ab, low bis max erlauben mehr. Leer entscheidet das Modell. Die Stufe gilt für jeden Aufruf mit dem Profil, auch für die Nachbewertung im Artikel-Matching.

Was das kostet. Abgerechnet wird nach Token – grob vier Zeichen je Token; eine Rechnungsseite ergibt etwa 1.500 bis 3.000 Token Eingabe. Eingabe und Ausgabe werden getrennt berechnet, Ausgabe ist mehrfach teurer.

Klasse	Je Beleg	1.000 Belege im Monat
Klein	Unter 1 Cent	Wenige Euro
Mittel	2 bis 5 Cent	20 bis 50 €
Groß	10 bis 30 Cent	100 bis 300 €

Das sind Größenordnungen, keine Zusagen – die Anbieterpreise ändern sich mehrmals im Jahr. Werden im Profil die Preise je Million Token eingetragen, weist das Verarbeitungsprotokoll die tatsächlichen Kosten je Lauf aus.

Empfehlung für den Start: zwei Profile.

• „Genau“ (mittlere Klasse) als Standardprofil – für Extraktion, Gegenkonto, KI-Prüfung und Chat.
• „Günstig“ (kleine Klasse) – den Pipeline-Schritten für Klassifizierung, Belegkategorie, Buchungstext, Schlagworte und KI-Beschreibung zugeordnet.

Ein einzelnes Profil für alles funktioniert ebenfalls; es kostet dann nur mehr oder erkennt schlechter. Später lässt sich gezielt verschieben, wo die Auswertung es nahelegt.

Prüfen statt vermuten – nach jeder Profiländerung:

1. Verbindung testen im Profil-Dialog. Meldet der Anbieter einen Fehler, steht dessen Text unverändert da.

2. Testlauf an einem echten Beleg im Pipeline-Editor – er zeigt die erkannten Felder, ohne etwas zu archivieren oder zu buchen.

3. Nach etwa 20 Dokumenten die Token-Auswertung unter Verwaltung → Betrieb → KI-Jobs & Verbrauch ansehen (Von/Bis wählen, Auswerten). Erst dort zeigt sich, ob die kleine Klasse für einen Schritt genügt – die Spalte Zweck trennt dabei die Aufrufe nach Verwendung.

   

Warum hier keine Modellnamen stehen: Die Anbieter veröffentlichen mehrmals im Jahr neue Modelle und stellen ältere ab. Eine Liste konkreter Namen wäre binnen Monaten irreführend, die Einteilung in Klassen und die drei Prüffragen bleiben gültig. Als Momentaufnahme (Stand August 2026): klein sind etwa gpt-5.4-mini oder claude-haiku-4-5, mittel gpt-5.6 oder claude-sonnet-5, groß claude-opus-5. Maßgeblich ist immer der aktuelle Modellkatalog des jeweiligen Anbieters.

Pipeline-Konfiguration

Die Pipeline-Konfiguration erlaubt es, die KI-Analyse-Schritte pro Dokumentenart individuell zusammenzustellen. Der visuelle Editor befindet sich unter Verwaltung → Einstellungen → Dokumentenarten.

Bedienung:

1. Die Übersicht listet alle in WinLine definierten Dokumentenarten mit ihrem Pipeline-Status auf – auch solche, für die im Mandanten noch kein Dokument archiviert wurde (Beleg-Anzahl 0). Ein Klick auf eine Zeile öffnet die Detailseite mit deren Pipeline. Über Neue Dokumentenart können Sie eine neue Konfiguration anlegen; Aktualisieren lädt die Liste unter Umgehung des Zwischenspeichers neu, sodass eine soeben in WinLine angelegte Dokumentenart sofort erscheint. Die Kopfzeile der Detailseite bietet Vorlage anwenden, Als Vorlage speichern, Export, Konfiguration löschen, Verwerfen und Speichern.

2. Rechts sehen Sie die Schritt-Liste. Schritte können per Drag & Drop umsortiert, hinzugefügt oder entfernt werden. Die gesamte Pipeline einer Dokumentenart entfernen Sie über Konfiguration löschen in der Kopfzeile der Detailseite – nach einer Rückfrage werden Schritte, Provider-Einstellungen und Feld-Zuordnungen dauerhaft gelöscht und die Übersicht wieder geöffnet. Die Dokumentenart selbst bleibt in WinLine bestehen, bereits archivierte Dokumente bleiben unverändert; neue Dokumente dieser Dokumentenart werden danach nicht mehr automatisch verarbeitet.

3. Jeder Schritt hat eigene Parameter (z. B. Instanzname, Modellauswahl, Vorlagen-ID, Feld-Mapping, Bedingungen, Zusatzaktionen), die per Klick aufgeklappt werden; die Fußzeile des Schritts nennt die Statistik der letzten Läufe.

   

4. Über die Schaltflächen ≡ Liste / ◆ Diagramm oberhalb der Schritt-Liste lässt sich zusätzlich eine schreibgeschützte Diagramm-Ansicht einblenden: links die Eingangsquellen (Direkter Upload, Portal-Upload, GMI-Webhook, E-Mail-Postfach), in der Mitte die Schritte in Reihenfolge (Schritte mit Laufbedingungen tragen ein ?-Kennzeichen mit den Bedingungen als Tooltip bzw. per Tipp auf das Kennzeichen, deaktivierte sind ausgegraut), rechts der aus den Schritten abgeleitete Ausgang (z. B. CRM-Fall, BelegPro-Import, Archivierung + Suchindex). Ein Klick auf einen Schritt-Knoten wechselt zur Listen-Ansicht und klappt den Schritt zur Bearbeitung auf.

   

Verfügbare Schritttypen:

• Archivierung: Legt das Dokument im WinLine-Archiv ab. Steht in neuen Pipelines an erster Stelle; bestehende Pipelines wurden beim Update automatisch um diesen Schritt ergänzt. Ein bereits archiviertes Dokument (z. B. weil Upload oder GetMyInvoices schon vorab archiviert haben) wird nicht erneut angelegt. Schritte, die ein archiviertes Dokument benötigen, weisen im Editor darauf hin, wenn davor keine Archivierung steht.

• Dokument-Extraktion: Dokumentenfelder erkennen (Azure Document Intelligence, LLM oder Dokumentmodell); in dieser Dokumentation kurz „Extraktion“

• Schlagworte setzen: Erkannte Felder als Schlagworte speichern

• GMI-Fallback: Reichert fehlende Felder aus GetMyInvoices an (nur bei Belegen, die über GetMyInvoices eingegangen sind; sonst übersprungen)

• Stammdaten-Anlage: Kreditor, Debitor, Kontakt, Artikel oder Custom-Datensätze automatisch anlegen. Bei Personenkonten sucht „Vorhandene Datensätze suchen“ über die erkannten Lieferantenfelder der Extraktion – oder, wenn der Parameter „Suchfelder (logisch → Pool)“ gesetzt ist, über frei benannte Pool-Felder wie bei der Stammdaten-Suche (logische Namen Name, UstId, Iban, Plz, Strasse, Land, Website, Email; z. B. Name → firmenname, Email → Mail.Absender; Ort ist kein Suchmerkmal und füllt nur die Anzeige im Dokument-Detail). In beiden Fällen wird nur gesucht, wenn Name, USt-ID, IBAN oder E-Mail vorliegt; eine Adresse oder Website allein führt zu keiner Suche, der Datensatz wird dann neu angelegt. Die Karte „KI-Erkennung“ im Dokument-Detail zeigt USt-ID und Adresse über dieselben Suchfelder an, auch wenn die Extraktion sie unter eigenen Namen liefert. Bei Artikeln prüft „Vorhandene Datensätze suchen“ vor der Anlage die erkannten Artikelfelder (Nummer/EAN und Bezeichnung; alternativ eine einzelne erkannte Position). Mit „Je Zeile wiederholen“ werden ausschließlich die Artikelfelder der aktuellen Zeile geprüft, niemals die einer anderen Position. Der Parameter „Partnerkonto-Feld (Artikel)“ schaltet dabei – wie bei der Stammdaten-Suche – kontospezifische Preislisten frei (leer = Konvention: Kreditor.Kontonummer, dann Portal.Kontonummer). Ein Treffer ab der „Mindest-Treffergenauigkeit (%)“ (Standard 80 %) liefert die bestehende Artikelnummer in den Feld-Pool, statt einen weiteren Artikel anzulegen. Ohne ausreichenden Treffer wird wie bisher die Import-Vorlage verwendet. Die Prüfung läuft ohne semantische Suche und ohne Preislisten-Sicht (Einkauf/Verkauf); für abweichend benannte Suchfelder oder eine bestimmte Preislisten-Seite die Stammdaten-Suche vorschalten und die Anlage auf Zeilen ohne Treffer beschränken. Der Typ Benutzerdefiniert mit dem WinLine-Template-Typ Preise (Preisliste T043) importiert je Aufruf einen Preislisteneintrag (Artikelnummer, Preisliste, Preis, Preisart, bei kontospezifischen Preisen die Kontonummer) – mit „Je Zeile wiederholen“ also je Rechnungsposition, etwa den Rechnungspreis in eine Fremdwährungspreisliste; eine Dublettensuche gibt es dafür nicht, das Ergebnisfeld bleibt leer. Die Import-Vorlage lässt sich für jeden Typ statt über die Auswahl auch über ihren WinLine-Namen angeben (Import-Vorlage (Name), z. B. MesoXPO_Preise) – die Nummer einer Vorlage ist je Installation verschieden, der Name nicht; fehlt die benannte Vorlage in WinLine, meldet der Schritt einen Fehler statt auf eine andere Vorlage auszuweichen.

• Stammdaten-Lookup: Sucht einen bestehenden Datensatz (Personenkonto oder Artikel) und schreibt die gefundene Nummer in den Pool – ohne Neuanlage. Personenkonten werden über USt-ID, IBAN, Adresse (PLZ + Straße), Website, Name und die Absenderadresse einer E-Mail erkannt; Artikel über Artikelnummer, EAN, alternative Artikelnummern, WinLine-Cross-Referenzen, kontospezifische Preislisten und die Bezeichnung. Bei einem Artikel-Lookup bestimmt der Parameter Preislisten-Sicht (Allgemein/Einkauf/Verkauf), welche Preislisten-Seite zählt – Einkauf durchsucht Lieferanten-Artikelnummern (z. B. bei Eingangsrechnungen), Verkauf Kundenartikelnummern (z. B. bei Anfragen); Allgemein durchsucht beide. Der Parameter Partnerkonto-Feld legt fest, welches Pool-Feld die Kontonummer des Geschäftspartners trägt und damit dessen kontospezifische Preislisten freischaltet – leer greift die Konvention (zuerst das Feld Kreditor.Kontonummer, dann Portal.Kontonummer). Kunde über die Absenderadresse: Beim Postfach-Eingang das logische Suchfeld Email auf Mail.Absender legen. Verglichen wird mit der E-Mail und der Rechnungsversand-E-Mail des Kontos und mit den E-Mail-Adressen der Ansprechpartner; ohne genauen Treffer zählt die Domain gegen die Website des Kontos. Die Adresse allein genügt, Firmenname oder USt-ID sind nicht nötig. Gehört sie einem Ansprechpartner des gefundenen Kontos, steht dessen Nummer zusätzlich unter <Präfix>.Ansprechpartner im Pool (z. B. Personenkonto.Ansprechpartner; abweichend über Ansprechpartner-Feld im Pool) und lässt sich im CRM-Fall-Mapping auf Kontakt Kunde (170/10) oder Kontakt Händler (170/23) legen. KI-Nachfrage bei fehlendem Treffer: Bleibt die Personenkonto-Suche ohne Treffer und ist der erkannte Name unplausibel (leer oder nur ein Kürzel wie „AL“ statt des Firmennamens – Grenze KI-Nachfrage bis Namenslänge, Standard 3 Zeichen, 0 = bei jedem fehlenden Treffer), liest ein Sprachmodell Firmenname, USt-ID, IBAN und Adresse des Ausstellers aus dem Dokument, und die Suche läuft mit diesen Werten ein zweites Mal. Die ergänzten Werte stehen danach in den zugeordneten Suchfeldern des Pools (ein plausibler vorhandener Wert bleibt), das Verarbeitungsprotokoll nennt sie und das verwendete KI-Profil (LLM-Profil der KI-Nachfrage, leer = Dokumentenart bzw. global). Der Schalter ist standardmäßig aus und kostet einen KI-Aufruf je betroffenem Dokument; kann das Modell nichts lesen, bleibt es beim fehlenden Treffer mit Angabe des Grunds. Die ergänzten Werte bleiben auch dann im Pool, und der Schritt setzt das Markerfeld <Ergebnisfeld>.KiNachfrage (z. B. Kreditor.Kontonummer.KiNachfrage = true). Folgt eine Stammdaten-Anlage (Personenkonto) ohne Bedingung, legte sie daraus einen Datensatz aus der KI-Lesung an; der Pipeline-Editor warnt in diesem Fall – die Anlage gehört mit der Bedingung Kreditor.Kontonummer.KiNachfrage ist leer abgesichert, damit nur Werte aus der Extraktion einen Datensatz anlegen. Bei „Liste verarbeiten“ legt der Schritt je Zeile neben der gefundenen Nummer (z. B. Positionen/0/GefundeneArtikelNr) auch .Konfidenz (0–100), .Matchgrund, .Bezeichnung und .Status (ok, fehler, uebersprungen) ab, bei fehler zusätzlich .Vorschlag mit dem besten Kandidaten unter der Schwelle. Ein Folgeschritt mit „Je Zeile wiederholen“ liest sie als Zeile/GefundeneArtikelNr.Konfidenz und kann so z. B. nur unsichere Zeilen mit der Bedingung Zeile/GefundeneArtikelNr.Konfidenz kleiner als 90 an eine eigene Prüfung weiterreichen. Die Zuordnung bleibt am Dokument gespeichert und steht auch nach einem Wechsel der BelegPro-Art oder bei der Fall-Anlage aus dem Dialog weiter zur Verfügung.

• Belegkategorie (LLM): Ordnet den Beleg anhand seines Inhalts einer Kategorie zu (z. B. Ware, Dienstleistung, Miete) und stellt sie als Pool-Feld {Belegkategorie} bereit. Zusammen mit bedingten BelegPro-Rucksack-Instanzen wählt die Pipeline damit die Buchungsart automatisch – etwa eine FAKT-Instanz mit Bedingung „Belegkategorie Equals Ware“ und eine FIBU-Instanz mit „Belegkategorie NotEquals Ware“. Der KI-Vorschlag wird strikt gegen die erlaubte Kategorienliste geprüft (Parameter Erlaubte Kategorien); liefert die KI nichts Verlässliches, greift die Standard-Kategorie (leer = Feld bleibt leer, dann trifft ggf. keine Bedingung zu und es entsteht kein Rucksack). Die ermittelte Kategorie wird am Analyseergebnis gespeichert und gilt darum auch beim manuellen Wechsel der BelegPro-Art und bei der Fall-Anlage aus der Detailansicht; die manuelle Übersteuerung bleibt möglich. Vor den Rucksack-Instanzen platzieren.

• BelegPro-Rucksack: XML-Daten für WinLine BelegPro erzeugen. Über den Parameter WinLine-Formulartyp lässt sich pro Schritt-Instanz steuern, mit welchem Formulartyp der Beleg im WinLine-Fenster „Beleg Pro-Workflow“ ankommt – als feste Zahl (z. B. 993) oder aus einem Feld des Erkennungsergebnisses ({Feld}, mit Fallback {FeldA|FeldB}). Leer = Standard (FIBU 990 „Belegeingang Buchung“, FAKT 994 „Belegeingang Batchbeleg Faktura“). Der konfigurierte Wert gilt auch bei manueller Fall-Anlage und beim Wechsel der BelegPro-Art; Feld-Ausdrücke werden dort wie bei der automatischen Verarbeitung aufgelöst (einschließlich Schlagwort- und Datums-Variablen). Bei mehreren FAKT-Schritt-Instanzen entscheidet beim Art-Wechsel die an der Aufgabe gewählte Belegweiterverarbeitung, welche Instanz den Formulartyp und die Vorrang-Einstellungen liefert (s. „Belegweiterverarbeitung umstellen“). Für FAKT-Buchungen steuert zusätzlich der Parameter Belegweiterverarbeitung, wie WinLine den Beleg weiterverarbeitet: „FAKT – Neue Rechnung“ (Standard), „FAKT – Rechnung zu Lieferschein“ (Zuordnung über die gemappte Lieferscheinnummer), „FAKT – Neuen Lieferschein“ oder „FAKT – Lieferschein zu Auftrag“ (Zuordnung über die gemappte Auftragsnummer). Bei Belegstufe „Lieferschein“ wird ohne eigenen Formulartyp automatisch 993 verwendet. Der Schalter Beleg nach Import drucken lässt WinLine den Beleg bei der Freigabe sofort drucken – bei „Lieferschein zu Auftrag“ als Lieferschein, bei „Rechnung zu Lieferschein“ als Rechnung; erst der Druck schreibt die Belegstufe. Die Vorlagen „Eingangsrechnungen (FAKT, Einkauf mit Bestellung)“ und „Eingangsrechnungen (FAKT)“ setzen ihn für „Rechnung zu Lieferschein“. Alternativ lässt sich die Importvariante über das Mapping-Zielfeld „Importoption“ dynamisch aus einem Dokumentfeld setzen; die Pipeline-Prüfung warnt, wenn die für die Vorbeleg-Zuordnung nötige Bezugsnummer nicht gemappt ist. Das FAKT-Mapping bietet außerdem die Gruppe „Belegeingang (Formularfelder)“ mit den Feldern der WinLine-Maske „Beleg Pro - Import“: die Kontrollsummen „Summe netto/brutto“ sowie die Prüffelder „Prüfung IBAN“ und „Prüfung UID-Nummer“ (der zugeordnete Wert erscheint in WinLine in der Spalte „Aus Datei“, den Stammdaten-Abgleich führt WinLine selbst durch). Werden keine Positionsfelder gemappt, entsteht ein reiner Belegkopf-Eintrag – bei den Varianten mit Vorbeleg-Zuordnung übernimmt WinLine die Positionen dann unverändert aus dem Vorbeleg. Für FIBU-Buchungen steuert der Parameter Steuerzeilen-Vorrang, aus welcher Quelle die WinLine-Steuerzeile zum extrahierten Steuersatz ermittelt wird: Buchungshistorie zuerst (Standard – letzte Buchung des Kreditors mit passendem Steuersatz, dann die pro Mandant gepflegten Standard-Steuerzeilen), Standard-Steuerzeilen zuerst, nur Buchungshistorie oder nur Standard-Steuerzeilen; findet keine der gewählten Quellen einen Treffer, sucht als letzte Stufe immer die T010-Stammdatensuche. Der Schalter T010-Fallback: nächstliegenden Steuersatz zulassen bestimmt, ob die Stammdatensuche ohne exakten Steuersatz-Treffer die nächstliegende Zeile wählen darf (ein exakter Treffer bleibt immer erlaubt) – bei exotischen Steuersätzen kann der Nächstliegend-Treffer grob falsch zuordnen. Die gewählte Quelle wird je Lauf im Verarbeitungsprotokoll ausgewiesen (z. B. „Steuerzeile 001 aus Buchungshistorie (Kreditor 70094, 0 %)“); die erste Auflösung steht zusätzlich als Pool-Felder {Steuerzeile} und {Steuerzeile.Quelle} für Bedingungen und Diagnose bereit.

  

• Buchungstext-Ermittlung: Ermittelt den FIBU-Buchungstext aus zwei Quellen – KI (LLM) und Buchungshistorie (letzter verwendeter Buchungstext des Personenkontos). Der Parameter Vorrang der Quellen legt fest, welche Quelle gewinnt (KI zuerst = Standard, Historie zuerst, nur KI, nur Historie – letzteres spart den KI-Aufruf komplett); ist die bevorzugte Quelle leer, greift die andere, sind beide leer, ein statischer Fallback aus Rechnungsnummer und Lieferantname. Der Schritt legt beide Rohwerte als Pool-Felder {Buchungstext.Ki} und {Buchungstext.Historie} ab, den gewählten Wert als {Buchungstext} und die Quelle als {Buchungstext.Quelle} – damit lässt sich die Entscheidung pro Dokument über Schritt-Bedingungen treffen (z. B. zwei Schritt-Instanzen: eine mit nur Historie, eine mit nur KI und Bedingung „Buchungstext.Historie ist leer“; der Parameter Nur wenn Buchungstext noch leer verhindert dabei das Überschreiben). Die gewählte Quelle wird im Verarbeitungsprotokoll ausgewiesen. Den Schritt nach dem Stammdaten-Lookup platzieren – die Buchungshistorie braucht die Kontonummer; bei neu angelegten Partnern ohne Historie greift automatisch die KI. Steht er davor, weist der Editor am Schritt einen Hinweis aus. Bevorzugt der KI-Assistent die KI-Beschreibung als Eingabe (Eingabetyp ist nicht „Erkennungsergebnis“), warnt der Editor außerdem, wenn kein KiBeschreibung-Schritt vor dem Buchungstext läuft – sonst fiele die Eingabe still auf die extrahierte Feldliste zurück. Der Lieferantenname in der KI-Eingabe kommt bevorzugt aus dem WinLine-Kontenstamm (Parameter Pool-Feld mit dem aufgelösten Partnernamen, leer = automatisch über die Konvention zum Kontonummern-Feld, notfalls per Nachschlag im Kontenstamm) – die Texterkennung kann z. B. das Logo statt der Firmenzeile lesen; ohne Stammdaten-Treffer bleibt der extrahierte Name die Quelle.

  

• Gegenkonto-Ermittlung: Ermittelt das Gegenkonto (KontoSoll) aus Buchungshistorie des Kreditors, KI-Vorschlag (gegen den Kontenplan geprüft) und dem Standard-Gegenkonto der Dokumentenart; der Parameter Vorrang der Quellen am Schritt legt die Reihenfolge fest (Buchungshistorie zuerst = Standard, KI-Vorschlag zuerst, nur Buchungshistorie, nur KI-Vorschlag). Bei Buchungshistorie zuerst wird die KI nur befragt, wenn die Historie leer ist – hat sie getroffen, würde ihr Vorschlag ohnehin verworfen; das Verarbeitungsprotokoll vermerkt dann „KI übersprungen – Buchungshistorie hat getroffen“. Das Standard-Mapping des BelegPro-Rucksacks liest das Ergebnis {Gegenkonto} für das KontoSoll aller Buchungszeilen. Nur FIBU. Nach der Stammdaten-Suche und vor dem BelegPro-Rucksack platzieren. In der Vorlage Eingangsrechnungen (FIBU) aktiv mit nur Buchungshistorie.

• Dubletten-Prüfung: Prüft, ob dieselbe Rechnung bereits verarbeitet wurde – Kriterium ist die Rechnungsnummer, standardmäßig zusammen mit dem Bruttobetrag. Findet auch Dubletten über verschiedene Eingangsquellen und Kreditoren hinweg: Liefern z. B. zwei GetMyInvoices-Portale dieselbe Rechnung als unterschiedliche PDF-Dateien, greift die Hash-Deduplizierung nicht und die Rechnung würde doppelt gebucht. Durchsucht bestehende BelegPro-Rucksäcke (T096) und die gespeicherten Analyse-Ergebnisse. Bei einem Treffer werden die Pool-Felder {Dublette.Gefunden}, {Dublette.FallId}, {Dublette.DokumentenId} und {Dublette.Hinweis} gesetzt und im Verarbeitungsprotokoll erscheint eine Warnung mit Verweis auf den bestehenden Fall (z. B. „Mögliche Dublette: Rechnungsnummer DE65L3IVABEI, 27,60 EUR bereits als Fall 1893 (Kreditor 70350) vorhanden“); ohne Treffer bleiben die Felder leer. Damit entscheidet die Konfiguration, was passiert: Eine Bedingung „Dublette.Gefunden ist leer“ an Fall-Anlage/BelegPro-Rucksack überspringt die Fall-Anlage; ohne Bedingung läuft die Pipeline weiter und der Treffer bleibt eine sichtbare Warnung ({Dublette.Hinweis} lässt sich z. B. in die Fall-Bemerkung mappen). Parameter: Bruttobetrag als zusätzliches Kriterium (Standard an), Nur gleicher Kreditor (Standard aus, weil dieselbe Rechnung über mehrere Eingangsquellen unterschiedlichen Kreditoren zugeordnet sein kann) und Zeitraum-Fenster in Tagen für die Analyse-Ergebnis-Suche (Standard 90, 0 = unbegrenzt). Nach der Extraktion und vor Fall-Anlage/BelegPro-Rucksack platzieren. In der Vorlage Eingangsrechnungen (FIBU) als deaktivierter Opt-in enthalten.

• Fremdwährung (Kurs & Umrechnung): Löst eine erkannte Fremdwährung zentral auf – WinLine-Währungsnummer aus dem Währungsstamm und EZB-Wechselkurs zum Belegdatum (ohne Belegdatum der Tageskurs) – und rechnet einen Betrag in die Hauswährung um. Die Ergebnisse stehen als Pool-Felder {Fremdwaehrung.Code}, {Fremdwaehrung.Nummer}, {Fremdwaehrung.Kurs}, {Fremdwaehrung.Betrag} und {Fremdwaehrung.BetragEur} jedem Folgeschritt zur Verfügung – z. B. {Fremdwaehrung.BetragEur} im CRM-Fall-Mapping oder Workflow-Folgeschritt, um den USD-Preis einer Anfrage in EUR weiterzugeben. Der BelegPro-Rucksack (FIBU) übernimmt das Standard-Prefix automatisch für Währungsfeld und FW-Betrag und rechnet die Buchungsbeträge um; auch ohne den Schritt löst der Rucksack die Fremdwährung selbst auf (gleiches Verhalten, ohne Konfigurierbarkeit und eigene Protokollzeile). EUR-Belege werden übersprungen. Über Pool-Feld mit dem umzurechnenden Betrag lässt sich ein beliebiger Pool-Betrag umrechnen; mehrere Instanzen mit eigenem Ziel-Prefix (z. B. AnfragePreis) rechnen weitere Beträge um, ohne die Buchung zu berühren. Ist kein Wechselkurs verfügbar, bleibt der Betrag in Fremdwährung und das Verarbeitungsprotokoll warnt (optional als harter Schritt-Fehler); die Umrechnung kann dann manuell im Aufgabendetail ausgelöst werden. In der Vorlage Eingangsrechnungen (FIBU) aktiv enthalten.

• KI-Beschreibung: Generiert per LLM eine Zusammenfassung des Dokuments. Wird als Pool-Feld {KiBeschreibung} verfügbar und zusätzlich als KI-Notiz am Dokument gespeichert (im Volltextindex durchsuchbar)

• LLM-Feld: Fragt das LLM nach genau einem Wert und legt ihn unter einem frei wählbaren Namen im Feld-Pool ab – für Werte, die kein Erkennungsschema liefert (z. B. eine hausinterne Bestellnummer, mit der ein nachfolgender Vorgang-Suche-Schritt den passenden Beleg findet). Parameter: Anweisung an das LLM (Pflicht, Feld-Platzhalter wie {Rechnungsnummer} erlaubt), Ziel-Pool-Feld (Pflicht), Zusatzkontext aus Pool-Feldern (optional, wie bei KI-Beschreibung), Nur wenn Zielfeld noch leer (Standard an – spart bei bereits gefülltem Feld auch den LLM-Aufruf), Max. Zeichen und Was dem LLM vorgelegt wird. Der Schritt legt dem Modell das Dokument selbst vor: in der Vorgabe Volltext des Dokuments den kompletten Dokumenttext (fehlt er, wird er erzeugt) – der gesuchte Wert ist typischerweise genau der, den das Erkennungsschema nicht liefert, Automatisch wäre hier meist die falsche Wahl (Rückfall auf das bereits erkannte, aber unvollständige Feldergebnis); Dokument als Bild schickt die Seite an ein Vision-Modell – die Wahl, wenn der gesuchte Wert nur im Bild steht (Stempel, Briefkopf); Nur das Erkennungsergebnis spart Token, wenn der Wert bereits in den erkannten Feldern steckt. Liegt gar kein lesbarer Inhalt vor, unterbleibt der LLM-Aufruf und das Verarbeitungsprotokoll vermerkt einen Hinweis. Anders als KI-Beschreibung legt der Schritt keine KI-Beschreibung am Dokument ab; fehlt dem Dokument noch der Volltext, wird er dabei erzeugt und gespeichert (dann durchsuchbar) – für mehrere gesuchte Werte mehrere Instanzen mit je eigenem Ziel-Pool-Feld anlegen. Als Volltext dient zuerst der Text, den die Extraktion in diesem Lauf gewonnen hat (nach einer Azure-Extraktion also deren Texterkennung, ohne zweite Erkennung); nur ohne ihn der Volltext im Archiv. Dasselbe gilt für KI-Beschreibung und Textmuster.

• KI-Prüfung: Lässt ein Sprachmodell einen Prüfgegenstand gegen eine Vergleichsgrundlage prüfen (z. B. Rechnung gegen Bestellung und Lieferschein) und legt Empfehlung, Begründung, Details und eine Zusammenfassung als Pool-Felder KiPruefung.* ab – siehe KI-Prüfung in der Pipeline

• Textmuster: Sucht mit einem regulären Ausdruck einen Wert im Volltext und legt ihn unter einem frei wählbaren Namen im Feld-Pool ab – ohne Sprachmodell, ohne Kosten, bei jedem Dokument mit demselben Ergebnis. Für Werte mit festem Aufbau (Bestellnummer BE-123456, Kundennummer, Aktenzeichen) oder Kennwörter wie „Gutschrift“. Parameter: Regulärer Ausdruck (Pflicht), Ziel-Pool-Feld (Pflicht), Groß-/Kleinschreibung beachten (Standard aus) und Nur wenn Zielfeld noch leer (Standard an; ausgeschaltet ersetzt das Muster auch einen Wert der Extraktion). Mit einer Klammergruppe wird nur deren Inhalt übernommen – Bestell-?Nr\.?:?\s*(BE-\d{6}) liefert aus „Ihre Bestell-Nr.: BE-123456“ den Wert BE-123456; ohne Gruppe zählt der ganze Treffer, es gilt der erste Treffer, ^/$ stehen für Zeilenanfang und -ende. Ob etwas gefunden wurde, prüfen Folgeschritte mit der Bedingung existiert auf das Ziel-Pool-Feld. Ein ungültiges Muster meldet der Editor beim Speichern. Ändert ein Absender sein Layout, findet das Muster nichts mehr – dann hilft ein LLM-Feld als zweite Instanz mit Nur wenn Zielfeld noch leer.

• Fall-Anlage: CRM- oder BelegPro-Fall anlegen. Im Modus CRM-Fall ist eine auflösbare CRM-Vorlage Pflicht (am Schritt, an der Dokumentenart oder als globale KI-Einstellung) – fehlt sie, schlägt der Schritt mit klarer Meldung fehl. Ein BelegPro-Buchungsrucksack (T096) entsteht nur im Modus BelegPro bzw. über den Schritt BelegPro-Rucksack, nie im Modus CRM-Fall. Der Parameter Workflow ist ein Matchcode-Suchfeld: Es sucht Workflow-Schritte nach Nummer und Text, Filter-Chips schränken auf einen Typ ein (Alle wählbaren / Startschritte / Nebenschritte / Schritte). Startschritte legen einen neuen Fall an, Nebenschritte können jederzeit geschrieben werden, normale Schritte sind kontextabhängig – nur schreibbar, wenn der Fall im passenden Vorgängerschritt steht (die Treffer tragen den Hinweis „nur als gültiger Folgeschritt schreibbar“). Ein bereits gespeicherter Schritt wird immer angezeigt, auch wenn er nicht im aktuell gewählten Typ-Filter liegt. Dasselbe Suchfeld steht überall dort, wo Workflow-Schritte auszuwählen sind – Freigabe-Verwaltung, Aufgaben-Filter und Partnerportal-Einschränkungen; gesucht wird immer serverseitig, damit auch Mandanten mit mehreren hundert Workflow-Schritten vollständig auswählbar bleiben. Bei einer Schritt-Nummer zählt dabei der Anfang der Nummer („316“ findet 316, 3160 und 31621, nicht aber 4316), ein Suchbegriff im Schritt-Text wird an jeder Stelle gefunden. Liefert ein sehr unspezifischer Suchbegriff mehr Treffer, als die Liste anzeigen kann, erscheint über dem Feld der Hinweis „Mehr als 500 Treffer – bitte Suche verfeinern.“

• Bestellpositionen zuordnen: Ordnet die erkannten Rechnungspositionen den Zeilen des von der Vorgang-Suche gefundenen Vorbelegs zu. Zuerst zählt die Artikelnummer; passt sie nicht, vergleicht der Schritt den Positionstext mit Bezeichnung, Notizblock, Lieferantenartikelnummer und Lieferantenartikelbezeichnung der Bestellzeile (T026/C004, C043, C068, C069), dann entscheiden Menge und Preis. Erreicht der Zeilentext die Text-Schwelle für die Übersteuerung (Standard 80), ersetzt der Artikel der Bestellzeile einen Stammdaten-Treffer, der nicht in der Bestellung steht – so landen Rechnungen auf Sammelartikeln, deren Bezeichnung der Einkauf je Bestellung pflegt. Positionen ohne Stammdaten-Treffer werden unabhängig von der Schwelle über die Menge zugeordnet; ein Text wie „Schneemann“ gegen „Ferrari“ paart nie. Das Ergebnis steht in der Artikelzuordnung (Lieferschein-Anlage, Rucksack, KI-Panel, „Rechnung vorbereiten“ und der Bestelldialog lesen es) und im Verarbeitungsprotokoll je Position mit Zeile und Grund. Hinter der letzten Vorgang-Suche und vor der Fall-Anlage platzieren; ohne gefundenen Vorbeleg wird der Schritt übersprungen. In den Vorlagen „Eingangsrechnungen (FAKT)“ und „Eingangsrechnungen (FAKT, Einkauf mit Bestellung)“ enthalten.

• Lieferschein anlegen: Legt zu einer gefundenen Bestellung (Vorgang-Suche) den Einkaufs-Lieferschein in WinLine an und verknüpft ihn mit der Aufgabe. Mit Liefermengen aus den Rechnungspositionen gehen nur die Rechnungspositionen mit ihrer Menge in den Lieferschein, die der Artikelabgleich einer Bestellzeile zuordnet (Teillieferung); sonst werden alle offenen Bestellzeilen geliefert. Gibt es schon einen Lieferschein, wird er nur verknüpft – auch wenn sich keine Position zuordnen lässt; mehrere Lieferscheine zur Bestellung meldet der Schritt wie bisher. Gepaarte Positionen gehen mit der Zeilennummer ihrer Bestellzeile in den Lieferschein, unabhängig von der Option Ohne Zuordnung alle offenen Bestellzeilen liefern. Ist vorher Bestellpositionen zuordnen gelaufen, zählt nur eine Position, die einer Bestellzeile zugeordnet wurde – ein Stammdaten-Treffer, der nicht in der Bestellung steht, wird nicht geliefert. Lässt sich keine Position zuordnen, entsteht ohne die Option Ohne Zuordnung alle offenen Bestellzeilen liefern kein neuer Lieferschein; der Schritt meldet eine Warnung und „Lieferschein zu Bestellung“ bleibt. Ohne erkannte Positionen werden weiterhin alle offenen Zeilen geliefert, auch ohne diese Option. Danach greift „Rechnung zu Lieferschein“; scheitert die Anlage, protokolliert der Schritt eine Warnung und „Lieferschein zu Bestellung“ greift. Nach der Fall-Anlage und vor den BelegPro-Rucksäcken platzieren. Die WinLine-Lieferscheinvorlage kommt aus dem Parameter ExIm-Vorlage – ein fester Name oder ein Ausdruck auf Pool-Variablen wie {Vorgang.Lieferscheinvorlage} –, sonst aus der Workflow-Zuordnung, sonst aus den Workflow-Einstellungen des Mandanten. Ein Name, den es in WinLine nicht als Beleg-Vorlage gibt, ist ein Fehler; der Schritt weicht dann nicht auf die nächste Stufe aus. Ein Lieferschein, der schon zu einer anderen Rechnung gehört, zählt weder als vorhanden noch wird er verknüpft; dann entsteht ein eigener. Angelegte und verknüpfte Lieferscheine vermerkt die Anwendung als Vorbeleg dieser Rechnung; das gilt für Lieferscheine, die ab dieser Version angelegt oder verknüpft werden. Laden Sie dieselbe Datei erneut hoch, übernimmt das neue Dokument den Lieferschein seines Vorgängers. Eine neu eingescannte oder anders erzeugte Fassung derselben Rechnung ist eine andere Datei; sie kennt den Lieferschein nicht und legt einen weiteren an – nutzen Sie „Neu analysieren“, bestätigen Sie den vorhandenen über „Vorbeleg verknüpfen“ oder setzen Sie die Dubletten-Prüfung mit der Bedingung „Dublette.Gefunden ist leer“ an Fall-Anlage und Lieferschein anlegen ein. Ein Lieferschein, der schon am Fall hängt, wird bei jedem Lauf erneut als Vorbeleg dieser Rechnung vermerkt – das repariert eine zuvor gescheiterte Zuordnung.

• Belegabgleich: Rechnet die erkannte Rechnung (netto) gegen den Bezugsbeleg der Vorgang-Suche – gegen den Lieferschein (gelieferte Mengen), sonst gegen die Bestellung (bestellte Mengen): Kopfsumme und je Position Menge und Einzelpreis, mit Toleranzen (Toleranz Summe (Belegwährung) 0,02, Toleranz Summe (%) 0,5, Toleranz Einzelpreis (%) 1, Toleranz Menge 0). Die Positionen paart der Schritt nicht selbst, die Paarung kommt aus Bestellpositionen zuordnen; ohne sie wird nur die Kopfsumme geprüft. Beträge stehen in der Rechnungswährung; Bestellung/Lieferschein und Rechnung müssen dieselbe Währung haben (ein Unterschied wird noch nicht erkannt). Das Ergebnis (Belegabgleich.Status = ok, abweichung oder unvollstaendig, dazu Differenzen, Befunde und je Position Abgleich.Status) steht im Pool, wird am Dokument gespeichert und im Rechnungsabgleich der Aufgabe angezeigt; bei jedem Status außer „ok“ meldet der Schritt eine Warnung. Schreibt nichts nach WinLine. Nach der Fall-Anlage (bzw. nach Lieferschein anlegen) und vor den BelegPro-Rucksäcken und der KI-Prüfung platzieren. Details: Belegabgleich. In den Vorlagen „Eingangsrechnungen (FAKT)“ (auch Fremdwährungs-Variante) und „Eingangsrechnungen (FAKT, Einkauf mit Bestellung)“ enthalten; bestehende Pipelines bekommen ihn nicht automatisch.

• Vorgang-Suche: Belegnummer-basierte Vorgangszuordnung. Sucht anhand einer erkannten Belegnummer nach einem bestehenden Vorgang und schreibt bei einem Treffer einen Folgeschritt am vorhandenen Fall („Rechnung eingetroffen“), statt einen neuen Fall anzulegen. Über den Parameter Belegstufen ist einstellbar, wogegen gesucht wird: Standard sind Bestellungen (Belegstufe 2/-2, unverändertes Bestandsverhalten), möglich sind auch Angebote (1), Lieferscheine (3/-3) und Fakturen (ab 4) – Stornobelege werden nie getroffen. Suchspalte legt unabhängig davon fest, welche Nummer verglichen wird: „Nummernspalte der Belegstufe (Standard)“ nutzt wie bisher Angebots-, Auftrags-, Lieferschein- oder Rechnungsnummer. Jede andere Wahl – Angebots-, Auftrags-, Lieferschein- oder Rechnungsnummer – vergleicht immer dieselbe Spalte, egal welche Belegstufe durchsucht wird. So findet die Bestellnummer auf dem Lieferantenbeleg mit Belegstufen 3,-3 und Suchspalte „Auftragsnummer“ (T025/C044) direkt den WinLine-Lieferschein statt der Bestellung; Sortierung und Fallzuordnung richten sich weiterhin nach der Belegstufe. Setzen Sie dabei das Partner-Feld (Pool-Feld mit der Partner-Kontonummer) – sonst läuft die Suche über alle Geschäftspartner hinweg; verlässt die Suchspalte die Belegstufe und fehlt das Partner-Feld, warnt der Pipeline-Editor. Ergänzend filtern Einkauf/Verkauf und das Partner-Feld (Kontonummer des Geschäftspartners) die Suche ein; der Partnerfilter ist wichtig, sobald nicht nach hauseigenen Bestellnummern gesucht wird, weil z. B. Lieferscheinnummern vom Partner vergeben und nicht eindeutig sind. Alternativ übernimmt der Schritt im Modus „Fall-Id aus Pool“ eine bereits ermittelte Fall-Id (z. B. aus einem vorangehenden SQL-Lookup-Schritt) und führt nur noch die Zuordnung aus. Liefert der Pool keinen Suchwert, ermittelt der Schritt die Nummer selbst – bei Suche gegen die Bestellnummer aus Analyse-Ergebnis, OCR-Text und optional LLM, bei Suche gegen die Lieferscheinnummer aus Analyse-Ergebnis und OCR-Text (Muster wie „Lieferschein-Nr.“, „LS-Nr.“, „Delivery Note“) (Parameter Referenznummer notfalls selbst ermitteln (OCR/LLM)). Ohne eigene Workflow-Angabe gilt der „Rechnung eingetroffen“-Schritt aus den Workflow-Einstellungen des Mandanten. Der Schritt darf mehrfach in einer Pipeline stehen („erst Lieferschein suchen, sonst Bestellung“ – die zweite Instanz greift nur, wenn die erste nicht getroffen hat) und wird von allen Eingangsquellen (Upload, E-Mail, GetMyInvoices) gleichermaßen genutzt; in den eingebauten Rechnungs-Vorlagen enthalten. Das Ergebnis steht als Pool-Felder für Folgeschritte bereit – {Vorgang.SuchMethode} nennt die tatsächlich gefundene Belegstufe (z. B. „Lieferschein“), {Buchungstext.Vorbeleg} den Buchungstext des gefundenen Belegs, und der komplette Kopf des Vorbelegs steht zusätzlich zur Verfügung (u. a. {Vorgang.Auftragsnummer}, {Vorgang.Lieferscheinnummer}, {Vorgang.Kontonummer}, {Vorgang.Nettobetrag}) – darüber befüllt das FAKT-Mapping z. B. die WinLine-Bezugsnummer. Diese Felder bleiben auch nach einem manuellen Wechsel der Belegweiterverarbeitung erhalten: Sie werden dann nicht aus dem ursprünglichen Lauf, sondern aus der am Fall hinterlegten Beleg-Verknüpfung neu geladen. Ohne Treffer als Warnung protokollieren: Endet die Suche ohne Vorbeleg – kein Treffer, kein Suchwert im Pool oder ein leeres Partnerfeld –, erscheint der Schritt standardmäßig als Hinweis im Verarbeitungsprotokoll. Dieser Parameter stuft denselben Ausgang stattdessen als Warnung ein – gedacht für Pipelines, die den Vorbeleg für die Belegweiterverarbeitung brauchen (z. B. „Rechnung zu Lieferschein“). Voraussetzung im Standardmodus ist ein CRM-Fall am Beleg: Gesucht werden nur Belege, an denen bereits ein Fall hängt (Belegworkflow); einen Beleg ohne Fall meldet der Schritt als „nicht gefunden“. Der Parameter Zuordnung hebt das auf: „Beleg direkt (ohne CRM-Fall)“ verknüpft das Dokument unmittelbar mit dem Beleg über dessen WinLine-Dokumenten-ID – ohne Folgeschritt, ohne Workflow-Nummer, ohne Import-Vorlage. Das Dokument erscheint in WinLine am Beleg und in der Detailansicht bei den verbundenen Belegen. „CRM-Fall, sonst Beleg“ nimmt den Fall, wenn es einen gibt, und fällt sonst auf die direkte Verknüpfung zurück. Legt die Fall-Anlage danach einen neuen Fall an, hängt der gefundene Beleg auch an diesem Fall: Er steht in der Aufgabe unter „Verknüpfte Belege“, und „Rechnung vorbereiten“ findet den Lieferschein ohne weiteren Handgriff – auch bei Bestellpflicht. Bei Fällen, die vorher angelegt wurden, holt „Neu analysieren“ die Verknüpfung nach. Ohne Fall-Filter kann eine Belegnummer mehrfach vorkommen; dann verknüpft der Schritt bewusst nicht und nennt im Verarbeitungsprotokoll die Auflösungsmöglichkeiten. Bei Teillieferungen sind mehrere Lieferscheine zur selben Bestellung normal – auch mit Partnerfilter. Setzen Sie den Partnerfilter und ermitteln Sie mit einem zusätzlichen Kriterium (z. B. Lieferdatum) per SQL-Lookup den eindeutigen Belegschlüssel für BelegKeyFeld. Alternativ ordnen Sie das Dokument an die Bestellung zu (Belegstufen 2,-2, Suchwert = Bestellnummer). Im Modus „CRM-Fall“ trägt jede Teillieferung einen eigenen Fall; dort nimmt der Schritt weiterhin den neuesten Beleg, wenn auch mit Fall-Filter mehrere Belege übrig bleiben, weist im Verarbeitungsprotokoll aber darauf hin und setzt {Vorgang.Mehrdeutig} – damit lässt sich der Fall über eine Schritt-Bedingung abfangen. Ist der Treffer dagegen nur durch den Fall-Filter eindeutig (ohne ihn blieben mehrere Lieferscheine), ordnet der Schritt nicht zu (Prüfung ohne Fall-Filter, siehe oben). Im Modus „Beleg direkt“ genügt auch ein gefülltes Belegschlüssel-Feld (Parameter Pool-Feld mit Belegschlüssel, kurz BelegKeyFeld, z. B. aus einem SQL-Lookup über die Bezugsnummer des Lieferanten) – die eigene Suche entfällt dann. Das Ergebnis nennt {Vorgang.Zuordnung} („Fall“ oder „Beleg“) und {Vorgang.DokumentenId} (die WinLine-Dokumenten-ID des Belegs), bei einer mehrdeutigen Belegnummer zusätzlich {Vorgang.Mehrdeutig}; der Bestellnummer-Fallback läuft in diesem Modus auch ohne Workflow-Nummer. Ein Einkaufs-Lieferschein, der schon zu einer anderen Rechnung gehört (durch Lieferschein anlegen oder Vorbeleg verknüpfen), wird übersprungen; das Protokoll nennt ihn mit dem Dokument, zu dem er gehört. Bleibt kein Lieferschein übrig, greift der nächste Such-Schritt, etwa die Bestellsuche. Bei Zuordnung über den CRM-Fall prüft der Schritt zusätzlich in einer Prüfung ohne Fall-Filter, ob der Treffer auch ohne ihn eindeutig wäre; ist er es nur durch die Fall-Bindung (zeitlich versetzte Teillieferungen), ordnet der Schritt nicht zu, meldet eine Warnung und setzt {Vorgang.Mehrdeutig}. Lassen sich die Zuordnungen dabei nicht lesen, ordnet der Schritt ebenfalls nicht zu. Hat die Suche die Obergrenze von 20 Lieferschein-Kandidaten gelesen und dabei mindestens einen gebundenen übersprungen, ordnet der Schritt auch nicht zu und warnt, dass weitere Lieferscheine folgen könnten (auch in der Prüfung ohne Fall-Filter). Im Modus „Fall, sonst Beleg“ läuft die ganze Suche zuerst mit dem Fall-Filter und, wenn nichts übrig bleibt, noch einmal ohne ihn.

  

• E-Mail: Benachrichtigung per E-Mail senden

• Webhook: HTTP-Aufruf an ein externes System – Parameter, Standard-Payload und Signatur-Prüfung im Abschnitt Webhook-Schritt

• Workflow-Folgeschritt: Automatisch den nächsten Workflow-Schritt auslösen; mehrfach erlaubt, je Instanz mit eigenem Feld-Mapping auf die CRM-Vorlage

• Lucene-Reindex: Suchindex nach Analyse aktualisieren; läuft immer am Ende und entfällt ohne Fehler, wenn der Lauf bewusst nichts archiviert hat

• Aggregation: Listen aus dem KI-Ergebnis (z. B. Steuerdetails, Positionen) gruppieren, summieren und filtern und als neue Pool-Liste bereitstellen

• SQL-Lookup: Werte per SQL-Abfrage direkt aus der WinLine-Mandantendatenbank ermitteln (z. B. die Kostenstelle zum erkannten Kreditor) und im Feld-Pool bereitstellen

• Nachklassifizierung: Prüft die Dokumentenart nach der Extraktion erneut gegen die Klassifizierungs-Beschreibungen aller Dokumentenarten (Heuristik + KI, derselbe Weg wie die automatische Erkennung beim Upload). Weicht die erkannte Art sicher von der aktuellen ab – z. B. Gutschrift statt Rechnung –, wird die Dokumentenart am Dokument korrigiert und die Pipeline der neuen Dokumentenart gestartet; die restlichen Schritte der alten Art laufen nicht mehr. Der Parameter Mindest-Konfidenz legt fest, ab welcher Sicherheit gewechselt wird (0 = Schwelle aus der globalen KI-Konfiguration), Maximale Dokumentenart-Wechsel (1–3, Standard 1) verhindert Endlosschleifen zwischen zwei Dokumentenarten. Das Ergebnis steht unabhängig vom Wechsel als Pool-Felder bereit ({Nachklassifizierung.FormularId}, {Nachklassifizierung.Bezeichnung}, {Nachklassifizierung.Konfidenz}, {Nachklassifizierung.Methode}) – damit können Folgeschritte per Bedingung darauf reagieren. Nach der Extraktion platzieren

• Chat-Nachricht: Sendet das Analyse-Ergebnis als Chat-Nachricht direkt in der Anwendung. Empfänger sind kommaseparierte Benutzernummern (z. B. „17, 23“) oder das Schlüsselwort Admins (alle Benutzer mit Benutzerverwaltungs-Recht). In beiden Fällen bekommt die Nachricht nur, wer auch Zugriff auf den Mandanten des Laufs hat; Geschäftspartner (Portalbenutzer) sind grundsätzlich ausgenommen, da die Nachricht interne Analyse-Werte und einen Verweis auf das Dokument enthält. Nachrichtentext und Empfänger unterstützen Platzhalter aus dem Feld-Pool (z. B. {Kreditor.Kontonummer} oder {Rechnungsnummer}), das analysierte Dokument wird automatisch als klickbarer Verweis an die Nachricht gehängt. Wie beim E-Mail-Schritt steuern Bei Erfolg/Bei Fehler und optionale Bedingungen, wann gesendet wird. Am Ende der Pipeline platzieren

Vorlagen: Zwanzig eingebaute Vorlagen stehen als Ausgangspunkt bereit und können nach dem Anwenden frei angepasst werden. Die Kunden-Vorlagen (Angebotsanfrage, Reklamation, Serviceanfrage – auch aus Postfach –, Kundenbestellung und Visitenkarte) legen das Kundenkonto neutral unter Personenkonto.Kontonummer ab (Bezeichnung Personenkonto.Kontobezeichnung, Kontakt Personenkonto.Ansprechpartner) und tragen beim Anwenden Personenkonto.Kontonummer als Partner-Pool-Feld der Dokumentenart ein. Alle extrahieren mit neutralen Feldnamen (firmenname, ustId, bei der Visitenkarte zusätzlich strasse, plz, ort). Reklamation, Serviceanfrage und Kundenbestellung suchen den Kunden über firmenname, ustId und die Absenderadresse; die Angebotsanfrage sucht zuerst über dieselben Felder und legt den Kunden nur ohne Treffer neu an, die Visitenkarte über Firma, USt-ID und Adresse (Parameter „Suchfelder“ der Stammdaten-Anlage). Alle extrahieren per LLM; das Azure-Modell spielt für sie keine Rolle und wird im Editor als „nicht verwendet“ angezeigt:

Vorlage	Deckt ab
Eingangsrechnungen (FIBU)	Der vollständige Rechnungsweg: Extraktion, Stammdaten, Buchungstext, Schlagworte, Vorgang-Suche, Fall-Anlage, Steuer-Aggregation, BelegPro-Rucksack. Eine Vorlage für alle Steuerfälle (s. Aggregations-Schritt)
Eingangsrechnungen (FIBU, E-Rechnung ohne KI)	Dieselben Schritte wie Eingangsrechnungen (FIBU), aber ohne einen einzigen Aufruf eines Sprachmodells: Der Buchungstext kommt nur aus der Buchungshistorie des Kreditors, ohne Historie aus Rechnungsnummer und Lieferantenname. Passen mehrere Buchungsvorlagen zum Kreditor, wählt nicht die KI, sondern die als Standard gekennzeichnete Vorlage. Gedacht für Mandanten, die ihre Rechnungen als E-Rechnung erhalten – zusammen mit der E-Rechnungs-Einstellung Nur direkt aus der Rechnung (s. Wie E-Rechnungen verarbeitet werden)
Eingangsrechnungen (FAKT)	Eingangsrechnung zu einem bereits vorhandenen Einkaufs-Lieferschein (WinLine-Belegweiterverarbeitung „Rechnung zu Lieferschein“, 4:2). Die Vorgang-Suche findet den Lieferschein über die Bestellnummer auf der Rechnung (Belegstufen 3,-3, Suchspalte „Auftragsnummer“ [T025/C044], Partnerfilter auf den gefundenen Kreditor). Ohne gefundenen Lieferschein entsteht der Fall mit einer Warnung, aber kein Rucksack; bei mehreren Lieferscheinen zur selben Bestellung (Teillieferungen) ebenfalls nicht – der Vorbeleg wird dann manuell zugeordnet. Treffen weitere Lieferungen zu derselben Bestellung zeitlich versetzt ein, sollte der zugeordnete Vorbeleg zusätzlich geprüft werden – die automatische Zuordnung stößt hier an ihre Grenze. Die Vorlage schreibt auch die erkannten Rechnungspositionen in den Rucksack; ohne Positionszeilen übernimmt WinLine die Positionen aus dem Lieferschein. Die Vorgang-Suche findet den Lieferschein zuerst über die auf der Rechnung erkannte Lieferscheinnummer, sonst über die Bestellnummer. Der Schritt Bestellpositionen zuordnen paart die Positionen mit den Zeilen des gefundenen Belegs; der Artikel der Bestellzeile gilt vor dem Stammdaten-Treffer.
Eingangsrechnungen (FAKT, Einkauf mit Bestellung)	Für Einkaufsprozesse mit Bestellpflicht: Die Vorgang-Suche prüft nacheinander Lieferschein über die erkannte Lieferscheinnummer, Lieferschein über die Bestellnummer und schließlich die Bestellung. Bei gefundenem Lieferschein entsteht „Rechnung zu Lieferschein“ (4:2). Bei gefundener Bestellung ohne Lieferschein legt der Schritt Lieferschein anlegen den Lieferschein in WinLine an, danach entsteht ebenfalls „Rechnung zu Lieferschein“; scheitert das oder fehlt die Lieferscheinvorlage, bleibt es bei „Lieferschein zu Bestellung“ (3:1). Ohne Vorbeleg entsteht der Fall mit Warnung, aber kein Rucksack. Gleiches gilt, wenn zur Bestellung bereits mehrere Lieferscheine vorliegen (Teillieferungen) – den passenden Lieferschein ordnen Sie dann über Vorbeleg verknüpfen zu. Kein FIBU-Zweig. Der Schritt Bestellpositionen zuordnen paart die Positionen mit den Zeilen des gefundenen Belegs; der Artikel der Bestellzeile gilt vor dem Stammdaten-Treffer.
Eingangsrechnungen (FAKT, Fremdwährungspreise)	Wie Eingangsrechnungen (FAKT), zusätzlich wandern die Rechnungspreise eines in Fremdwährung fakturierenden Lieferanten je Position in dessen Fremdwährungspreisliste – ohne Umrechnung in die Hauswährung. Die Kette: Fremdwährung ermittelt die WinLine-Währungsnummer, ein SQL-Lookup die Preisliste mit dieser Währung (Preislistendefinition, Feld FW-Zeile), die Artikelzuordnung der FAKT-Vorlage liefert je Rechnungsposition den Artikel, die Stammdaten-Anlage (Typ Preise, Vorlage MesoXPO_Preise) importiert den Einzelpreis als lieferantenspezifischen Einkaufspreis (Preisart 13). Jedes Glied hängt am vorherigen: EUR-Rechnungen, Positionen ohne gefundenen Artikel oder ohne Preis laufen ohne Import durch. Voraussetzungen: die ExIm-Vorlage MesoXPO_Preise in WinLine und je Fremdwährung eine Preislistendefinition mit dieser Währung (s. Installationsanleitung). Ob ein bereits vorhandener Eintrag aktualisiert oder ergänzt wird, bestimmt die ExIm-Vorlage
Lieferantenpreisliste	Preisliste oder Katalog eines Lieferanten: alle erkannten Artikel anlegen bzw. mit Einkaufspreisen versorgen – mit den vorhandenen Bausteinen, ohne eigenen Schritt. Die LLM-Extraktion liest Lieferant, Gültig-ab, Währung und die Positionen (Lieferanten-Artikelnummer, EAN, Bezeichnung, Preis). Danach: Kreditor suchen (kein Anlegen), Fremdwährung und SQL-Lookup ermitteln die Preisliste zur Währung (EUR-Listen die Hauswährungsliste), die Stammdaten-Suche findet je Position den Artikel auf der Einkaufsseite des Kreditors (auch über Lieferanten-Artikelnummer und EAN), die Stammdaten-Anlage legt nur nicht gefundene Artikel über MesoXPO_Artikel an (unter der Lieferanten-Artikelnummer; + im Mapping schaltet auf die WinLine-Nummernvergabe um), und der Preis-Schritt schreibt je Position einen lieferantenspezifischen Einkaufspreis (Preisart 13) auf den gefundenen oder neu angelegten Artikel. Bestandsartikel bekommen bewusst nur Preise: ein ExIm-Update leert jedes Vorlagenfeld, das nicht mitgesendet wird – wer Bezeichnung oder EAN nachziehen will, ergänzt eine zweite Artikel-Anlage ohne Bedingung mit einer individuellen Vorlage, die nur sicher gelieferte Felder enthält. Nach dem Anwenden: Steuerzeile und Artikeluntergruppe neuer Artikel als Pflichtfelder am Schritt „Artikel anlegen“ eintragen (mandantenspezifisch). Grenzen: die LLM-Extraktion kappt den Text bei der eingestellten Höchstlänge (Standard 8000 Zeichen, KI-Grundeinstellungen); Staffelpreise werden nicht übernommen (Preis der kleinsten Staffel, Ab-Menge 0)
Auftragsbestätigung (Lieferant)	Auftragsbestätigung eines Lieferanten an die Bestellung hängen – ohne CRM-Fall. Die LLM-Extraktion liest Lieferant, AB-Nummer, unsere Bestellnummer und den bestätigten Liefertermin; der Kreditor wird nur gesucht (auch über die Absenderadresse), die Vorgang-Suche findet die Bestellung (Belegstufen 2,-2, Einkauf, Partnerfilter auf den Kreditor) und verknüpft das Dokument direkt mit dem Beleg (Zuordnung „Beleg direkt“). Fehlt die Bestellnummer auf dem Dokument, ermittelt die Vorgang-Suche sie selbst aus dem Text. Ohne Treffer bleibt das Dokument archiviert, das Verarbeitungsprotokoll zeigt eine Warnung. Schlagworte: Kontonummer und -bezeichnung, Betreff, Bestellnummer (AB)
Lieferschein (Lieferant)	Lieferschein eines Lieferanten an den Wareneingang hängen – ohne CRM-Fall. Zuerst sucht die Vorgang-Suche den bereits erfassten Einkaufs-Lieferschein über die Lieferscheinnummer des Lieferanten (Suchspalte „Lieferscheinnummer“ [T025/C045]), ohne Treffer die Bestellung über unsere Bestellnummer; beide verknüpfen direkt am Beleg. Schlagworte wie bei der Auftragsbestätigung, zusätzlich die Lieferscheinnummer (LS)
Nur Archivierung	Das Minimum: Extraktion (inkl. Texterkennung für die Suche) und Schlagworte. Kein LLM nötig
CRM-Dokument	Lieferanten finden und einen CRM-Fall erzeugen
Zertifikat (Lieferant)	Eigener Extraktions-Prompt für Zertifikatsfelder, KI-Beschreibung, Personenkonto- und Artikel-Suche, CRM-Fall mit Gültigkeitszeitraum – geeignet als Standard für Zertifikate aus dem Lieferantenportal
Visitenkarte (Kontakt anlegen)	Foto/Scan → Kundenkonto finden oder anlegen, Ansprechpartner anlegen
Visitenkarte (CRM-Fall)	Wie „Kontakt anlegen“, zusätzlich CRM-Fall mit der Visitenkarte als Anhang; Kundenkonto/Kontakt nur bei sicher erkannter Firma (Konfidenz-Bedingung), sonst bleibt das Kundenkonto am Fall leer
Angebotsanfrage (CRM-Fall)	Der umfangreichste Fall: eigener Prompt, Kunde zuerst suchen (auch über die Absenderadresse der E-Mail) und nur ohne Treffer anlegen, Artikel je Position (Liste verarbeiten), CRM-Fall mit Kundenkonto und Kontakt Kunde
Kundenbestellung (CRM-Fall)	Bestellung eines Kunden (Auftragseingang), auch als reiner Mailtext: eigener Prompt (Bestellnummer des Kunden, Bezug auf unser Angebot, Wunschtermin, Positionen), KI-Zusammenfassung, Kunde wird nur gesucht – auch über die Absenderadresse – und kommt samt Ansprechpartner in den Fall, Artikel je Position auf der Verkaufsseite. Nennt die Bestellung eine Angebotsnummer, hängt die Vorgang-Suche das Dokument direkt an dieses Angebot (Zuordnung „Beleg direkt“). CRM-Fall mit dem Wunschtermin als Enddatum. Den Auftrag selbst legt die Bearbeitung aus dem Fall an – einen Pipeline-Schritt dafür gibt es nicht; Workflow-Nummer und CRM-Vorlage nach dem Anwenden eintragen
Reklamation (CRM-Fall)	Beschwerden, Mängelrügen, Retouren – auch als reiner Mailtext: eigener Prompt (Reklamationsgrund, gewünschte Lösung, betroffene Rechnungs-/Lieferschein-/Auftragsnummer, Frist), KI-Zusammenfassung, Kunde wird nur gesucht (kein neuer Debitor) – auch über die Absenderadresse der E-Mail – und kommt samt Ansprechpartner als Kundenkonto und Kontakt Kunde in den Fall, Artikel je Position, Belegnummern als Schlagworte, CRM-Fall mit Frist als Enddatum, Kurzbeschreibung = Betreff der E-Mail (sonst extrahierter Betreff), Langbeschreibung extern = KI-Zusammenfassung; Workflow-Nummer nach dem Anwenden eintragen
Serviceanfrage (CRM-Fall)	Allgemeine Kundenanliegen ohne Produktbezug (Adressänderung, Zahlungskonditionen, Rechnungskopie, Terminwunsch, Auskunft), auch als reiner Mailtext: Prompt mit Anliegen-Kategorie und Einzelanliegen, KI-Zusammenfassung, Kunde wird nur gesucht – auch über die Absenderadresse der E-Mail – und kommt samt Ansprechpartner als Kundenkonto und Kontakt Kunde in den Fall, CRM-Fall mit Frist als Enddatum; kein Artikel-Lookup; Workflow-Nummer nach dem Anwenden eintragen
Reklamation aus Postfach / Serviceanfrage aus Postfach (CRM-Fall)	Für ein Postfach im Modus Nur überwachen: dieselbe Erkennung, derselbe Prompt und dieselben Zuordnungen wie die gleichnamige Vorlage, aber ohne vorherige Archivierung. Die Extraktion bewertet zusätzlich, ob die Mail relevant ist (Newsletter, Werbung, Abwesenheitsnotizen oder reine Dank-Mails nicht), und fasst sie zusammen. Einen CRM-Fall – und erst damit eine archivierte Mail – gibt es nur für relevante Mails von Absendern, die als Kunde bekannt sind; alle anderen Mails bleiben unangetastet im Posteingang. Der Fall trägt Kundenkonto, Kontakt Kunde und die Zusammenfassung als Langbeschreibung extern; Workflow-Nummer und CRM-Vorlage nach dem Anwenden eintragen. Die Beschreibung zur automatischen Erkennung ist dieselbe wie bei der gleichnamigen Vorlage – wer beide als Dokumentenart nutzt und automatisch erkennen lässt, passt eine davon an
Angebotsanfrage aus Postfach (CRM-Fall)	Dieselbe Ableitung für die Angebotsanfrage, mit einem Unterschied: Eine Anfrage kommt oft von einem Interessenten, der noch kein Kunde ist. Der CRM-Fall entsteht deshalb für jede relevante Mail, nicht nur für bekannte Kunden. Ein neues Kundenkonto legt die Vorlage nur für eine relevante Mail mit erkanntem Firmennamen an – aus Werbung oder Newslettern entsteht kein Debitor

Visitenkarte und Angebotsanfrage zeigen mit eigenem LLM-Extraktions-Prompt, wie Nicht-Rechnungs-Dokumentenarten abgebildet werden – Details im Abschnitt Anwendungsfälle jenseits der Rechnung.

Deaktivierte Schritte als Opt-in: Die Vorlage Eingangsrechnungen (FIBU) bringt die Schritte Belegkategorie (LLM) und die Dubletten-Prüfung bereits mit – aber ausgeschaltet; die Gegenkonto-Ermittlung ist aktiv mit nur Buchungshistorie, die KI dort ein Opt-in über den Vorrang. Wer sie braucht, schaltet sie um, statt sie von Hand nachzurüsten; wer sie nicht braucht, zahlt keine KI-Kosten. Dasselbe Vorgehen eignet sich für eigene Schritte, die vorbereitet, aber noch nicht scharf sein sollen – ein deaktivierter Schritt erscheint im Verarbeitungsprotokoll als „übersprungen“.

Validierung: Der Editor prüft automatisch Abhängigkeiten zwischen Schritten und zeigt Warnungen an – etwa wenn ein Fall-Anlage-Schritt ohne vorherige Extraktion konfiguriert ist, der BelegPro-Rucksack oder der Workflow-Folgeschritt vor der Fall-Anlage steht, die Vorgang-Suche nach der Fall-Anlage kommt (das würde zusätzlich zum neuen Fall einen Folgeschritt am gefundenen Fall schreiben), der Buchungstext vor der Stammdaten-Suche liegt, eine Belegweiterverarbeitung mit Vorbeleg-Zuordnung gewählt, die Bezugsnummer aber nicht gemappt ist, zwei Workflow-Folgeschritte oder zwei BelegPro-Rucksäcke gleichzeitig zutreffen können, eine KI-Prüfung Vorbelege oder den Rucksack liest, ohne dass Vorgang-Suche bzw. Rucksack-Schritt davorstehen, ihre Konfiguration ungültig ist, oder mehrere KI-Prüfungen bzw. mehrere Workflow-Folgeschritte denselben Instanznamen tragen, ein Workflow-Folgeschritt allein an einer KI-Empfehlung hängt und bei „ok“ ausgeführt würde (Hinweis: für eine Freigabe eine feste Zusatzbedingung ergänzen oder auf einen Sichtungsschritt verzweigen), ein Instanz-Mapping zu keinem Schritt der Pipeline mehr gehört (Hinweis: verwaist), der Belegabgleich ohne Vorgang-Suche steht (Warnung: es gibt keinen Referenzbeleg), vor der Fall-Anlage steht (Warnung: der Referenzbeleg ist dann noch nicht am Fall verknüpft) oder ohne Bestellpositionen zuordnen davor läuft (Hinweis: dann wird nur die Kopfsumme geprüft), oder die Fall-Anlage im Modus „CRM-Fall“ läuft, ohne dass am Schritt, an der Dokumentenart oder in den globalen KI-Einstellungen eine CRM-Vorlage hinterlegt ist bzw. ohne dass es überhaupt eine CRM-Fall-Feldzuordnung gibt (der Schritt würde in beiden Fällen beim ersten Upload fehlschlagen). Warnungen verhindern das Speichern nicht, benennen aber ein absehbares Problem.

Historie: Unterhalb der Schritt-Liste sehen Sie die letzten Pipeline-Ausführungen mit Status und Dauer. Jeder aufgeklappte Schritt zeigt zusätzlich eine Kurzstatistik seiner letzten Läufe („14 Erfolg · 0 Fehler · 0 Übersprungen · ø 6720 ms“) – damit fällt ein Schritt auf, der still immer übersprungen wird oder ungewöhnlich lange braucht.

Schritte je Zeile wiederholen

Iterierbare Schritte lassen sich statt einmal je Dokument auf jede Zeile einer Pool-Liste anwenden – z. B. je Rechnungs- oder Bestellposition. Der Abschnitt „Je Zeile wiederholen“ (bei Schritten, die die ganze Liste in einem Durchgang verarbeiten: „Liste verarbeiten“) liegt unter den Bedingungen des Schritts und wird per Kontrollkästchen eingeblendet, nicht eingeklappt.

• Liste: Name der Pool-Liste (z. B. Items für Items/0/…, Items/1/…, …).
• Zeile/…: In der Schleife stehen die Felder der aktuellen Zeile zusätzlich unter Zeile/… zur Verfügung, dazu Zeile/Index (nullbasiert), Zeile/Nummer (einsbasiert) und Zeile/Liste. Bedingungen des Schritts gelten dann je Zeile; eine Zeile, die eine Bedingung nicht erfüllt, gilt als übersprungen. Ergebnisse landen wieder in der jeweiligen Zeile, nicht im Dokument insgesamt.
• Fehlerverhalten: Weiter lässt alle Zeilen laufen, auch wenn einzelne fehlschlagen; Abbruch beendet die Schleife bei der ersten fehlgeschlagenen Zeile.
• Maximale Zeilen: Begrenzt die Anzahl verarbeiteter Zeilen, leer = unbegrenzt; wird die Grenze erreicht, endet die Schritt-Meldung mit „… auf X von Y Zeilen begrenzt“ (bei „Liste verarbeiten“ zusätzlich als eigene Warnung „Liste auf X von Y Zeilen begrenzt – überzählige Positionen nicht verarbeitet“).
• Zähler: Nach dem Lauf stehen {Schritt}.Zeilen.Anzahl, .Erfolgreich, .Fehler und .Uebersprungen im Pool – nutzbar in Bedingungen und Texten nachfolgender Schritte.
• Liste verarbeiten (Batch): Bei der Stammdaten-Suche (Artikel) verarbeitet der Schritt alle Zeilen der Liste in einem Durchgang statt in einer Schleife – die frühere Grenze von 100 Positionen entfällt damit. Bleiben alle gesuchten Zeilen ohne Treffer, gilt die Stammdaten-Suche als fehlgeschlagen (Zeilen ohne Suchwert zählen nicht mit); mit „Abbruch bei Fehler“ endet die Pipeline dort – für den Fall „fehlende Artikel anlegen“ den Schalter aus lassen. Der Parameter „Ohne Treffer nur Warnung“ macht diesen Fall zur Warnung statt zum Fehler – bei den Eingangsrechnungs-Vorlagen (FAKT) eingeschaltet, weil dort der Rückfall auf die Artikelnummer des Lieferanten genügt.

Zwei Referenzfälle:

• Kundenanfrage per Mail: Extraktion (Items/n/Artikelnummer, /Beschreibung, /Menge) → Stammdaten-Suche (Artikel) als „Liste verarbeiten“ → Stammdaten-Anlage (Artikel) „Je Zeile wiederholen“ mit Bedingung Zeile/GefundeneArtikelNr IstLeer: legt fehlende Artikel per Import-Vorlage an.
• Warenbegleitschein: Extraktion → Stammdaten-Suche Kreditor (Dokumentebene) und Artikel („Liste verarbeiten“) → SQL-Lookup „Je Zeile wiederholen“ über Items: offene Bestellposition zu Lieferant und Artikel → Items/n/BestellNr, /BestellPos, /OffeneMenge → Aggregation fasst Zeilen mit Treffer für den späteren Belegimport zusammen (dieser folgt in einer weiteren Ausbaustufe).

Eine neue Pipeline erproben (Testlauf)

Oberhalb der Schrittliste steht der Bereich Testlauf. Laden Sie dort ein Beispieldokument hoch und klicken Sie Extraktion testen: Sie sehen die erkannten Felder mit Konfidenzwerten, den verwendeten Provider, das wirksame KI-Profil, die Laufzeit und den Token-Verbrauch. Der Testlauf verwendet den gerade im Editor eingestellten Provider und Prompt – also auch ungespeicherte Änderungen. Sie können einen Prompt anpassen und sofort sehen, was er liefert.

0 Felder sind kein Erfolg: Liefert der Testlauf keine Felder, zeigt das Ergebnis einen Hinweis auf die Ursache statt eines grünen „Erfolgreich“ – etwa wenn der KI-Assistent deaktiviert ist (Verwaltung → Einstellungen → Erkennung & KI → Dokumentenerkennung, Karte „KI-Assistent (Dokumentenbeschreibung)“; sein Schalter gilt für alle Sprachmodell-Aufrufe der Dokumentverarbeitung) oder wenn im Dokument kein lesbarer Text gefunden wurde. Braucht der gewählte Erkennungs-Provider ein Sprachmodell, warnt zusätzlich die Pipeline-Prüfung schon vor dem Testlauf, wenn der KI-Assistent ausgeschaltet ist.

Hat das Sprachmodell geantwortet, aber ohne verwertbare Felder, nennt der Hinweis die Ursache aus der Antwort selbst:

• Am Token-Limit abgeschnitten: Das JSON kam unvollständig an. Erhöhen Sie „Max. Tokens (Antwort)“ in der Karte „KI-Assistent (Dokumentenbeschreibung)“ oder „Max Tokens“ im verwendeten LLM-Profil — wirksam ist der höhere der beiden Werte. Modelle mit Denkprozess verbrauchen einen Teil des Budgets für ihre Überlegungen, bevor sie antworten.
• Leere Antwort: Prüfen Sie Modell und Endpunkt des LLM-Profils sowie den Eintrag in der KI-Statistik.
• Kein JSON-Objekt: Der Extraktions-Prompt verlangt Prosa statt eines JSON-Objekts. Er muss genau ein JSON-Objekt fordern; jede Eigenschaft der obersten Ebene wird ein Feld.

Wer Pipelines konfigurieren darf, kann unter dem Ergebnis die Rohantwort des Sprachmodells aufklappen und sieht damit genau, was das Modell geliefert hat. Die Kopfzeile des Ergebnisses nennt außerdem den tatsächlich gelaufenen Provider.

Gedeutete Felder markieren

Unter dem Extraktions-Prompt listet Erkannte Felder alle Feldnamen der Dokumentenart. Ein Klick auf ein Feld markiert es als gedeutet (gestrichelter Rahmen, Zusatz „gedeutet“), ein zweiter Klick hebt die Markierung auf. Gedacht ist das für Felder, deren Wert das Modell selbst formuliert oder aus einer vorgegebenen Werteliste wählt – Kategorie, Betreff, Zusammenfassung, Anliegen, Relevanz.

Warum das nötig ist: Die KI-Konfidenz im Dokument-Detail prüft, ob die erkannten Werte wörtlich im Dokument stehen. Ein Wert wie „Auskunft“ als Kategorie oder eine Zusammenfassung in eigenen Worten tut das nie. Ohne Markierung senken solche Felder die Konfidenz, und eine richtig erkannte Mail trägt den Hinweis „Manuelle Prüfung empfohlen“. Markierte Felder zählen nicht zur Konfidenz.

• Die Markierung gilt für das Feld samt Unterfeldern und allen Listenpositionen: anliegen/0 aus einem Testlauf markiert jede Position von anliegen.
• Felder innerhalb einer Liste, etwa der Mangel je Position, markieren Sie über das Feld aus einem Testlauf (positionen/0/mangel).
• Die Vorlagen Serviceanfrage, Reklamation und Angebotsanfrage (jeweils auch aus Postfach) sowie Kundenbestellung und Zertifikat (Lieferant) bringen die Markierung mit. Wer eine Vorlage mit eigenem Prompt anwendet, übernimmt ihre Markierung anstelle der bisherigen.
• Wirksam wird die Änderung mit Speichern, und zwar für Dokumente, die danach analysiert werden.

Wichtige Grenze: Der Testlauf prüft nur die Extraktion, nicht die Folgeschritte. Stammdaten-Suche, Fall-Anlage, Aggregation und BelegPro-Rucksack laufen dabei nicht, und es wird nichts gespeichert: kein Dokument, kein Fall, keine Buchung, kein Schlagwort.

Empfohlenes Vorgehen für eine neue Dokumentenart:

1. Vorlage anwenden, die dem Ziel am nächsten kommt (bei Rechnungen Eingangsrechnungen (FIBU) bzw. (FAKT), sonst meist Nur Archivierung als Grundgerüst).
2. Prompt und Klassifizierung per Testlauf verfeinern, bis die Felder stimmen – in dieser Phase entstehen keine Nebenwirkungen.
3. Schreibende Schritte zunächst deaktiviert lassen (Fall-Anlage, BelegPro-Rucksack, E-Mail, Webhook) und ein Testdokument hochladen. Das Verarbeitungsprotokoll zeigt je Schritt Ergebnis, Dauer und Meldung.
4. Bei unklarer Feldherkunft das Feldprotokoll einschalten – es hält je Lauf den Feld-Pool, die Mapping-Quelle und die Herkunft jedes einzelnen Werts fest.
5. Erst dann die schreibenden Schritte einschalten und mit einem echten Beleg gegenprüfen.

Aggregations-Schritt

Der Aggregations-Schritt fasst Listen aus dem KI-Ergebnis (z. B. Steuerdetails) zu einer gruppierten Übersicht zusammen. Standard-Einsatz: pro Steuersatz wird genau eine Buchungszeile im BelegPro-Rucksack erzeugt – Anzahlungen und Stornos werden saldiert, statt mehrere widersprüchliche Zeilen zu erzeugen.

Bei den eingebauten Rechnungs-Vorlagen ist der Schritt bereits vorkonfiguriert. Eigene Pipelines, die BelegProRucksack nutzen und mit mehreren Steuersätzen arbeiten, sollten den Aggregations-Schritt vor BelegProRucksack einfügen.

Modus „Anhängen“ für mehrere Aggregationen: Über den Parameter Modus (Ersetzen = Standard, Anhängen) können mehrere Aggregations-Schritte in dieselbe Zielliste schreiben. So lassen sich steuerpflichtige und steuerfreie Positionen zu einer gemeinsamen Steuerpositionen-Liste kombinieren.

Listen 1:1 übernehmen: Tragen Sie bei Gruppieren nach den Spezialwert #Zeile ein, wird nicht gruppiert – jede Quellzeile wird unverändert zu einer Zielzeile, inklusive aller Textfelder. Gleich aussehende Zeilen werden dabei nicht zusammengefasst. Filter und berechnete Felder wirken weiterhin je Zeile.

Als Zahl aufbereitet werden dabei nur die Felder, für die Sie unter Normalisierung ausdrücklich Dezimal oder Prozent eingetragen haben. Alle übrigen Felder werden unverändert übernommen – auch dann, wenn sie wie eine Zahl aussehen. Das ist wichtig für Artikel- und Belegnummern: 0004711 bleibt 0004711 und wird nicht zu 4711,00. Umgekehrt gilt: Soll ein Betrag im Zielformat erscheinen oder in einem berechneten Feld verwendet werden, muss er unter Normalisierung als Dezimal deklariert sein.

Aggregationsfunktionen haben im #Zeile-Modus keine Wirkung, weil jede Gruppe nur aus einer Zeile besteht – sie werden übersprungen. Tragen Sie neben #Zeile noch weitere Feldnamen ein, gilt trotzdem die 1:1-Übernahme; die übrigen Einträge werden ignoriert und im Protokoll vermerkt.

Zahlformat der Ausgabe: Über den Parameter Zahlformat der Ausgabe legen Sie fest, ob Zahlen deutsch mit Komma (1234,56, Standard) oder invariant mit Dezimalpunkt (1234.56) geschrieben werden. Der Dezimalpunkt ist sinnvoll, wenn die Werte per Webhook an ein anderes System weitergegeben werden.

Steuerfreie Anteile (City Tax, IG-Lieferung, steuerfreie Leistungen): Ob eine Rechnung rein steuerpflichtig ist, eine steuerfreie kommunale Abgabe enthält (Hotel: City Tax, Bettensteuer, Kurtaxe) oder komplett steuerfrei ist (innergemeinschaftliche Lieferung, Ausfuhrlieferung), steht erst nach der Dokumenterkennung fest – nicht beim Einrichten der Dokumentenart. Die eingebaute Vorlage „Eingangsrechnungen (FIBU)“ deckt deshalb alle diese Fälle mit einer Konfiguration ab, statt eine Vorauswahl zu verlangen:

1. Steuerpflichtige Umsätze aus den Steuerdetails – eine Position je Steuersatz. Der Nettobetrag wird aus Steuerbetrag und Steuersatz zurückgerechnet; wurde auch der Bruttobetrag erkannt, gleicht ein Centausgleich die Positionen dagegen ab: Bei einer Position entspricht das Netto dann exakt Brutto − Steuer, bei mehreren wird die Rundungsdifferenz auf die betragsgrößte Position geschlagen – die Buchungszeilen summieren sich damit immer auf den Rechnungsbetrag, und WinLine meldet keine Cent-Differenz.
2. Summe der bereits erfassten Positionen.
3. Steuerfreier Rest = Gesamt-Netto minus steuerpflichtiges Netto. Ergibt sich ein Restbetrag, entsteht daraus eine eigene 0 %-Buchungszeile.

Damit wird die City Tax einer Hotelrechnung als Differenz erfasst (Gesamt-Netto minus Logis-Netto) – betragsgleich zur früheren Erkennung über die Positions-Beschreibung, aber ohne dass ein Suchbegriff gepflegt werden muss. Bei einer komplett steuerfreien Rechnung fehlt der steuerpflichtige Anteil, der gesamte Betrag wird zur 0 %-Zeile.

Zwei Absicherungen verhindern falsche 0 %-Zeilen:

• Restbeträge unter 0,50 € werden ignoriert. Das Netto je Steuersatz wird aus Steuerbetrag und Steuersatz zurückgerechnet, wodurch Cent-Differenzen entstehen – ohne diese Schwelle bekäme fast jede Rechnung eine überflüssige Kleinbetragszeile. Der Wert lässt sich im Pipeline-Editor je Mandant anpassen.
• Entspricht der Restbetrag genau der Umsatzsteuer, wurde vermutlich der Brutto- statt des Nettobetrags erkannt; in diesem Fall entsteht keine Zeile.

Bestehende Rechnungs-Pipelines werden beim Programmstart automatisch auf diese Kette aktualisiert, sofern sie unverändert aus einer der früheren Rechnungs-Vorlagen oder einem älteren Stand dieser Vorlage stammen. Selbst angepasste Aggregationen bleiben unberührt.

SQL-Lookup-Schritt

Der SQL-Lookup-Schritt führt eine SQL-Abfrage gegen die WinLine-Mandantendatenbank aus und übernimmt das Ergebnis in den Feld-Pool, z. B. die Kostenstelle zum erkannten Kreditor. Platzhalter wie {Kreditor.Kontonummer} werden sicher als Parameter übergeben. Im Modus „Erste Zeile“ wird jeder Spaltenalias ein Pool-Feld (SELECT ... AS Kostenstelle → {Kostenstelle}), im Modus „Liste“ entstehen nummerierte Einträge für alle Zeilen. Über das optionale Trefferanzahl-Feld können Folgeschritte per Bedingung reagieren (kein Treffer gilt nicht als Fehler).

Wichtig: Abfragen auf mandantenabhängige Tabellen müssen mesocomp = {Mandant} enthalten – das SQL wird nicht automatisch nach Mandant gefiltert. Für wirtschaftsjahresabhängige Tabellen steht zusätzlich {Mesoyear} bereit (das aktuelle Wirtschaftsjahr des Mandanten), z. B. mesoyear = {Mesoyear}. Erlaubt ist genau ein SELECT-, WITH- oder EXEC-Statement; bei gespeicherten Prozeduren liegt die Verantwortung, dass nur gelesen wird, beim Administrator. Der Pipeline-Testlauf führt nur die Extraktion aus – die Abfrage läuft dort nie.

Webhook-Schritt

Der Webhook-Schritt sendet einen HTTP-Request (POST oder PUT, immer Content-Type: application/json) an eine externe URL – z. B. um ein Fremdsystem über ein fertig analysiertes Dokument zu informieren oder die erkannten Werte dort weiterzuverarbeiten. Ziel-URL, Body und Kopfzeilen-Werte unterstützen Template-Expressions ({Feldname}), etwa https://fremdsystem.example/api/{Mandant}/{DokumentenId}.

Parameter:

• Ziel-URL (Pflicht) – mit Platzhaltern aus dem Feld-Pool.
• HTTP-Methode – POST (Standard) oder PUT.
• Body-Template – eigener Request-Body mit Platzhaltern. Bleibt das Feld leer, sendet der Schritt das Komplett-JSON (siehe unten).
• Zusätzliche Kopfzeilen (JSON) – Schlüssel-Wert-Objekt, z. B. {"x-api-key":"geheim"}; typischerweise der API-Schlüssel des Zielsystems. Auch die Werte unterstützen Platzhalter. Eine ungültige Angabe (kein JSON-Objekt) bricht den Schritt mit klarer Meldung ab, statt ohne die Kopfzeilen zu senden.
• Timeout – 5 bis 120 Sekunden (Standard 30).
• Retries bei Fehler – bei HTTP 5xx oder Timeout wiederholt der Schritt die Anfrage bis zu 3-mal (Standard 2, jeweils 1 Sekunde Pause). 4xx-Antworten werden bewusst nicht wiederholt – der Schritt schlägt sofort fehl.
• HMAC-Secret – signiert den Request (siehe unten).
• Bedingungen – wie bei jedem Schritt; sind sie nicht erfüllt, wird der Aufruf übersprungen.

Standard-Payload (leeres Body-Template): Der Empfänger erhält ein JSON-Objekt mit vier Feldern (Namen in camelCase): {"dokumentenId":35243,"mandant":"500M","ergebnis":{…},"felder":{"Rechnungsnummer":"RE-2026-0815",…}}. Dabei ist felder der komplette Feld-Pool zum Zeitpunkt des Schritts (alle Werte als Text) – die Position des Schritts in der Pipeline bestimmt also, welche Felder enthalten sind; ein Webhook am Ende der Pipeline sieht auch die Ergebnisse von Lookup-, Aggregations- und Buchungstext-Schritten. ergebnis ist das vollständige Erkennungsergebnis der Extraktion; seine innere Struktur hängt vom verwendeten Erkennungs-Provider ab. Für die meisten Integrationen ist felder die richtige Quelle.

Signatur prüfen (HMAC-Secret gesetzt): Der Schritt sendet zusätzlich die Kopfzeile X-Webhook-Signature: sha256=<hex> – ein HMAC-SHA256 über den rohen (UTF-8-kodierten) Request-Body mit dem hinterlegten Secret, Hex-Darstellung kleingeschrieben. Die Gegenstelle berechnet denselben Wert über den empfangenen Body und vergleicht; so ist sichergestellt, dass der Aufruf wirklich aus dem Archiv stammt und unterwegs nicht verändert wurde.

Weiterleitungen: Antwortet der Zielserver mit einer Umleitung (HTTP 3xx), folgt der Schritt ihr bewusst nicht – sonst gingen die konfigurierten Kopfzeilen (typischerweise der API-Schlüssel) an einen anderen Host. Tragen Sie die endgültige Adresse direkt ein; das Verarbeitungsprotokoll nennt in diesem Fall das Umleitungsziel.

Das Ergebnis jedes Aufrufs (HTTP-Status, bei Fehlern der Anfang der Antwort) steht im Verarbeitungsprotokoll. Der Pipeline-Testlauf führt nur die Extraktion aus – Webhooks feuern dort nie; zum Erproben eignet sich ein Testdokument gegen eine Test-Gegenstelle (siehe empfohlenes Vorgehen).

Zusatzaktionen (Vor-/Nach-Aktion je Schritt)

Jeder Pipeline-Schritt kann zusätzlich eine Vor-Aktion und eine Nach-Aktion bekommen – einen SQL-Aufruf gegen die WinLine-Mandantendatenbank, der unmittelbar bevor bzw. nachdem der Schritt läuft ausgeführt wird. Die Aktion sieht den kompletten Feld-Pool und kann Werte ergänzen, den Schritt dynamisch überspringen oder die gesamte Verarbeitung abbrechen – z. B. eine Plausibilitätsprüfung gegen die WinLine-Datenbank, bevor ein Fall angelegt wird. Im Pipeline-Editor erscheint dafür an jeder Schritt-Karte ein aufklappbarer Bereich „Zusatzaktionen“; konfigurierte Aktionen zeigt ein Kennzeichen „SQL“ an der Karte.

Drei reservierte Spaltenaliase steuern den Ablauf und landen selbst nie im Feld-Pool: Aktion.Skip (Schritt überspringen, nur in der Vor-Aktion wirksam), Aktion.Abbruch (Pipeline abbrechen, in Vor- und Nach-Aktion wirksam) und Aktion.Meldung (Begründungstext fürs Verarbeitungsprotokoll). Bei der Rückgabe „Ersetzen“ (Standard) gewinnt die Aktion gegenüber bereits gesetzten Werten – ein leer zurückgegebenes Feld leert den Wert bewusst; bei „Nur ergänzen“ werden nur fehlende oder leere Felder übernommen. Der Schalter „Fehler blockiert Schritt“ legt fest, ob ein Fehler der Zusatzaktion nur als Warnung erscheint (Standard) oder wie ein Schritt-Fehler behandelt wird.

Anwendungsfälle jenseits der Rechnung

Der Produktgrundsatz lautet: eine Pipeline, konfigurierbare Bausteine, keine Sonderlösungen. Ein Dokument wird entweder nur archiviert (sicher ablegen und durchsuchbar machen) oder zusätzlich in intelligente Prozesse überführt – und alles dazwischen bildet dieselbe Dokumentenpipeline ab. Die Pipeline ist dabei nicht auf Eingangsrechnungen beschränkt: Mit einem eigenen Extraktions-Prompt (freies JSON-Zielschema), einer eigenen Klassifizierungs-Beschreibung und ggf. einem eigenen KI-Profil lässt sich jede Dokumentenart abbilden – Zertifikate, Visitenkarten, Anfragen, Verträge, Lieferscheine und mehr. Dieser Abschnitt zeigt einen Gradienten praxisnaher Anwendungsfälle von minimal bis komplex – alle vollständig im aktuellen Funktionsumfang umsetzbar, ohne neue Schritte oder Code.

Querschnitt: Eigenes LLM (KI-Profile)

Ein „eigenes LLM“ wird als KI-Profil (auch LLM-Profil genannt) verwaltet (Verwaltung → Einstellungen → Erkennung & KI → KI-Zugänge, Berechtigung KI-Grundkonfiguration). Ein Profil bündelt Provider, Modell, Endpoint, API-Schlüssel, Temperatur, Token-Limit und Preise (bei Azure OpenAI zusätzlich die API-Version, z. B. 2024-11-01-preview); ein Profil kann als Standardprofil markiert werden. Die Preisfelder werden für bekannte Modelle automatisch aus dem Preiskatalog vorbelegt – mit den Listenpreisen der Anbieter in US-Dollar je 1 Mio. Token. Umgerechnet wird nicht, die Kostenschätzung der Token-Auswertung weist die Beträge deshalb in USD aus; von Hand eingetragene Preise gelten in der Währung, in der Sie sie erfassen. Unterstützte Provider: OpenAI, AzureOpenAI, Ollama, OpenAIKompatibel und Anthropic. Die KI-Profile sind die einzige Ablage für KI-Zugangsdaten: KI-Assistent, Chat-KI und alle Pipeline-Schritte referenzieren ein Profil, statt eigene Anbieter-/Endpunkt-/Schlüssel-Felder zu führen. Zugangsdaten, die früher direkt im KI-Assistenten oder in der Chat-KI hinterlegt waren, werden beim ersten Start automatisch in ein KI-Profil („KI-Assistent (migriert)“ bzw. „Chat-KI (migriert)“) überführt.

• Globales eigenes LLM: Das Standardprofil (bzw. das in der globalen KI-Assistent-Konfiguration gewählte KI-Profil) bestimmt, welches Modell für Extraktion, KI-Beschreibung und Buchungstext verwendet wird.
• Lokal / On-Premises (Datenschutz): Für sensible Dokumente kann ein lokales LLM eingesetzt werden, damit kein Dokumentinhalt die eigene Umgebung verlässt – Provider Ollama (Endpoint z. B. http://llm-server:11434/v1, API-Schlüssel leer lassen) oder OpenAIKompatibel (LM Studio, vLLM u. a.). OpenAI, AzureOpenAI, Ollama und OpenAIKompatibel laufen über die OpenAI-kompatible Schnittstelle /chat/completions; Anthropic wird nativ über /v1/messages angesprochen – ein Anthropic-Profil braucht also nur den API-Schlüssel, keinen OpenAI-kompatiblen Umweg-Endpunkt, und Token-Verbrauch sowie Kosten werden korrekt erfasst.
• Abweichendes LLM pro Dokumentenart: Das in der Dokumentenart gewählte KI-Profil bestimmt Provider, Endpoint, Modell und Schlüssel der Aufrufe für Extraktion (inklusive der Direktanalyse von E-Rechnungs-XML), KI-Beschreibung und Buchungstext. Ist dort kein Profil gewählt, gilt das Profil aus der globalen KI-Konfiguration und danach das Profil der globalen KI-Assistent-Konfiguration (ohne Auswahl: das Standardprofil).
• Abweichendes LLM pro Schritt: Zusätzlich lässt sich ein Profil direkt am Schritt wählen (KI-Profil) – verfügbar bei Extraktion, KI-Beschreibung, Gegenkonto-Ermittlung und Belegkategorie. Es hat Vorrang vor der Dokumentenart. Ebenfalls profilfähig sind Klassifizierung (Klassifizierungs-Profil je Dokumentenart), Testlauf und Mail-Plausibilitäts-Check. Der LLM-Rückfall bei schwacher Konfidenz (siehe Dokumentenerkennung einrichten) läuft innerhalb des Extraktion-Schritts und hat ein eigenes, globales Rückfall-Profil – kein eigener wählbarer Pipeline-Schritt. Praxis-Tipp: ein günstigeres (oder lokales) Modell nur für die Kontenzuordnung einsetzen, während die Extraktion mit dem leistungsfähigeren Standardmodell läuft.
• Reihenfolge: Schritt-Profil → Profil der Dokumentenart → globales Profil → Profil der globalen KI-Assistent-Konfiguration (ohne Auswahl: das Standardprofil). Das tatsächlich verwendete Profil steht im Verarbeitungsprotokoll am jeweiligen Schritt.
• Wenn ein Profil nicht verfügbar ist: Damit die Verarbeitung nicht stehen bleibt, läuft der Aufruf dann über das Standardprofil bzw. die globale KI-Konfiguration. Das Verarbeitungsprotokoll weist das ausdrücklich aus („Ersatz – Profil … nicht gefunden“ bzw. „global – Profil … nicht auflösbar“). Bei einem lokalen LLM aus Datenschutzgründen sollte dieser Hinweis geprüft werden: in diesem Fall wurde das Dokument über die globale Konfiguration verarbeitet.

Querschnitt: Eigene Prompts

Die Prompts sind pro Dokumentenart bzw. pro Schritt anpassbar – das ist der Hebel, mit dem eine neue Dokumentenart „gelesen“ wird, ganz ohne Programmierung:

Prompt	Wo konfiguriert	Wirkung
Extraktions-Prompt	Dokumentenart (LLM-Provider)	Freies JSON-Zielschema – bestimmt, welche Felder aus dem Dokument extrahiert und in den Feld-Pool gelegt werden (z. B. zertifikatNummer, norm, gueltigBis statt Rechnungsfeldern)
Klassifizierungs-Beschreibung	Dokumentenart	Steuert, woran die Dokumentenart erkannt wird (Heuristik-Stichworte + LLM-Klassifizierung)
System-Prompt	Schritt KI-Beschreibung	Override für die Zusammenfassung – z. B. fachspezifische Kurzbeschreibung
Buchungstext-System-Prompt	Schritt Buchungstext	Override für den generierten Buchungstext

Der Extraktions-Prompt endet konventionsgemäß mit „Antworte NUR mit dem JSON-Objekt. Setze null für nicht erkannte Felder.“ – so bleibt die Antwort maschinell auswertbar. Verschachtelte Listen (z. B. positionen) werden automatisch flach in den Pool gelegt (positionen/0/bezeichnung, positionen/1/bezeichnung, …) und lassen sich über „Je Zeile wiederholen“/„Liste verarbeiten“ (Feldname in der Zeile: Zeile/bezeichnung, siehe Schritte je Zeile wiederholen) weiterverarbeiten.

Die Klassifizierungs-Beschreibung wird zweifach genutzt: von der KI (die den Text versteht) und von einer vorgeschalteten schnellen Stichwort-Stufe, die im Text die Nennungen des am Dokument erkannten Begriffs zählt. Nennungen, die verneint sind („… – KEINE Rechnung“) oder auf eine andere Dokumentenart verweisen („Eingangsrechnungen gehören auf Dokumentenart 990“), zählen dabei nicht mit – solche Beschreibungen ziehen den Begriff also nicht mehr fälschlich an. Beschreiben Sie die Dokumentenart trotzdem am besten positiv mit ihren typischen Begriffen; passen mehrere Dokumentenarten gleich gut, entscheidet die KI.

Fall A – Minimal: Nur ablegen + Schlagworte

Dokumentenart: allgemeiner Beleg, Schriftverkehr. Quelle: Upload, E-Mail-Postfach.

Schrittkette (eingebaute Vorlage „Nur Archivierung“):

1. Extraktion – Klassifizierung + Texterkennung (OCR); der Volltext wird für die Suche indiziert. Ein LLM ist nicht zwingend nötig.
2. Schlagworte – setzt Archiv-Schlagworte aus dem Feld-Mapping und macht das Dokument filterbar.

Das Einstiegsbeispiel: sicher ablegen, durchsuchbar machen – mehr nicht.

Fall B – Archivieren + auffindbar machen (KI-Zusammenfassung, eigener Prompt)

Wie Fall A, plus der Schritt KI-Beschreibung mit eigenem System-Prompt, z. B.:

„Fasse das Dokument in maximal 3 Sätzen fachlich zusammen. Nenne den Absender und das Kernthema. Antworte ausschließlich mit der Zusammenfassung – ohne Einleitung.“

Die Zusammenfassung landet als Pool-Feld {KiBeschreibung} (z. B. für Schlagwort 95 „Langtext“), wird als KI-Notiz am Dokument gespeichert und in den Volltextindex aufgenommen – umfangreiche PDFs werden so später über ihren Inhalt gefunden. Datenschutz-Variante: den KI-Assistenten global auf ein lokales LLM stellen (siehe Fall F).

Fall C – Lieferant/Kreditor ermitteln und ggf. anlegen (eigenes Extraktions-Schema)

Dokumentenart: Zertifikat, Lieferantenerklärung, Vertrag. Quelle: Portal-Upload, E-Mail-Postfach.

Referenz: die eingebaute Vorlage „Zertifikat (Lieferant)“ – sie bringt einen eigenen Extraktions-Prompt (Felder: Zertifikatsnummer, Aussteller, Norm, Prüfgegenstand, Gültigkeit, Prüfergebnis, Zertifikatsinhaber) und eine eigene Klassifizierungs-Beschreibung mit.

1. Extraktion (eigener Prompt + Klassifizierungs-Beschreibung) – befüllt den Pool mit den fachlichen Feldern statt Rechnungsfeldern.
2. KI-Beschreibung (eigener System-Prompt) – fachliche Zusammenfassung des Zertifikats.
3. Stammdaten-Lookup (Personenkonto) – findet den Lieferanten über den Namen des Zertifikatsinhabers → {Kreditor.Kontonummer} im Pool.
4. Stammdaten-Lookup (Artikel) – ordnet den Prüfgegenstand einem Artikel zu.
5. Schlagworte – Kontonummer und -bezeichnung des Lieferanten, Zertifikatsnummer + Norm als Betreff, gefundene Artikelnummer, Zusammenfassung als Langtext. Der Schritt steht hinter den beiden Suchen, weil er deren Ergebnisse schreibt.
6. Fall-Anlage (CRM-Fall) – legt den Vorgang mit Start-/Enddatum aus der Zertifikats-Gültigkeit an.

Soll der Lieferant bei fehlendem Treffer automatisch angelegt werden, wird zusätzlich ein Schritt Stammdaten-Anlage (Kreditor, Lookup aktiv) vor der Fall-Anlage eingefügt: bei einem Treffer wird der bestehende Kreditor verwendet, sonst per ExIm-Vorlage neu angelegt.

Fall D – Visitenkarten-Scan → Ansprechpartner/Kontakt anlegen

Dokumentenart: Visitenkarte. Quelle: Upload (Foto/Scan).

Eingebaute Vorlage „Visitenkarte (Kontakt anlegen)“:

1. Extraktion (eigener Prompt) – extrahiert Vorname, Nachname, Firma, Position, Telefon, Mobil, E-Mail, Webseite und Adresse als freies JSON-Schema.
2. Stammdaten-Anlage (Kunde/Debitor) – finden oder anlegen: sucht die Firma zuerst als Debitor im WinLine-Kontenstamm (Name/USt-ID/Adresse, Suchfelder firmenname, ustId, strasse, plz); ohne Treffer wird das Kundenkonto per Debitor-ExIm-Vorlage neu angelegt. Die Kontonummer landet in beiden Fällen als {Personenkonto.Kontonummer} + {Personenkonto.Kontobezeichnung} im Pool.
3. Stammdaten-Anlage (Kontakt) – legt den Ansprechpartner per ExIm-Vorlage an und verknüpft ihn über die gefundene bzw. angelegte Kontonummer mit dem übergeordneten Konto (FK-Verknüpfung; View/Var müssen zur verwendeten ExIm-Vorlage passen).
4. Schlagworte – Person + Firma als Betreff, Kontobezeichnung als Filter.

Voraussetzung: In den KI-Grundeinstellungen muss eine Debitor-ExIm-Vorlage hinterlegt sein (Verwaltung → Einstellungen → Erkennung & KI → Dokumentenerkennung, Slot Debitor (Kunde) unter „ExIm-Vorlagen je Konto-Art“). Fehlt sie, meldet der Schritt einen klaren Protokollfehler – die Pipeline läuft weiter (das Dokument wird trotzdem archiviert).

Ehrlich benannt: Ein Kontakt-Lookup existiert nicht – der Ansprechpartner wird immer neu angelegt (kein Dublettencheck). Wird dieselbe Visitenkarte zweimal verarbeitet, entsteht ein doppelter Kontakt. Das Kundenkonto selbst wird dagegen dedupliziert (Lookup vor Anlage).

Variante „Visitenkarte (CRM-Fall)“: Die zweite eingebaute Visitenkarten-Vorlage ergänzt eine Fall-Anlage (CRM-Fall, kein BelegPro) – die Visitenkarte hängt als Anhang am Fall, Kurzbeschreibung („Vorname Nachname · Firma“) und Startdatum werden gemappt, das Kundenkonto kommt automatisch über die Partner-Verknüpfung. Zwei Dinge unterscheiden sie von „Kontakt anlegen“:

1. Konfidenz-Bedingung (bewusst vorsichtig): Der Extraktions-Prompt fordert je Feld eine Erkennungs-Sicherheit an (feldKonfidenzen), die als Pool-Variablen Konfidenz.Feldname (0–100 %) bereitstehen. Kundenkonto- und Kontakt-Anlage laufen nur bei Konfidenz.firmenname über 70 % – ist die Firma unsicher erkannt (oder liefert das Modell keine Konfidenzen), werden beide Schritte übersprungen und der Fall entsteht mit leerem Kundenkonto zum manuellen Nachtragen. Die Schwelle ist eine normale Schritt-Bedingung und im Pipeline-Editor anpassbar.
2. Mandantenspezifische Pflichtangaben: Wie bei allen Fall-Vorlagen sind Workflow-Nummer und CRM-Vorlage nach dem Anwenden einzutragen (Schritt-Parameter der Fall-Anlage bzw. Dokumentenart-Konfiguration).

Fall E – Angebotsanfrage → CRM-Fall „Anfrage bearbeiten“

Dokumentenart: Angebotsanfrage/Anfrage (Heuristik erkennt „Angebot“, „Offerte“, „Quotation“, „Preisanfrage“). Quelle: E-Mail-Postfach, Upload.

Der komplexeste Fall – eingebaute Vorlage „Angebotsanfrage (CRM-Fall)“ – bündelt alle Bausteine inkl. eigenem Prompt:

#	Schritt	Beitrag
1	Extraktion (eigener Prompt)	Kunde, USt-ID, Ansprechpartner, Betreff, Wunschtermin, angefragte Positionen (positionen/*)
2	KI-Beschreibung (eigener System-Prompt)	Zusammenfassung „Wer fragt was in welcher Menge bis wann an“ → {KiBeschreibung}
3	Stammdaten-Lookup (Kunde/Debitor)	Kunde über Name, USt-ID oder – bei Eingang per Postfach – die Absenderadresse suchen → {Personenkonto.Kontonummer} (für die Partner-Verknüpfung des Falls), bei Treffer über die Absenderadresse auch {Personenkonto.Ansprechpartner}
4	Stammdaten-Anlage (Kunde/Debitor)	nur ohne Treffer und mit erkanntem Firmennamen: Kunde per Debitor-ExIm-Vorlage anlegen
5	Stammdaten-Lookup (Artikel, Liste verarbeiten über positionen)	angefragte Artikel je Position → positionen/{Index}/GefundeneArtikelNr
6	Schlagworte	Betreff, Kundenkonto, erste Artikelnummer, Zusammenfassung als Filter
7	Fall-Anlage (CRM-Fall)	legt den CRM-Fall an; Kurz-/Langbeschreibung, Start-/Endtermin, Kundenkonto und Kontakt Kunde werden auf T170-Felder gemappt

Der Fall-Typ ist frei über die Workflow-Nummer wählbar (z. B. ein Workflow „Anfrage bearbeiten“). Da Workflow-Nummern mandantenspezifisch sind, ist sie in der Vorlage bewusst nicht vorbelegt – nach dem Anwenden der Vorlage im Schritt-Parameter WorkflowNummer (oder in der Dokumentenart-Konfiguration) eintragen. Bei Bedarf lässt sich ein Schritt Stammdaten-Anlage (Kontakt) ergänzen, der den Ansprechpartner am gefundenen Kundenkonto anlegt (wie in Fall D).

Fall F – Datenschutz-Variante mit lokalem LLM (On-Premises)

Ein sensibler Dokumententyp (z. B. Personalunterlage, Vertrag mit personenbezogenen Daten) wird bewusst über ein lokales LLM verarbeitet, damit kein Inhalt die eigene Umgebung verlässt:

1. Profil anlegen: Verwaltung → Einstellungen → Erkennung & KI → KI-Zugänge → Neues Profil, Provider Ollama (Endpoint z. B. http://llm-server:11434/v1, Modell z. B. llama3.1, API-Schlüssel leer) oder OpenAIKompatibel (LM Studio, vLLM).
2. Nur diese Dokumentenart lokal: In der Dokumentenart das lokale KI-Profil wählen – Extraktion (auch die XML-Direktanalyse von E-Rechnungen), KI-Beschreibung und Buchungstext dieser Dokumentenart laufen dann über das lokale Modell, alle anderen Dokumentenarten unverändert weiter.
3. Alles lokal: Alternativ den KI-Assistenten (bzw. das Standardprofil) auf das lokale Profil stellen – damit laufen sämtliche Dokumentenarten lokal.
4. Pro Schritt: Einzelne Schritte (Extraktion, KI-Beschreibung, Gegenkonto-Ermittlung, Belegkategorie, Klassifizierung, LLM-Fallback) können zusätzlich gezielt ein abweichendes Profil bekommen; das Schritt-Profil hat Vorrang vor der Dokumentenart.

Fall G – Weitere praxisnahe Fälle (Skizzen)

• Lieferschein → Vorgang-Suche gegen die bestehende Bestellung: bei Treffer wird ein Folgeschritt am vorhandenen Fall geschrieben statt ein neuer Fall angelegt.
• Eingangslieferschein → WinLine-Lieferschein ohne CRM-Fall → Vorgang-Suche mit Belegstufen 3,-3, Suchspalte „Auftragsnummer“, Richtung Einkauf, Partner-Feld {Kreditor.Kontonummer|Portal.Kontonummer} und Zuordnung „Beleg direkt“: Der Lieferschein des Lieferanten trägt unsere Bestellnummer (z. B. im Pool-Feld Bestellreferenz, gewählt über Pool-Felder für die Suche); das Dokument wird ohne SQL-Lookup und ohne Fall direkt am gefundenen WinLine-Lieferschein verknüpft und per Schlagworte-Schritt aus {Vorgang.Auftragsnummer} und {Vorgang.Kontonummer} beschlagwortet. Bei Teillieferungen wird nicht automatisch verknüpft: zusätzliches Kriterium per SQL-Lookup → BelegKeyFeld vorgeben oder bewusst an die Bestellung (2,-2) zuordnen.
• Eingangslieferschein → Bestellung ohne CRM-Fall → Vorgang-Suche mit Belegstufen 2,-2, Richtung Einkauf und Zuordnung „Beleg direkt“: Dieselbe Bestellnummer, aber die Verknüpfung entsteht an der Bestellung statt am Lieferschein. Für Installationen ohne Belegworkflow der Normalfall – und die Abhilfe, wenn Teillieferungen den Lieferschein nicht eindeutig machen.
• Zuordnung über die Bezugsnummer des Lieferanten → SQL-Lookup ermittelt den Belegschlüssel (T025/C000) aus der Lieferscheinnummer des Partners und legt ihn in ein Pool-Feld; Vorgang-Suche mit Zuordnung „Beleg direkt“ und BelegKeyFeld verknüpft ohne eigene Suche.
• Eingangsrechnung → Lieferschein → Vorgang-Suche mit Belegstufen 3,-3, Richtung Einkauf und Partner-Feld {Kreditor.Kontonummer|Portal.Kontonummer}: die Rechnung findet den Lieferschein desselben Lieferanten (der Partnerfilter verhindert Fehlzuordnungen, weil Lieferscheinnummern vom Partner vergeben werden). In Kette mit einer zweiten Vorgang-Suche (Standard-Belegstufen) gilt „erst Lieferschein, sonst Bestellung“.
• Ausgangslieferschein → Kundenauftrag → Vorgang-Suche mit Belegstufen 2,-2, Richtung Verkauf und Partner-Feld {Debitor.Kontonummer}: dieselbe Mechanik in Verkaufsrichtung, der Beleg wird dem bestehenden Kundenauftrags-Fall zugeordnet. Wichtig ist die -2: sobald der Lieferschein existiert, steht der Auftrag in der Belegdatei meist als „Auftrag, der in Lieferschein umgewandelt wurde“ (Belegstufe -2) – mit nur 2 würde genau dieser Normalfall verfehlt.
• Freie Suchkriterien (z. B. Charge, Projekt) → SQL-Lookup ermittelt die Fall-Id mit einer eigenen Abfrage und legt sie in den Pool; Vorgang-Suche übernimmt sie im Modus „Fall-Id aus Pool“ (Parameter Pool-Feld mit fertiger Fall-Id) und führt nur noch Folgeschritt und Verknüpfungen aus.
• Vertrag mit Fristen → Fall-Anlage (CRM-Fall) mit Enddatum aus dem extrahierten Ablaufdatum, plus E-Mail- oder Webhook-Schritt mit Bedingung auf das Ablaufdatum als Fristerinnerung.
• Preisliste/Katalog → Stammdaten-Lookup (Artikel) je Position (Liste verarbeiten wie in Fall E), Ergebnis für Mappings und Prüfprozesse. Fertig vorkonfiguriert als eingebaute Vorlage Lieferantenpreisliste (Artikel anlegen bzw. bepreisen, s. Vorlagen-Tabelle oben).
• Mahnung / Kontoauszug → Personenkonto-Zuordnung per Stammdaten-Lookup, Schlagworte und E-Mail-Benachrichtigung an die Buchhaltung.
• Gegenkonto-Ermittlung mit eigenem KI-Profil → ein separates (günstigeres oder lokales) Modell nur für die Kontenzuordnung – der Schritt Gegenkonto-Ermittlung ist der Referenzfall für ein wirksames Profil pro Schritt.

Grenzen des aktuellen Funktionsumfangs

Damit Erwartungen realistisch bleiben – diese Punkte sind Kandidaten für künftige Erweiterungen:

• Eigenes LLM pro Schritt: direkt am Schritt wählbar bei Extraktion, KI-Beschreibung, Gegenkonto-Ermittlung und Belegkategorie; Klassifizierung, LLM-Fallback, Testlauf und Mail-Check nutzen ihr jeweils eigenes Profil. Alle übrigen Schritte folgen dem Profil der Dokumentenart bzw. der globalen KI-Assistent-Konfiguration.
• Rückfall bei nicht verfügbarem Profil: Ist ein gewähltes Profil gelöscht oder nicht lesbar, wird der Aufruf nicht abgebrochen, sondern läuft über das Standardprofil bzw. die globale KI-Konfiguration – sichtbar gekennzeichnet im Verarbeitungsprotokoll. Ein harter Abbruch (statt Rückfall) ist derzeit nicht konfigurierbar.
• Unterstützte Schnittstellen: OpenAI, Azure OpenAI, Ollama und OpenAI-kompatible Dienste werden über /chat/completions angesprochen, Anthropic nativ über /v1/messages. Andere Protokolle werden nicht unterstützt.
• Artikel-Anlage: Benötigt eine passende WinLine-Import-Vorlage. Die eingebaute Dublettenprüfung verwendet dokumentweite Artikelfelder oder eine einzelne erkannte Position; bei mehreren Positionen „Je Zeile wiederholen“ verwenden oder die Stammdaten-Suche vorschalten.
• Kein Kontakt-Lookup: Die Kontakt-Anlage legt immer neu an (kein Dublettencheck).

Alle Konto-Arten: finden oder anlegen

Personenkonten sind nicht auf Kreditor und Debitor beschränkt. Die Schritte Stammdaten-Lookup und Stammdaten-Anlage arbeiten mit allen Konto-Arten des WinLine-Kontenstamms – auswählbar als Konto-Art bzw. Stammdaten-Typ:

Konto-Art	Kennzeichen (T055/C004)
Kreditor (Lieferant)	3 (Standard)
Debitor (Kunde)	2
Interessent	4
Anfragelieferant	5

Ein eigenes Feld-Mapping ist für jede dieser Arten möglich: Im Feld-Mapping-Editor steht im Abschnitt Stammdaten die Spalte Typ zur Auswahl (Kreditor, Debitor, Interessent, Anfragelieferant, Ansprechpartner). Die Mappings dieses Abschnitts bilden die Felder aus der Erkennung auf die WinLine-Zielfelder ab – daraus entsteht die Feldliste für die Anlage. Ein Mapping ohne Typ gilt für alle Arten.

Damit die Anlage die richtige Konto-Art erzeugt, muss das Kennzeichen gesetzt sein – entweder durch die gewählte Import-Vorlage oder als Pflichtfeld T055/C004 im Schritt (so machen es die eingebauten Vorlagen mit 2 für Debitor).

Die Nummer des angelegten Datensatzes wird anschließend immer zurückgemeldet: bevorzugt aus der Antwort des WinLine-Imports, andernfalls über eine erneute Suche. Sie steht damit Folgeschritten zur Verfügung (z. B. für die Kontakt-Verknüpfung oder die Partner-Zuordnung eines CRM-Falls) – auch bei einer Kontakt-Anlage, für die es keine Suche gibt.

Eigene Feldnamen: das Partner-Pool-Feld

Wohin die gefundene bzw. angelegte Kontonummer geschrieben wird, bestimmt das Ergebnisfeld des Schritts – der Name ist frei wählbar. Die eingebauten Rechnungs-Vorlagen verwenden Kreditor.Kontonummer; für andere Anwendungsfälle ist z. B. Personenkonto.Kontonummer genauso möglich.

Damit Fall-Anlage und BelegPro den Wert auch unter einem eigenen Namen finden, gibt es pro Dokumentenart die Einstellung Partner-Pool-Feld (Verwaltung → Einstellungen → Erkennung & KI → Dokumentenerkennung, Spalte in der Dokumentenarten-Tabelle). Gesucht wird in dieser Reihenfolge:

1. das dort eingetragene Feld (z. B. Personenkonto.Kontonummer),
2. Kreditor.Kontonummer,
3. Portal.Kontonummer (angemeldeter Geschäftspartner bei Portal-Uploads).

Bleibt die Einstellung leer, gilt unverändert die Konvention aus 2. und 3. – bestehende Konfigurationen verhalten sich also genau wie bisher. In Feld-Mappings wird der Wert wie gewohnt als {Feldname} referenziert, bei Bedarf mit Alternativen: {Personenkonto.Kontonummer|Kreditor.Kontonummer}.

Universelles Feld-Mapping

Das Feld-Mapping-System steuert, wie Felder aus der KI-Dokumenterkennung auf WinLine-Zielfelder abgebildet werden. Alle Vorlagen und Felder werden über Auswahllisten gewählt – eine manuelle ID-Eingabe ist nicht erforderlich.

BelegPro-Zielfelder (FIBU/FAKT): Für BelegPro-Buchungen und -Belege stehen die Zielfelder als vollständige, nach Bereich gruppierte und durchsuchbare Auswahlliste bereit – auch im KI-Pipeline-Editor. Jeder Eintrag zeigt Bezeichnung und Element-Nummer. Über die Schaltfläche Feldreferenz bzw. das Hilfe-Symbol neben dem Mapping-Abschnitt lässt sich nachschlagen, welche Feldnummer für welchen Wert steht. Zeilen- und Positionsfelder (z. B. FAKT-Positionen, FIBU-Steuerzeilen) werden pro Zeile geschrieben; die Wildcard-Variante (…Z*) bildet automatisch alle Zeilen ab. Wird ein Feld benötigt, das nicht in der Liste steht, kann die Nummer weiterhin über Freier Key direkt eingegeben werden.

Unterstützte Aktionen:

• CRM-Fall (Feldliste): Erzeugt einen CRM-Fall mit konfigurierbaren Feldern aus einer ExIm-Vorlage
• Template-Ausdrücke: Zusammengesetzte Werte wie {VendorName} - RE {InvoiceId}
• Kreditor-/Kontakt-Anlage: Automatische Stammdatenpflege basierend auf Mappings

CRM-Fall-Mapping konfigurieren:

1. Unter Verwaltung → Einstellungen → Dokumentenarten die gewünschte Dokumentenart öffnen
2. Aktion auf CRM-Fall (Feldliste) setzen
3. CRM-Vorlage aus der Auswahlliste wählen (die verfügbaren Vorlagen werden automatisch vom WinLine-Server geladen)
4. Zeile aufklappen (Detail-Bereich): Hier erscheint ein Mapping-Tabelle mit den Feldern der gewählten Vorlage
5. Pro Feld einen Quellausdruck definieren – entweder ein einzelnes KI-Feld (z. B. InvoiceId) oder ein Template-Ausdruck (z. B. {VendorName} - RE {InvoiceId})

Kontakt-Anlage konfigurieren:

• Im Detail-Bereich jeder Dokumentenart kann der Kontakt-Anlage-Modus festgelegt werden:
  • Deaktiviert: Keine automatische Kontakt-Anlage
  • Automatisch: Bei jedem erkannten Dokument einen Ansprechpartner anlegen
  • Manuell: Erfordert manuelle Bestätigung
• Die Kontakt-Vorlage wird ebenfalls aus einer Auswahlliste gewählt

Globales CRM-Fall-Mapping: In den KI-Einstellungen kann eine zentrale CRM-Vorlage gewählt werden. Deren Felder dienen als Zielfelder für alle CRM-Fall-Mappings. Das globale Mapping-Tabelle erlaubt die Zuordnung von KI-Quellfeldern bzw. Template-Ausdrücken zu den Vorlagenfeldern.

Vorlagenbasierte Zielfelder: Die Zielfelder in allen Mapping-Tabelles (CRM-Fall, Kreditor, Kontakt, BelegPro) stammen dynamisch aus der jeweils gewählten ExIm-Vorlage. Beim Klick auf Standard-Mapping laden werden Standardwerte geladen und gegen die tatsächlichen Vorlagenfelder geprüft – Felder, die in der Vorlage nicht vorhanden sind, werden übersprungen und eine Hinweismeldung angezeigt.

Quellfeld und Konstante / Template: Jede Zuordnungszeile kann ein Quellfeld (erkanntes Dokumentfeld oder Pool-Feld der Pipeline) und eine Konstante bzw. ein Template tragen. In allen Kategorien gilt dieselbe Regel: Das Quellfeld zählt, wenn es einen Wert liefert – sonst die Konstante. Eine Zeile mit beiden Angaben bedeutet „Quellfeld, ersatzweise Konstante“; die Vorschau-Spalte zeigt den Wert, den der Lauf nimmt, und nennt den Rückfall im Tooltip. Alle Feld-Zuordnungen – globales Mapping, Dokumentenart, Pipeline-Editor, GMI-Abgleich – verwenden dieselbe Tabelle mit denselben Spalten. Die Spalte Typ gibt es nur im globalen Stammdaten-Mapping; im Pipeline-Editor gehört das Mapping zum Schritt, das Zielfeld kommt aus dessen Vorlage und lässt sich notfalls als Tabelle:Spalte (z. B. 55:3) eintippen. In schmalen Fenstern blendet die Tabelle zuerst Vorschau und Format aus; beide bleiben über das Aufklapp-Symbol am Zeilenanfang erreichbar.

Standard-Mapping laden: Die Schaltfläche belegt die üblichen Zuordnungen vor, statt sie einzeln zusammenzusuchen – verfügbar für Stammdaten, BelegPro FIBU und BelegPro FAKT. Der FAKT-Standard belegt Rechnungsnummer, Belegdatum, die Kontrollsummen Summe brutto/netto und die Prüffelder Prüfung IBAN / Prüfung UID-Nummer vor – ohne Positionsfelder. Das ist Absicht: so entsteht ein reiner Belegkopf, und WinLine übernimmt die Positionen bei einer Vorbeleg-Zuordnung unverändert aus dem Vorbeleg. Wer eigene Positionen mappen will, ergänzt sie danach.

Bestehende FAKT-Zuordnungen aus früheren Programmversionen (T339-Felder, „Kumulierter Zahlungsbetrag“, veralteter Positions-Gesamtwert) werden beim Programmstart automatisch auf die korrekten Belegeingang-Felder umgeschlüsselt – in allen Mandanten, im globalen Mapping wie in den Zuordnungen der Dokumentenarten. FIBU-Zuordnungen bleiben unberührt.

ExIm-Vorlagen: Alle Vorlagen-Auswahlen (CRM, Kreditor, Kontakt) werden als Auswahlliste dargestellt. Die Vorlagen und deren Felder werden automatisch vom WinLine-Server geladen.

Format-Spalte: Jedes Mapping-Tabelle (CRM-Fall, Schlagworte, Kreditor, Kontakt, BelegPro) hat eine optionale Spalte Format. Ist ein Format eingetragen, übersteuert es die automatische Datumsnormalisierung, die sonst nur für erkannte BelegPro-Datumsfelder (z. B. Belegdatum) automatisch greift. Bei KI-Feldern (LLM-Extraktion) empfiehlt es sich, den Wert kanonisch von der KI liefern zu lassen (z. B. immer als Datum, ohne eigene Formatierungswünsche im Prompt) und die gewünschte Darstellung stattdessen über die Format-Spalte am Zielfeld zu steuern – so bleibt die Erkennung robust, unabhängig davon, in welcher Schreibweise das Ausgangsdokument das Datum enthält.

Format und Vorschau. Neben jeder Zuordnung lässt sich ein Ausgabeformat wählen – etwa dd.MM.yyyy für ein Datum oder N2 für einen Betrag mit zwei Nachkommastellen. Die Auswahlliste zeigt zu jedem Muster den Wert, den es erzeugt; eigene Muster können eingetippt werden. Die Vorschau-Spalte rechnet mit Musterwerten und macht sichtbar, ob ein Muster wirkt. Die deutsche Schreibweise TT.MM.JJJJ ist kein gültiges Muster und wird als solches gemeldet. Über das Stift-Symbol in der Spalte „Konstante / Template“ öffnet sich ein Editor, in dem sich Feldwerte, Fallback-Ketten und feste Texte zu einem Ausdruck kombinieren lassen. Die vollständige Musterübersicht steht in der Online-Hilfe unter „Format und Ausdrücke im Feld-Mapping“.

Manueller Upload (Standardwerte)

Die Karte Manueller Upload unter Eingang & Quellen legt je Mandant die Standard-Dokumentenart für den Schnell-Upload und für archivierte Bestellungen fest. Sie gilt für alle Benutzer des Mandanten; die persönliche Standard-Dokumentenart im Benutzerprofil hat für den jeweiligen Benutzer Vorrang.

GetMyInvoices-Anbindung (GMI)

Anbindung des Dienstes GetMyInvoices (GMI) für den automatischen Empfang von Eingangsrechnungen.

• Einstellungen je Mandant: Die Auswahl „Einstellungen gelten für“ oben auf der Seite bestimmt, für wen die Einstellungen gelten. Alle Mandanten (Standard) pflegt die installationsweiten Werte; ein gewählter Mandant überschreibt nur die Verarbeitungswerte (Standardwerte, Lieferanten-Zuordnungen, Feld-Zuordnung) – Verbindung und Zugangsdaten bleiben immer installationsweit (ein GetMyInvoices-Konto für alle Mandanten). Solange ein Mandant keine eigenen Werte gespeichert hat, gilt der Standard; „Mandanten-Einstellungen zurücksetzen“ entfernt die mandantenspezifischen Werte wieder. Die Karte „Einstellungen von Mandant übernehmen“ in der Workflow-Verwaltung kopiert den Bereich „GetMyInvoices“ zwischen Mandanten – ohne Zugangsdaten.
• Empfangsadresse: Fest eingestellte Adresse, die in den GetMyInvoices-Einstellungen eingetragen wird.
• Zugangsdaten: Authentifizierungsgeheimnisse (unverschlüsselt in der Datenbank der Anwendung gespeichert, nach dem Speichern nur maskiert angezeigt).
• Standardeinstellungen: Dokumentenart, Folgeaktion, Workflow-Nummer und ob Kreditoren automatisch angelegt werden sollen.
• Lieferanten-Abgleich: Automatische oder manuelle Zuordnung von WinLine-Kreditoren zu GetMyInvoices-Lieferanten. Sichere Treffer (über Umsatzsteuer-ID, Kontonummer oder exakten Namen) werden automatisch zugeordnet; unsichere Treffer zur manuellen Entscheidung markiert.
• Abweichende Einstellungen je Lieferant: Pro Lieferant können Dokumentenart, Aktion und Workflow-Nummer vom Standard abweichen.
• Feld-Zuordnung: Festlegung, welche GetMyInvoices-Felder auf welche Schlagworte oder Buchungsfelder abgebildet werden.
• Automatische Bestell-Zuordnung: Rechnungen mit erkannter Bestellnummer werden über den Pipeline-Schritt Vorgang-Suche dem bestehenden Bestell-Vorgang zugeordnet (Folgeschritt „Rechnung eingetroffen“ statt neuem Fall) – derselbe Mechanismus wie bei manuellen Uploads und E-Mail-Eingängen. Voraussetzung: Der Schritt Vorgang-Suche ist in der Pipeline der Dokumentenart enthalten (bei den eingebauten Rechnungs-Vorlagen der Fall) und der „Rechnung eingetroffen“-Schritt ist in den Workflow-Einstellungen des Mandanten hinterlegt.
• Webhook-Journal: Übersicht aller eingegangenen Übertragungen mit Status und Fehlerdetails – auch der abgewiesenen und der doppelten. Damit lässt sich die Frage „der Beleg ist in GetMyInvoices synchronisiert, warum liegt er bei uns nicht?“ ohne Datenbankzugriff beantworten.
  • Abgewiesene Übertragungen: Eine Übertragung, die wegen deaktivierter Anbindung, falschem Kennwort, fehlendem Anhang oder eines in der Mandanten-Freischaltung gesperrten Ziel-Mandanten zurückgewiesen wurde, erscheint mit dem Status Abgewiesen und dem Grund. Ohne diesen Eintrag wäre „abgewiesen“ nicht von „nie eingegangen“ zu unterscheiden. Das übermittelte Kennwort wird dabei nicht gespeichert.
  • Dubletten: Wird derselbe Beleg erneut übertragen, entsteht kein zweites Archivdokument. Die Wiederholung erscheint als Dublette mit Verweis auf das bereits archivierte Dokument.
  • Suche und Filter: Freitextsuche über Lieferant, Rechnungsnummer und Dateiname; eine reine Zahl trifft zusätzlich die GetMyInvoices-Nummer und die Dokument-Nummer. Dazu Filter nach Status und Mandant. Ohne gewählten Mandanten liest die Ansicht über alle Mandanten – das ist Benutzern ohne Mandanten-Einschränkung vorbehalten.
  • Sprung ins Ergebnis: Dokument- und Fall-Nummer sind verlinkt und öffnen das Archivdokument bzw. die Aufgabe.
  • Erneut verarbeiten: Verarbeitet einen bereits archivierten Beleg nach der aktuellen Konfiguration erneut – etwa nachdem ein Lieferant zugeordnet oder eine Feld-Zuordnung korrigiert wurde. Existiert bereits ein Fall, wird vor dem Anlegen eines zweiten nachgefragt. Bei einer abgewiesenen Übertragung gibt es kein Dokument; sie muss in GetMyInvoices erneut angestoßen werden.
  • Aufbewahrung: In Tagen einstellbar (Vorgabe 90). Ältere Einträge werden automatisch entfernt.

Mail-Postfach einrichten

Über die Eingangsquelle E-Mail-Postfach (Verwaltung → Einstellungen → Eingang & Quellen → E-Mail-Postfach) holt die Anwendung eingehende Dokumente automatisch aus IMAP- oder Microsoft-365-Postfächern ab. Pro Mandant lassen sich beliebig viele Profile anlegen. Die Seite ist in die Bereiche Profile, Quarantäne und Verarbeitung gegliedert.

Profil anlegen (Schritt für Schritt):

1. Neues Profil wählen – es öffnet sich ein Editor mit den Tabs Verbindung, Verarbeitung und Plausibilität.
2. Verbindung: Protokoll wählen.
   • IMAP: Server, Port, SSL/TLS, Benutzername und Passwort eingeben.
   • Microsoft 365 (Graph): UPN des Postfachs (die Adresse, auch bei einem geteilten Postfach) sowie Tenant-ID, Client-ID und Client-Secret der registrierten App eingeben. Die App braucht die Anwendungsberechtigung Mail.ReadWrite, möglichst auf die angebundenen Postfächer beschränkt. Eine App-Registrierung genügt für mehrere Postfächer, je Postfach wird ein eigenes Profil angelegt. Einrichtung in Entra ID und Exchange Online: Installationsanleitung, Abschnitt „Microsoft-365-Postfach anbinden“.
   • Zugangsdaten werden verschlüsselt gespeichert und beim erneuten Bearbeiten nicht angezeigt (Feld leer lassen = unverändert übernehmen).
3. Ordner: Posteingang festlegen und optional Ordner für Archiviert, Fehler, Quarantäne (Prüfen) und Ignoriert angeben. Verarbeitete Mails werden in den jeweiligen Ordner verschoben. Unterordner werden bei Microsoft 365 als Pfad mit / angegeben, z. B. INBOX/Scan für den Unterordner Scan im Posteingang oder INBOX/Scan/Archiviert als Zielordner. Fehlende Zielordner werden an dieser Stelle angelegt (der Posteingang selbst muss bestehen), ein Name ohne / meint wie bisher einen Ordner der obersten Ebene. Bei IMAP gilt die Schreibweise des Mailservers (z. B. INBOX/Scan oder INBOX.Scan).
4. Verarbeitung: Die Ziel-Dokumentenart wählen und das Abrufintervall (60–3600 Sekunden) festlegen. Ohne Auswahl wird der Anhang nur archiviert (keine KI-Verarbeitung). Alternativ kann Dokumentenart automatisch erkennen aktiviert werden: Die KI klassifiziert dann jeden Anhang anhand der Klassifizierungs-Beschreibungen aller Dokumentenarten (wie beim Hochladen ohne gewählte Dokumentenart) und startet die Pipeline der erkannten Art – geeignet für gemischte Postfächer mit unterschiedlichen Dokumenttypen an derselben Adresse. Unsicher erkannte Anhänge bleiben ohne Dokumentenart archiviert (nur Ablage und Suche, keine Quarantäne); das Verarbeitungsprotokoll dokumentiert das Erkennungsergebnis.
5. E-Mail selbst archivieren: Nie (Standard), Nur ohne Anhang oder Immer – jeweils sofern die Plausibilitätsprüfung die E-Mail durchlässt (eine E-Mail, deren Anhang die Strukturprüfung nicht besteht, landet als Ganzes in der Quarantäne). Damit wird die E-Mail als .eml-Dokument archiviert und durchläuft die Pipeline ihrer Dokumentenart – sinnvoll für Anfragen oder Reklamationen, die als reiner Mailtext eingehen. Bei Immer ist die E-Mail das Hauptdokument, die Anhänge werden daran geklammert. Voraussetzung für Mails ohne Anhang: unter Plausibilität muss Trotzdem verarbeiten gewählt sein. Nur überwachen: Für Team-Postfächer (z. B. Support), die nicht geleert werden sollen. Jede neue Mail läuft als .eml (Anhänge darin enthalten) durch die Pipeline der Dokumentenart, wird aber weder vorab archiviert noch verschoben – sie bleibt im Posteingang. Archiviert wird nur, was ein Pipeline-Schritt braucht, etwa Fall anlegen mit einer Schritt-Bedingung: Legt er einen Fall an, wird die Mail archiviert und am Fall verknüpft; alle anderen Mails bleiben unangetastet. Erfasst werden nur Mails, die nach dem Einschalten eingehen, auch nach erneutem Einschalten oder einem Wechsel des Postfachs – oder ab dem Stichtag Mails ab, falls gesetzt. E-Mail selbst archivieren ist in diesem Modus ohne Wirkung. Voraussetzung: bei Mails ohne Anhang ist Trotzdem verarbeiten gewählt. Die Plausibilitätsprüfung läuft weiter; auffällige Mails erscheinen in der Quarantäne-Liste, bleiben aber ebenfalls im Posteingang. Freigeben verarbeitet eine solche Mail direkt aus dem Posteingang, Verwerfen erledigt nur den Eintrag. Scheitert die Verarbeitung einer Mail, erscheint sie ebenfalls in der Quarantäne (Stufe Verarbeitung); Freigeben versucht es erneut. Nicht archivierte Mailinhalte werden nach der Aufbewahrungsfrist der Eingänge (Standard 7 Tage) gelöscht. Enthält die Pipeline einen KI-Schritt, geht jede Mail des Postfachs an das Sprachmodell. Passende Ausgangspunkte sind die Vorlagen Reklamation aus Postfach und Serviceanfrage aus Postfach: Sie legen nur für relevante Mails bekannter Kunden einen CRM-Fall an. Angebotsanfrage aus Postfach legt ihn für jede relevante Anfrage an, auch von Interessenten ohne Kundenkonto. Mails ab (Stichtag): Ohne Stichtag holt der Abruf den gesamten Posteingang – gelesen oder ungelesen spielt keine Rolle – und verschiebt ihn Abruf für Abruf (25 Mails je Durchlauf) in die Zielordner. Wer ein bereits genutztes Postfach neu einbindet, setzt deshalb einen Stichtag: Nur Mails, die ab diesem Tag beim Mailserver eingegangen sind, werden abgerufen; ältere bleiben unangetastet im Posteingang und werden weder verarbeitet noch verschoben. Maßgeblich ist der Eingang beim Server, nicht das Datum im Kopf der Mail. Bei Nur überwachen ersetzt der Stichtag den Einschalt-Zeitpunkt als Beginn der Erfassung; ein geänderter Stichtag setzt den Abrufstand zurück.
6. Plausibilität: Die mehrstufige Prüfung konfigurieren (siehe unten).
7. Test & Aktivieren: Mit Test die Verbindung prüfen, mit Jetzt pollen einen sofortigen Abruf auslösen. Nur aktive Profile werden automatisch abgerufen.

Plausibilitäts-Prüfung: Jede Mail durchläuft vor der Verarbeitung vier Stufen. Schlägt eine Stufe an, wird die Mail in die Quarantäne verschoben:

• Stufe 1 – Struktur: Vorhandensein von Anhängen, erlaubte Dateiformate, maximale Anhangsgröße und -anzahl sowie eine Prüfung des tatsächlichen Dateityps. Bleibt Erlaubte Formate leer, ist jedes Format erlaubt. Ausführbare und aktive Web-Formate, Office-Dateien mit Makros und Disk-Images (z. B. exe, bat, ps1, js, html, svg, docm, xlsm, iso) nimmt das Postfach wie der Eingangsordner nie an; sie lassen sich auch nicht in die Liste eintragen. Für Mails ohne Anhang ist Ignorieren, Quarantäne oder Trotzdem verarbeiten wählbar.
• Stufe 2 – Heuristik (optional): SPF/DKIM/DMARC, Reply-To-Abweichungen, Absender-Whitelist und Phishing-Betreffmuster (Regex).
• Stufe 3 – LLM (optional): Zusätzliche Phishing-/Plausibilitätsbewertung über ein KI-Profil mit einstellbarer Konfidenzschwelle. Erfordert ein lizenziertes KI-Modul – ohne Lizenz ist diese Stufe nicht aktivierbar und wird beim Abruf übersprungen.
• Stufe 4 – Duplikat: Mandantenweite Prüfsumme über die archivierten Inhalte; bereits archivierte Dokumente werden nicht erneut angelegt.

Quarantäne bearbeiten: Im Bereich Quarantäne werden geblockte Mails mit Absender, Betreff, blockierender Stufe und Grund aufgelistet (Filter Offen / Freigegeben / Verworfen). Über Detail sind alle Angaben einsehbar.

• Freigeben: Die Mail wird zurück in den Posteingang verschoben und zur Verarbeitung eingereiht.
• Verwerfen: Die Mail wird endgültig verworfen und in den Ignoriert-Ordner verschoben.

Optional erhalten berechtigte Administratoren bei einer neuen Quarantäne eine Chat-Benachrichtigung. Der Bereich Verarbeitung zeigt die jüngsten Protokoll-Einträge der Mail-Schritte (Abholung, Plausibilität, Einspeisung) zur Diagnose.

Eingangsordner einrichten

Über die Eingangsquelle Eingangsordner (Verwaltung → Einstellungen → Eingang & Quellen → Eingangsordner) liest die Anwendung Dateien aus überwachten Ordnern – egal ob ein Scanner, ein Export oder ein Kopierjob sie dort ablegt. Voraussetzung ist ein vom Administrator konfigurierter Basis-Pfad (Installationsanleitung, „Eingangsordner einbinden"); ohne ihn zeigt die Karte Nicht konfiguriert (keine Störung).

Profil anlegen (Schritt für Schritt):

1. Neues Profil wählen – der Editor hat die Tabs Ordner und Verarbeitung.
2. Ordner: Bezeichnung und Unterordner relativ zum Basis-Pfad eingeben (z. B. 500M/Eingang). Absolute Pfade, .. und die Namen InArbeit, Erfolgreich, Fehler sind nicht erlaubt; erlaubt sind nur Buchstaben, Ziffern, Leerzeichen sowie _ . -. Abrufintervall (ab 30 Sekunden) festlegen.
3. Pfadschema (optional): Wenn Scanner oder ein vorgelagertes Werkzeug (z. B. der MESO Archivimporter) die Dateien in Unterordnern nach Dokumentenart und Beleg ablegen, das Schema eintragen, z. B. {Dokumentenart}/{Kontonummer}-{Laufnummer}. Die Werte stehen der Pipeline als Ordner.Pfad.Dokumentenart, Ordner.Pfad.Kontonummer, Ordner.Pfad.Laufnummer zur Verfügung; {Dokumentenart} (Nummer oder Name) bestimmt die Dokumentenart je Datei und übersteuert dabei die Dokumentenart-Auswahl unter Verarbeitung.
4. Verarbeitung: Dokumentenart wählen oder automatisch erkennen aktivieren (beides ohne Wirkung, wenn das Schema {Dokumentenart} enthält), erlaubte Formate und maximale Dateigröße prüfen. Die Formate-Liste ist Freitext – nur Formate eintragen, die das Archiv anzeigen kann, denn eine unbekannte Endung passiert die Inhaltsprüfung (Magic-Bytes) ungeprüft. Ausführbare und aktive Web-Formate, Office-Dateien mit Makros und Disk-Images (z. B. exe, bat, ps1, js, html, svg, docm, xlsm, iso) nimmt der Eingangsordner nie an – auch wenn sie in den erlaubten Formaten stehen.
5. Ordner testen prüft Erreichbarkeit und Schreibrecht, zählt wartende Dateien und nennt Ordner, die nicht zum Pfadschema passen (auch bei einem führenden Punkt oder Leerzeichen im Ordnernamen) – solche Ordner bleiben liegen und sind sonst nirgends einsehbar; Ordnernamen auf der Platte dürfen dabei Umlaute und Sonderzeichen tragen. Jetzt verarbeiten stößt einen Zyklus sofort an.

Was mit den Dateien passiert: Neue Dateien wandern zuerst nach InArbeit/, nach erfolgreicher Annahme nach Erfolgreich/ (bei Pfadschema mit gespiegeltem Unterpfad). Fachlich abgelehnte Dateien – Format nicht erlaubt, zu groß, leer, Inhalt passt nicht zur Endung, unbekannte Dokumentenart im Pfad, Duplikat – landen in Fehler/ mit einer gleichnamigen .fehler.txt, die den Grund nennt. Eine 0-Byte-Datei entsteht meist, weil ein Scanner sie zunächst leer anlegt und erst danach beschreibt; deshalb wird die Länge erst nach dem Verschieben nach InArbeit/ geprüft. Technische Störungen – Ordner nicht erreichbar, Ordner nicht beschreibbar (Schreib-/Löschrecht des Dienstkontos fehlt), Datei nicht lesbar (Leserecht des Dienstkontos fehlt), Dokumentenart-Katalog nicht verfügbar (WinLine nicht erreichbar oder keine Dokumentenarten angelegt – betrifft nur Profile mit {Dokumentenart} im Pfadschema) oder Datenbank nicht erreichbar – lassen die Datei liegen; der Grund steht als Letzter Fehler am Profil und der nächste Zyklus versucht es erneut. Ein gelöschtes Profil lässt seine bereits abgelegten Dateien auf der Platte liegen.

Verarbeitung: Der Bereich Verarbeitung auf derselben Seite zeigt die 200 jüngsten Einspeisungen und Ablehnungen; der komplette Lauf eines Dokuments steht im Tab Verarbeitung mit Quelle „Eingangsordner". Archiviert wird durch den Pipeline-Schritt Archivierung; hat die Dokumentenart keine aktive Pipeline, wird das Dokument nur archiviert („… — Dokument wird nur archiviert." im Protokoll); enthält die Pipeline keinen Archivierungsschritt, ergänzt die Anwendung ihn automatisch („Pipeline enthält keinen Archivierungsschritt — Dokument wird zusätzlich archiviert.").

Suchindex

Der Suchindex beschleunigt die Schnellsuche und ermöglicht erweiterte Suchfunktionen. Die Verwaltung liegt an zwei Orten: Verwaltung → Betrieb → Suchindex zeigt Status, Neuaufbau und erlaubt die direkte Durchsicht des Indexinhalts; Verwaltung → Einstellungen → Suche & Index stellt Ähnlichkeitssuche und Fuzzy-Verhalten ein.

• Status (Betrieb): Übersicht über den Indexstand aller Mandanten.
• Neuaufbau starten (Betrieb): Index für einen Mandanten vollständig neu erstellen (läuft im Hintergrund).
• Indexierte Felder: Anzeige, welche Schlagwortfelder im Index enthalten sind.
• Index-Inhalt durchsuchen (Betrieb): Index zu Prüfzwecken direkt durchsuchen.
• Ähnlichkeitssuche (Einstellungen): Zu einem Dokument ähnliche Dokumente finden.
• Einstellungen für Fuzzy-Suche (Einstellungen): Schwellenwerte für unscharfe Suche und Ähnlichkeitserkennung anpassen. Max. Editierdistanz ist eine Obergrenze: sie gilt erst ab der Wortlänge Volle Distanz ab (Standard 7); kürzere Wörter erlauben höchstens ein abweichendes Zeichen, reine Ziffernfolgen keines.

Der Index wird automatisch im Hintergrund aktualisiert (einstellbares Intervall, Standard: 5 Minuten).

Berechtigung: Die Verwaltung lässt sich rollenbasiert feiner delegieren als über das allgemeine Systemverwaltungs-Recht – getrennt in „Suchindex: Status, Neuaufbau & Index-Inhalt“ (Statusanzeige, Neuaufbau, Indexdurchsicht) und „Suchindex: Ähnlichkeits- & Fuzzy-Einstellungen verwalten“ (Feineinstellung der unscharfen Suche und Ähnlichkeitserkennung). Beide Rechte lassen sich unabhängig voneinander an eine Rolle vergeben; das Recht System (siehe Administration delegieren) schaltet weiterhin beide Bereiche gemeinsam frei.

Texterkennung nachträglich erzeugen

Unter Verwaltung → Einstellungen → Erkennung & KI → Volltext & OCR können fehlende Texte (aus der automatischen Texterkennung) für den gesamten Archivbestand nachträglich erstellt werden. Der Lauf ist installationsweit: Er verarbeitet die Dokumente aller freigeschalteten Mandanten, unabhängig davon, welcher Mandant beim Start gewählt war. Unterstützte Formate: PDF, PNG, JPG, TIFF, BMP, GIF, archivierte E-Mails (EML) und Outlook-Nachrichten (MSG) sowie Word (DOC/DOCX) und Excel (XLS/XLSX), Textdateien (TXT, CSV, LOG) und XML-Dateien (z. B. E-Rechnungen), WinLine-Belegdrucke (SPL, sofern der MesoSpool-Dienst konfiguriert ist) – bei E-Mails (EML und MSG) wird der Nachrichtentext samt Betreff, Absender, Empfänger und Anhangs-Dateinamen übernommen, bei Office-Dokumenten der Text direkt aus der Datei gelesen statt per Texterkennung; bei XML-Dateien werden die Inhalte ohne die technischen Auszeichnungen übernommen.

• Jetzt einmalig starten: Startet den Vorgang sofort. Deaktiviert sich nach Abschluss automatisch; wird der Schalter vorher ausgeschaltet, stoppt der Lauf nach dem gerade bearbeiteten Dokument.
• Täglicher Zeitplan: Führt die Texterkennung automatisch täglich zur eingestellten Uhrzeit aus (z. B. 02:00 Uhr nachts). Beim Hochladen erkennt die Anwendung nur Formate, die sie sofort lesen kann (PDF und Bilder unterhalb des Größenlimits). Für WinLine-Belegdrucke (SPL), archivierte E-Mails sowie Word- und Excel-Dateien entsteht der Volltext erst durch einen solchen Lauf – ohne Zeitplan bleiben diese Dokumente ohne durchsuchbaren Text und sind nur über ihre Schlagworte auffindbar, nicht über ihren Inhalt. Standard-Zeitplan: Wurde noch nie ein Zeitplan gespeichert, gilt automatisch ein Standard-Zeitplan um 02:00 Uhr; die Einstellungen kennzeichnen ihn als Standard-Zeitplan, und er lässt sich dort ändern oder bewusst abschalten – ein abgeschalteter Zeitplan bleibt abgeschaltet. Zu große Dateien holt der Zeitplan nicht nach: sie bekommen beim Hochladen den Vermerk [ZU_GROSS] ins Volltextfeld, und dieser Vermerk nimmt sie dauerhaft aus dem Lauf – hier hilft nur, das Größenlimit anzuheben und danach einmal Vorhandene OCR-Texte neu aufbauen zu verwenden.
• Endzeit: Optional zum täglichen Zeitplan – der nächtliche Lauf endet zu dieser Uhrzeit, damit er nicht bis in den Tagesbetrieb hinein läuft. Bleibt sie leer, läuft der Zeitplan unbegrenzt. Ist der Bestand an einem Abend nicht vollständig abgearbeitet, macht der Lauf in der nächsten Nacht dort weiter – bearbeitet werden die zuletzt archivierten Dokumente zuerst. Maßgeblich ist die Reihenfolge der Archivierung, nicht das Dokumentdatum; der Fortschritt lässt sich daher nicht an Jahrgängen ablesen. Gilt nicht für „Jetzt einmalig starten“.
• Belegdrucke (SPL) ab / Übrige Dokumente ab: Zwei optionale Datumsgrenzen, getrennt für WinLine-Belegdrucke (SPL) und für alle übrigen Dokumente (PDF, Bilder, Office). Dokumente mit älterem Archivdatum als die jeweilige Grenze werden nicht nachgetragen und zählen nicht zum Volltext-Rückstand; der Grenztag selbst gehört dazu. Typischer Einsatz: Belegdrucke erst ab 01.01.2020, alle übrigen ohne Grenze – der Volltext alter Belegdrucke ist selten gefragt, ein altes PDF dagegen schon, und der Nachtlauf kommt so schneller zu den Dokumenten, nach denen tatsächlich gesucht wird. Maßgeblich ist das Archivdatum des Dokuments, nicht das Belegdatum. Die Grenzen gelten auch für „Vorhandene OCR-Texte neu aufbauen“. Ausgeschlossene Dokumente erhalten keinen Vermerk: Wird eine Grenze wieder entfernt oder zurückgesetzt, holt der nächste Lauf sie nach.
• Worker je MesoSpool-Instanz: Wie viele WinLine-Belegdrucke (SPL) der Lauf gleichzeitig an dieselbe MesoSpool-Instanz schickt (1 bis 16, Standard 1 = bisheriges Verhalten). Der MesoSpool-Wrapper verarbeitet mehrere Anfragen intern parallel – bei sehr großen Rückständen (mehrere hunderttausend Belegdrucke) lässt sich der Durchsatz damit vervielfachen, ohne weitere MesoSpool-Instanzen einzurichten. Der Wert muss zur maximalen Parallelität (MaxParallel) der angesprochenen Instanz passen, und die Summe aller gleichzeitigen Konvertierungen sollte die verfügbaren CPU-Kerne nicht überschreiten – ein zu hoher Wert verlangsamt den Lauf statt ihn zu beschleunigen. Beim älteren mesospool.exe-Servermodus (strikt sequenziell) bringt ein Wert über 1 keinen Vorteil.
• Fortschritt: Wird in Echtzeit angezeigt – mit der Anzahl verarbeiteter Dokumente und dem aktuellen Dateinamen. Die Texterkennung ist rechenintensiv; bei großen Archiven dauert der Erstlauf mehrere Stunden (Richtwerte in den Systemvoraussetzungen).

Der System-Status (Verwaltung → Betrieb → Systemstatus) zeigt zusätzlich den aktuellen Volltext-Rückstand – wie viele archivierte Dokumente noch auf Texterkennung warten – zusammen mit dem Datum der letzten Messung. Gezählt werden nur Dokumente in Formaten, aus denen sich überhaupt ein Text gewinnen lässt; Dateien in Formaten ohne Textunterstützung (z. B. PowerPoint-Präsentationen) bleiben dauerhaft ohne Volltext und erscheinen nicht in dieser Zahl. Die Zahl wird am Ende jedes nächtlichen Laufs neu ermittelt, nicht laufend live gezählt; ein abgebrochener Lauf im Modus „Alle neu aufbauen“ aktualisiert sie nicht – ein vollständig durchgelaufener schon. Hat noch nie ein Lauf stattgefunden, erscheint an dieser Stelle gar keine Zahl – die Angabe fehlt dann ganz, statt irreführend „0“ zu melden. Ob ein Zeitplan greift, zeigt die Schaltfläche Details im System-Status: in der Liste der Hintergrunddienste stehen beim Eintrag OCR-Nachtragen die Spalten Nächster Lauf und Letzter Fehler. Der letzte Fehler wird beim Start des nächsten Laufs quittiert – ein einzelnes dauerhaft nicht verarbeitbares Dokument lässt den Dienst also nicht für immer auf „Hinweis“ stehen; die Fehler-Historie steht im Verarbeitungsprotokoll.

Einstellungen

Die Kategorien der Einstellungen sind oben unter Verwaltung (nur Administratoren) aufgeführt; hier folgen Details zu einzelnen Karten, die dort nicht ausgeführt sind.

Die Chat-Konfiguration ist auf zwei Karten aufgeteilt – die globale Aktivierung unter „Kommunikation & Branding“, die KI-Konfiguration (KI-Profil und Verhalten der Antworten) unter „Erkennung & KI“ (Bereich KI-Zugänge). Die Zugangsdaten kommen aus dem gewählten KI-Profil; ohne Auswahl gilt das Standardprofil. Die Aktivierung muss zuerst gesetzt werden, bevor die KI-Konfiguration wirkt.

Bestehende Lesezeichen und Links auf einzelne Einstellungsseiten (z. B. auf die GetMyInvoices- oder Mail-Postfach-Konfiguration) funktionieren nach der Umstellung unverändert weiter.

• Einrichtungsübersicht (Kategorie Übersicht): Zehn zentrale Einrichtungsbausteine – Lizenzumfang, KI-Modul, KI-Profile, Chat, E-Mail-Versand (SMTP), MesoSpool, Dokumentenerkennung, Dokumentenarten mit aktiver Pipeline, E-Mail-Postfach, Eingangsordner – werden nach Zustand gruppiert dargestellt: eingerichtet (✓, vollständig konfiguriert), fehlt (⚠, etwas Eingeschaltetes hängt am Baustein, der aber nicht eingerichtet ist), offen (○, nicht eingerichtet, aber es hängt noch nichts Eingeschaltetes daran – kein Handlungsbedarf) und, sofern die Berechtigung für eine abschließende Einschätzung fehlt, nicht bewertbar (eingeklappt am Ende der Liste). Jede Zeile außer „eingerichtet“ trägt einen Sprunglink direkt zur zuständigen Einstellung; dieselben Statuszeilen erscheinen zusätzlich unmittelbar an den betroffenen Karten selbst (u. a. Dokumentenerkennung, KI-Assistent, Chat-KI-Konfiguration, E-Rechnungen, Volltext & OCR).

• Mandanten-Freischaltung (Kategorie Mandanten): Festlegen, welche Mandanten in der Anwendung verfügbar sind. Die Freischaltung wirkt als verbindliche Grenze für alle Benutzer: Ein nicht freigeschalteter Mandant ist nicht nur ausgeblendet, sondern auch beim direkten Zugriff gesperrt. Zusätzlich sieht und bearbeitet jeder Benutzer nur die Mandanten, für die er in WinLine bzw. über seine Rollen berechtigt ist – das gilt auch für diese Maske selbst: Zur Auswahl stehen nur die eigenen Mandanten, und die Freischaltung der übrigen Mandanten bleibt beim Speichern unverändert. Ein Benutzer mit eingeschränkter Mandanten-Berechtigung kann also keine fremden Mandanten freischalten oder sperren.

  

• Anmerkungs-Einstellungen (kein eigener Verwaltungs-Bereich): Welche Dokumentenart die Anmerkungen eines Mandanten trägt, wird nicht in Einstellungen oder Betrieb konfiguriert, sondern aus der Dokument-Detailansicht heraus – ist für den gewählten Mandanten noch keine Dokumentenart hinterlegt, erscheint dort im Abschnitt „Anmerkungen“ der Hinweis „Anmerkungen sind für diesen Mandanten nicht konfiguriert“ mit einer Schaltfläche Jetzt konfigurieren, sichtbar nur für Administratoren.

• Login-Logo (Kategorie Kommunikation & Branding): Eigenes Firmenlogo für die Anmeldeseite hochladen (PNG, JPG, SVG oder WebP, max. 2 MB; empfohlen 200 × 200 px, am besten PNG mit Transparenz oder SVG). Kann jederzeit auf das Standardlogo zurückgesetzt werden. Das Logo liegt in der Anwendungsdatenbank und bleibt damit auch bei Container-Neustarts ohne zusätzliches Volume erhalten.

• E-Mail-Versand (SMTP) (Kategorie Kommunikation & Branding): Ausgehenden Mailserver konfigurieren (Host, Port, SSL/TLS, optionale Zugangsdaten, Absenderadresse und -name). Über Testversand lässt sich die Konfiguration mit einer Probenachricht prüfen. Ein bereits gespeichertes Passwort bleibt erhalten, solange das Passwortfeld leer gelassen wird. Erst mit konfiguriertem SMTP steht im Dokument-Karussell und im Versand-Dialog die Option zur Verfügung, ein Dokument direkt als E-Mail-Anhang zu versenden – andernfalls wird nur der Freigabelink angeboten.

Sitzungsdauer anpassen

Unter Verwaltung → Einstellungen → System → Sitzungsdauer (Berechtigung: System) lässt sich festlegen, wie lange eine Anmeldung gültig bleibt – getrennt für interne Benutzer und Portal-Benutzer:

• Intern: Standard 8 Stunden
• Portal: Standard 2 Stunden

Der Wertebereich liegt zwischen 1 und 72 Stunden. Nach Ablauf der eingestellten Dauer wird der Benutzer automatisch abgemeldet und muss sich erneut anmelden. Die Änderung wirkt für neue Anmeldungen ab dem Speichern; bereits laufende Sitzungen behalten ihre ursprüngliche Gültigkeitsdauer.

Aktive Sitzungen

Unter Verwaltung → Betrieb → Sitzungen (Aktive Sitzungen) finden Sie eine Übersicht aller aktuell angemeldeten Benutzer mit Benutzername, Anzeigename, IP-Adresse, Anmeldezeitpunkt, letztem Kontakt und Browser.

API-Schlüssel (Service-Accounts)

Unter Verwaltung → Einstellungen → API-Schlüssel verwalten Administratoren mit dem Recht „API-Schlüssel verwalten“ Zugangsschlüssel für externe Anwendungen, die das Archiv über die Web-API ansprechen (Schnittstellen, Automatisierungen, Fremdsysteme).

• Bindung an einen Benutzer: Jeder Schlüssel gehört zu genau einem internen WinLine-Benutzer und erbt dessen Rechte, Rollen und Mandanten-Freischaltung. Für Integrationen empfiehlt sich ein eigener, minimal berechtigter Service-Benutzer. Portal-Benutzer (Geschäftspartner) können nicht gebunden werden.
• Einmalige Anzeige: Der Schlüssel wird genau einmal direkt nach dem Anlegen angezeigt und ist danach nicht wieder abrufbar – gespeichert wird nur eine Prüfsumme.
• Verwendung: Die Anwendung sendet den Schlüssel an POST /api/auth/token und erhält ein zeitlich begrenztes Zugriffs-Token für alle weiteren API-Aufrufe; eine Zwei-Faktor-Eingabe ist dabei nicht nötig. Die vollständige Schnittstellenbeschreibung liefert der Server maschinenlesbar unter /openapi/v1.json.
• Widerruf und Befristung: Schlüssel lassen sich jederzeit widerrufen und optional mit einem Ablaufdatum versehen; die Liste zeigt die letzte Verwendung je Schlüssel.
• Nachvollziehbarkeit: Anlage und Widerruf können im Audit-Log protokolliert werden (Kategorie „Anmeldung & Sitzung“).

Verarbeitungsprotokoll

Das Verarbeitungsprotokoll bietet eine lückenlose Nachverfolgung der Dokumentenverarbeitung. Von der Archivierung über die KI-Analyse bis zur Fallanlage wird jeder Schritt mit Status, Dauer und technischen Details protokolliert. Sie erreichen es über den eigenen Menüpunkt Verarbeitung im Arbeitsbereich – mit dem entsprechenden Recht auch ohne Administratorrechte und ohne das WebArchiv-Produkt.

Jede Zeile ist ein Verarbeitungsschritt mit Zeitpunkt, Dokument, Quelle, Schritt, Status und Meldung. Die Spalte Dokument zeigt den Dateinamen, die Spalte Quelle den Eingangsweg (z. B. „E-Mail-Postfach“, „Eingangsordner“, „GetMyInvoices“); ein Link in die Archiv-Detailansicht erscheint nur, wenn das Dokument archiviert und das Archiv-Modul verfügbar ist. Filtern Sie oben auf eine Dok-ID, sehen Sie den kompletten Weg eines Belegs – von der Extraktion über Stammdaten- und Fall-Anlage bis zur Aktualisierung des Suchindex. Für einen Eingang, der noch keine Dok-ID trägt (noch nicht archiviert), filtert die neue Eingang-ID stattdessen auf dessen Verlauf. Die Lupe neben dem Dateinamen öffnet den Verlauf als Zeitstrahl – bei einem nicht archivierten Eingang (z. B. einer als nicht relevant erkannten Mail eines überwachten Postfachs) den des Eingangs, mit denselben Request-/Response-Details.

• Übersichtsliste: Alle Verarbeitungsschritte, neueste zuerst, seitenweise vom Server geladen – unten wählen Sie die Seite und 25, 50, 100 oder 200 Einträge je Seite, die Anzeige nennt die Gesamtzahl der Treffer. Gefiltert wird ausschließlich über die Leiste oberhalb der Liste, sie wirkt auf das gesamte Protokoll (Filter Status, Schritt, Quelle, Mandant, Zeitraum, Suche, Dok-ID und Eingang-ID; Spalten Zeitpunkt, Dokument, Quelle, Fall-ID, Mandant, Schritt, Status, Meldung, Benutzer, Dauer). Alle Mandanten umfasst nur die Mandanten, für die Sie berechtigt sind.
• Zeitraum: Die Schnellauswahl (Heute, Gestern, Aktuelle Woche, Letzte 7 Tage …) setzt Von und Bis; beide Felder lassen sich auch von Hand wählen, die Auswahl zeigt dann „Eigener Zeitraum“. Die Tage gelten in der Ortszeit Ihres Browsers, Bis schließt den ganzen Tag ein.
• Suche: Findet Schritte, deren Meldung oder Dokumentname den Begriff enthält – etwa einen Dateinamen, eine Fall-Nummer aus der Meldung oder „Duplikat“. Die Suche startet mit Enter oder beim Verlassen des Feldes.
• Filter „Quelle“: Zeigt nur die Verarbeitung eines Eingangswegs – manueller Upload, Partnerportal, GetMyInvoices, E-Mail-Postfach, Eingangsordner, API oder Archiv-Altbestand. Erfasst wird der ganze Lauf: auch Schritte, die erst nach der Archivierung am Dokument laufen (Schlagworte, CRM-Fall, Rucksack), und Läufe ganz ohne Archivierung. Dazu kommen Schritte, die vor oder ohne Eingang entstehen – Abholung und Plausibilitätsprüfung eines Postfachs, abgelehnte Dateien eines Eingangsordners, der Kreditorabgleich mit GetMyInvoices. Ein Upload, der schon vor dem Eingang scheitert, lässt sich keiner Quelle zuordnen und erscheint nur unter Alle Quellen. Wurde ein Dokument mehrfach eingespeist (z. B. erneut aus dem Archiv analysiert), zählen seine Dokument-Schritte zum jüngsten Eingang.
• Schritt „Eingang“: Jedes Dokument beginnt mit demselben Schritt, unabhängig von seiner Herkunft – manueller Upload, GetMyInvoices oder E-Mail-Postfach. Die Meldung lautet z. B. „rechnung.pdf“ aus Upload eingegangen (42.318 Bytes); die Herkunft steht zusätzlich in den Details des Schritts und in der Detailansicht des Dokuments unter Eingang über. Protokollzeilen aus früheren Versionen tragen den alten Schrittnamen „Upload“; im Filter ist er als Eingang (alt: Upload) wählbar.
• Schritt „Archivierung“: Legt das Dokument im WinLine-Archiv ab – als eigener Schritt direkt nach „Eingang“. War das Dokument bereits archiviert (Upload, GetMyInvoices), erscheint der Schritt trotzdem als protokollierter, folgenloser Durchlauf.
• Zeitstrahlansicht: Für ein einzelnes Dokument oder einen einzelnen Eingang werden alle Verarbeitungsschritte als Zeitstrahl dargestellt – mit Status-Anzeige (Erfolg, Warnung, Fehler) und aufklappbaren technischen Details. Ein Klick auf eine Zeile öffnet den ganzen Lauf; die Lupe in der Spalte Fall-ID zeigt stattdessen alle Schritte zu dieser Aufgabe – auch Folgeschritte aus späteren Läufen. Die Fall-ID steht an jedem Schritt ab der Fall-Anlage. Bei älteren Läufen wurde sie einmalig nachgetragen, wo der Fall eindeutig feststeht; wurden zu einem Eingang mehrere Fälle angelegt, bleibt die Spalte dort leer.
• Debug-Details: Pro Pipeline-Schritt werden Request- und Response-Daten protokolliert (z. B. erkannte Felder, Suchkriterien, Treffer, LLM-Prompts). Nützlich zur Diagnose bei unerwarteten Ergebnissen.
• KI-Profil-Anzeige: Zeigt das verwendete KI-Profil und Provider-Informationen pro Verarbeitungsschritt an.
• Aufbewahrungsfrist: Konfigurierbar (Standard: 90 Tage), mit automatischer Bereinigung.

Feldprotokoll

Das Feldprotokoll ist eine ergänzende Diagnosefunktion zum Verarbeitungsprotokoll: Es zeichnet auf, welche Felder einer Dokumentverarbeitung zur Verfügung standen, welcher Verarbeitungsschritt welchen Wert gesetzt hat und welche Werte dabei zugunsten eines anderen verworfen wurden. Damit lässt sich nachvollziehen, warum eine Feld-Zuordnung (Fall, BelegPro, Stammdaten, Schlagworte) leer geblieben ist oder einen unerwarteten Wert geschrieben hat, statt den Fall nachstellen zu müssen.

• Schalter: Unter Verwaltung → Einstellungen → Protokolle & Aufbewahrung → Feldprotokoll (Berechtigung „Feldprotokoll-Erfassung und Aufbewahrung konfigurieren“). Die Aufzeichnung ist standardmäßig ausgeschaltet und lässt sich zusätzlich auf einzelne Dokumentenarten begrenzen.
• Einsicht: Eine eigene Berechtigung „Feldprotokoll einsehen“ ist nötig, da die aufgezeichneten Werte aus Dokumentinhalten stammen und im Klartext gespeichert werden. Sichtbar wird das Protokoll im Verarbeitungsprotokoll über „Pipeline anzeigen“ – je Verarbeitungsschritt die übernommenen und verworfenen Feldwerte, dazu der Feld-Zustand am Ende des Laufs.
• Übersprungene, abgestürzte und unbekannte Schritte: Ein Schritt, den eine Bedingung ausgeschlossen hat, oder einer, der mit einem Fehler abgebrochen ist, erscheint mit dem jeweiligen Grund – bisher waren solche Schritte im Protokoll gar nicht sichtbar. Verweist die Dokumentenart auf einen Verarbeitungsschritt, den diese Installation nicht kennt (z. B. nach einer Umbenennung), wird das als Fehler ausgewiesen – im Feldprotokoll und im Verarbeitungsprotokoll.
• Kappung: Sehr lange Werte oder sehr viele Felder werden gekürzt bzw. abgeschnitten; das Protokoll weist das jeweils aus – schon in der zugeklappten Überschrift, nicht erst nach dem Aufklappen.
• Nur die neuesten Läufe: Wurde ein Dokument mehrfach verarbeitet, zeigt die Ansicht die zehn neuesten Läufe. Gibt es mehr, wird das über der Liste ausgewiesen.
• Aufbewahrungsfrist: Konfigurierbar (Standard: 30 Tage), mit automatischer Bereinigung.
• Ein- und Ausschalten wird protokolliert: Jede Änderung an der Feldprotokoll-Konfiguration schreibt einen Eintrag ins Audit-Log – unabhängig davon, welche Audit-Ereignisse sonst aktiviert sind, und auch beim Abschalten. Damit bleibt nachweisbar, in welchem Zeitraum Dokumentinhalte aufgezeichnet wurden.

Audit-Log

Das Audit-Log protokolliert Benutzeraktionen im Archiv – wer hat wann was getan. Es dient der Nachvollziehbarkeit ohne die Anwendung selbst zu belasten: Es wird ausschließlich protokolliert, was ausdrücklich aktiviert wurde. Im Auslieferungszustand ist der Umfang leer – das entspricht dem datenschutzrechtlichen Grundsatz der Datensparsamkeit (standardmäßig aus). Da die Protokollierung von Lesezugriffen verhaltensbezogene Mitarbeiterdaten erzeugen kann, sollte vor der Aktivierung je nach Betrieb die Mitbestimmung (Betriebs-/Personalrat) einbezogen werden.

Zwei getrennte Rechte steuern den Zugriff, sodass sich Einsicht und Konfiguration unabhängig voneinander delegieren lassen:

• Audit-Log einsehen – zeigt die protokollierten Einträge (nur lesend).
• Audit konfigurieren – legt fest, was protokolliert wird und wie lange.

Umfang konfigurieren: Unter Verwaltung → Einstellungen → Protokolle & Aufbewahrung, Abschnitt Protokollumfang, lassen sich einzelne Ereignisarten je Kategorie (Anmeldung & Sitzung, Benutzer & Rollen, Einstellungen, Dokument-Änderungen, Dokument-Zugriff, Teilen, Workflow, Audit) gezielt aktivieren. Vier Voreinstellungen erleichtern den Einstieg:

• Aus – nichts wird protokolliert.
• Basis – An-/Abmeldungen und Mandantenwechsel.
• Empfohlen – zusätzlich alle Änderungen, Teilen und Workflow-Starts.
• Vollständig – zusätzlich Lesezugriffe (Vorschau, Download).

Lesezugriffe lassen sich zusätzlich auf bestimmte Dokumentenarten begrenzen (Dokumentenarten-Whitelist) – z. B. nur besonders sensible Dokumentenarten wie Personalunterlagen, statt jeden Vorschau- oder Download-Aufruf im gesamten Archiv zu erfassen.

Log einsehen: Unter Verwaltung → Betrieb → Audit-Log zeigt die Log-Ansicht Zeitpunkt, Ereignis, Benutzer, Mandant, Dok-ID, Bezug, Erfolg und IP-Adresse, neueste zuerst. Ein Klick auf einen Eintrag öffnet die Details.

Die Liste wird seitenweise vom Server geladen – unten wählen Sie die Seite und 25, 50, 100 oder 200 Einträge je Seite, die Anzeige nennt die Gesamtzahl der Treffer. Gefiltert wird ausschließlich über die Leiste oberhalb der Liste, sie wirkt auf das gesamte Protokoll:

• Ereignis, Mandant, Erfolg (erfolgreiche oder fehlgeschlagene Einträge) und Dok-ID. Alle Mandanten umfasst nur die Mandanten, für die Sie berechtigt sind; Einträge ohne Mandantenbezug (z. B. Anmeldungen oder Zugriffe über einen Freigabelink) erscheinen dort immer.
• Zeitraum: wie im Verarbeitungsprotokoll über die Schnellauswahl (Heute, Letzte 7 Tage …) oder Von/Bis, in der Ortszeit Ihres Browsers, Bis einschließlich des ganzen Tages.
• Suche: findet Einträge, deren Benutzername, Bezug oder IP-Adresse den Begriff enthält. Die Suche startet mit Enter oder beim Verlassen des Feldes.

Auch die Einsicht in das Audit-Log selbst kann protokolliert werden.

Aufbewahrung: Einträge werden nach Ablauf der konfigurierten Aufbewahrung automatisch gelöscht (7 bis 1825 Tage, Standard 90). Änderungen an der Audit-Konfiguration selbst – auch das Abschalten der Protokollierung – werden unabhängig von der Konfiguration immer protokolliert, damit diese besonders sensible Änderung nicht unbemerkt bleibt. Kennwörter und Schlüssel erscheinen in den protokollierten Details grundsätzlich maskiert.

Berechtigungsabgleich

Jedes Archivdokument trägt sein eigenes Berechtigungsprofil – wie in WinLine. Weicht dieses Profil von dem der zugeordneten Stammdaten (Artikel, Personen- oder Sachkonto) ab oder fehlt es ganz, ist das Dokument nicht mehr automatisch an die aktuellen Stammdaten gebunden. Der Berechtigungsabgleich gleicht das ab, ohne jedes Dokument einzeln nachpflegen zu müssen.

Bedienung unter Verwaltung → Einstellungen → Mandanten → Berechtigungsabgleich (eigenes Recht „Berechtigungsabgleich“):

1. Mandant wählen – der Abgleich läuft immer für genau einen Mandanten.
2. Vorschau laden – die Liste zeigt alle Dokumente mit Handlungsbedarf: aktuelles Profil, vorgeschlagenes Zielprofil samt Herkunft (z. B. „Kreditor 70094 → Profil 3“) und Status.
3. Auswahl prüfen – Dokumente ohne Konflikt sind bereits vorausgewählt und lassen sich abwählen oder ergänzen. Über die Filterzeile und die Kopfzeilen-Filter lässt sich die Liste eingrenzen (z. B. auf eine Dokumentenart); das Kontrollkästchen in der Kopfzeile wählt dann alle gefilterten Zeilen auf einmal aus. Die Vorschau lässt sich außerdem als Excel- oder CSV-Datei exportieren (Symbol oben rechts in der Tabelle).
4. Übernehmen – schreibt die ausgewählten Profile. Der Server berechnet die Zielprofile dabei aus den aktuellen Stammdaten neu; Dokumente, die zwischenzeitlich mehrdeutig geworden sind, werden übersprungen statt fehlerhaft geschrieben. Das Ergebnis meldet, wie viele Dokumente übernommen und wie viele übersprungen wurden.

Konflikte: Ist ein Dokument gleich mehreren Stammsätzen mit unterschiedlichem Profil zugeordnet (z. B. Artikel und Personenkonto mit widersprüchlichem Profil), erscheint es als Konflikt und wird nie automatisch übernommen. Bei mehreren eindeutigen Quellen gilt die Rangfolge Personenkonto → Sachkonto → Artikel.

Wiederholbar: Der Abgleich lässt sich beliebig oft ausführen und ändert nur Dokumente mit tatsächlicher Abweichung. Neu archivierte Dokumente erhalten zunächst automatisch das Profil ihrer Dokumentenart; der Berechtigungsabgleich verfeinert das anschließend auf das Profil des konkreten Stammsatzes. Sofern das Audit-Ereignis „Berechtigungsabgleich angewendet“ in der Audit-Konfiguration aktiviert ist, wird jeder Anwenden-Lauf mit Mandant und Anzahl der geänderten Dokumente protokolliert (wie alle Audit-Ereignisse standardmäßig deaktiviert).

Der Abgleich erfasst nur Dokumente, die per Kontonummer- oder Artikelnummer-Schlagwort einem Stammsatz mit Berechtigungsprofil zugeordnet sind – andere Dokumente bleiben unverändert.

Automatik

Der Abschnitt Automatik derselben Seite automatisiert den Abgleich pro Mandant. Alle Funktionen sind standardmäßig aus und müssen bewusst eingeschaltet werden:

• Profil-Vererbung beim Zuweisen – ein Dokument erhält das Berechtigungsprofil des Stammsatzes sofort, wenn ihm ein Kontonummer- oder Artikelnummer-Schlagwort zugewiesen wird (Schlagwort hinzufügen, Massen-Schlagwort, Upload mit Schlagwortwerten). Die Vererbung läuft im Hintergrund und bricht das Zuweisen nie ab – schlägt sie fehl, holt der nächste manuelle oder automatische Abgleich sie nach.
• Zeitgesteuerter Abgleich – führt den Abgleich regelmäßig im Hintergrund aus, wahlweise in einem Intervall (1–720 Stunden) oder einmal täglich zu einer festen Uhrzeit (hat Vorrang vor dem Intervall). Damit werden auch Dokumente erfasst, die ohne Web-Oberfläche entstehen (Pipeline, E-Mail-Postfach, WinLine-Belegdruck). Der letzte automatische Lauf wird mit Zeitpunkt, Anzahl geprüfter und angewendeter Dokumente angezeigt.
• Berücksichtigte Schlagwort-Quellen – die beiden Brücken „Kontonummer → Personen-/Sachkonten“ und „Artikelnummer → Artikel“ lassen sich einzeln abschalten. Die Einstellung gilt einheitlich für die manuelle Vorschau, die Vererbung beim Zuweisen und den zeitgesteuerten Abgleich.
• Arbeitnehmer-Quelle (optional) – die dritte Brücke „Arbeitnehmer → Arbeitnehmerstamm“ überträgt das Berechtigungsprofil aus dem WinLine-Arbeitnehmerstamm auf Dokumente mit Arbeitnehmer-Schlagwort (Schlagwort 86) – gedacht für die klassische Personalverwaltung, damit ein Mitarbeiter seine eigenen Unterlagen sehen kann. Sie ist standardmäßig aus und berücksichtigt ausschließlich Dokumente, die noch gar kein Profil tragen: Gibt die Dokumentenart bereits ein Profil mit (etwa für Unterlagen, die nur die Personalverwaltung sehen darf), bleibt dieses immer unangetastet.

Wichtig: Automatisch angewendet werden nur Dokumente ohne eigenes Profil mit eindeutiger Quelle. Ein abweichendes Profil kann bewusst gesetzt sein – es wird nie automatisch zurückgesetzt, sondern bleibt dem manuellen Abgleich vorbehalten; Konflikte werden nie automatisch übernommen. Jeder automatische Lauf erscheint – sofern das Audit-Ereignis „Berechtigungsabgleich angewendet“ aktiviert ist – im Audit-Log als „Automatischer Abgleich“.

Dokumentenart-Profil auf Alt-Dokumente

Dokumente, die vor Einführung des dokumenteigenen Berechtigungsprofils archiviert wurden, tragen gar kein Profil und sind damit – wie in WinLine – für alle sichtbar, selbst wenn ihre Dokumentenart ein Profil trägt. Der Berechtigungsabgleich oben erreicht davon nur die Dokumente mit Kontonummer- oder Artikelnummer-Schlagwort. Für den Rest gibt es auf derselben Seite den zweiten Abschnitt Dokumentenart-Profil auf Alt-Dokumente:

1. Vorschau laden – die Liste zeigt je Dokumentenart das Zielprofil und die Anzahl der Dokumente ohne eigenes Profil.
2. Auswahl prüfen – alle Einträge sind vorausgewählt und lassen sich abwählen.
3. Profil stempeln – schreibt das Profil der Dokumentenart auf die betroffenen Dokumente. Das Ergebnis meldet die Anzahl der gestempelten Dokumente; bei sehr großen Beständen wird pro Lauf gedeckelt, die Meldung weist dann auf die Wiederholung hin.

Ein bestehendes Profil wird nie überschrieben – angefasst werden ausschließlich Dokumente ohne jedes Profil. Der Lauf ist beliebig wiederholbar und findet danach nichts mehr zu tun. Er kann Dokumente für Benutzer unsichtbar machen, die nicht im Profil der Dokumentenart stehen; genau das ist die Absicht (WinLine-Verhalten), weshalb er bewusst ausgelöst und nicht automatisch ausgeführt wird. Sofern das Audit-Ereignis „Dokumentenart-Profil gestempelt“ aktiviert ist, wird jeder Lauf mit Mandant, Dokumentenarten und Anzahl protokolliert.

---