Verwaltung (nur Administratoren)

Die Verwaltungsfunktionen sind hinter der Sektion Verwaltung in der Sidebar zusammengefasst und nur für Administratoren sichtbar.

Benutzerverwaltung

Übersicht aller WinLine-Benutzer mit Status, Rollen und Zwei-Faktor-Status.

In der Detailansicht eines Benutzers lässt sich außerdem dessen Profilbild ändern oder entfernen (PNG, JPEG, GIF, BMP oder WEBP, max. 8 MB). Das Bild wird automatisch auf das WinLine-Format zugeschnitten, 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 (Name, Berechtigungen, Benutzergruppen, Mandanten)
• Für Portal-Benutzer verfügbar: Checkbox 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 dem Dropdown 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 Badge „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:

Der Button 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 die Sektion „Meine Aufgaben“ in der Sidebar.
• BelegPro in Aufgaben — Steuert, ob der BelegPro-Bereich (Rechnungsprüfung) in Aufgaben sichtbar ist.

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

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
• Benutzer auf bestimmte Mandanten einschränken
• Bei Portal-Benutzern erscheint im Bearbeitungsdialog eine zusätzliche Sektion mit Einschränkungen. Dokumentarten 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	KI-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 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-Administration, 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 → Benutzerverwaltung → Rollen 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 Sidebar 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 aktivieren: Einem WinLine-Konto (Debitor/Kreditor) einen Portalzugang zuweisen.
• 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 gelten für alle Mandanten und lassen sich nur von uneingeschränkt berechtigten Anwendern verwalten.
• 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 Portal-spezifischer Bearbeitungssektion.
• Sperren/Freigeben: Zugang vorübergehend deaktivieren oder wieder freigeben.

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

Freigabe-Verwaltung (Workflow)

Die Workflow-Administration ist in die Bereiche Aufgaben-Tab, Abschluss und Automatisierung gegliedert. Der frühere Bereich KI & Erkennung ist in die Einstellungen umgezogen (Kategorie KI & Verarbeitung, Abschnitt Dokumenten-KI); alte Verknüpfungen leiten automatisch weiter. Der Wechsel erfolgt wie in den Einstellungen über die linke Kategorie-Leiste, die sich über den Umschalter am unteren Ende auf eine Icon-Spalte einklappen lässt. Der aktive Bereich steht in der Adresszeile (z. B. #/workflow-admin/abschluss) – Browser-Vor- und -Zurück-Tasten funktionieren damit, und ein Bereich lässt sich als Lesezeichen speichern oder an Kollegen weitergeben.

• Relevante Workflows: Die Sektion Meine Aufgaben auf bestimmte Workflow-Schritte einschränken.
• 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 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: Schritte für Freigabe, Rückfrage und Ablehnung zuordnen – allgemein oder je Workflow. 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 Buttons erscheinen dann unabhängig von der Workflow-Definition.
• Fallanlage-Einstellung: Festlegen, bei welcher Dokumentart 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-Dokumentenerkennung einrichten

Konfiguration der automatischen Dokumentenanalyse unter Verwaltung → Einstellungen → KI & Verarbeitung, Abschnitt Dokumenten-KI (zuvor Workflow-Administration → KI & Erkennung):

• Zugangsdaten: Adresse und Schlüssel der Azure Document Intelligence-Ressource.

• Erkennungsmodell: Voreingestelltes Modell (z. B. das Standardmodell für Rechnungen oder ein eigenes Modell).

• LLM-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.

• 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.

• Einstellung je Dokumentart: Für jede Dokumentart 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 Dokumentart 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.

• Laufende Analysen: Übersicht aller aktuell laufenden oder fehlgeschlagenen Erkennungs-Aufträge.

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 LLM-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-Rechnungsprüfung	Mittel bis groß	Abwägung mit Vorwissen (Kontenhistorie, Bestellung) statt bloßem Ablesen
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

Drei 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 und die KI-Rechnungsprüfung. 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 KI-Dokumentenerkennung einrichten). Der Verbindungstest nennt in diesem Fall Feld und richtigen Wert.

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, Rechnungsprü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 im Verarbeitungsprotokoll ansehen. Erst dort zeigt sich, ob die kleine Klasse für einen Schritt genügt.

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.

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. Modellauswahl, Vorlagen-ID, Bedingungen), die per Klick aufgeklappt werden.

4. Über die Buttons ≡ 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 ?-Badge mit den Bedingungen als Tooltip bzw. per Tipp auf das Badge, 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:

• Extraktion: Dokumentenfelder erkennen (Azure Document Intelligence oder LLM)

• Schlagworte: Erkannte Felder als Schlagworte speichern

• Stammdaten-Anlage: Kreditor, Debitor, Kontakt oder Custom-Datensätze automatisch anlegen

