KI in ERP-Systemen: Architektur, Nutzen und Rollout

Um 14 Uhr liegen im Buchhaltungspostfach bereits neue Rechnungen, während drei Mitarbeitende Belege sortieren und Freigaben nachtelefonieren. Beim Mahnlauf hakt es, und der Controller braucht am späten Nachmittag wieder eine Liquiditätsauskunft, für die dieselben Daten wie am Vortag manuell zusammengesucht werden. Das Problem ist nicht fehlende Intelligenz im Unternehmen. Es fehlt eine verlässliche Verbindung zwischen Datenfeldern, ERP-Logik und dem nächsten Arbeitsschritt.

Genau dort entscheidet sich, ob KI in ERP-Systemen produktiv wird oder als Chatfenster neben dem eigentlichen Prozess stehen bleibt. Der Druck wächst: Laut Statistik Austria setzten 2025 30 % der österreichischen Unternehmen mit mindestens 10 Beschäftigten KI ein, nach 20 % im Jahr 2024 und rund 11 % im Jahr 2023. Viele dieser Einsätze laufen aber neben den Kernsystemen, nicht in ihnen.

Warum KI-Projekte an den Übergaben scheitern

Das Muster ist bekannt. Ein KI-Pilot läuft sauber im Demo-Chat, das Team ist beeindruckt, und beim nächsten Termin liegt die eigentliche Frage auf dem Tisch: Lässt sich das mit ERP, CRM und Buchhaltung verbinden? An dieser Stelle kippen viele Vorhaben, weil der Pilot isoliert funktioniert, aber im Tagesgeschäft keine sauberen Übergaben, keine belastbare Governance und keinen klaren operativen Nutzen erzeugt.

Die eigentliche Arbeit beginnt erst, wenn ein Vorschlag in ein Feld im CRM, eine Buchung in der Finanzsoftware oder einen Freigabeschritt im Workflow überführt werden muss. Das ERP speichert den Vorgang zuverlässig, aber es erkennt nicht automatisch, warum ein Beleg ungewöhnlich ist oder welcher nächste Schritt sinnvoll wäre. Ein Modell, das daneben Vorschläge macht, löst die Arbeit nicht. Es muss Daten lesen dürfen, Regeln verstehen, Aktionen über klar definierte Werkzeuge ausführen und jede Entscheidung nachvollziehbar hinterlassen.

Praktische Regel: Wenn ein KI-Ergebnis nicht kontrolliert in ein bestehendes System zurückschreibt, bleibt es ein Nebenprojekt.

Daraus ergibt sich die zentrale Architekturfrage: Wie kommt KI kontrolliert in den Workflow, statt nur auf den Workflow zu schauen? Wer gerade ein ERP erneuert, sollte KI deshalb nicht als nachträgliches Add-on behandeln. Schnittstellen, Rollen und Datenmodelle entscheiden bereits im Architekturentwurf, ob Automatisierung später sicher eingebettet werden kann.

So entsteht operative Wirkung im ERP

KI funktioniert im ERP nicht deshalb, weil ein Sprachmodell gut formuliert. Sie funktioniert, wenn der Prozess genügend Struktur besitzt und das System den Unterschied zwischen einer Empfehlung und einer Buchung sauber behandelt. Die Datenqualität ist dabei keine technische Nebensache. Ein Beitrag der FH Oberösterreich beschreibt KI in ERP-Systemen genau in dieser Doppelrolle: als Werkzeug für Entscheidungen und als Instrument, um Datenqualität zu verbessern und abzusichern.

Vier Voraussetzungen für belastbare Automatisierung

1. Strukturierte Stammdaten: Mandanten, Lieferanten, Kunden, Konten, Kostenstellen und Zahlungsbedingungen müssen eindeutig sein. Ein Agent kann Dubletten markieren, sollte aber keine unsichere Zusammenführung eigenständig durchführen.

