Wie testet man eine ERP-Schnittstelle, die KI-Agenten aufbauen?

Das Wichtigste in Kürze

• Die KI-Agenten von Transformance lesen die ERP-Dokumentation und Ihre Antworten zur Einrichtung, schlagen das Datenmapping vor, entwerfen Workflow und Testfälle, führen die Tests in einer Testumgebung aus und melden die Ergebnisse; eine Person zeichnet jeden Test ab.
• Jede Schnittstelle, die Transformance baut, durchläuft dieselben sieben Tests in fester Reihenfolge: Verbindung, Einzelschritt, Feldzuordnung, Gesamtablauf mit Testdaten, Volumen, Fehler und Wiederholung sowie Wiederanlauf ab dem fehlgeschlagenen Schritt.
• Jeder Test hat ein Abnahmekriterium, das ein Finanzverantwortlicher nachprüfen kann, etwa Anzahl der Datensätze, Kontrollsummen und keine zweite Buchung bei einer Wiederholung, und eine namentlich benannte Person, die ihn abzeichnet.
• Der Produktivbetrieb startet erst, wenn alle sieben Tests bestanden sind und eine Person die Umstellung freigibt; die ERP-Anbindung dauert in der Regel 2 bis 3 Tage (Transformance-Kundendaten, 2026), und Ihre IT kann eingebunden sein.
• Nach dem Go-live zeigt der Integration Monitor den Zustand jedes Jobs und jeden Fehler in verständlicher Sprache, mit verantwortlicher Person und Wiederholung; bei einem ERP-Update läuft zuerst der Testplan erneut.

In diesem Artikel

• Das Wichtigste in Kürze
• Wie bauen und testen KI-Agenten eine ERP-Schnittstelle?
• Was übernehmen die Agenten, was bleibt bei Menschen?
• Welche Tests braucht eine ERP-Schnittstelle, und in welcher Reihenfolge?
• Wie testen Sie Fehler, Dubletten und Wiederholungen?
• Was zeigt der Integration Monitor nach dem Go-live?
• Was tun Sie bei einem ERP-Update?

Wie bauen und testen KI-Agenten eine ERP-Schnittstelle?

Die KI-Agenten von Transformance entwerfen Workflow und Testfälle aus dem bestätigten Datenmapping und führen sie in einer Testumgebung aus; vor dem Produktivbetrieb zeichnet eine Person jeden Test ab.

Integrationstest einer ERP-Schnittstelle: sieben Tests, Prüfgegenstand, Abnahmekriterium, Abzeichnung

Die sieben Tests sind der Standardprozess des Integrations-Hubs. Transformance baut, betreibt, überwacht und repariert die Verbindung; Ihr Team gibt den Zugriff und jede Änderung im Produktivbetrieb frei. Die Abnahmekriterien vereinbaren wir mit Ihnen, bevor der erste Test läuft; es sind Regeln, keine Richtwerte.

Der Implementierungsleitfaden von Microsoft für Dynamics 365 unterscheidet unter anderem Komponenten-, Funktions-, Prozess-, End-to-End-, Abnahme-, Regressions- und Performancetests sowie die Probe der Datenübernahme vor dem Produktivstart und führt den Test der Schnittstellen als eigenen Testtyp auf: Er soll bestätigen, dass die Schnittstellen wie vorgesehen arbeiten (Microsoft Learn, 2026). Die sieben Tests oben zerlegen diesen Schnittstellentest in Schritte, die ein Finanzteam lesen und abzeichnen kann.

Dieser Plan prüft die Schnittstelle selbst. Die Abnahme des gesamten Debitorenprozesses (Fachabnahme, Parallellauf, Umstellung) folgt, sobald er bestanden ist.

Merksatz: Ein Integrationstest ohne vorab festgelegtes Abnahmekriterium ist nur eine Vorführung.

Was übernehmen die Agenten, was bleibt bei Menschen?

Die Agenten erledigen die wiederkehrende Arbeit: Dokumentation lesen, Mapping vorschlagen, Workflow entwerfen, Tests ausführen und berichten. Menschen bestätigen, zeichnen ab und geben jede Änderung frei, die Ihre Systeme erreicht.

Das Kontrollkonzept folgt neutralen Leitlinien. Das OWASP Gen AI Security Project empfiehlt gegen übermäßige Handlungsbefugnis von KI-Systemen, dass ein Mensch folgenreiche Aktionen freigibt, bevor sie ausgeführt werden, und dass die Erweiterungen eines Agenten nur auf das notwendige Minimum zugreifen dürfen (OWASP Gen AI Security Project, LLM06:2025, 2025).

