Wie funktioniert Debitorenautomatisierung mit On-Premises-ERP?

Das Wichtigste in Kürze

• Die KI-Agenten von Transformance verbinden sich mit einem On-Premises-ERP über eine Schnittstelle, die sein Hersteller bereits dokumentiert: Business Central On-Premises stellt OData standardmäßig auf Port 7048 bereit, sobald ein Administrator den Dienst aktiviert (Microsoft Learn, 2026).
• Eine rein ausgehende Verbindung ist ein etabliertes Muster: Das On-Premises-Datengateway von Microsoft kommt laut Dokumentation ohne eingehende Ports in Ihr Netz aus (Microsoft Learn, 2026).
• Der On-Premises-Agent von Transformance verbindet sich nur nach außen: keine Änderung an eingehenden Firewall-Regeln, und die Passwörter für das ERP bleiben in Ihrem Netz.
• ClearMatch erreicht eine Auto-Match-Quote von 95 % und läuft in unter 8 Minuten durch; ohne Freigabe durch eine Person wird nichts gebucht (Transformance-Kundendaten, 2026).
• Abgleich, Freigaben und Audit Trail funktionieren bei einem On-Premises-ERP wie bei einem ERP aus der Cloud; nur die Anbindung unterscheidet sich.

In diesem Artikel

• Das Wichtigste in Kürze
• Wie funktioniert Debitorenautomatisierung mit einem On-Premises-ERP?
• Was leistet ein On-Premises-ERP im Order-to-Cash-Prozess schon selbst?
• Was bleibt in Ihrem Netz und was überquert die Grenze?
• Wie entsteht die Verbindung, Schritt für Schritt?
• Was ändert sich zwischen On-Premises- und Cloud-ERP, und was nicht?
• Wie sieht ein Rechenbeispiel aus?
• Womit beginnen Sie bei einem On-Premises-ERP?

Wie funktioniert Debitorenautomatisierung mit einem On-Premises-ERP?

Die KI-Agenten von Transformance nutzen eine Schnittstelle, die das ERP bereits dokumentiert, und bauen die Verbindung aus Ihrem Netz heraus nach außen auf; das ERP bleibt das führende System, und eine Person gibt jede Buchung frei.

Sieben On-Premises-ERP-Systeme und ein weiteres Standard-ERP: die vom Hersteller dokumentierte Schnittstelle, die Wege über den Integrations-Hub und was Sie mit Ihrem ERP-Team klären

Quellen zur linken Spalte: SAP Learning; Microsoft Learn zu Business Central (2026), Dynamics NAV 2018, Dynamics GP und Dynamics AX 2012; Oracle zum Integrated SOA Gateway der E-Business Suite und zum JD Edwards Orchestrator. Der Weg richtet sich nach Ihrer Umgebung; die Tabelle ist kein Ranking.

„On Premises“ beschreibt, wo das ERP läuft, nicht wie gut es ist. Viele Unternehmen betreiben ihr ERP bewusst auf eigenen Servern: für mehr Kontrolle, wegen regulierter Daten oder weil es über Jahre auf die eigenen Abläufe zugeschnitten wurde.

Diese Seite behandelt gängige On-Premises-ERP-Systeme. Für ein selbst entwickeltes System oder eines, das in keiner Liste steht, lesen Sie den Beitrag zur Anbindung an ein individuelles ERP; die Aufgabenliste für die IT steht im Beitrag zum IT-Aufwand bei der Einführung, und für SAP R/3 und ECC gibt es eine eigene Seite. Alle ERP-Systeme und ihr Status: die Übersicht der ERP-Schnittstellen.

Die Schnittstelle bestimmt, wie die Daten ankommen; was danach geschieht, hängt nicht davon ab, wo das ERP läuft. ClearMatch erreicht eine Auto-Match-Quote von 95 % und läuft in unter 8 Minuten durch, und ohne Freigabe durch eine Person wird nichts gebucht (Transformance-Kundendaten, 2026).

Kurz gesagt: Die vom Hersteller dokumentierte Schnittstelle ist die Tür; der Agent in Ihrem Netz öffnet sie von Ihrer Seite aus.

Was leistet ein On-Premises-ERP im Order-to-Cash-Prozess schon selbst?