2. Sauberes Buchungsjournal: Buchungen brauchen konsistente Kontierungen, Zeitbezüge und Referenzen. Ohne diese Historie kann ein Modell zwar Muster erkennen, aber keine verlässliche Erklärung für Abweichungen liefern.

3. Eindeutige Beleghistorie: Der Prozess muss zeigen, wann ein Beleg eingegangen ist, wer ihn verändert oder freigegeben hat und welche Datenquelle verwendet wurde. Das ist die Grundlage für spätere Prüfung und Fehleranalyse.

4. Kontrollierte Prozessaktion: OCR kann Inhalte auslesen, ein Klassifikationsmodell kann Konten vorschlagen und ein Agent kann den nächsten Schritt vorbereiten. Die tatsächliche Buchung oder Freigabe braucht aber einen definierten Berechtigungsweg.

Wo KI im Kernprozess passt

Belegerkennung eignet sich, wenn OCR, Kontierungsregeln und Lieferantenstammdaten zusammenspielen. Liquiditätsprognosen brauchen echte Zahlungsströme sowie eine klare Trennung von Ist-Daten und Annahmen. Anomalieerkennung im Mahnwesen kann ungewöhnliche Verzögerungen, doppelte Vorgänge oder abweichende Beträge markieren. Stammdatenpflege profitiert von Vorschlägen und Validierungen, sollte bei kritischen Änderungen aber einen Menschen einbinden.

Der häufigste Fehler ist ein Agent, der direkt auf unsortierte Daten losgelassen wird. Das erzeugt keine Automatisierung, sondern schwer erklärbare Folgearbeit. Erst Datenmodell, Berechtigung und Prozesszustand festlegen, dann das Modell anschließen.

Architekturmuster im Vergleich

In DACH-ERP-Landschaften stehen meist zwei Muster zur Wahl. Beim MCP-Layer (Model Context Protocol) greifen Agenten über einen zentralen Vermittlungspunkt auf DATEV, Navision, BMD oder weclapp zu. Authentifizierung, Schema-Mapping, Tool-Aufrufe und Protokollierung liegen an einer kontrollierten Stelle. Beim Punkt-zu-Punkt-Connector verbindet jede Anwendung den jeweiligen Agenten oder Prozess direkt mit dem ERP.

Der direkte Connector ist zunächst attraktiv. Ein einzelner Belegworkflow lässt sich schnell an eine API hängen, und das Team sieht rasch ein Ergebnis. Der Preis folgt später. Jede neue ERP-Instanz bringt eigene Authentifizierungslogik, Feldzuordnung, Fehlerbehandlung und Protokollierung mit. Bei mehreren Systemen entstehen unterschiedliche Regeln dafür, wer was auslösen darf und wie ein Vorgang rekonstruiert wird.

Punkt-zu-Punkt ist nicht grundsätzlich falsch. Für einen klar abgegrenzten Prozess mit einem ERP kann es die vernünftige Startoption sein. Sobald aber mehrere Mandanten, Buchungskreise oder Systeme beteiligt sind, wird der zentrale Layer wichtiger. Eine gute Architektur für Enterprise-Automatisierung trennt dabei Adapter und Orchestrierung, statt beide Schichten in einer individuellen Schnittstelle zu vermischen.

Connector-Strategien für DATEV, Navision und Co.

Die Schnittstelle bestimmt, wie weit ein Agent kommt. Ein modernes ERP mit dokumentierter API erlaubt ereignisbasierte Abläufe und klare Rückmeldungen. Eine ältere Installation liefert vielleicht nur Dateien oder einen Datenbankzugriff. Beide Situationen sind lösbar, aber nicht mit derselben Adapterlogik.

Bei DATEV kommen für Buchungsdaten die ASCII-Schnittstelle (DATEV-Format) und DATEVconnect in Betracht. Die Entscheidung hängt davon ab, ob der Prozess synchron reagieren muss oder ein kontrollierter Dateiimport genügt. Ein dateibasierter Ablauf braucht zusätzliche Prüfungen für Vollständigkeit, Reihenfolge und Wiederholung. Eine API-Anbindung erleichtert unmittelbare Rückmeldungen, verlangt aber ein präzises Berechtigungsmodell.

