Um 14 Uhr liegen im Buchhaltungs-Postfach bereits neue Rechnungen, während drei Sachbearbeiter:innen Belege sortieren und Freigaben nachtelefonieren. Ein viertes Postfach läuft beim Mahnungslauf aus dem Takt. Der Controller braucht am späten Nachmittag wieder eine Liquiditätsauskunft, doch dafür müssen 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. In Österreich zeigt die Fraunhofer-Austria-Studie zu KI in ERP-Systemen, dass nur rund 4 % von 455 befragten Unternehmen KI vollständig in Kernprozesse integriert hatten. Ein Drittel stufte KI als nicht relevant ein, ein weiteres knappes Drittel sah zwar Relevanz, hatte aber noch keine konkreten Umsetzungspläne.
Inhaltsverzeichnis
- Warum KI jetzt im ERP-Alltag ankommt
- So entsteht operative Wirkung im ERP
- Architekturmuster im Vergleich
- Connector-Strategien für DATEV, Navision und Co.
- Use Cases mit echtem AT-ROI
- Governance als Engpass statt als Anhang
- 90-Tage-Rollout für ERP und KI
Warum KI jetzt im ERP-Alltag ankommt
Die Szene aus dem Backoffice ist kein Technologieproblem, sondern ein Prozessproblem. Eine Rechnung kommt als PDF, eine Kontierung fehlt, der Lieferant ist doppelt angelegt und die Freigabe hängt an einer Person, die gerade in einem Termin sitzt. Das ERP speichert den Vorgang zuverlässig, aber es erkennt nicht automatisch, warum der Beleg ungewöhnlich ist oder welcher nächste Schritt sinnvoll wäre.
Gleichzeitig müssen Unternehmen ihre ERP-Landschaften erneuern. Eine österreichische KPMG-Erhebung zum Rechnungswesen zeigt, dass 40 % der heimischen Unternehmen die Erneuerung ihres ERP-Systems priorisieren. In derselben Erhebung war die Systemlandschaft bei 28 % der Unternehmen bereits flächendeckend homogenisiert, bei 41 % teilweise. Papierlose Buchhaltung oder standardisierte Workflows waren bei 45 % nur in Teilbereichen eingeführt, wie IT Welt zur ERP-Erneuerung berichtet.
Praktische Konsequenz: Wer jetzt ein ERP erneuert, sollte KI nicht als nachträgliches Add-on behandeln. Die Schnittstellen, Rollen und Datenmodelle entscheiden bereits im Architekturentwurf darüber, ob Automatisierung später sicher eingebettet werden kann.
Der Reifegrad ist allerdings niedriger als der Erneuerungsdruck. Laut Statistik Austria nutzten 2024 nur 21 % der österreichischen Unternehmen mit mindestens 10 Beschäftigten künstliche Intelligenz. Bei den KI-nutzenden Unternehmen setzten 24 % die Technologie für Prozessautomatisierung oder unterstützte Entscheidungsfindung ein. Das ist für Finance und Operations relevant, weil genau diese Tätigkeiten im ERP stattfinden, etwa bei Belegprüfung, Zahlungsplanung, Stammdatenpflege und Freigaben.
Die Lücke liegt damit zwischen dem sichtbaren Bedarf und der produktiven Einbettung. Ein Modell, das neben dem ERP Vorschläge macht, löst die Arbeit nicht automatisch. Es muss Daten lesen dürfen, Regeln verstehen, Aktionen über klar definierte Werkzeuge ausführen und jede Entscheidung nachvollziehbar hinterlassen. Daraus ergibt sich die zentrale Architekturfrage: Wie kommt KI kontrolliert in den Workflow, statt nur auf den Workflow zu schauen?
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. Sie bestimmt, ob ein Forecast, eine Freigabe oder eine Automatisierung belastbar ist.
Die Fraunhofer-Austria-Studie beschreibt genau diese Reife-Lücke und den Zusammenhang zwischen integrierter KI, Datenqualität und operativer Wirkung. Schlechte ERP-Felder reduzieren die Verlässlichkeit von Forecasts, Freigaben und Automatisierungen. Eine KI-gestützte Validierung kann Inkonsistenzen früh erkennen, bevor sie Finanz- und Operationsprozesse weiter unten verteuern.
Vier Voraussetzungen für belastbare Automatisierung
-
Strukturierte Stammdaten: Mandanten, Lieferanten, Kund:innen, Konten, Kostenstellen und Zahlungsbedingungen müssen eindeutig sein. Ein Agent kann Dubletten markieren, aber er sollte keine unsichere Zusammenführung eigenständig durchführen.
-
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.
-
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.
-
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 anschliessen.
Architekturmuster im Vergleich
In DACH-ERP-Landschaften stehen meist zwei Muster zur Wahl. Beim MCP-Layer 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.
Die beiden Muster im direkten Vergleich
| Kriterium | MCP-Layer | Punkt-zu-Punkt-Connector |
|---|---|---|
| Anbindung | Einheitliche Tool-Schnittstelle über mehrere ERPs | Individuelle Schnittstelle pro ERP und Use Case |
| Initialer Aufwand | Höher, weil Gateway, Berechtigungen und Schemata aufgebaut werden | Niedriger bei einem einzelnen Prozess |
| Skalierung | Neue Adapter lassen sich in ein bestehendes Orchestrierungsmodell einfügen | Jede zusätzliche Verbindung erhöht die Sonderlogik |
| Mandantentrennung | Zentral erzwingbar, wenn sie im Tool- und Policy-Layer modelliert ist | Muss in jedem Connector separat umgesetzt werden |
| Audit-Trail | Einheitlich zentral protokollierbar | Häufig über mehrere Logs verteilt |
| Fehleranalyse | Ein gemeinsamer Kontrollpunkt erleichtert Tracing und Replay | Fehler liegen oft in ERP-, Middleware- oder Agentenlogik |
| Risiko | Mehr Architekturarbeit und ein eigenes Berechtigungskonzept | Connector-Spaghetti und inkonsistente Kontrollen |
Das bedeutet nicht, dass Punkt-zu-Punkt grundsätzlich falsch ist. 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.
Der Befund aus dem öffentlichen Sektor zeigt, wo dieser Hebel zählt. Laut EY-Studie zur Zukunft der Verwaltung wurden 2026 173 Organisationen aus Bund, Ländern, Gemeinden und Unternehmen des öffentlichen Sektors befragt. 29 % hatten bereits ein Drittel ihrer Prozesse hochautomatisiert, bei 13 % der Verwaltung liefen mehr als 60 % der Prozesse ohne manuelle Eingriffe. Wiederkehrende Freigaben, Datenerfassungen und Übergaben sind also geeignete Angriffspunkte. Die Architektur muss diese Muster über Systemgrenzen hinweg kontrollierbar machen.
Connector-Strategien für DATEV, Navision und Co.
Die Schnittstelle bestimmt, wie weit ein Agent kommt. Ein modernes ERP mit dokumentierter API erlaubt eventbasierte 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 und die DATEVconnect-API 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 Installationen, etwa Navision-Versionen aus früheren Generationen, 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 lässt sich über das BMD-NTCS-Webservice-Konzept anbinden. Exact bietet REST, 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.
| ERP | Schnittstelle | Adapter-Typ | MCP-Eignung |
|---|---|---|---|
| DATEV | ASCII-Schnittstelle, DATEVconnect-API | API- oder dateibasierter Adapter | Hoch, mit strenger Buchungsfreigabe |
| Navision / Business Central | OData, AL-Webservices, bei Legacy ODBC oder CSV | Native oder dateibasierte Adapter | Hoch, wenn Versionen getrennt modelliert sind |
| BMD NTCS | BMD-NTCS-Webservices | API-Adapter | Hoch, mit Mandanten- und Rollenprüfung |
| Exact | REST | Native API-Adapter | Hoch für strukturierte Prozessaufrufe |
| weclapp | REST, Webhooks | Event- und API-Adapter | Hoch für ereignisbasierte Workflows |
Der 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.
Der Agent sollte nie wissen, wie ein ERP intern spricht. Er sollte nur ein klar begrenztes Werkzeug mit definierten Ein- und Ausgaben sehen.
Use Cases mit echtem AT-ROI
Im österreichischen Mittelstand gewinnt nicht der spektakulärste KI-Demonstrator. Gewonnen hat der Prozess, der häufig läuft, gut abgrenzbar ist und dessen Ergebnis ein Mensch rasch prüfen kann. Die Datenbasis und die Prozessfrequenz müssen zusammenpassen.
Die Kombination aus ERP-Erneuerungsdruck und vorsichtiger KI-Nutzung führt zu einer klaren Priorisierung. Einerseits priorisieren laut der österreichischen KPMG-Auswertung 40 % der Unternehmen die Erneuerung ihres ERP-Systems. Andererseits nutzten laut Statistik Austria 21 % der österreichischen Unternehmen mit mindestens 10 Beschäftigten KI, und bei den KI-nutzenden Unternehmen verwendeten 24 % sie für Prozessautomatisierung oder unterstützte Entscheidungsfindung.
Prozesse, die sich zuerst rechnen
Beleglose Buchung mit OCR und Belegklassifikation ist ein guter Startpunkt. Eingangsrechnungen besitzen wiederkehrende Strukturen, DATEV-Konten und Freigaberegeln können als kontrollierter Kontext dienen. Die vorgesehenen Effekte zeigen sich laut den Projektanforderungen bereits in 4 bis 8 Wochen, sofern Stammdaten, Kontierungslogik und Freigabepfade vorliegen. Diese Zeitangabe ist kein allgemeines Versprechen, sondern eine realistische Zielgrösse für einen eng begrenzten Pilotprozess.
Predictive Cash Forecasting auf Navision oder Business Central lohnt sich erst, wenn Buchungs- und Bankdaten zusammengeführt sind. Sonst lernt das Modell aus Lücken und erzeugt scheinbar präzise Artefakte. Das Ergebnis muss ausserdem erklären, welche offenen Posten, Zahlungsläufe oder Annahmen den Forecast beeinflussen.
Mahnwesen mit LLM-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. Priorisiert werden sollten daher Prozesse mit hoher Wiederholung, klarer Datenbasis, niedriger Fehlertoleranz 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.
Der Fachbeitrag zu KI im ERP 2026 benennt den blinden Fleck: KI darf keinen unkontrollierten Zugriff auf ERP-Daten erhalten. Jeder Zugriff muss definiert, protokolliert und auditierbar sein. Für österreichische Organisationen wird das besonders wichtig, weil die Diskussion laut Statistik Austria von der reinen Adoptionsfrage zu Nutzungsqualität, Kontrolle und Risikomanagement weitergeht.
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.
Rollen müssen granular sein. Eine Rolle für das 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 unveränderbar sein. Protokolliert werden sollten Eingabedaten, Modellversion, Prompt-Hash, Tool-Aufruf, Ergebnis, menschliche Entscheidung und allfällige Korrektur. Eine Replay-Funktion ermöglicht dem Steuerberater oder Prüfer, den Ablauf mit derselben Eingabe und den damaligen Regeln nachzuvollziehen.
Modellüberwachung braucht einen Besitzer. Finance verantwortet die fachliche Regel, IT die technische Kontrolle und der Datenschutz die Verarbeitung sensibler Daten. Für österreichische Daten sollten LLM-Aufrufe bevorzugt in EU-Regionen laufen, besonders bei Sozialversicherungs- oder Lohndaten.
Diese Kontrollen lassen sich im MCP-Layer zentral durchsetzen. Wer Security und Governance für Unternehmenssysteme als eigene Kontrollschicht modelliert, kann neue ERP-Adapter anschliessen, ohne jede Freigabe- und Protokollregel neu zu bauen. Mehr KI löst den Engpass nicht. Ein begrenzter, prüfbarer Agent schon eher.
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 Entscheidungspunkt liegt am Ende dieser Phase. Der Pilot startet nur, wenn die Datenquellen eindeutig sind, der Prozessowner 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 dem Modellentscheid 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 die DATEVconnect-API 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. Gemessen werden Trefferquote, Bearbeitungszeit und Anzahl menschlicher Eingriffe. Diese 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 zwei 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 der Steuerberater den Ablauf nachvollzieht. Danach geht es nicht um maximale Autonomie, sondern um stabile, begrenzte Automatisierung mit einem klaren Verantwortlichen.
Specialty Tokens unterstützt Unternehmen mit eingebetteten Senior Engineers bei ERP-Integrationen, kundenspezifischen Konnektoren für BMD, DATEV, Navision, Exact und weclapp sowie beim Aufbau einer kontrollierten MCP-Schicht über Supercenter. Besuchen Sie Specialty Tokens, wenn Sie einen ERP-Pilotprozess von der Datenprüfung bis zum auditierbaren Produktivbetrieb umsetzen möchten.