Jedes ERP dokumentiert eigene Funktionen, um Bankdaten zu importieren und Zahlungen nach Regeln zuzuordnen; Agenten bauen darauf auf und übernehmen die Zahlungen, Zahlungsavise und Nachfassaktionen, die Urteilsvermögen brauchen.

Drei Beispiele, jeweils aus der Dokumentation des Herstellers:

• Business Central ordnet Zahlungen im Journal für den Zahlungsabgleich (Payment Reconciliation Journal) offenen Posten zu, indem es die Daten einer Kontoauszugszeile mit den Daten eines oder mehrerer offener Posten abgleicht; die Regeln legen Sie auf der Seite Payment Application Rules fest. Jeder Vorschlag trägt eine Match Confidence von Low, Medium oder High (Microsoft Learn, 2025). Teams setzen Agenten für die Zeilen ein, die die Regeln zur Prüfung vorlegen.
• Oracle E-Business Suite führt AutoLockbox in drei Schritten aus: Import, Validierung und Post QuickCash. Greifen die Zuordnungsregeln nicht, wendet Post QuickCash den Zahlungseingang mit dem AutoCash-Regelsatz an, und ein Zahlungseingang, den auch die AutoCash-Regeln nicht zuordnen können, erhält den Status Unapplied (Oracle Receivables User Guide 12.2). Teams setzen Agenten für die Zahlungseingänge im Status Unapplied ein.
• SAP liest laut Dokumentation zum elektronischen Kontoauszug die Verwendungszweckfelder mit einem Interpretationsalgorithmus aus, der festlegt, wie das System die Angaben in diesen Feldern deutet. Ein Beleg wird gefunden, wenn die Referenz in genau derselben Form und mit genau derselben Zeichenzahl ankommt, wie sie gespeichert ist (SAP Help Portal). Teams setzen Agenten für Referenzen ein, die in anderer Form ankommen.

Darauf aufbauend übernehmen Agenten die Arbeit in der Debitorenbuchhaltung rund um jedes ERP:

• Zahlungsavise in jedem Format lesen: E-Mails, PDFs, Tabellen.
• Zuordnungen mit Begründung vorschlagen, wenn Referenzen teilweise, falsch oder nicht vorhanden sind.
• Kurzzahlungen und Abzüge klassifizieren.
• Das Forderungsmanagement priorisieren und Kunden zu überfälligen Rechnungen anrufen.
• Die Liquidität aus offenen Posten und Zahlungsverhalten vorhersagen.

Bleibt eine Zahlung offen, untersucht Vero, der Agent von Transformance, sie in Customer 360, dem Arbeitsgedächtnis je Kunde, und holt weitere interne und externe Informationen, um zusätzliche Treffer zu finden. Vero schlägt die Zuordnung mit den Belegen vor; eine Person gibt sie frei, ändert sie oder lehnt sie ab. Welche Zahlungen zu Regeln passen und welche zu einem Agenten: regelbasierter oder KI-Zahlungsabgleich.

CollectPulse bearbeitet 100 % der überfälligen Rechnungen innerhalb von 24 Stunden, und ClaimIQ erreicht eine Genauigkeit von 97 % bei der Identifikation von Abzügen (Transformance-Kundendaten, 2026).

Kurz gesagt: Die Regeln des ERP bleiben bestehen; Agenten übernehmen die Ausnahmen, die die Regeln weitergeben.

Was bleibt in Ihrem Netz und was überquert die Grenze?

Zugangsdaten und die Verbindung bleiben in Ihrem Netz; offene Posten und Kundendaten wandern nach außen zu einer Plattform in Ihrer Region, und freigegebene Buchungen kommen zurück.

Das Datengrenzen-Verzeichnis: was in Ihrem Netz läuft, was die Grenze überquert und wer es steuert

‍

‍

Daten verlassen Ihr Netz durchaus, nach außen und gewollt; das Passwort zu Ihrem ERP verlässt es nie.

Ein schlanker Agent wird auf einem Host in Ihrem Netz installiert. Er verbindet sich nur nach außen, daher werden keine eingehenden Ports geöffnet und es braucht kein VPN. Passwörter für On-Premises-Systeme werden in Ihrem Netz eingegeben und gespeichert und nie in die Cloud gesendet. Jede Aktion, die der Agent ausführen kann, ist als Lesen, Schreiben oder Ausführen gekennzeichnet, sodass die IT genau freigibt, was ein Workflow tun darf.

