Drei-Wege-Abgleich automatisieren: Bestellung, Wareneingang und Rechnung prüfen, am Beispiel n8n

Ein Drei-Wege-Abgleich prüft eine Lieferantenrechnung gegen zwei weitere Belege, bevor sie bezahlt wird: die eigene Bestellung und die Bestätigung des Wareneingangs. Der Abgleich lässt sich automatisieren, sofern alle drei Belege für das Automatisierungswerkzeug erreichbar sind und sich über einen gemeinsamen Schlüssel – Bestellnummer und Position – einander zuordnen lassen: Stimmen Menge, Artikel und Preis überein, bucht der Workflow ohne weiteren Schritt; weicht etwas ab, braucht es eine Freigabe durch den Einkauf, nicht durch die Rechnungsprüfung.

Der Aufbau ist hier am Beispiel n8n gezeigt. Die Voraussetzungen und die Freigabe-Matrix sind Festlegungen Ihres Unternehmens und gelten unabhängig davon, mit welchem Werkzeug Sie den Abgleich umsetzen. Dieser Beitrag behandelt den Abgleich selbst, nicht das Einlesen der Rechnung – wie eine eingehende E-Rechnung in n8n ankommt, zeigt unser Beitrag zu E-Rechnungen. Und er behandelt die umgekehrte Richtung als unser Beitrag zur Auftragsabwicklung: Dort geht es um die eigene Ausgangsrechnung an den Kunden, hier um die eingehende Rechnung eines Lieferanten gegen die eigene Bestellung.

Was beim Abgleich technisch passiert

Ein Drei-Wege-Abgleich braucht drei Datensätze, die zum selben Vorgang gehören: die Bestellung (was wurde zu welchem Preis bestellt), den Wareneingang (was kam tatsächlich an) und die Rechnung (was wird abgerechnet). Technisch heißt das: drei Abfragen gegen drei Quellen – je nach Betrieb dasselbe ERP- oder Warenwirtschaftssystem, oder getrennte Systeme für Einkauf und Lager – und ein gemeinsamer Schlüssel, über den sich die drei Datensätze einander zuordnen lassen. Dafür eignet sich die Kombination aus Bestellnummer und Positionsnummer, weil eine einzelne Bestellung mehrere Artikel in unterschiedlichen Mengen enthalten kann und ein Abgleich allein über die Bestellnummer diese Positionen nicht auseinanderhält.

Fehlt dieser Schlüssel oder wird er in einem der drei Systeme anders erfasst – etwa die Bestellnummer frei im Textfeld der Rechnung statt in einem eigenen Feld –, hat der Abgleich nichts, worauf er matchen kann. Diese Erfassungsfrage liegt vor jeder Workflow-Entscheidung und entscheidet, ob sich die Automatisierung überhaupt lohnt.

Wo die Daten herkommen: Zugriff auf Bestellung und Wareneingang

Für den Zugriff auf Bestellung und Wareneingang gilt dasselbe Bild wie beim Zugriff auf DATEV: Einen von n8n selbst gebauten, zertifizierten Node für ein verbreitetes ERP-System wie SAP gibt es nicht (Stand 9. November 2026). Im n8n-Communityforum verweisen Antworten auf eine Frage nach SAP-Integration auf Drittanbieter-Projekte und auf die eigene Praxis, etwa den SAP-Business-One-Service-Layer – eine OData-Schnittstelle – mit mehreren HTTP-Request-Nodes anzusprechen. n8n selbst beschreibt die generischen Credentials des HTTP-Request-Node ausdrücklich als Weg für „Integrationen, die n8n nicht unterstützt“. Praktisch heißt das: Sie bauen die Abfrage gegen die REST- oder OData-Schnittstelle Ihres ERPs selbst, inklusive Authentifizierung und Paginierung bei vielen Treffern.