Im Integrations-Hub sieht das so aus:

• Minimale Rechte. Jede Aktion auf dem On-Premise-System ist als Lesen, Schreiben oder Ausführen gekennzeichnet, damit die IT genau freigibt, was ein Workflow tun darf.
• Test vor Produktivbetrieb. Die Agenten führen die Tests gegen eine Testumgebung aus, und eine Person aktiviert den Produktivlauf.
• Freigabe. Nichts wird ohne menschliche Freigabe im ERP gebucht; Administratoren legen Regeln fest, das Finanzteam gibt frei, mit Wertgrenzen je Betrag, Gesellschaft und Kunde (Freigabegrenzen für KI-Agenten).
• Nachweis. Das Audit-Log speichert Zeitstempel, was das System getan hat, was der Benutzer getan hat, wer freigegeben hat, die Eingabe und den Konfidenzwert.

Derselbe Prozess gilt für jede Verbindung, die der Hub aufbaut (was eine KI-gestützte Integrationsplattform für Finanzen ist).

Merksatz: Die Agenten bereiten vor und führen aus; eine Person zeichnet ab, und der Produktivbetrieb wartet auf diese Abzeichnung.

Welche Tests braucht eine ERP-Schnittstelle, und in welcher Reihenfolge?

Sieben Tests in fester Reihenfolge: Verbindung, Einzelschritt, Feldzuordnung, Gesamtablauf mit Testdaten, Volumen, Fehler und Wiederholung, Wiederanlauf ab dem fehlgeschlagenen Schritt; jeder Test wird bestanden, bevor der nächste beginnt.

Die Reihenfolge folgt der aufeinander aufbauenden Logik der Testtypen von Microsoft, zugeschnitten auf die Schnittstelle: die Leitung, jeder Schritt, die Daten, der ganze Lauf, die Last, dann die Fehlerfälle.

‍

‍

1. Verbindung. Der Hub meldet sich mit den Zugangsdaten an, die in seinem Tresor liegen, liest einen Datensatz und bestätigt, dass er im Testsystem angekommen ist, nicht im Produktivsystem. Nutzt das ERP OAuth 2.0, verwendet die Verbindung ein Token, das Ihre IT dafür ausgestellt hat. Bei einem ERP im eigenen Rechenzentrum läuft der Test über den On-Premise-Agenten von Transformance, der heute durchgängig läuft, nur ausgehend verbindet (keine Änderung an der eingehenden Firewall, kein VPN) und die Zugangsdaten vor Ort belässt (Wege für Individual- und Altsysteme). Ein Fehlschlag zeigt sich als Authentifizierungsfehler oder als Datensatz aus der falschen Umgebung.

2. Einzelschritt. Jeder Schritt läuft allein auf der Workflow-Oberfläche mit einer Beispieleingabe, und seine Antwort wird mit dem dokumentierten Beispiel verglichen. Ein Fehlschlag zeigt sich als fehlendes Feld oder als Fehlercode des ERP.

3. Feldzuordnung. Stichproben werden Feld für Feld verglichen: Kundennummer, Belegnummer, Betrag, Währung, Fälligkeitsdatum, Dezimaltrennzeichen und Textlänge. Ein Fehlschlag zeigt sich als abgeschnittener Kundenname oder als Dezimalkomma, das als Tausendertrennzeichen gelesen wird, sodass aus 12,50 plötzlich 1250 wird.

4. Gesamtablauf mit Testdaten. Lesen, Umwandeln, Schreiben und Bestätigen laufen durchgängig, und das ERP zeigt die erwarteten offenen Posten oder Ausgleichsbuchungen (was gelesen und geschrieben wird, wie ein korrekter Ausgleich aussieht). Buchungen laufen über die eigenen Schnittstellen des ERP (API, OData, BAPI oder der MCP-Server des ERP); direkt in die Datenbank wird nur geschrieben, wenn Sie das ausdrücklich vereinbaren. Ein Fehlschlag zeigt sich als offener Posten, der offen bleibt, etwa nach einer Zahlung mit Skonto oder einer Teilgutschrift, oder als Buchung auf dem falschen Konto.

5. Volumen. Eine realistische Last, etwa eine Bankdatei vom Monatsende, läuft in gedrosselten Paketen mit laufender Fortschrittsanzeige und der Zahl der geänderten Datensätze. Ein Fehlschlag zeigt sich als Paket mit Timeout oder als Zahlen, die von der Quelle abweichen.

