KI-Rechnungsverarbeitung im kleinen Unternehmen: Was darf automatisch laufen?

Unter Rechnungsautomatisierung werden häufig Tätigkeiten zusammengefasst, die wirtschaftlich und technisch unterschiedliche Risiken haben. Ein Dokument zu erkennen ist etwas anderes, als einen Buchungsvorschlag zu erzeugen. Einen Buchungsvorschlag zu speichern ist wiederum etwas anderes, als eine Zahlung auszulösen. Für die Projektplanung sollten diese Schritte getrennt beschrieben werden. Andernfalls entsteht leicht ein System, das zwar hervorragend Daten ausliest, aber unbemerkt weitergehende Rechte erhält, als für diese Aufgabe erforderlich wären.

Auch das Wort Prüfung braucht eine genaue Bedeutung. Eine rechnerische Prüfung kontrolliert beispielsweise Summen und Steuerbeträge. Eine sachliche Prüfung fragt, ob die Leistung tatsächlich erbracht wurde. Ein Bestellabgleich untersucht, ob Preis und Menge zur Bestellung passen. Aus dem Dokument allein lässt sich nicht zuverlässig ableiten, ob die bestellte Maschine angekommen ist oder eine Beratungsleistung abgenommen wurde. Unsere Empfehlung ist deshalb, jede Prüfart mit ihrer Datenquelle und ihrer verantwortlichen Rolle festzuhalten.

Ein geeigneter erster Automatisierungsumfang kann lauten: Rechnungen aus einem definierten Postfach übernehmen, Pflichtfelder auslesen, vorhandene Lieferanten zuordnen, Dublettenverdacht prüfen und einen Entwurf im Buchhaltungssystem anlegen. Änderungen an Bankverbindungen, neue Lieferanten und Zahlungsfreigaben bleiben außerhalb dieses Umfangs. Ein solcher Zuschnitt liefert bereits praktische Entlastung, ohne vorauszusetzen, dass die KI sämtliche buchhalterischen und betrieblichen Zusammenhänge beurteilen kann.

Die Trennung passt zum Grundgedanken kontrollierter KI-Prozesse: Head and Code beschreibt eine Verbindung aus Datensammlung, Analyse, Entwurf, menschlicher Bewertung und anschließender automatisierter Weiterverarbeitung. Der DUP-Gastbeitrag von Kilian Springer betont außerdem, dass die übertragene Verantwortung für die Automatisierungsentscheidung maßgeblich ist. Beides sind hilfreiche Gestaltungsansätze, aber keine Garantie für die Zuverlässigkeit eines konkreten Rechnungssystems. Diese muss der Betrieb selbst prüfen. [1][3]

Für einen Pilot eignen sich nicht automatisch die häufigsten oder teuersten Rechnungen. Gesucht wird eine Gruppe mit wiederkehrendem Eingang, verfügbaren Vergleichsdaten und überschaubaren Folgen bei Fehlern. Denkbar sind Materialrechnungen bekannter Lieferanten mit hinterlegter Bestellung und dokumentiertem Wareneingang. Schwieriger sind frei formulierte Leistungsabrechnungen, bei denen nur die Projektleitung beurteilen kann, ob zusätzliche Stunden berechtigt waren. Hier kann die KI vorbereiten, aber die fehlende fachliche Information nicht ersetzen.

Vor der Modellauswahl lohnt eine Bestandsaufnahme der Eingangsformate. Enthält eine Rechnung bereits zuverlässig maschinenlesbare strukturierte Daten, sollte zunächst ein regelbasierter Import geprüft werden. Ein Sprachmodell muss keine vorhandenen Felder erneut aus einem sichtbaren Dokument erraten. Bei eingescannten Belegen kann dagegen eine Texterkennung erforderlich sein; bei uneinheitlichen Beschreibungen kann KI die Zuordnung unterstützen. Die grundsätzliche Verbindung strukturierter Verarbeitung und KI für unstrukturierte Informationen wird auch in den vorliegenden Prozessbeschreibungen hervorgehoben. [1][4]

Ein fiktiver Handwerksbetrieb könnte beispielsweise mit Rechnungen seiner drei regelmäßig genutzten Materiallieferanten beginnen. Abschlagsrechnungen für große Projekte, fremdsprachige Sonderbelege und Rechnungen ohne Bestellbezug werden zunächst ausgeschlossen. Diese Eingrenzung ist kein technischer Rückschritt. Sie schafft eine überprüfbare Ausgangslage: Das Team weiß, welche Fälle das System beherrschen muss, und kann erkennen, wann ein Dokument gar nicht in den freigegebenen Arbeitsbereich gehört.