Zur Einordnung, weil der Punkt in Tool-Vergleichen leicht zu grob dargestellt wird: Für SAP gibt es nach dem Stand vom 9. November 2026 durchaus einen offiziell zertifizierten Connector – allerdings nicht von n8n, sondern von Microsoft für Power Automate. Microsoft stuft ihn als Premium-Connector ein; er ruft RFC- und BAPI-Funktionen auf, setzt ein On-Premises-Datengateway und die SAP-eigene .NET-Connector-Bibliothek auf derselben Maschine voraus und ist damit weder kostenlos noch ohne lokale Infrastruktur nutzbar. Für n8n existiert kein Gegenstück; der Zugriff bleibt selbst gebaut. Für DATEV dagegen haben beide Werkzeuge zum selben Stand keinen offiziellen Connector: In Microsofts eigener, alphabetischer Connector-Referenz für Power Automate erscheint zwischen „DataScope Forms“ und „Dayforce HCM“ kein DATEV-Eintrag. Dort bauen Sie, wie im verlinkten Beitrag beschrieben, den Export im DATEV-Format oder die Anbindung an die DATEV-Datenservices selbst.

Ein Hinweis zum Stand der obigen Angaben: Alle Aussagen zu Connectoren, Node-Standardverhalten und Schnittstellen geben den Stand der n8n-Dokumentation, des n8n-Communityforums und der Microsoft-Learn-Connector-Referenz vom 9. November 2026 wieder. Das ändert sich; die Quellen sind unten verlinkt, damit Sie den aktuellen Stand selbst nachschlagen können.

Kommen Bestellung und Wareneingang aus einem System ohne API, etwa einer reinen Excel-Verwaltung, reicht n8n auch ein regelmäßig exportierter Datei-Abgleich – langsamer als eine Live-Abfrage, aber ohne Schnittstellenprojekt umsetzbar.

Der Abgleich selbst: Merge-Node statt stiller Verwerfung

Liegen die drei Datensätze als n8n-Items vor, übernimmt der Merge-Node im Modus „Combine by Matching Fields“ den eigentlichen Vergleich: Sie tragen Bestellnummer und Position als die Felder ein, nach denen abgeglichen wird, und n8n führt zusammen, was übereinstimmt.

Hier liegt die Stelle, an der eine automatisierte Prüfung am ehesten genau die Fälle verschluckt, die sie finden soll. Die Standardeinstellung des Merge-Node ist nach dem Stand vom 9. November 2026 „Keep Matches“: n8n gibt nur die Items aus, die auf beiden Seiten einen Treffer haben, ähnlich einem Inner Join. Eine Rechnungsposition ohne passende Bestellung oder ein Wareneingang ohne zugehörige Rechnung verschwindet dann kommentarlos aus dem Workflow – genau die Abweichung, die eine Prüfung eigentlich melden soll, bleibt unsichtbar. Erst die Einstellung „Keep Everything“ gibt auch die nicht zugeordneten Items aus und macht sie damit für den nächsten Schritt sichtbar. Dasselbe Muster beschreibt unser Beitrag zur Auftragsabwicklung für den Switch-Node, dessen „Fallback Output“ nicht passende Items zum gleichen Stand ebenfalls standardmäßig ignoriert: Ein Abgleich, der nur die Treffer zeigt, ist kein strengerer Workflow als die manuelle Prüfung, sondern ein blinderer.

Ab „Keep Everything“ unterscheidet ein IF- oder Switch-Node die Fälle: vollständige Treffer, Mengen- oder Preisabweichungen bei vorhandener Zuordnung, und Items ohne Zuordnung auf einer der drei Seiten. Eine vierte Kategorie braucht einen eigenen, zusätzlichen Vergleich: Der Merge-Schlüssel ist Bestellnummer und Position, nicht die Artikelnummer. Zwei Items können also über den Schlüssel zusammengeführt werden, obwohl die Artikelnummer oder -bezeichnung zwischen Bestellung und Rechnung abweicht – eine Substitution, die der Merge-Node selbst nicht meldet. Ihr IF- oder Switch-Node braucht deshalb nach dem Merge einen eigenen Vergleich der Artikelfelder, nicht nur von Menge und Preis. Jede dieser Kategorien bekommt einen eigenen Ausgang – die folgende Matrix legt fest, was mit jeder Kategorie passiert.

Freigabe-Matrix nach Abweichungstyp