Navision beziehungsweise Business Central stellt mit OData und AL-Webservices moderne Integrationswege bereit. Bei älteren Navision-Installationen kann der Zugriff jedoch auf ODBC oder CSV-Exporte beschränkt sein. Hier sollte der Adapter die Legacy-Eigenheiten kapseln. Der Agent darf nicht wissen müssen, ob ein Datensatz per Webservice oder Datei geliefert wurde.

Adapter klein halten, Orchestrierung zentral führen

BMD NTCS bietet Webservices und Importschnittstellen, deren Umfang von Version und Lizenz abhängt. Exact bietet eine REST-API, weclapp REST plus Webhooks. Für moderne Cloud-ERPs eignen sich native API-Adapter, die Ereignisse, Status und Fehler strukturiert zurückgeben. Für Legacy-Systeme braucht es dateibasierte Adapter mit Schema- und Plausibilitätsprüfung. Der MCP-Layer übernimmt darüber die gemeinsame Sprache für Werkzeuge und Prozesse.

Ein MCP-Layer direkt auf dem ERP klingt zunächst elegant, kostet aber Granularität. Mandanten- und Buchungskreistrennung muss dann in jedem Tool-Aufruf explizit mitgeführt werden. Besser ist eine schmale Adapter-Schicht pro ERP und eine zentrale Orchestrierung darüber. So bleibt der Adapter technisch überschaubar, während Policies, Tool-Namen, Freigabestufen und Audit-Ereignisse einheitlich bleiben. Wenn zusätzlich Kundendaten zwischen CRM und ERP synchronisiert werden, gehört die Frage der Datenhoheit je Feld dazu; mehr dazu in unserem Beitrag zur CRM-ERP-Integration.

Der Agent sollte nie wissen müssen, wie ein ERP intern spricht. Er sollte nur ein klar begrenztes Werkzeug mit definierten Ein- und Ausgaben sehen.

Anbieter und Technologie auswählen

Die falsche Anbieterwahl kostet nicht nur Budget, sondern vor allem Tempo. Wer KI-Integration ernst meint, bewertet deshalb nicht nur die Modellqualität, sondern vor allem Connectoren, Legacy-Fähigkeit, Sicherheitsausrichtung und das Betriebsmodell. Drei Fragen helfen mehr als jede Hochglanzpräsentation:

1. Gibt es erprobte Anbindungen für die Systeme, die im Unternehmen tatsächlich laufen?
2. Kann der Anbieter auch Altsysteme über Custom Connectoren oder eine Orchestrierungsschicht integrieren?
3. Bleiben Ownership und Betrieb beim Unternehmen, oder entsteht ein schwer kontrollierbarer Lock-in?

Fordern Sie bei Angeboten Referenzen mit ERP-, CRM- und Backoffice-Bezug. Entscheidend ist, ob der Anbieter die Brücke zwischen Fachprozess, Governance und Betrieb liefert, nicht wie überzeugend eine generische Demo wirkt.

Use Cases mit messbarem Nutzen

Im Mittelstand gewinnt nicht der spektakulärste KI-Demonstrator. Es gewinnt der Prozess, der häufig läuft, gut abgrenzbar ist und dessen Ergebnis ein Mensch rasch prüfen kann. Datenbasis und Prozessfrequenz müssen zusammenpassen.

Belegerkennung mit OCR und Klassifikation ist ein guter Startpunkt. Eingangsrechnungen besitzen wiederkehrende Strukturen, Konten und Freigaberegeln können als kontrollierter Kontext dienen. Ein eng begrenzter Pilot sollte innerhalb weniger Wochen erste Messwerte liefern, sofern Stammdaten, Kontierungslogik und Freigabepfade vorliegen. Das ist ein Planungsziel, kein Versprechen. Details zu diesem Anwendungsfall beschreibt unser Beitrag zu KI in der Buchhaltung.