Entscheidend ist außerdem, ob die heutigen Daten den gewünschten Abgleich erlauben. Wenn Bestellungen nur telefonisch erfolgen und Lieferscheine nicht zugeordnet werden, fehlt der Automatisierung eine belastbare Vergleichsgrundlage. In diesem Fall kann die erste Verbesserung ein einfaches digitales Bestellregister sein. Unsere Empfehlung lautet: Erst den fehlenden Informationsfluss schließen, dann die Entscheidung automatisieren. Ein größeres Modell ist kein Ersatz für einen nicht dokumentierten Wareneingang.

Die Bezeichnung digitaler Mitarbeiter kann anschaulich sein, verschleiert aber leicht die tatsächliche Befugnisverteilung. Auf der aiworx-Seite wird beschrieben, dass Unternehmen festlegen, was ein Agent allein erledigen darf und wo Menschen freigeben. Für die Umsetzung reicht diese allgemeine Aussage nicht. Benötigt wird eine Freigabematrix: eine schriftliche Zuordnung von Fallmerkmalen, erlaubten Aktionen und zuständigen Personen. Sie sollte verständlich genug sein, dass Buchhaltung und Geschäftsführung denselben Ablauf daraus ableiten. [2]

Unsere Empfehlung ist eine dreistufige Matrix. In der ersten Stufe darf das System Daten erfassen und einen Entwurf erstellen. In der zweiten darf es klar definierte Standardfälle an einen bereits freigegebenen Folgeprozess übergeben. In der dritten muss es anhalten und eine Entscheidung anfordern. Maßgeblich sind nicht nur Beträge, sondern beispielsweise Lieferantenstatus, Bestellübereinstimmung, Dokumenttyp, fehlende Angaben und veränderte Zahlungsdaten. Ein kleiner Betrag macht eine geänderte Bankverbindung nicht automatisch harmlos.

Für jeden Stopp braucht es einen konkreten Bearbeitungsauftrag. Die Meldung „Bitte Rechnung prüfen“ ist zu allgemein. Besser wäre: „Die Rechnungsmenge beträgt zwölf Stück, der dokumentierte Wareneingang zehn. Bitte Teilbelieferung bestätigen oder Rechnung zurückweisen.“ Die prüfende Person erhält das Original, die betroffene Position und die Vergleichsdaten. Dadurch wird die menschliche Freigabe zu einer fachlichen Entscheidung statt zu einem reflexhaften Klick auf einen grünen Knopf.

Grenzen müssen außerdem zur personellen Ausstattung passen. Wenn nur eine Person für Buchhaltung zuständig ist, darf ihr Urlaub nicht zur unkontrollierten Umgehung aller Prüfungen führen. Vertretung, maximale Liegezeit und Eskalationsweg gehören deshalb in dieselbe Matrix. Wird eine Grenze überschritten oder fehlt die Vertretung, bleibt der Vorgang offen. Eine Automatisierung sollte fehlende Zuständigkeit sichtbar machen, nicht durch zusätzliche Eigenständigkeit verdecken.

Als Referenzarchitektur empfehlen wir eine feste Verarbeitungskette: Eingang, Dokumentaufbereitung, Datenextraktion, Abgleich, Freigabe, Übergabe und Überwachung. Ein Workflow-System steuert dabei die Reihenfolge. Workflow bedeutet hier schlicht einen technisch beschriebenen Arbeitsablauf. Das Sprachmodell übernimmt nur Aufgaben, die flexible Interpretation benötigen. Die Integration über Schnittstellen und die Kombination klassischer Verarbeitung mit KI werden auch von Head and Code beschrieben; dort werden Workflow-Systeme und individuelle Software als mögliche Bausteine genannt. [1]

Beim Eingang erhält jeder Vorgang eine eindeutige Kennung. Das System speichert das Original in der vorgesehenen Dokumentenablage und erfasst den Eingangskanal. Danach wird festgestellt, ob strukturierte Rechnungsdaten vorliegen oder eine Texterkennung gebraucht wird. Die Extraktion erzeugt einen definierten Datensatz mit Lieferant, Rechnungsnummer, Datum, Währung, Beträgen und Positionen. Für sensible Felder sollte zusätzlich hinterlegt werden, aus welcher Stelle des Originals der Wert stammt. Fehlende Informationen bleiben ausdrücklich leer statt plausibel ergänzt zu werden.