Die Matrix ist der Baustein, der in diesem Beitrag mehr liefert als eine Prozessbeschreibung: eine konkrete Zuordnung von Abweichungstyp zu Handlungsempfehlung, die Sie direkt in die If- und Switch-Verzweigung Ihres Workflows übernehmen können, statt sie für Ihren Betrieb erst selbst zu entwerfen.

Abweichung	Was geprüft wird	Automatisch buchen?	Was stattdessen passiert
Keine Abweichung	Menge, Artikel und Preis stimmen auf allen drei Belegen überein	Ja	–
Preis innerhalb Toleranz	Rechnungspreis weicht vom Bestellpreis ab, aber innerhalb eines von Ihnen festgelegten Toleranzbands	Ja, mit Protokolleintrag	Die Abweichung wird vermerkt, aber nicht blockiert
Preis außerhalb Toleranz	Rechnungspreis weicht stärker ab, als das Toleranzband zulässt	Nein	Freigabe durch den Einkauf – er hat den Preis verhandelt, nicht die Rechnungsprüfung
Menge: Rechnung übersteigt Wareneingang	Mehr wird abgerechnet, als laut Wareneingang geliefert wurde	Nein	Freigabe durch den Einkauf, Rückfrage beim Lieferanten vor der Zahlung
Menge: Rechnung unter Wareneingang (Teilrechnung)	Weniger wird abgerechnet als geliefert, der Rest ist als offene Menge angekündigt	Ja, für den abgerechneten Teil	Offene Menge bleibt im Status „erwartet“, keine Freigabe nötig
Artikel weicht ab, Schlüssel matcht (Substitution)	Bestellnummer und Position stimmen überein, aber Artikelnummer oder -bezeichnung zwischen Bestellung und Rechnung weichen ab	Nein	Freigabe durch den Einkauf – nur er weiß, ob eine zulässige Ersatzlieferung vorliegt oder ein Fehler
Kein Merge-Treffer (fehlender Schlüssel, nachträgliche Position)	Bestellung oder Wareneingang lässt sich über Bestellnummer und Position gar nicht zuordnen – der Merge-Node liefert hierfür kein Gegenstück	Nein	Eigener Prüfpfad statt automatischer Verwerfung – sonst verschwindet die Rechnung wie beim Merge-Node-Standardverhalten oben
Mehrere Abweichungen gleichzeitig	Zum Beispiel Menge und Preis weichen beide ab	Nein	Eskalation statt Einzelprüfung – zwei gleichzeitige Abweichungen sind ein anderes Risiko als eine einzelne

Vier Zeilen verdienen eine Erklärung. Die Teilrechnung bucht automatisch, obwohl eine Mengenabweichung vorliegt, weil die Differenz erwartet und dokumentiert ist – das unterscheidet sie von einer Rechnung, die mehr verlangt, als geliefert wurde. Die Substitutions-Zeile existiert, weil der Merge-Schlüssel bewusst nur Bestellnummer und Position ist, nicht die Artikelnummer: Ein Item kann also einen Merge-Treffer haben und trotzdem einen anderen Artikel tragen als bestellt – das meldet nur der separate Artikelvergleich aus dem vorigen Abschnitt, nicht der Merge-Node selbst. Die Zeile „Kein Merge-Treffer“ bleibt dagegen auf echte Zuordnungsfehler beschränkt: Ob eine Rechnungsposition an einem fehlenden Schlüssel oder einer nachträglich eingefügten Position scheitert, sieht der Node gleich – in beiden Fällen bleibt sie ohne Treffer, und nur ein Mensch kann klären, ob es an der Erfassung oder am Beleg selbst liegt. Und mehrere gleichzeitige Abweichungen gehen bewusst in eine eigene Kategorie statt in die erste zutreffende Einzelregel: Prüfen Sie diese Kategorie in Ihrer Switch-Verzweigung vor den Einzelregeln, sonst fängt die erste zutreffende Einzelregel die Rechnung ab, bevor die Kombinationsregel greift. Eine Rechnung, die sowohl bei der Menge als auch beim Preis abweicht, braucht eher eine Einzelprüfung als eine Routinefreigabe.