Das Muster ist etabliert. Das On-Premises-Datengateway von Microsoft baut Verbindungen von innen zur Cloud auf und braucht keine eingehenden Verbindungen (Microsoft Learn, 2026). Der SAP Cloud Connector arbeitet als Reverse-Invoke-Proxy, sodass in der Firewall des eigenen Netzes keine eingehenden Ports geöffnet werden müssen (SAP Learning); für SAP ist er eine von mehreren Optionen, und der Weg richtet sich nach Ihrer Umgebung.

Was die Grenze überquert, wird in Ihrer eigenen Region gehostet, bei US-Kunden in den USA und bei EU-Kunden in der EU, wahlweise mit VPC-Betrieb in Ihrer eigenen Cloud (Datenhaltung in Ihrer Region). Kundendaten werden nicht zum Training von Modellen verwendet. Lesen und Zurückbuchen laufen nach dem Zeitplan, den Sie vereinbaren, zum Beispiel stündlich oder täglich.

Die Aussage zur Firewall ist präzise: keine Änderung an eingehenden Firewall-Regeln. Die IT gibt weiterhin den Agent-Host, das eine ausgehende Ziel und die Aktionsliste frei. Mehr Tiefe: technischer Benutzer und minimale Rechte, die vollständige Feldzuordnung und wie die Ausgleichsbuchung zurückkommt.

Kurz gesagt: Ihre Daten wandern nach außen in Ihre Region; Ihr ERP-Passwort bleibt zu Hause.

Wie entsteht die Verbindung, Schritt für Schritt?

Ihr ERP-Team und unser Team wählen den Weg, installieren den Agenten in Ihrem Netz, binden das Testsystem an, testen mit Ihren eigenen Transaktionen, fahren parallel und gehen dann live.

1. Weg. Wählen Sie die Schnittstelle aus der Tabelle gemeinsam mit Ihrem ERP-Team: API, Datei, Datenbank oder der On-Premises-Agent. Für ein System außerhalb der Tabelle lesen Sie den Beitrag zur Anbindung an ein individuelles ERP.
2. Host und Regeln. Die IT installiert den Agenten auf einem Host im Netz, erlaubt ein ausgehendes Ziel und gibt die Aktionsliste frei (IT-Aufgaben bei der Einführung).
3. Zugangsdaten. Das Passwort des technischen Benutzers wird vor Ort in den Agenten eingetragen; andere Zugangsdaten kommen in sichere Ablagen im Onboarding-Hub, nie per E-Mail.
4. Zuerst das Testsystem. Derselbe Workflow zeigt über eine Einstellung auf ein Test- oder ein Produktivsystem.
5. Ihre eigenen Transaktionen. Testszenarien laufen mit Ihren eigenen Transaktionen in der Staging-Umgebung, danach läuft ein Parallelbetrieb neben Ihrem bisherigen Prozess.
6. Abnahme. Der Go-live folgt auf einen Abnahmebericht, und eine Person gibt alles frei, was in den Produktivbetrieb gelangt (Onboarding vom Kickoff bis zum Go-live).

Der Onboarding-Hub führt durch die Einrichtung der Verbindung, mit Ihrer IT im Boot. Nach dem Go-live erklärt ein Monitor jeden fehlgeschlagenen Datensatz in verständlicher Sprache, mit der Möglichkeit zur Wiederholung. Im Integrations-Hub führen KI-Agenten den standardisierten Integrationsprozess aus (entdecken, zuordnen, bauen, testen, planen, überwachen), und eine Person gibt jede Änderung frei, die Ihr System erreicht (eine agentengeführte Integrationsplattform).

Für SAP S/4HANA, SAP ECC, Business Central und Oracle E-Business Suite dauert die ERP-Anbindung in der Regel 2 bis 3 Tage, und Ihre IT kann eingebunden sein. Bei den übrigen ERP-Systemen der Tabelle ist die Anbindung Teil des gesamten Rollouts, der bis zu 4 bis 8 Wochen dauert. Ein Proof of Value läuft 4 bis 5 Wochen an einer Gesellschaft (Einführungsdauer).

Kurz gesagt: erst das Testsystem, dann Ihre eigenen Transaktionen, zuletzt die Produktion, an jeder Schwelle mit der Freigabe einer Person.

Was ändert sich zwischen On-Premises- und Cloud-ERP, und was nicht?