Für Entwickler empfiehlt sich ein streng definiertes Ausgabeschema, beispielsweise mit festgelegten Datentypen, erlaubten Währungen und getrennten Betragsfeldern. Eine formal gültige Ausgabe ist allerdings noch keine sachlich richtige Ausgabe. Nach der Formatprüfung folgen daher unabhängige Kontrollen: Summenrechnung mit Dezimalarithmetik, Abgleich mit Lieferantenstammdaten, Prüfung von Bestellbezügen und Suche nach möglichen Dubletten. Ein Modellvorschlag darf diese Regeln nicht selbst umschreiben oder durch eine sprachliche Begründung außer Kraft setzen.

Die Übergabe an das Buchhaltungssystem sollte über eine dokumentierte Programmierschnittstelle erfolgen, eine sogenannte API. Wichtig ist Idempotenz: Wird derselbe technische Auftrag wegen einer Zeitüberschreitung erneut gesendet, darf kein zweiter Buchungsvorschlag entstehen. Dafür werden eine stabile Vorgangskennung und ein Abgleich des Zielstatus benötigt. Bei Unterbrechungen muss der Workflow erkennen können, ob der Zielschritt bereits erfolgreich war. Ein bloßes Wiederholen der gesamten Kette wäre dafür zu riskant.

Externe Schreibzugriffe gehören in einen eigenen, eng begrenzten Dienst. Das Modell darf beispielsweise eine Lieferantenzuordnung vorschlagen, aber nicht beliebige Datenbankbefehle ausführen. Pro Vorgang sollten Dokumentversion, eingesetzte Modellversion, Regelstand, Prüfergebnisse und Freigaben nachvollziehbar sein. Diese Trennung erleichtert auch einen späteren Modellwechsel: Solange der vereinbarte Datenvertrag erhalten bleibt und die Tests bestanden werden, muss nicht die komplette Buchhaltungsintegration neu gebaut werden.

In einer Vorführung ist meist der erfolgreiche Standardfall zu sehen. Für die Einführung ist jedoch mindestens ebenso wichtig, was bei beschädigten Dateien, unklaren Positionen oder ausgefallenen Schnittstellen passiert. Der factro-Beitrag nennt Rechnungsabgleich, Dublettenerkennung und die Weiterleitung auffälliger Fälle zur manuellen Prüfung als Einsatzmöglichkeiten. Daraus folgt für die Gestaltung: Die Ausnahmebearbeitung ist kein nachträgliches Zusatzfenster, sondern ein eigenständiger Teil des Produkts. [4]

Nehmen wir eine Rechnung, deren Nummer einmal als „2026-I08“ und einmal als „2026-108“ gelesen wird. Eine exakte Zeichenkettenprüfung könnte die mögliche Doppelung übersehen. Eine zusätzliche Ähnlichkeitssuche anhand von Lieferant, Datum und Betrag kann einen Prüfhinweis erzeugen. Sie sollte aber nicht ohne Weiteres eine Rechnung löschen oder ablehnen: Wiederkehrende Beträge kommen auch bei berechtigten Rechnungen vor. Der passende Ausgang ist ein begründeter Verdacht mit sichtbaren Vergleichsbelegen.

Andere Fehler entstehen erst über mehrere Schritte. Eine Rechnung wird korrekt gelesen, aber dem falschen Unternehmen innerhalb einer Unternehmensgruppe zugeordnet. Eine Gutschrift wird als normale Rechnung behandelt. Ein geändertes Lieferantenlayout verschiebt die Zuordnung von Netto- und Bruttobetrag. Ein PDF enthält mehrere Rechnungen, obwohl die Verarbeitung genau einen Beleg erwartet. Für solche Fälle braucht das System explizite Zustände wie „Dokumenttrennung erforderlich“, „Empfänger unklar“ oder „Belegtyp widersprüchlich“.