Die Matrix ist ein Ausgangspunkt, keine feste Regel. Die Toleranzbänder bei Preisabweichungen legen Sie selbst fest, idealerweise gemeinsam mit dem Einkauf – wer die Toleranz definiert, trägt auch die Fälle, die dadurch automatisch durchlaufen.

Für den Mittelstand heißt das

Bauen Sie den Abgleich nicht an, bevor Bestellnummer und Position in Ihrem Bestell-, Wareneingangs- und Rechnungsprozess durchgängig gleich erfasst werden. Prüfen Sie das an Ihren letzten zwanzig Eingangsrechnungen, bevor Sie den ersten Workflow bauen: Wie oft lässt sich die Rechnungsposition heute schon eindeutig einer Bestellposition zuordnen? Ist die Quote niedrig, liegt die eigentliche Arbeit nicht im Workflow, sondern in der Erfassungsdisziplin davor – daran ändert kein Werkzeug etwas.

Richten Sie den Pfad für nicht zugeordnete Belege von Anfang an ein, nicht nachträglich. Ein Abgleich, der nur die glatten Treffer zeigt und Abweichungen stillschweigend auslässt, ist riskanter als die manuelle Prüfung, die er ersetzen soll – er erzeugt den Eindruck von Kontrolle, ohne sie zu liefern. Wie sich eine Freigabe mit Frist und Eskalation technisch aufbauen lässt, ohne die Entscheidung selbst zu automatisieren, zeigt unser Beitrag zur Buchhaltungs-Pipeline vom Beleg bis zur Buchung – das Muster aus Schritt 3 dort passt unverändert auf die Freigabe nach einer Drei-Wege-Abweichung.

FAQ

Was ist ein Drei-Wege-Abgleich?

In der Rechnungsprüfung bezeichnet der Begriff den Vergleich einer Lieferantenrechnung mit zwei vorangehenden Belegen: der eigenen Bestellung und der Bestätigung des Wareneingangs. Stimmen Menge, Artikel und Preis auf allen drei Belegen überein, gilt die Rechnung als geprüft; weicht eine der drei Größen ab, braucht es vor der Zahlung eine Freigabe.

Hat n8n einen fertigen Node für den Drei-Wege-Abgleich?

Nein, jedenfalls nicht im Stand vom 9. November 2026. Weder für den Abgleich selbst noch für den Zugriff auf ein ERP-System wie SAP gibt es einen von n8n gebauten, zertifizierten Node. Der Abgleich läuft über den generischen HTTP-Request-Node gegen die REST- oder OData-Schnittstelle Ihres Systems und den Merge-Node für den eigentlichen Vergleich.

Was passiert, wenn eine Rechnungsposition in der Bestellung fehlt?

Das ist der Fall, den eine automatisierte Prüfung am ehesten übersieht, wenn sie falsch konfiguriert ist. Der Merge-Node von n8n verwirft nicht zugeordnete Items in seiner Standardeinstellung „Keep Matches“ (Stand 9. November 2026); erst die Einstellung „Keep Everything“ zeigt eine Rechnungsposition ohne passende Bestellung sichtbar an, statt sie kommentarlos zu überspringen.

Welche Abweichungen darf ich automatisch durchwinken?

Nur die, die Sie vorher als unkritisch festgelegt haben – etwa eine geringe Preisabweichung innerhalb eines selbst gewählten Toleranzbands. Jede Mengen- oder Artikelabweichung und jede Preisabweichung außerhalb der Toleranz gehört vor die Buchung in eine Freigabe durch den Einkauf, nicht in eine stille automatische Buchung. Die Freigabe-Matrix in diesem Beitrag zeigt die Einteilung im Detail.

Brauche ich ein ERP, oder reicht eine Tabelle für Bestellung und Wareneingang?

Technisch reicht n8n jede Datenquelle, die sich per HTTP oder Datei abfragen lässt, auch eine Tabelle. Entscheidend ist nicht das System, sondern ob Bestellnummer und Position in allen drei Belegen gleich erfasst sind – ohne einen gemeinsamen Schlüssel kann der Merge-Node nicht zuordnen, und der Abgleich bleibt Handarbeit.