SAP Rechnungsprüfung: Rechnungseingang für S/4HANA automatisieren

Ins SAP schreiben, aus SAP lesen

Eine ernstzunehmende SAP-Anbindung ist keine Einbahnstraße. BelegrAIdar kommuniziert in beide Richtungen über freigegebene S/4HANA-OData-Services:

BelegrAIdar · Admin-Center · SAP S/4HANA

Drei Wege, mit Ihrem SAP zu sprechen

Weil Landschaften unterschiedlich sind, unterstützt der Connector mehrere Authentifizierungs- und Betriebsmodelle:

• OAuth2 Client-Credentials über eine Communication Arrangement, der empfohlene Weg für S/4HANA Cloud (Public).
• Basic-Auth über einen Communication/Technical User für S/4HANA Private Cloud / On-Premise; der OData-Service wird in der Landschaft aktiviert (/IWFND/MAINT_SERVICE).
• API-Key gegen die SAP-API-Business-Hub-Sandbox, zum Ausprobieren ohne eigenes Tenant (read-only Demodaten).

Der Schreibzugriff nutzt den vorgeschriebenen CSRF-Token-Flow (X-CSRF-Token: Fetch). Der Connector handhabt das automatisch. Zugangsdaten werden verschlüsselt gespeichert.

Sauber gebucht, nicht nur „irgendwie übergeben"

• Bestellbezug auf echte Positionen: Bei PO-Rechnungen wird je gematchter Rechnungsposition auf die echte Bestellposition gebucht, nicht alles pauschal auf Position 10. Das hält den Abgleich und den Bestand in SAP korrekt.
• Sachkontobuchung für Rechnungen ohne Bestellbezug (mit Sachkonto und Kostenstelle).
• Steuercode-Mapping für beliebige EU-Sätze (19/7/0 und Reverse-Charge sowie NL, PL, LU … über eine konfigurierbare Zuordnung).
• Parken oder direkt buchen: Sie entscheiden, ob BelegrAIdar einen Buchungslauf auslöst oder einen Entwurf zur Freigabe stellt.

Verstehen, bevor gebucht wird

Der eigentliche Wert liegt vor der Buchung. BelegrAIdar erfasst die Rechnung mit KI statt Template-OCR, auf Wunsch mit einer lokalen KI, sodass Belegdaten das Haus nicht verlassen. Darauf setzt die fachliche Prüfung auf: § 14-Pflichtangaben, § 13b-Reverse-Charge am Bau, Dubletten- und IBAN-Anomalie, Skonto und mehrere Steuersätze. Nur was geprüft ist, geht als saubere Buchung nach SAP. So steigt die Dunkelverarbeitungsquote, ohne dass falsche Belege durchrutschen.

Mehr dazu: OCR oder KI in der Rechnungsprüfung? · Reverse-Charge § 13b bei Bauleistungen

Warum SAPs eigene Dublettenprüfung Doppelzahlungen übersieht

SAP kennt eine Dublettenprüfung beim Rechnungseingang (Nachrichten M8 108 / M8 462). Sie vergleicht allerdings exakt: Lieferant, Rechnungsnummer, Rechnungsdatum und Betrag müssen zeichengleich übereinstimmen, und welche Felder überhaupt geprüft werden, hängt an der Einstellung im Kreditorenstamm und im Customizing. Genau daran scheitert sie im Alltag:

• Abweichende Schreibweise der Rechnungsnummer. 2026-0312, 20260312 und RG 2026/0312 sind für SAP drei verschiedene Belege – für den Lieferanten derselbe.
• Zwei Kreditorenstämme für ein Unternehmen. Nach Umfirmierung oder Konzernzukauf laufen Belege auf zwei Konten; die Prüfung greift je Kreditor und sieht die Dublette nicht.
• PDF und E-Rechnung derselben Rechnung. Kommt dieselbe Forderung einmal per Mail und einmal als XRechnung, unterscheiden sich oft Betragsrundung oder Datumsformat – schon greift der Exact-Match nicht mehr.
• Die Prüfung ist nur eine Warnung. M8 108 lässt sich als Hinweis statt als Fehler konfigurieren und wird dann im Massengeschäft weggeklickt.

BelegrAIdar prüft deshalb vor der Übergabe an SAP – mit unscharfem Abgleich der Rechnungsnummer, aber immer gegen einen zweiten Anker (Betrag, Datum, Lieferant), weil fortlaufende Nummern sonst massenhaft Fehlalarme erzeugen. Warum ein einzelner Anker nicht genügt, steht ausführlich unter Doppelzahlung vermeiden.

Was SAP selbst prüft – und was nicht

Der SAP-Standard ist stark, wo es um Beschaffungslogik geht, und blind, wo es um den Beleg geht. Diese Trennung entscheidet darüber, was eine vorgelagerte Prüfung überhaupt beitragen kann:

Anders gesagt: SAP prüft die Rechnung gegen die Bestellung. Ob die Rechnung selbst formal tragfähig, steuerlich richtig eingeordnet und nicht manipuliert ist, prüft es nicht – das ist per Konstruktion die Aufgabe davor. Wie weit sich das automatisieren lässt, ohne die Kontrolle zu verlieren, behandelt Dunkelverarbeitung: was die Automatik darf.

MIRO, MIR7 und wo BelegrAIdar sitzt

Im SAP-Standard läuft der Rechnungseingang über MIRO (buchen) beziehungsweise MIR7 (vorerfassen/parken). BelegrAIdar ersetzt diese Transaktionen nicht, sondern füllt sie: Der geprüfte Beleg wird über die Standard-OData-API als Lieferantenrechnung angelegt – wahlweise geparkt, damit die Freigabe in gewohnter SAP-Oberfläche erfolgt, oder direkt gebucht, wenn der Beleg alle Prüfungen bestanden hat.

Was die SAP-Basis dafür konkret freigeben muss und woran Projekte in der Praxis wirklich hängen, steht im Beitrag SAP anbinden ohne SAP-Projekt.

Das ist der Grund, warum kein Z-Code nötig ist und warum die Umstellung ohne Eingriff in bestehende Berechtigungs- und Freigabekonzepte funktioniert: In SAP entsteht derselbe Belegtyp wie bisher, nur mit geprüften Daten und vollständigem Bestellbezug.

Häufige Fragen