Technische und fachliche Ausnahmen sollten getrennt werden. Eine kurzfristig nicht erreichbare Schnittstelle kann mit begrenzten Wiederholungsversuchen erneut angesprochen werden. Ein fehlender Wareneingang wird dagegen nicht durch zehn weitere Modellaufrufe geklärt. Die Warteschlange sollte Ursache, Alter, Zuständigkeit und nächsten Schritt zeigen. Wiederkehrende Ursachen werden regelmäßig ausgewertet: Vielleicht ist nicht das Modell schlecht, sondern ein Lieferant schickt ständig unvollständige Bestellreferenzen.

Eine hohe Trefferquote einzelner Felder beantwortet noch nicht, ob ein Prozess sicher genug ist. Viele richtig erkannte Adressen gleichen eine falsch übernommene Bankverbindung nicht aus. Unsere Empfehlung ist deshalb eine risikogewichtete Bewertung: Welche Fehler sind lästig, welche verursachen Nacharbeit, und welche könnten eine falsche Buchung oder Zahlung begünstigen? Aus dieser Einteilung entstehen getrennte Messgrößen und Freigabekriterien statt einer einzigen attraktiven Prozentzahl.

Für den Test wird eine repräsentative Sammlung historischer, zulässig verwendbarer Belege benötigt. Sie sollte Lieferanten, Layouts, Betragsklassen und schwierige Sonderfälle abdecken. Fachkundige Personen legen die erwarteten Ergebnisse fest und klären strittige Fälle. Ein Teil der Belege bleibt als unabhängige Abnahmeprüfung zurück; er wird nicht ständig zur Anpassung der Anweisungen verwendet. Sonst zeigt der Test hauptsächlich, wie gut das System die bereits bekannten Beispiele trifft.

Besonders wichtig sind zwei unterschiedliche Fehlerarten: Ein korrekter Standardfall wird unnötig angehalten, oder ein problematischer Fall wird fälschlich durchgelassen. Der erste Fehler kostet Zeit. Der zweite kann größere Folgeschäden auslösen. Beide müssen gemessen werden, zusätzlich zur Bearbeitungszeit und zur Korrekturarbeit. Ein vom Sprachmodell ausgegebener Sicherheitswert genügt dafür nicht. Seine Aussagekraft müsste zuerst anhand bekannter Fälle geprüft werden; besser sind nachvollziehbare Prüfmerkmale und belegte Abgleiche.

Vor produktiven Schreibzugriffen empfiehlt sich ein Schattenbetrieb. Das System verarbeitet reale Eingänge parallel, seine Ergebnisse werden aber nicht eigenständig ins führende System übernommen. Anschließend lassen sich Vorschläge mit der tatsächlichen Bearbeitung vergleichen. Die Abnahme umfasst auch absichtlich eingebaute Störungen: doppelte Zustellung, ungültige Antwortformate, Schnittstellenausfall und widersprüchliche Dokumente. Nach Änderungen an Modell, Anweisungen oder Regeln werden die relevanten Tests erneut ausgeführt.

Eine Rechnung enthält nicht nur Zahlen. Je nach Fall stehen darin Namen, Kontaktdaten, Projektinformationen oder personenbezogene Leistungsbeschreibungen. Vor dem Einsatz muss deshalb nachvollziehbar sein, welche Inhalte an welchen Dienst gelangen, wo sie gespeichert werden und wer darauf zugreifen kann. Head and Code nennt sowohl Cloud-Modelle als auch lokale KI-Umgebungen und führt Benutzerrechte, Protokollierung sowie definierte Prozessgrenzen als mögliche Kontrollmechanismen auf. Welche Variante passt, hängt vom konkreten Schutzbedarf ab. [1]

Für die Beschaffung empfehlen wir eine dokumentierte Datenschutzprüfung des gesamten Ablaufs. Dazu gehören Rechtsgrundlage und Zweck der Verarbeitung, gegebenenfalls erforderliche Vereinbarungen zur Auftragsverarbeitung, Unterauftragnehmer, Drittlandtransfers, Löschregeln und die vertraglichen Bedingungen zur Datennutzung. Diese Punkte sind projektspezifisch mit Datenschutzverantwortlichen zu bewerten. Eine europäische Serverregion allein beantwortet nicht sämtliche Fragen. Ebenso wenig ist eine lokale Installation automatisch sicher, wenn Zugangskontrollen, Aktualisierungen und Datensicherungen fehlen.