6. Fehler und Wiederholung. Dazu der nächste Abschnitt.

7. Wiederanlauf ab dem fehlgeschlagenen Schritt. Nach einer Korrektur laufen nur die übrigen Schritte und Datensätze. Ein Fehlschlag zeigt sich als Datensätze, die schon geschrieben waren und im ERP erneut auftauchen.

Drei Regeln gelten für alle sieben Tests:

• Testdaten. Verwenden Sie realistische Datensätze aus Ihrem eigenen ERP, nicht nur Demodaten. Microsoft weist darauf hin, dass End-to-End-Tests übernommene Daten brauchen, weil diese andere Datenmuster haben können als Demo- oder Testdaten (Microsoft Learn, 2026). Enthalten Testdatensätze personenbezogene Daten, gilt der Grundsatz der Datenminimierung der DSGVO: Verwenden Sie nur, was der Test braucht, und pseudonymisieren Sie den Rest.
• Umgebungen. Derselbe Workflow zeigt über seine Einstellungen auf ein Test- oder ein Produktivsystem. Zugangsdaten und Konstanten werden je Umgebung und je Kunde geführt.
• Kontrollsummen. Bei jedem Test des Gesamtablaufs werden Anzahl der Datensätze und Betragssumme zwischen Quelle und Ziel verglichen. Zur Veranschaulichung: Der Auszug aus dem Quellsystem enthält 1.240 offene Posten über 3.150.280,40 EUR; nach dem Test zeigt das ERP 1.240 Posten und dieselbe Summe. Ein Posten oder ein Cent Abweichung, und der Test ist nicht bestanden.

Der Weg unterscheidet sich je System (API, OData, RFC / BAPI, der eigene MCP-Server des ERP, Dateien, eine Datenbank, ein Postfach, der On-Premise-Agent oder RPA); die sieben Tests bleiben gleich.

Merksatz: Jeder Test beantwortet eine Frage, und der nächste beginnt erst, wenn die Antwort Ja lautet.

Wie testen Sie Fehler, Dubletten und Wiederholungen?

Bringen Sie die Schnittstelle gezielt zum Scheitern, von der fehlenden Bankdatei bis zur doppelten Belegnummer; der Test ist bestanden, wenn jeder Fall sicher stoppt, die betroffenen Datensätze benennt und nichts doppelt bucht.

Microsoft schreibt, der Prozesstest umfasse auch negative Tests, die nach unerwarteten Ergebnissen oder Fehlern im Prozess suchen (Microsoft Learn, 2026). Für eine Schnittstelle der Debitorenbuchhaltung sind das die acht Fälle, die Sie durchspielen:

Das Abnahmekriterium in Worten, die eine Person aus der Finanzabteilung nachprüfen kann:

• Jeder Fehler landet mit einer verständlichen Begründung und einer verantwortlichen Person in der Ausnahmeliste.
• Die Wiederholung verarbeitet nur die fehlgeschlagenen Datensätze.
• Die Kontrollsummen stimmen nach der Wiederholung weiterhin.

Dass bei einer Wiederholung nichts ein zweites Mal gebucht wird, ist ein Kriterium, das dieser Test für Ihre Schnittstelle mit Ihren Daten vor dem Go-live nachweist, kein Versprechen vorab. Die Agenten entwerfen und führen die acht Fälle aus; Controlling und IT-Sicherheit zeichnen das Ergebnis ab. Wird eine Buchung später storniert, hält das Audit-Log fest, was das System getan hat und wer freigegeben hat (Audit-Trail bei Stornos).

Merksatz: Testen Sie den Tag, an dem etwas schiefgeht, nicht nur den, an dem alles klappt.

Was zeigt der Integration Monitor nach dem Go-live?

Ein Ort für jeden Job: wann er zuletzt lief und zuletzt erfolgreich war, Fehler in verständlicher Sprache mit verantwortlicher Person, die fehlgeschlagenen Datensätze einzeln und eine Wiederholung mit einem Klick.

Integration Monitor nach dem Go-live: was das Finanzteam sieht und tut

Er deckt Kundenabgleiche, Rechnungsbuchungen, Zahlungsaktualisierungen, den E-Mail-Versand und Mahnläufe ab. Ein allgemeiner API-Monitor misst die Verfügbarkeit; das Finanzteam will wissen, ob die Zahlungen von gestern angekommen sind und welche Datensätze gescheitert sind.