Nur die Anbindung ändert sich: Agent, Weg und Zugangsdaten liegen bei einem On-Premises-ERP auf Ihrer Seite, während Abgleich, Freigaben, Schwellenwerte und Audit Trail gleich funktionieren.

Das Freigabemodell und seine Schwellenwerte: wer freigibt, wenn ein KI-Agent in Ihrem ERP arbeitet. Das Audit-Log hält Zeitstempel, die Aktion des Systems, die Aktion des Nutzers, die freigebende Person, die Eingabedaten und die Konfidenz fest (Audit Trail und Stornos).

Wechseln Sie später das ERP oder die Betriebsart, bleiben die Freigaberegeln und Mahnrhythmen im Forderungsmanagement, die Sie eingerichtet haben, in der Plattform erhalten; die Verbindung wird für das neue System neu eingerichtet. SAP-Teams, die den Zeitpunkt abwägen, lesen Debitorenbuchhaltung automatisieren: vor oder nach der S/4HANA-Migration.

Kurz gesagt: Wo das ERP läuft, verändert die Anbindung, nicht die Kontrollen.

Wie sieht ein Rechenbeispiel aus?

Ein Fertigungsunternehmen mit 900 Mitarbeitenden, einem On-Premises-ERP und 6.000 Kundenzahlungen im Monat hätte bei einer Auto-Match-Quote von 95 % im Monat etwa 300 Zahlungen, die eine Person bearbeitet.

Die Eingangsgrößen sind Annahmen zur Veranschaulichung; ersetzen Sie sie durch Ihre eigenen Werte. Nur die 95 % sind eine Kennzahl von Transformance (Transformance-Kundendaten, 2026).

• Zahlungen im Monat: 6.000 (Annahme).
• Automatisch zugeordnet bei 95 %: 6.000 mal 0,95 = 5.700 Zahlungen, vorgeschlagen mit Begründung.
• Für eine Person bleiben: 6.000 minus 5.700 = 300 Zahlungen, jede mit der Untersuchung von Vero.

Die 5.700 werden weiterhin erst nach Freigabe gebucht, innerhalb Ihrer Schwellenwerte. Das Ergebnis hängt von Ihren Daten ab (Qualität der Zahlungsavise, Zahlermix, Form der Referenzen); ein Proof of Value an einer Gesellschaft zeigt Ihre tatsächliche Zahl.

Kurz gesagt: Bei 6.000 Zahlungen im Monat verschiebt sich die Arbeit von 6.000 Zeilen von Hand auf etwa 300 geprüfte Ausnahmen.

Womit beginnen Sie bei einem On-Premises-ERP?

Beginnen Sie mit dem Umfang, der am wichtigsten ist, Zahlungsabgleich allein oder der gesamte Order-to-Cash-Prozess, und mit einem kurzen Gespräch über Ihr ERP, seine Version und den Weg, den Ihre IT bevorzugt.

Bringen Sie das ERP samt Version, die Schnittstellen, die Ihr Team bereits nutzt, und Ihr monatliches Zahlungsvolumen mit; bei einem ERP außerhalb der Tabelle prüfen wir die Machbarkeit zuerst an Beispieldatensätzen. Buchen Sie einen Termin, um Ihren Weg zu planen.

Kurz gesagt: Das erste Gespräch dreht sich um Ihre Schnittstelle, nicht um den Wechsel Ihres ERP.

Wer Transformance einsetzt

• ERP: SAP S/4HANA (On-Premises, Private oder Public Cloud), SAP ECC, NetSuite (auch mit OneWorld-Tochtergesellschaften), Microsoft Dynamics 365 Finance & Operations und Business Central sowie Odoo, alle bei Kunden im Produktivbetrieb; Oracle und Infor werden unterstützt; On-Premises-ERP-Systeme und weitere ERP-Systeme über unseren Integrations-Hub.
• Größe: Mittelstand bis Großunternehmen, 250 bis über 2.000 Mitarbeitende, auch Gruppen 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: Zahlungsabgleich allein oder der gesamte Order-to-Cash-Prozess (Zahlungsabgleich, Abzugsmanagement, Forderungsmanagement, Liquiditätsplanung).

Fazit: das ERP dort lassen, wo es läuft, und die Grenze festlegen