Liquiditätsprognosen auf Navision oder Business Central lohnen sich erst, wenn Buchungs- und Bankdaten zusammengeführt sind. Sonst lernt das Modell aus Lücken und erzeugt scheinbar präzise Ergebnisse. Die Prognose muss außerdem erklären, welche offenen Posten, Zahlungsläufe oder Annahmen sie beeinflussen.

Mahnwesen mit KI-generierten Anschreiben kann die Textarbeit reduzieren, aber nicht die rechtliche Verantwortung ersetzen. Ein Freigabe-Workflow muss Tonfall, Kundensegment, Fälligkeit und Formulierung prüfen. Ohne diesen Kontrollpunkt verschiebt der Agent das Risiko nur vom Postfach in den Kundenkontakt.

Lieferanten-Matching über BMD oder Exact ist sinnvoll, wenn der Lieferantenstamm eine belastbare Matching-ID führt. Fehlt diese Eindeutigkeit, muss zuerst die Stammdatenlogik verbessert werden. Ein Modell kann Ähnlichkeiten finden, aber Ähnlichkeit ist keine sichere Identität.

Hype-Use-Cases scheitern meist nicht am Modell. Sie scheitern daran, dass niemand den Nutzen im Tagesablauf braucht, dass die Daten zu unvollständig sind oder dass die letzte Freigabe trotzdem vollständig manuell bleibt. Priorisieren Sie daher Prozesse mit hoher Wiederholung, klarer Datenbasis und einem messbaren menschlichen Prüfpunkt.

Governance als Engpass statt als Anhang

Sobald ein Agent in der Buchhaltung schreiben oder Freigaben auslösen darf, ist Governance kein Dokumentationsanhang mehr. Sie wird Teil der Prozessarchitektur. Die relevante Frage lautet nicht, ob das Modell eine gute Antwort erzeugt, sondern ob das Unternehmen später beweisen kann, welche Daten, Regeln und Berechtigungen zu einer Aktion geführt haben.

Vier Kontrollen, die in den Prozess gehören

Das Vier-Augen-Prinzip bleibt bei Buchungsfreigaben sinnvoll. Der Agent kann Belege klassifizieren, Konten vorschlagen und eine Buchung vorbereiten. Eine berechtigte Person bestätigt die Aktion, und im Audit-Log erscheint ein eigener technischer Agenten-User statt eines menschlichen Kontos. Wie sich das mit der klassischen Funktionstrennung verbinden lässt, beschreibt ein eigener Beitrag.

Rollen müssen granular sein. Eine Rolle für das ganze Unternehmen reicht nicht, wenn mehrere Mandanten oder Buchungskreise verarbeitet werden. Der Tool-Aufruf sollte Mandant, Buchungskreis, Aktion und erlaubten Datenumfang enthalten. Ein Agent, der lesen darf, muss nicht automatisch schreiben dürfen.

Der Audit-Trail muss manipulationssicher sein. Protokolliert werden sollten Eingabedaten, Modellversion, Prompt-Hash, Tool-Aufruf, Ergebnis, menschliche Entscheidung und allfällige Korrektur. Eine Replay-Funktion ermöglicht Steuerberatung oder Prüfung, den Ablauf mit derselben Eingabe und den damaligen Regeln nachzuvollziehen. Die Details beschreibt unser Beitrag zum Audit-Log-Management.

Modellüberwachung braucht einen Owner. Finance verantwortet die fachliche Regel, IT die technische Kontrolle und der Datenschutz die Verarbeitung sensibler Daten. LLM-Aufrufe mit personenbezogenen Daten sollten bevorzugt in EU-Regionen laufen, besonders bei Lohn- oder Sozialversicherungsdaten.