Ein besonderer technischer Test betrifft manipulierte Dokumentinhalte. Als Prompt Injection bezeichnet man den Versuch, einem KI-System über verarbeitete Inhalte neue Anweisungen unterzuschieben. In einer Rechnung könnte beispielsweise ein versteckter Text stehen, der zur Änderung von Zahlungsdaten auffordert. Für die empfohlene Architektur gilt deshalb: Dokumenttexte sind Daten, keine Befehle. Die KI darf daraus Werte extrahieren, aber weder neue Werkzeuge freischalten noch Empfänger für Datenübertragungen bestimmen.

Praktisch bedeutet das: separate technische Konten, minimale Rechte, zugelassene Zielsysteme und keine frei nutzbaren Zugangsdaten im Modellkontext. Eine vorgeschlagene neue Bankverbindung wird ausschließlich über einen gesonderten Prüfprozess behandelt. Auch Protokolle brauchen Schutz und Löschregeln; vollständige Beleginhalte sollten nicht unnötig in mehreren Diagnosewerkzeugen landen. Berechtigungen müssen bis in die Prüfansicht reichen, damit Beschäftigte nur die Rechnungen und Vergleichsdaten sehen, für die sie zuständig sind.

Die aiworx-Seite stellt beispielhaft eine manuelle Bearbeitung von 15 Minuten einer weitgehend automatisierten Verarbeitung mit ungefähr einer Minute gegenüber. Solche Anbieterrechnungen können die Idee veranschaulichen, ersetzen aber keine Messung im eigenen Betrieb. Wer bereits strukturierte Rechnungen importiert, startet unter anderen Bedingungen als ein Unternehmen, das jede Position abtippt. Außerdem muss die Zeit für Ausnahmen, Korrekturen und die laufende Betreuung in die Rechnung einfließen. [2]

Ein ausdrücklich hypothetisches Rechenbeispiel: Ein Betrieb verarbeitet monatlich 400 geeignete Rechnungen und benötigt bisher durchschnittlich sechs Minuten pro Beleg. Das entspricht 40 Stunden. Nach Einführung entfallen im Durchschnitt zwei Minuten auf die Prüfung jedes Belegs, also rund 13,3 Stunden. Zusätzlich brauchen 60 Ausnahmefälle jeweils fünf weitere Minuten, zusammen fünf Stunden. Weitere drei Stunden fallen für Systemkontrolle und Pflege an. Die rechnerische Nettoentlastung beträgt damit ungefähr 18,7 Stunden im Monat, nicht 40 Stunden.

Bei einem angenommenen internen Vollkostensatz von 40 Euro pro Stunde entspricht diese Kapazität rund 747 Euro monatlich. Werden für das Beispiel 300 Euro laufende Gesamtkosten angesetzt, verbleibt ein rechnerischer Nutzen von ungefähr 447 Euro. Eine ebenfalls angenommene Einführungssumme von 6.000 Euro wäre damit nach etwa 13,4 Monaten ausgeglichen. Alle Zahlen sind Planungsannahmen, keine Marktpreise oder Kundenergebnisse. Zudem wird frei werdende Arbeitszeit nur dann zur unmittelbaren Kosteneinsparung, wenn tatsächlich Ausgaben entfallen.

Für eine belastbare Entscheidung sollten mindestens ein günstiges und ein ungünstiges Szenario berechnet werden. Was passiert, wenn doppelt so viele Ausnahmen auftreten oder eine Schnittstelle zusätzliche Pflege benötigt? Einzubeziehen sind Einrichtung, Datenbereinigung, Schulung, Modellnutzung, Dokumentenverarbeitung, Support und Sicherheitsbetrieb. Eine Standardlösung kann schneller starten; eine individuelle Integration kann besser zu komplexen Abläufen passen. Entscheidend ist der Gesamtaufwand über den Betrieb hinweg, nicht allein die Lizenz oder der Preis eines Modellaufrufs.

Bei der Anbieterauswahl sollte eine Demonstration mit eigenen, datenschutzgerecht vorbereiteten Testbelegen mehr zählen als ein allgemeines Agentenversprechen. Lassen Sie nicht nur den erfolgreich verarbeiteten Beleg zeigen, sondern auch eine Dublette, eine unbekannte Lieferantenkennung und eine Rechnung mit widersprüchlichen Beträgen. Der Anbieter sollte erklären können, welche Entscheidung durch feste Regeln entsteht, welche durch ein Modell und welche durch eine Person. Unklare Antworten an dieser Stelle sprechen gegen einen frühen produktiven Schreibzugriff.