Ein On-Premises-ERP braucht von der Debitorenautomatisierung zwei Dinge: eine Tür, die sein Hersteller bereits dokumentiert, und ein klares Verzeichnis dessen, was die Grenze Ihres Netzes überquert. Mit einem Agenten, der nur nach außen verbindet, Zugangsdaten vor Ort und einer Person, die jede Buchung freigibt, laufen Zahlungsabgleich und Forderungsmanagement auf dem ERP, für das Sie sich entschieden haben.

Wichtige Begriffe

• Cash Application (Zahlungsabgleich): eingehende Zahlungen den offenen Rechnungen zuordnen und den Ausgleich buchen.
• Order-to-Cash: der Prozess von der Kundenbestellung bis zum Zahlungseingang.
• Zahlungsavis: die Mitteilung des Kunden, welche Rechnungen eine Zahlung abdeckt.
• Lockbox: ein Bankservice, der Kundenzahlungen einsammelt und die Zahlungsdaten weitergibt.
• Audit Trail: die Aufzeichnung, wer oder was wann was getan hat.
• SAP S/4HANA: die aktuelle ERP-Suite von SAP, betrieben On-Premises oder in der Cloud.

Weiterführende Ratgeber

• Welche ERP-Schnittstellen bietet Transformance?
• Lässt sich die Debitorenautomatisierung an ein individuelles ERP anbinden?
• Was muss die IT tun, wenn Sie die Debitorenautomatisierung einführen?
• Wie helfen KI-Agenten Teams mit Dynamics NAV, GP und AX in der Debitorenbuchhaltung?
• Wie greifen KI-Agenten sicher auf ERP- und Kundendaten zu?

Häufig gestellte Fragen

Funktioniert Debitorenautomatisierung mit einem On-Premises-ERP?

Ja: KI-Agenten verbinden sich über eine Schnittstelle, die das ERP bereits bietet (eine API, eine Datei oder ein freigegebener Datenbankweg), getragen von einem Agenten in Ihrem Netz, der die Verbindung nach außen aufbaut. Das ERP bleibt Ihr führendes System.

Müssen wir unsere Firewall öffnen?

Nein, an eingehenden Firewall-Regeln ändert sich nichts, weil der Agent in Ihrem Netz die Verbindung nach außen aufbaut. Ihre IT gibt weiterhin den Agent-Host, das eine ausgehende Ziel und die Aktionen frei, die der Agent ausführen darf.

Verlassen unsere Daten unser Netz?

Offene Posten, Rechnungen und Kundenstammdaten wandern nach außen zu einer Plattform in Ihrer eigenen Region, wahlweise mit VPC-Betrieb in Ihrer Cloud. Passwörter für Ihr ERP bleiben vor Ort, und Kundendaten werden nicht zum Training von Modellen verwendet.

Mit welchen On-Premises-ERP-Systemen arbeitet Transformance?

SAP S/4HANA (On-Premises) und SAP ECC laufen bei Kunden im Produktivbetrieb, und Transformance verbindet sich über den Integrations-Hub mit Business Central, Oracle E-Business Suite, JD Edwards, Dynamics NAV, GP und AX sowie weiteren ERP-Systemen. Bei einem System außerhalb dieser Liste prüfen wir die Machbarkeit zuerst an Beispieldatensätzen.

Ist Transformance für unsere Größe und unser Zahlungsvolumen gemacht?

Transformance richtet sich an Unternehmen mit 250 bis über 2.000 Mitarbeitenden und von unter 1.000 bis über 100.000 Zahlungen im Monat.

Wie lange dauert die Anbindung und was kostet sie?

Bei SAP S/4HANA, SAP ECC, Business Central und Oracle E-Business Suite dauert die ERP-Anbindung in der Regel 2 bis 3 Tage, und Ihre IT kann eingebunden sein; der gesamte Rollout dauert bis zu 4 bis 8 Wochen. Die Kosten hängen von Umfang und Zahl der Gesellschaften ab, daher buchen Sie einen Termin für ein Angebot.

Müssen wir zuerst auf ein Cloud-ERP wechseln?

Nein: Transformance verbindet sich mit dem ERP, das Sie heute betreiben. Ändern sich ERP oder Betriebsart später, bleiben die Freigaberegeln und Mahnrhythmen im Forderungsmanagement, die Sie eingerichtet haben, in der Plattform erhalten, und die Verbindung wird für das neue System neu eingerichtet.