• Verantwortung. Jeder Job hat eine verantwortliche Person und einen Eskalationsweg; ein Schnittstellenverzeichnis (Quelle, Ziel, Richtung, Zeitplan, Verantwortliche) gehört zur Übergabe beim Go-live.
• Rolle der Agenten. Die Agenten entwerfen die verständliche Erklärung eines Fehlers; die verantwortliche Person entscheidet, wie es weitergeht. Transformance überwacht die Verbindungen und behebt, was auf der eigenen Seite ausfällt.
• Hypercare. In den ersten Wochen nach dem Go-live prüfen Sie die Ausnahmeliste täglich (wie lange die Einführung einer AR-Automatisierung dauert).

Merksatz: Das Finanzteam sollte von einem gescheiterten Abgleich über den Monitor erfahren, nicht über fehlende Zahlungen.

Was tun Sie bei einem ERP-Update?

Lassen Sie den Testplan der Schnittstelle in der Testumgebung laufen, bevor das Update das Produktivsystem erreicht, vergleichen Sie die Kontrollsummen und geben Sie die Umstellung erst frei, wenn wieder jeder Test besteht.

‍

‍

Ablauf bei einem ERP-Update in 7 Schritten, mit Verantwortlichen

1. Lesen Sie die Release Notes des ERP-Herstellers auf Änderungen an den Objekten, die Sie nutzen (verantwortlich: ERP-Verantwortliche).
2. Aktualisieren Sie die Testumgebung auf das neue Release (verantwortlich: IT).
3. Lassen Sie die sieben Tests mit den gespeicherten Testdaten erneut laufen; die Agenten führen den gespeicherten Plan erneut aus und berichten (verantwortlich: Schnittstellenverantwortliche).
4. Vergleichen Sie Kontrollsummen und Anzahl der Datensätze mit dem letzten bestandenen Lauf (verantwortlich: Finanzverantwortliche).
5. Korrigieren und testen Sie neu, was durchgefallen ist (verantwortlich: Schnittstellenverantwortliche).
6. Geben Sie die Umstellung auf den Produktivbetrieb frei (verantwortlich: Controlling).
7. Beobachten Sie die ersten Läufe im Integration Monitor (verantwortlich: Finanzverantwortliche).

Für Dynamics 365 Finance & Operations veröffentlicht Microsoft den Kalender: vier Service-Updates im Jahr (Februar, April, Juli und Oktober), die als Abnahme-Sandbox benannte Testumgebung erhält jedes Update zuerst, und Kunden haben sieben Kalendertage für Test und Validierung, bevor das Produktivsystem aktualisiert wird. Änderungen, die bestehende Funktionen brechen, werden 12 Monate im Voraus angekündigt (Microsoft Learn, One Version service updates FAQ, 2026). Andere ERP-Hersteller veröffentlichen eigene Release-Kalender; prüfen Sie den Ihres Herstellers.

Microsoft rät außerdem zu Regressionstests, bevor eine Änderung das Produktivsystem erreicht, und nennt Automatisierung den Schlüssel dafür (Microsoft Learn, 2026). Wer Testfälle und Testdaten vom ersten Lauf aufbewahrt, kann den erneuten Lauf jederzeit wiederholen.

Der Wechsel von SAP ECC zu SAP S/4HANA folgt derselben Logik mit einem umfangreicheren Plan (Debitorenbuchhaltung vor oder nach der S/4HANA-Migration automatisieren).

Merksatz: Ein ERP-Update ist eine Änderung wie jede andere: Zuerst läuft der Testplan.

Wer Transformance einsetzt

• ERP-Systeme: im Produktivbetrieb bei Kunden mit SAP S/4HANA (On-Premises, Private oder Public Cloud) und SAP ECC, NetSuite (einschließlich OneWorld-Tochtergesellschaften), Microsoft Dynamics 365 Finance & Operations und Business Central sowie Odoo; Oracle und Infor werden unterstützt; weitere ERP-Systeme über unseren Integrations-Hub, jeweils an Ihren eigenen Daten in einer Testumgebung geprüft.
• Größe: Mittelstand bis Großunternehmen, 250 bis über 2.000 Mitarbeitende, auch Konzerne mit mehreren Gesellschaften und Shared Service Centern.
• Zahlungsvolumen: von unter 1.000 bis über 100.000 Zahlungen im Monat.
• Branchen: Fertigung, Konsumgüter sowie Lebensmittel und Getränke, Logistik, E-Commerce, Landwirtschaft, Energie und unternehmensnahe Dienstleistungen.
• Umfang: nur Cash Application oder der gesamte Order-to-Cash-Prozess (Cash Application, Abzüge, Forderungsmanagement, Liquiditätsplanung).