• Stammdaten-Lookup: Bestehende Stammdaten suchen (Kreditor, Debitor, Artikel)

• 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). Für FAKT-Buchungen steuert zusätzlich der Parameter Belegweiterverarbeitung, wie WinLine den Beleg weiterverarbeitet: „Faktura — neuer Beleg“ (Standard), „Faktura — Rechnung zu Lieferschein“ (Zuordnung über die gemappte Lieferscheinnummer), „Lieferschein — neuer Beleg“ oder „Lieferschein — Lieferschein zu Auftrag“ (Zuordnung über die gemappte Auftragsnummer). Bei Belegstufe „Lieferschein“ wird ohne eigenen Formulartyp automatisch 993 verwendet. 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: 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 „Form Recognizer“), 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 (LLM): Wählt per LLM das passende Aufwands-Sachkonto aus allen Erfolgskonten des Mandanten und legt es als {Gegenkonto} ab. Am BelegPro-Rucksack hat dieser Vorschlag Vorrang vor Kreditor-Historie und Dokumentenart-Default. Nur FIBU. Vor dem BelegPro-Rucksack platzieren, sinnvoll mit der Bedingung „Gegenkonto ist leer“, damit die KI nur einspringt, wenn die Historie nichts liefert. In der Vorlage Eingangsrechnungen als deaktivierter Opt-in enthalten. Für den Lieferantennamen im Prompt gilt dieselbe Kontenstamm-Auflösung wie beim Buchungstext-Schritt (Parameter Pool-Feld mit dem aufgelösten Partnernamen); das gilt ebenso für die Belegkategorie (LLM).

• 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 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)

• 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.“

• 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. Ergänzend filtern Richtung (Einkauf/Verkauf) und 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. Liegt keine Bestellnummer im Erkennungsergebnis vor, ermittelt der Schritt sie auf Wunsch selbst (Texterkennung, bei Bedarf KI). 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“) und {Buchungstext.Vorbeleg} den Buchungstext des gefundenen Belegs.

  

• 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

• Lucene-Reindex: Suchindex nach Analyse aktualisieren

• 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: Sechs eingebaute Vorlagen stehen als Ausgangspunkt bereit und können nach dem Anwenden frei angepasst werden:

Vorlage	Deckt ab
Eingangsrechnungen	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)
Nur Archivierung	Das Minimum: Extraktion (inkl. Texterkennung für die Suche) und Schlagworte. Kein LLM nötig
CRM-Dokument	Stammdaten finden bzw. anlegen 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 finden/anlegen, Artikel je Position (Wildcard-Suche), CRM-Fall

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 bringt die Schritte Gegenkonto-Ermittlung (LLM) und Belegkategorie (LLM) bereits mit — aber ausgeschaltet. 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, 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.

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 LLM-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.

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, 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“ 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 „SQL"-Badge 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 LLM-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 (LLM-Profile)