Klären Sie außerdem, welche Daten und Konfigurationen exportiert werden können. Dazu zählen Vorgangsstatus, Freigabehistorie, Feldzuordnungen und dokumentierte Prüfregeln. Ein Wechsel des Anbieters darf nicht bedeuten, dass niemand mehr nachvollziehen kann, warum ein Beleg weitergegeben wurde. Ebenso wichtig sind die unterstützten Schnittstellen: Eine vorhandene Verbindung zum Buchhaltungssystem ist nur hilfreich, wenn sie den benötigten Belegtyp, die richtigen Statuswerte und eine sichere Fehlerbehandlung tatsächlich unterstützt.

Intern braucht der Prozess eine fachliche und eine technische Verantwortung. Die fachliche Seite entscheidet über erlaubte Fallgruppen, Abweichungen und Freigaben. Die technische Seite überwacht Verarbeitung, Berechtigungen und Störungen. In kleinen Betrieben können Personen mehrere Rollen übernehmen; die Aufgaben müssen trotzdem benannt bleiben. Eine externe Betreuung sollte feste Eskalationswege haben. Niemand sollte erst beim Monatsabschluss herausfinden, dass seit Tagen Rechnungen in einer unbeobachteten Warteschlange liegen.

Die notwendige Qualifizierung geht deshalb über das Formulieren von Modellanweisungen hinaus. Der vorliegende alfatraining-Treffer beschreibt zwar ein entsprechendes Bildungsangebot, doch für die konkrete Betriebsentscheidung ist vor allem die im DUP-Gastbeitrag betonte Abnahmekompetenz relevant: Ergebnisse fachlich bewerten und Grenzen erkennen. Beschäftigte müssen lernen, Vergleichsdaten zu prüfen, Fehlermuster zu melden und einen Vorgang bewusst zurückzuweisen. Eine Einführung ist erst dann vollständig, wenn diese Aufgaben im Arbeitsalltag vorgesehen sind. [3]

Ein sinnvoller Pilot endet nicht mit einer gelungenen Vorführung, sondern mit einer dokumentierten Betriebsentscheidung. Zu Beginn werden Zielgruppe der Belege, erlaubte Aktionen, erwartete Entlastung und Abbruchkriterien festgelegt. Danach entsteht eine kleine, durchgängige Kette für genau diesen Umfang. Es ist meist hilfreicher, wenige Belegtypen einschließlich Ausnahmebearbeitung sauber abzudecken, als viele Typen nur im Idealfall zu erkennen. Erweiterungen folgen erst, wenn die ursprüngliche Gruppe zuverlässig beherrscht wird.

Die Einführung sollte stufenweise erfolgen: zunächst historische Belege, dann Schattenbetrieb, anschließend Entwürfe im Zielsystem und erst danach gegebenenfalls eng begrenzte automatische Übergaben. Jede Stufe erhält eine eigene Abnahme. Ein kritischer Fehler kann den Umfang wieder reduzieren, ohne dass das gesamte Projekt scheitert. Dafür muss ein Rückfall auf manuelle Bearbeitung vorbereitet sein. Originaldokumente, offene Vorgänge und bereits erfolgte Übergaben bleiben auch nach dem Abschalten der KI zugänglich.

Nach dem Start braucht es regelmäßige Auswertungen über Ausnahmen, Fehler und tatsächliche Zeitersparnis. Neue Lieferanten, andere Rechnungsformate oder geänderte interne Regeln können Anpassungen erforderlich machen. Das bedeutet nicht, dass das Modell automatisch aus jeder Korrektur lernt. Auch factro weist darauf hin, dass nicht jedes eingesetzte System mit jeder Interaktion selbstständig dazulernt. Verbesserungen sollten daher als kontrollierte Änderungen mit Tests und Freigabe organisiert werden. [4]

Die zentrale Entscheidung lautet am Ende nicht „KI oder keine KI“, sondern: Welche klar beschriebene Handlung lässt sich mit ausreichender Evidenz delegieren? Ein kleiner Betrieb kann sehr viel gewinnen, wenn Belege vorbereitet, Unstimmigkeiten sichtbar gemacht und doppelte Eingaben vermieden werden. Dafür muss das System nicht selbstständig bezahlen. Die beste erste Lösung ist diejenige, deren Arbeitsergebnisse sich leicht prüfen lassen und deren Grenzen im Alltag tatsächlich halten.