Fazit: Der Testplan entscheidet über den Produktivstart

Eine ERP-Schnittstelle ist bereit, wenn sieben Tests gegen vorab festgelegte Kriterien bestanden und abgezeichnet sind. Die Agenten von Transformance übernehmen den wiederkehrenden Aufbau und die Tests; Menschen bestätigen das Mapping, zeichnen jeden Test ab und geben den Produktivbetrieb frei. Nach dem Go-live halten Monitor und Update-Routine den Plan wirksam. Wenn Sie den Testplan für Ihr ERP durchgehen möchten: Termin buchen.

Wichtige Begriffe

• Audit-Trail: wer wann was auf welcher Eingabe getan hat, für jeden Lauf und jede Freigabe.
• Buchungssatz: eine Buchung im Hauptbuch, einer der Datensätze, die eine Schnittstelle nach der Freigabe zurückschreibt.
• Zahlungsabgleich: das Zuordnen eingehender Zahlungen zu den Rechnungen, die sie begleichen.
• Bankabstimmung: der Abgleich von Kontoauszug und Bankkonto im Hauptbuch, Position für Position.
• Straight-Through-Processing: ein Vorgang, der ohne manuelle Bearbeitung von Anfang bis Ende durchläuft.

Weiterführende Ratgeber

• Mit welchen ERP-Systemen arbeitet Transformance zusammen?
• Was ist eine KI-gestützte Integrationsplattform für Finanzteams?
• Lässt sich Forderungsmanagement an ein Altsystem anbinden?
• IT-Aufwand bei der Automatisierung im Forderungsmanagement
• Wie automatisieren Sie Finanzprozesse bei mehreren ERP-Systemen?
• Was die AR-Automatisierung aus Ihrem ERP liest und dorthin schreibt
• Wie externe Systeme Zahlungen buchen und offene Posten ausgleichen

Häufig gestellte Fragen

Wie bauen und testen KI-Agenten eine ERP-Schnittstelle?

Die KI-Agenten von Transformance entwerfen Workflow und Tests aus dem bestätigten Datenmapping und führen die Tests in einer Testumgebung aus; eine Person zeichnet jeden Test ab und gibt den Wechsel in den Produktivbetrieb frei.

Laufen die Tests gegen unser Produktiv-ERP?

Nein. Die Tests laufen gegen eine Testumgebung, derselbe Workflow zeigt nur über seine Einstellungen auf das Produktivsystem, und eine Person aktiviert den Produktivlauf.

Wie lange dauert das?

Die ERP-Anbindung dauert bei ERP-Systemen im Produktivbetrieb in der Regel 2 bis 3 Tage (Transformance-Kundendaten, 2026), und Ihre IT kann eingebunden sein; individuelle Systeme klären wir nach einer Machbarkeitsprüfung. Der gesamte Rollout dauert bis zu 4 bis 8 Wochen (Transformance-Kundendaten, 2026), und der Testplan der Schnittstelle ist ein Teil davon.

Gegen welche ERP-Systeme können Sie testen?

Gegen Ihr eigenes. Transformance läuft im Produktivbetrieb bei Kunden mit SAP S/4HANA, SAP ECC, NetSuite, Dynamics 365 Finance & Operations und Business Central sowie Odoo und unterstützt Oracle und Infor. Wenn ein System eine API, eine Datenbank, eine Dateiablage oder ein Postfach hat, lässt es sich auf dieselbe Weise anbinden und testen.

Was passiert bei einem Update unseres ERP?

Sie lassen zuerst den Testplan der Schnittstelle in der Testumgebung laufen, vergleichen die Kontrollsummen mit dem letzten bestandenen Lauf und geben die Umstellung erst frei, wenn wieder jeder Test besteht.

Funktioniert das bei 100.000 Zahlungen im Monat und über viele Gesellschaften hinweg?

Ja. Große Lasten laufen in gedrosselten Paketen mit Fehlermeldungen je Datensatz, von unter 1.000 bis über 100.000 Zahlungen im Monat. Gesellschaften auf unterschiedlichen ERP-Systemen laufen in einer Umgebung von Transformance mit einer Arbeitsliste und einer Planung (Finanzautomatisierung mit mehreren ERP-Systemen).

Was kostet das?

Das hängt vom Umfang und von der Zahl der Gesellschaften und Systeme ab. Buchen Sie einen Termin, dann dimensionieren wir es gemeinsam mit Ihnen.