Ein „eigenes LLM“ wird als LLM-Profil verwaltet (Einstellungen → LLM-Profile, Berechtigung admin.ki). Ein Profil bündelt Provider, Modell, Endpoint, API-Schlüssel, Temperatur, Token-Limit und Preise; 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 LLM-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 (LLM-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), LLM-Fallback, Testlauf und Mail-Plausibilitäts-Check. 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 können per Wildcard-Lookup (positionen/*/bezeichnung) weiterverarbeitet werden.

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. Schlagworte — Zertifikatsnummer + Norm als Betreff, Zusammenfassung als Langtext.
4. Stammdaten-Lookup (Personenkonto) — findet den Lieferanten über den Namen des Zertifikatsinhabers → {Kreditor.Kontonummer} im Pool.
5. Stammdaten-Lookup (Artikel) — ordnet den Prüfgegenstand einem Artikel zu.
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); ohne Treffer wird das Kundenkonto per Debitor-ExIm-Vorlage neu angelegt. Die Kontonummer landet in beiden Fällen als {Kreditor.Kontonummer} + {Kreditor.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 → KI-Analyse → Grundeinstellungen, 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-Anlage (Kunde/Debitor)	Kunde über Name/USt-ID finden oder per Debitor-ExIm-Vorlage anlegen → {Kreditor.Kontonummer} (für die Partner-Verknüpfung des Falls)
4	Stammdaten-Lookup (Artikel, Wildcard)	angefragte Artikel je Position → positionen/{Index}/GefundeneArtikelNr
5	Schlagworte	Betreff, Kundenkonto, erste Artikelnummer, Zusammenfassung als Filter
6	Fall-Anlage (CRM-Fall)	legt den CRM-Fall an; Kurz-/Langbeschreibung, Start-/Endtermin 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: Einstellungen → LLM-Profile → 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 LLM-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.
• 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 Fall-Id-Feld) 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 (Wildcard wie in Fall E), Ergebnis für Mappings und Prüfprozesse.
• Mahnung / Kontoauszug → Personenkonto-Zuordnung per Stammdaten-Lookup, Schlagworte und E-Mail-Benachrichtigung an die Buchhaltung.
• Gegenkonto-Ermittlung mit eigenem LLM-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.
• OpenAI-kompatible Endpunkte erforderlich: Alle LLM-Aufrufe der Analyse-Pipeline laufen über /chat/completions im OpenAI-Format.
• Keine Artikel-Neuanlage: Artikel sind nur findbar (Lookup), nicht anlegbar.
• Kein Kontakt-Lookup: Die Kontakt-Anlage legt immer neu an (kein Dublettencheck).
• Import-Vorlage für weitere Konto-Arten: Global hinterlegbar sind Vorlagen für Kreditor, Debitor und Ansprechpartner. Für Interessent und Anfragelieferant wird die Import-Vorlage direkt am Pipeline-Schritt gewählt.

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 in der Sektion Stammdaten die Spalte Typ zur Auswahl (Kreditor, Debitor, Interessent, Anfragelieferant, Ansprechpartner). Die Mappings dieser Sektion 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 → KI-Analyse, Spalte im Dokumentenarten-Grid). 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 per Dropdown ausgewä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 den Button Feldreferenz bzw. das Hilfe-Symbol neben der Mapping-Sektion 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. Im Admin-Bereich unter KI-Analyse → Dokumentarten die gewünschte Dokumentart öffnen
2. Aktion auf CRM-Fall (Feldliste) setzen
3. CRM-Vorlage per Dropdown auswählen (die verfügbaren Vorlagen werden automatisch vom WinLine-Server geladen)
4. Zeile aufklappen (Detail-Bereich): Hier erscheint ein Mapping-Grid 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 Dokumentart 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 per Dropdown ausgewä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-Grid erlaubt die Zuordnung von KI-Quellfeldern bzw. Template-Ausdrücken zu den Vorlagenfeldern.

Vorlagenbasierte Zielfelder: Die Zielfelder in allen Mapping-Grids (CRM-Fall, Kreditor, Kontakt, BelegPro) stammen dynamisch aus der jeweils gewählten ExIm-Vorlage. Beim Klick auf Standard 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.

Standard-Mapping laden: Der Knopf 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 Dropdown dargestellt. Die Vorlagen und deren Felder werden automatisch vom WinLine-Server geladen.

Format-Spalte: Jedes Mapping-Grid (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“.

GetMyInvoices-Anbindung (GMI)

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

• Empfangsadresse: Fest eingestellte Adresse, die in den GetMyInvoices-Einstellungen eingetragen wird.
• Zugangsdaten: Authentifizierungsgeheimnisse (verschlüsselt gespeichert).
• Standardeinstellungen: Dokumentart, 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 Dokumentart, 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 oder fehlendem Anhang 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): Tenant (Domain), UPN des Postfachs sowie Tenant-ID, Client-ID und Client-Secret der registrierten App eingeben.
   • 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.
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. Plausibilität: Die mehrstufige Prüfung konfigurieren (siehe unten).
6. 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. 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.

Suchindex

Der Suchindex beschleunigt die Schnellsuche und ermöglicht erweiterte Suchfunktionen.

• Status: Übersicht über den Indexstand aller Mandanten.
• Neu aufbauen: Index für einen Mandanten vollständig neu erstellen (läuft im Hintergrund).
• Indexierte Felder: Anzeige, welche Schlagwortfelder im Index enthalten sind.
• Durchsuchen: Index zu Prüfzwecken direkt durchsuchen.
• Ähnlichkeitssuche: Zu einem Dokument ähnliche Dokumente finden.
• Einstellungen: Schwellenwerte für unscharfe Suche und Ähnlichkeitserkennung anpassen.

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 (admin.system, siehe Administration delegieren) schaltet weiterhin beide Bereiche gemeinsam frei.

Texterkennung nachträglich erzeugen

Unter Einstellungen können fehlende Texte (aus der automatischen Texterkennung) für den gesamten Archivbestand nachträglich erstellt werden. Unterstützte Formate: PDF, PNG, JPG, TIFF, BMP, GIF, archivierte E-Mails (EML) sowie Word (DOC/DOCX) und Excel (XLS/XLSX), WinLine-Belegdrucke (SPL, sofern der MesoSpool-Dienst konfiguriert ist) — bei E-Mails 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.

• Einmalig starten: Startet den Vorgang sofort. Deaktiviert sich nach Abschluss automatisch.
• Täglicher Zeitplan: Führt die Texterkennung automatisch täglich zur eingestellten Uhrzeit aus (z. B. 02:00 Uhr nachts).
• 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 neuesten Dokumente zuerst. Gilt nicht für „Einmalig starten“.
• Fortschritt: Wird in Echtzeit angezeigt.

Der System-Status (Verwaltung → Einstellungen → Übersicht) 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. Outlook-Nachrichten im MSG-Format) 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.

Einstellungen

Die Einstellungen sind über eine durchgehend sichtbare Kategorie-Leiste auf der linken Seite gegliedert; ein Klick auf eine Kategorie tauscht rechts nur den Inhaltsbereich aus – auch in Detailseiten (z. B. der Pipeline-Konfiguration einer Dokumentenart oder der GetMyInvoices-Einrichtung) bleibt die Leiste sichtbar. Verfügbare Kategorien (abhängig von den eigenen Berechtigungen):

Die Einstellungen sind nach Themen gegliedert; die Leiste links führt zu den einzelnen Bereichen. Die Übersicht meldet den Systemzustand und die wichtigsten Kennzahlen — Anzahl der Dokumentenarten, aktive Eingangsquellen, heute verarbeitete Belege.

• Übersicht – System-Status und Kennzahlen der Dokumentverarbeitung.
• Eingang & Quellen – Konfiguration aller Eingangskanäle: Manueller Upload, GetMyInvoices und E-Mail-Postfach. Diese Einstellungen waren bisher am Ende der Dokumentenarten-Seite versteckt und sind jetzt als eigene Kategorie direkt auffindbar.
• Dokumentenarten – zentrale Übersicht aller in WinLine definierten Dokumentenarten (auch ohne archivierte Dokumente) mit KI-Modell, Workflow-Zuweisung und Pflichtfeldern; über Aktualisieren erscheinen neu angelegte Dokumentenarten sofort.
• KI & Verarbeitung – KI-Infrastruktur: KI-Profile (die zentrale Ablage aller KI-Zugangsdaten), OCR-Vervollständigung, Chat-KI-Konfiguration.
• Mandanten & Daten – Mandanten-Freischaltung, Aufbewahrung des Verarbeitungsprotokolls, Feldprotokoll.
• Branding & Kommunikation – Login-Logo, Chat-Aktivierung, Feedback-Funktion, E-Mail-Versand (SMTP), Sitzungsdauer.

Die Chat-Konfiguration ist auf zwei Karten aufgeteilt — die globale Aktivierung unter „Branding & Kommunikation“, die KI-Konfiguration (KI-Profil und Verhalten der Antworten) unter „KI & Verarbeitung“. 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.

Weitere Verwaltungsoptionen:

• Mandanten-Freischaltung: 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.
• Anmerkungs-Einstellungen: Dokumentenart für Anmerkungen zuordnen.
• Anmelde-Logo: Eigenes Firmenlogo für die Anmeldeseite hochladen (PNG oder SVG, bis 2 MB). Kann jederzeit auf das Standardlogo zurückgesetzt werden.
• E-Mail-Versand (SMTP): 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 Einstellungen → Branding & Kommunikation → 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

Übersicht aller aktuell angemeldeten Benutzer mit Sitzungsdetails.

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.

Jede Zeile ist ein Verarbeitungsschritt mit Zeitpunkt, Dokument, Schritt, Status und Meldung. Filtern Sie oben auf eine Dokument-ID, sehen Sie den kompletten Weg eines Belegs — von der Extraktion über Stammdaten- und Fall-Anlage bis zur Aktualisierung des Suchindex.

• Übersichtsliste: Filterbare, sortierbare Ansicht aller Verarbeitungsschritte.
• Schritt „Eingang": Jedes Dokument beginnt mit demselben Schritt, unabhängig von seiner Herkunft — manueller Upload, GetMyInvoices oder E-Mail-Postfach. Die Herkunft steht 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.
• Zeitstrahlansicht: Für ein einzelnes Dokument werden alle Verarbeitungsschritte als Zeitstrahl dargestellt — mit Status-Anzeige (Erfolg, Warnung, Fehler) und aufklappbaren technischen Details.
• 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.
• LLM-Profil-Anzeige: Zeigt das verwendete LLM-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 Einstellungen → Mandanten & Daten → 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 → Audit 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: Die Log-Ansicht zeigt Zeitpunkt, Benutzer, Mandant, Ereignisart und Bezug (z. B. Dokument oder Fall); ein Klick auf einen Eintrag öffnet die Details. Aus Performance-Gründen werden maximal 200 Einträge je Abfrage angezeigt – ein Hinweis macht darauf aufmerksam, wenn die Filter eingeschränkt werden sollten. 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 → 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); die Kopfzeilen-Checkbox 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.

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.

---