Die meisten ERP-Anwendungsfälle in Buchhaltung und Operations fallen nicht unter die Hochrisiko-Kategorien des EU AI Act. Ausnahmen gibt es, etwa KI zur Kreditwürdigkeitsprüfung natürlicher Personen oder im Personalbereich. Für diese Hochrisiko-Systeme nach Anhang III gelten die Pflichten nach der Änderung durch die Verordnung (EU) 2026/1744 ab dem 2. Dezember 2027. Diese Kontrollen lassen sich im MCP-Layer zentral durchsetzen. Wer KI-Governance für Unternehmenssysteme als eigene Kontrollschicht modelliert, kann neue ERP-Adapter anschließen, ohne jede Freigabe- und Protokollregel neu zu bauen.

90-Tage-Rollout für ERP und KI

Ein produktiver Rollout braucht einen engen Prozess, einen benannten Owner und klare Stop-Kriterien. Der folgende Plan trennt die technische Anbindung vom fachlichen Use Case, damit nicht gleichzeitig Datenbereinigung, Modellwahl und Organisationsdesign ausufern.

Woche 1 bis 2: Daten und Pilot festlegen

Finance und Operations wählen gemeinsam zwei Backoffice-Prozesse, etwa Belegfreigabe und Mahnwesen. Das ERP-Team erhebt Daten aus DATEV oder Navision, prüft Stammdaten, dokumentiert Statusfelder und identifiziert fehlende Referenzen. IT-Security definiert Mandantentrennung, Rollen und erlaubte Aktionen.

Der Pilot startet nur, wenn die Datenquellen eindeutig sind, der Prozess-Owner feststeht und ein manueller Rückfallweg existiert. Stoppen sollte das Team, wenn Buchungslogik oder Beleghistorie nicht zuverlässig rekonstruiert werden können. Eine KI-Strategie für ERP- und Backoffice-Prozesse hilft dabei, diese Prioritäten vor der Modellentscheidung festzuhalten.

Woche 3 bis 5: Connector und MCP aufbauen

Die Integration beginnt mit einem kleinen Adapter gegen die vorhandene ERP-Schnittstelle. Bei DATEV kann das DATEVconnect oder ein kontrollierter ASCII-Austausch sein, bei Navision OData, AL-Webservices oder ein Legacy-Adapter. Das Team definiert Event-Payloads, Fehlercodes und das Mapping auf das ERP-Schema.

Parallel entsteht der MCP-Layer, falls mehrere Systeme, Mandanten oder Agenten beteiligt sind. Der technische Owner testet Sandbox-Aufrufe, ungültige Berechtigungen, doppelte Events und Wiederholungen. Stop-Kriterium ist ein fehlender Audit-Eintrag oder ein Tool-Aufruf, der mehr Daten lesen oder verändern kann als vorgesehen.

Woche 6 bis 8: Pilot mit echten Vorgängen

Der Pilot läuft mit echtem Datenvolumen, aber zunächst mit menschlicher Freigabe. Die Kennzahlen müssen pro Prozess definiert werden, nicht als allgemeiner KI-Score:

Finance prüft Stichproben, IT überwacht Fehler und Security kontrolliert Rollen sowie Protokolle. Bleiben Fehlklassifikationen ungeklärt oder eskalieren Vorgänge ohne nachvollziehbaren Grund, wird der Automatisierungsgrad nicht erhöht. Das Modell erhält zuerst bessere Regeln und Daten, nicht einfach mehr Schreibrechte.

Woche 9 bis 12: kontrolliert erweitern

In der letzten Phase rollt das Team den Prozess auf weitere Mandanten oder Buchungskreise aus. Key User erhalten konkrete Schulungen, Eskalationspfade werden dokumentiert, und der Regelbetrieb bekommt einen quartalsweisen Review für Modellverhalten, Berechtigungen und Datenqualität.

Der Rollout ist abgeschlossen, wenn ein Fachbereich den Prozess betreiben kann, Fehler korrigiert werden können und die Steuerberatung den Ablauf nachvollzieht. Danach geht es nicht um maximale Autonomie, sondern um stabile, begrenzte Automatisierung mit einer klaren Verantwortung.

Sprechen Sie mit uns

Wenn Sie einen ERP-Pilotprozess von der Datenprüfung bis zum prüfbaren Produktivbetrieb planen, sprechen Sie mit uns.