Abläufe bauen mit n8n

Wie ein Ablauf mit einem Modellschritt aufgebaut ist, beschreibt Kapitel 01, am Beispiel eines Rechnungseingangs. Ob ein Schritt überhaupt ein Modell braucht, fragt Kapitel 02. Dieses Kapitel baut denselben Rechnungseingang in einem echten Werkzeug nach, in n8n, Knoten für Knoten, als Bauplan. Wann ein Agent die bessere Bauform wäre, steht in Agenten und Harness, Kapitel 01.

Der Rechnungseingang als Kette von Knoten

n8n ist ein Baukasten für Abläufe. Ein Ablauf besteht dort aus Knoten, die einer nach dem anderen laufen, und jeder Knoten erledigt eine Aufgabe. Die Begriffe Auslöser, Knoten und Ausführung erklärt das erste Kapitel des Pfads mit dem Glossar von n8n (externe Seite, docs.n8n.io). Hier geht es um die Knoten selbst.

Der Rechnungseingang braucht sechs davon:

1. Email Trigger (IMAP). Der Auslöser. Er hört auf ein Postfach, und jede neue Mail startet eine Ausführung. Die Seite des Knotens (externe Seite, docs.n8n.io) nennt ihn ausdrücklich einen Auslöser, und den Anhang lädt er auf Wunsch gleich mit.
2. Extract From File. Er holt den Text aus dem PDF und gibt ihn als Felder weiter, die der nächste Knoten lesen kann. Dafür gibt es eine eigene Operation für PDFs (externe Seite, docs.n8n.io).
3. Information Extractor. Der einzige Knoten mit Modell. Er bekommt den Text und gibt sechs Felder zurück: Absender, Rechnungsnummer, Datum, Nettobetrag, Steuerbetrag, Gesamtbetrag. Das Modell selbst hängt als eigener kleiner Knoten darunter.
4. If. Er rechnet nach, ob Netto und Steuer den Gesamtbetrag ergeben, und schickt die Rechnung in einen von zwei Zweigen.
5. Send and Wait. Er schickt eine Nachricht mit zwei Knöpfen an einen Menschen, etwa über Slack oder eine Mail, und hält den Ablauf an, bis jemand antwortet.
6. Buchen. Ein HTTP Request (externe Seite, docs.n8n.io) ruft die Schnittstelle der Buchhaltung auf und übergibt die Rechnung.

seitlich verschiebbar

eigene Darstellung nach der Dokumentation von n8n, Stand 16.10.2026

Im ersten Kapitel hatte der Rechnungseingang fünf Schritte. Hier sind es sechs, weil das Herausholen des Textes ein eigener Knoten ist. Die Reihenfolge steht im Ablauf fest, und den nächsten Knoten bestimmt immer der Ablauf selbst. Den Lieferanten prüft dieser Ablauf nicht. Der Abgleich mit der Lieferantenliste aus dem ersten Kapitel wäre ein zweiter Vergleich im If.

Fünf Knoten ohne Modell

Von sechs Knoten fragt einer ein Modell. Die anderen fünf folgen Regeln, die jemand eingestellt hat, und sie verhalten sich bei derselben Eingabe jedes Mal gleich.

Am deutlichsten ist das beim If-Knoten. Er teilt den Ablauf nach einem Vergleich (externe Seite, docs.n8n.io): gleich, größer, kleiner. Die Summe aus Netto und Steuer entsteht in einem kurzen Ausdruck, und ein Spielraum von einem Cent für Rundungen gehört mit hinein. Geht die Summe auf, läuft die Rechnung weiter zur Freigabe. Geht sie nicht auf, landet sie bei einem Menschen zur Klärung.

Dass eine feste Regel der richtige Platz für so eine Prüfung ist, sagt n8n selbst. Seit Ende September gibt es einen Knoten für ein Ent­schei­dungs­mo­dell (externe Seite, docs.n8n.io), der für die unscharfen Teile eines Ablaufs gedacht ist. In derselben Ankündigung steht, dass für eine feste Regel wie einen Betrag über einer Grenze weiter der If-Knoten richtig ist. Was ein Ent­schei­dungs­mo­dell ist, erklärt KI jenseits der Sprachmodelle, Kapitel 15.

Auch der zweite Knoten kommt ohne Modell aus, solange das PDF eine Textschicht hat. Ein PDF, das ein Buch­hal­tungs­pro­gramm erzeugt hat, enthält die Zeichen, mit denen es gesetzt wurde. Ein eingescanntes Blatt enthält nur ein Bild, und die Seite des Knotens nennt für diesen Fall keine Texterkennung. Die eigene Texterkennung dieser Seite trennt die beiden Fälle mit einer Regel und fragt nur für Bildseiten ein Modell.

Der Modellknoten ist eine Kette

Für den Modellschritt bietet n8n zwei Arten von Knoten: Ketten mit festem Ablauf und Agenten, die ihr nächstes Werkzeug selbst wählen. Wie n8n die beiden trennt, steht in der zweiten Ebene von Kapitel 01.

Der Information Extractor gehört zu den Ketten, im Quelltext liegt er im Ordner der Kettenknoten (externe Seite, raw.githubusercontent.com). Er hat genau eine Aufgabe: Er liest aus einem Text feste Felder heraus (externe Seite, docs.n8n.io). Welche Felder, legt man vorher fest, etwa mit einem Beispiel im JSON-Format.

Ein Agentenknoten könnte dieselben Felder liefern. n8n rät auf der Seite zu häufigen Problemen (externe Seite, docs.n8n.io) davon ab: Das Auslesen fester Felder sei bei Agenten oft unzuverlässig. Wer einen Agenten einsetzt, soll seine Antwort von einer eigenen Kette auslesen lassen, das liefere bessere und gleichmäßigere Ergebnisse. Für den Rechnungseingang braucht es den Agenten gar nicht, denn die Reihenfolge steht fest.

Wie der Information Extractor die Form der Antwort sichert, ist eine eigene Frage. Die Seite des Knotens (externe Seite, docs.n8n.io) sagt, dass n8n die Formvorgabe selbst an die Anweisung anhängt. Geprüft wird die Antwort danach, und bei einem Fehler fragt der Knoten das Modell ein zweites Mal. Die zweite Ebene nimmt das auseinander.

Die Freigabe ist ein eigener Knoten

Im ersten Kapitel erscheint die Rechnung am Ende in einer Liste, in der jemand sie freigibt. In n8n sitzt diese Freigabe als Knoten im Ablauf, vor dem Buchen. Send and Wait schickt die Rechnung mit zwei Knöpfen an einen Menschen und wartet. Erst nach der Antwort läuft der Ablauf weiter, bei Zustimmung zum Buchen, bei Ablehnung in einen anderen Zweig.

Seit Fassung 2.30 vom Juli 2026 hält jeder dieser Knoten den Zeitpunkt der Antwort (externe Seite, docs.n8n.io) fest. Damit steht in der Ausführung, wann freigegeben wurde.

Der Name der Person fehlt in der Voreinstellung. Die Seite zu Freigaben über Slack (externe Seite, docs.n8n.io) beschreibt die voreingestellten Knöpfe als signierte Links: Jeder, der den Link hat, kann antworten, und n8n kann nicht sagen, wer geklickt hat. Für Slack und Telegram gibt es eine zweite Einstellung, die den Namen festhält. Für eine Rechnungsfreigabe ist das die Einstellung, nach der man zuerst sucht.

Die Freigabe für einen ganzen Ablauf unterscheidet sich von der Freigabe, die das erste Kapitel in seiner dritten Ebene beschreibt. Dort hält ein Agentenknoten vor einem einzelnen Werkzeug an. Hier steht die Freigabe an einer festen Stelle, und jede Rechnung kommt dort vorbei.

Den Ablauf kann ein Assistent anlegen

n8n hat einen Assistenten, der einen Ablauf aus einer Beschreibung in Sprache anlegt, testet und bei Fehlern hilft. Das Ergebnis ist laut Doku (externe Seite, docs.n8n.io) ein gewöhnlicher Ablauf, den man öffnen, lesen und ändern kann. Die Funktion ist eine Vorschau, und dieselbe Seite verlangt, jeden erzeugten Ablauf vor dem Betrieb durchzusehen.

Das erste Beispiel auf dieser Seite ist ein Rechnungseingang. Der Ablauf soll jeden Morgen ein Postfach nach Rechnungen durchsuchen, die PDFs ablegen und für jede eine Zeile in eine Tabelle schreiben. Darin steht kein Modellschritt, keine Summenprüfung und keine Freigabe vor dem Buchen. Wer so einen Ablauf erzeugen lässt, ergänzt die Prüfung selbst, und das Durchsehen beginnt mit der Frage, ob sie da ist.

Was ohne Modell ginge

Fünf von sechs Knoten kommen bereits ohne Modell aus. Den sechsten spart, wer Rechnungen in fester Form bekommt: Eine elektronische Rechnung bringt ihre Felder mit, wie Kapitel 02 zeigt. Dann liest ein Knoten die XML-Datei, und der Information Extractor fällt weg. Was geschieht, wenn einer der Knoten scheitert, steht in Kapitel 05.

Die erste Ebene hat den Rechnungseingang als Kette von sechs Knoten gebaut, mit einem Modellknoten in der Mitte. Diese Ebene sieht in den Modellknoten hinein. Sie fragt, wie n8n die Form seiner Antwort sichert, welche Prüfung danach noch fehlt und wie man den Knoten misst, bevor er Rechnungen bucht.

Wie der Information Extractor die Form sichert

Die zweite Ebene von Kapitel 01 beschreibt eine Einstellung der Schnittstelle, die die Form schon beim Erzeugen sichert. Bei Anthropic heißt sie strukturierte Ausgabe: Das Modell kann nur Zeichen wählen, die zum Schema passen. Der Information Extractor in n8n geht einen anderen Weg, in drei Schritten.

Erstens die Anweisung. Die Seite des Knotens (externe Seite, docs.n8n.io) sagt, dass n8n eine Formvorgabe automatisch an die Systemanweisung anhängt. Im Quelltext (externe Seite, raw.githubusercontent.com) ist das eine Zeile: Die Anweisung bekommt die For­mat­be­schrei­bung des Parsers angehängt. Das Modell liest also, welche Felder erwartet werden, so wie es jede andere Bitte liest.

Zweitens die Prüfung. Die Antwort läuft danach durch einen Parser, der sie gegen das Schema hält. Passt sie, gehen die Felder an den nächsten Knoten.

Drittens die Reparatur. Passt sie nicht, greift eine zweite Schicht. Der Knoten baut seinen Parser in allen drei Wegen, ein Schema anzugeben, als reparierenden Parser um den eigentlichen herum. Was der tut, beschreibt n8n beim gleichnamigen Unterknoten (externe Seite, docs.n8n.io): Scheitert die erste Prüfung, geht die Antwort mit der Fehlermeldung an ein Modell, das sie richten soll. Im Information Extractor ist das dasselbe Modell, das die Rechnung gelesen hat.

Daraus folgen zwei Dinge für den Betrieb. Die Form ist in diesem Knoten eine Prüfung nach dem Aufruf, und eine Antwort kann sie verfehlen. Und wer zählt, wie oft ein Ablauf ein Modell fragt, zählt den Reparaturaufruf mit. Er steckt im Knoten selbst. Diese Beschreibung gilt für den Information Extractor am Stand des Quelltexts vom 16.10.2026.

Die Sicherung beim Erzeugen gibt es in n8n auch, an einer anderen Stelle: am Unterknoten für das Modell. Der Modellknoten für OpenAI (externe Seite, docs.n8n.io) bietet als Ausgabeformat ein JSON-Schema an und empfiehlt es für Daten im JSON-Format. Laut Quelltext (externe Seite, raw.githubusercontent.com) gibt es die Wahl nur über die Responses API von OpenAI, die der Knoten ab Fassung 1.3 voreinstellt. Ob das Modell sich an das Schema halten muss, regelt ein eigener Schalter „Strict“, und der steht vorab auf aus. Der Information Extractor lässt diese Einstellung unberührt und sichert die Form auf seinem eigenen Weg, mit Anweisung, Parser und Reparatur.

Derselbe Weg aus sichtbaren Teilen

Der Information Extractor bündelt Anweisung, Parser und Reparatur in einem Knoten. Dieselben Teile gibt es in n8n auch einzeln, als Kette aus drei Bausteinen:

• Die Basic LLM Chain (externe Seite, docs.n8n.io) schickt eine Anweisung an ein Modell und kann ein festes Ausgabeformat verlangen.
• Der Structured Output Parser (externe Seite, docs.n8n.io) hängt als Unterknoten daran und hält die Antwort gegen ein JSON-Schema.
• Der reparierende Parser (externe Seite, docs.n8n.io) kommt nur dazu, wenn man ihn selbst anschließt.

Dieser Weg kostet mindestens einen Unterknoten mehr. Dafür ist der Reparaturaufruf dort zu sehen, und wer ihn nicht will, lässt ihn weg. Eine Antwort, die nicht zum Schema passt, fällt dann am Parser auf, und über die Fehlereinstellung des Knotens kann der Ablauf sie zur Klärung schicken. Für den Rechnungseingang ist das die übersichtlichere Bauform, weil jeder zusätzliche Modellaufruf als Knoten dasteht.

Pflichtfeld und Weglassen

Das Schema lässt sich auf drei Wegen angeben: als Liste von Attributen, als JSON-Beispiel oder als JSON-Schema. Beim Beispiel macht n8n laut Doku (externe Seite, docs.n8n.io) jedes Feld zur Pflicht. Im Quelltext gilt das ab der Knotenfassung 1.2.

Die voreingestellte Anweisung an das Modell sagt etwas anderes. Sie erlaubt, ein Feld wegzulassen, dessen Wert das Modell nicht kennt, so steht es in den Voreinstellungen des Knotens (externe Seite, raw.githubusercontent.com). Fehlt auf einer Rechnung der Steuerbetrag, etwa bei einer Klein­be­trags­rech­nung, stehen beide Vorgaben gegeneinander. Lässt das Modell das Feld weg, scheitert die Pflichtprüfung, und der Reparaturaufruf soll es richten. Was er dann liefert, zeigt erst ein Testfall.

Wer den Ablauf baut, legt diese Stelle vorher fest. Ein Weg ist ein Schema, in dem der Steuerbetrag fehlen darf, etwa die Liste von Attributen: Dort ist ein Feld im Quelltext nur dann Pflicht, wenn man es so einstellt, und eine Regel danach, die eine Rechnung ohne Steuerbetrag zur Klärung schickt. Ob das reicht, zeigt ein Testfall mit genau so einer Rechnung, wie im Abschnitt zu Evaluations unten.

Was der Parser prüft und was der If-Knoten prüft

Der Parser prüft die Form: ob jedes Pflichtfeld da ist, ob es den richtigen Namen hat, ob ein Betrag eine Zahl ist. Ob die Zahl stimmt, liegt außerhalb seiner Prüfung. Liest das Modell beim Nettobetrag eine 3 als 8, ist die Antwort für den Parser einwandfrei.

Diesen Fehler fängt der If-Knoten. Er rechnet Netto plus Steuer und vergleicht mit dem Gesamtbetrag. Weicht das Ergebnis um mehr als einen Cent ab, geht die Rechnung zur Klärung.

Dieselbe Arbeitsteilung beschreibt die zweite Ebene von Kapitel 01 für die Schnittstelle: Die Form sichert die Schnittstelle, den Inhalt der eigene Code. Bei Anthropic kommt dort eine Grenze hinzu, die strukturierte Ausgabe (externe Seite, platform.claude.com) kennt keine Wertebereiche für Zahlen. Auch in n8n gehört die Frage, ob ein Betrag positiv ist, in den Knoten nach dem Modell.

Die Weiche in drei Bauarten

Eine Verzweigung ist in n8n ein Knoten, und für die Frage, wohin ein Element geht, gibt es drei Bauarten.

Der If-Knoten teilt nach einem Vergleich (externe Seite, docs.n8n.io). Der Text Classifier ordnet einen Text mit einem Sprachmodell einer von mehreren Kategorien zu. Seine Voreinstellung verdient Aufmerksamkeit: Findet er keine passende Kategorie, verwirft er das Element (externe Seite, docs.n8n.io). Eine Rechnung, die er keiner Kategorie zuordnet, verschwindet damit ohne Fehlermeldung aus dem Ablauf. Die zweite Einstellung leitet solche Fälle in einen eigenen Zweig, und für einen Rechnungseingang ist sie die richtige.

Der dritte Knoten ist seit dem 30.09.2026 im Changelog (externe Seite, docs.n8n.io) angekündigt. Er fragt das Ent­schei­dungs­mo­dell Jev, das eine Entscheidung samt Sicherheitswert zurückgibt. Was ein Ent­schei­dungs­mo­dell von einem Sprachmodell unterscheidet, erklärt KI jenseits der Sprachmodelle, Kapitel 15. Für den Rechnungseingang bleibt die Summenprüfung beim If-Knoten, so wie n8n es in derselben Ankündigung für feste Regeln empfiehlt.

Evaluations als zweiter Auslöser

Warum ein Ablauf mit Modellschritt gemessen werden muss, begründet die zweite Ebene von Kapitel 01 mit der Doku von n8n (externe Seite, docs.n8n.io): Code lässt sich durchdenken, ein Modell nur an Daten messen. Dort stehen auch die zwanzig Testrechnungen. In n8n werden sie ein Teil des Ablaufs.

Die leichte Evaluation (externe Seite, docs.n8n.io) setzt einen zweiten Auslöser neben den ersten. Der Evaluation Trigger liest eine Tabelle mit Testfällen, je Zeile eine Rechnung mit den richtigen Feldern, und schickt jede einzeln durch denselben Ablauf. Am Ende schreibt ein Evaluation-Knoten das Ergebnis neben den Testfall zurück. Der Ablauf hat damit zwei Eingänge, einen für den Betrieb und einen für die Testsammlung.

Die Evaluation mit Metriken (externe Seite, docs.n8n.io) rechnet dazu eine Zahl je Testfall aus. Für die Rechnungsfelder passt die einfachste eingebaute Metrik, Categorization, also der genaue Abgleich mit der Referenz: 1 bei Übereinstimmung, sonst 0. Ein Betrag, ein Datum und eine Rechnungsnummer sind richtig oder falsch. Eine Bewertung durch ein zweites Modell, die n8n ebenfalls anbietet, hieße hier, ein Modell prüft ein Modell, wo eine Regel genügt. Das ist die Frage aus Kapitel 02, angewandt auf die Prüfung selbst.

Dieselbe Seite rät, Metriken nur beim Testen zu berechnen, weil sie Zeit und Kosten verursachen. Dafür hat der Evaluation-Knoten eine Abfrage, ob gerade getestet wird. Vor der Freigabe steht dann eine Weiche: Im Test schreibt der Ablauf das Ergebnis zurück, im Betrieb geht die Rechnung zur Freigabe und danach zum Buchen. So schickt die Testsammlung keine Anfrage an einen Menschen und schreibt nichts in die Buchhaltung.

Die Freigabe mit Namen

Die erste Ebene hat die Grenze der voreingestellten Freigabe genannt: Die Knöpfe sind signierte Links, und n8n weiß nicht, wer geklickt hat. Die Seite zu Freigaben über Slack (externe Seite, docs.n8n.io) beschreibt den zweiten Weg. Mit der Einstellung, die festhält, wer antwortet, werden die Knöpfe zu Knöpfen in Slack selbst. Der Ablauf setzt fort, sobald jemand antwortet, und die Ausgabe nennt die Person. Eine Liste legt fest, wer freigeben darf. Bleibt sie leer, kann jeder freigeben, der die Nachricht sieht, in einem Kanal also jedes Mitglied. Die Einrichtung verlangt eine eigene Slack-App und eine n8n-Instanz, die Slack über öffentliches HTTPS erreichen kann.

Laut Changelog (externe Seite, docs.n8n.io) gibt es denselben Weg für Telegram. Für Gmail, Outlook und gewöhnliche Mail nennt die Ankündigung nur den Zeitstempel. Wer für eine Rechnungsfreigabe den Namen braucht, legt die Freigabe also in einen dieser beiden Kanäle.

Wie n8n auf ein Ereignis wartet, beschreibt die Seite zum Wait-Knoten (externe Seite, docs.n8n.io): Die Ausführung liegt währenddessen in der Datenbank und wird zurückgeholt, sobald die Bedingung zum Weitermachen erfüllt ist. Die Seiten zu Send and Wait sagen dazu nichts Eigenes, die Antwort aus Slack geht aber an dieselbe Warteadresse von n8n (webhook-waiting-slack). Eine Freigabe darf also Tage dauern. Was geschieht, wenn niemand antwortet, gehört zu Kapitel 05.

Die ersten beiden Ebenen haben den Rechnungseingang gebaut und gemessen. Diese Ebene fragt, was es heißt, ihn zu betreiben. n8n gibt es als Cloud des Herstellers und zum Selbstbetrieb auf eigenen Rechnern. Die Entscheidung zwischen beiden betrifft Daten, Funktionen und Arbeit. Am Ende steht, was andere Werkzeuge an derselben Stelle mitbringen und wo ein Agent in einen festen Ablauf passt.

Wer für die Daten verantwortlich ist

Durch den Rechnungseingang laufen Namen, Anschriften und Beträge von Lieferanten. Die Datenschutzseite von n8n (externe Seite, docs.n8n.io) verteilt die Rollen nach der DSGVO je Betriebsform:

• Cloud. n8n ist Verantwortlicher und Auf­trags­ver­ar­beiter zugleich.
• Selbstbetrieb. n8n ist keines von beiden, weil der Hersteller die Daten nicht verwaltet. Die Pflicht, Daten zu löschen, liegt beim Betreiber.

Für den Rechnungseingang heißt das: Jede Ausführung speichert, was die Knoten gelesen und geschrieben haben, also auch die sechs Felder jeder Rechnung. Beim Selbstbetrieb bestimmt der Betreiber, wie lange diese Ausführungen liegen bleiben. Die Seite empfiehlt, sie regelmäßig automatisch löschen zu lassen. Bis dahin liegt jede gelesene Rechnung ein zweites Mal in der Datenbank von n8n.

Gesondert davon steht die Telemetrie, also Nutzungs- und Diagnosedaten, die eine Instanz an n8n schickt. Für sie ist n8n auch beim Selbstbetrieb der Verantwortliche. Sie ist voreingestellt eingeschaltet. Beim Selbstbetrieb schaltet sie der Betreiber über Umge­bungs­va­ria­blen ab, in der Cloud geht das laut derselben Seite (externe Seite, docs.n8n.io) derzeit nicht.

Wohin der Modellaufruf geht

Der Selbstbetrieb hält die Ausführungen im eigenen Haus. Der Modellknoten schickt den Text jeder Rechnung trotzdem an den Anbieter des Modells, das an ihm hängt. Wer die Rechnungsfelder im eigenen Haus halten will, braucht deshalb zwei Entscheidungen: eine über den Betrieb von n8n und eine über das Modell.

Für den n8n Assistant, der beim Bauen hilft, beschreibt der Changelog (externe Seite, docs.n8n.io) den Weg seit Fassung 2.35 vom August 2026. Für die selbst betriebene Enterprise-Edition ist der Assistent laut Doku (externe Seite, docs.n8n.io) noch nicht freigegeben. Beim Selbstbetrieb bringt man einen eigenen Schlüssel für einen Anbieter mit. Oder man richtet den Assistenten auf eine Schnittstelle im Format von OpenAI, auch auf eine lokale. Anweisungen, der Inhalt des Ablaufs und die Ausführungsdaten, die der Assistent liest, gehen an diesen Anbieter. Liest der Assistent zur Fehlersuche eine vergangene Ausführung, gehen deren Rechnungsfelder mit.

Wer für den Modellknoten ein lokales Modell einsetzt, misst es mit der Testsammlung aus der zweiten Ebene. Sie ist dafür gemacht, ein Modell gegen ein anderes zu messen, und sie zeigt, ob es die sechs Felder gut genug liest.

Was die Edition entscheidet

Selbst betrieben gibt es n8n in vier Editionen: Community, Registered Community, Business und Enterprise. Die Community-Edition hat laut Vergleichsseite (externe Seite, docs.n8n.io) fast alle Funktionen. Was ihr fehlt, betrifft vor allem die Arbeit im Team:

• Teilen. Abläufe und Zugangsdaten sieht nur der Besitzer der Instanz und wer sie angelegt hat.
• Projekte, SSO und Umgebungen. Getrennte Bereiche, Anmeldung über das Firmenkonto und eine Trennung von Test und Betrieb fehlen.
• Ver­si­ons­ver­wal­tung mit Git. Änderungen am Ablauf lassen sich nicht über Git nachverfolgen.

Ein Rechnungseingang, den eine Buchhaltung gemeinsam pflegt, stößt in der freien Edition also zuerst ans Teilen. Die Seite nennt selbst die Preisseite als maßgeblich, und Preise stehen deshalb hier keine.

Dasselbe gilt für die Prüfung aus der zweiten Ebene. Die leichte Evaluation (externe Seite, docs.n8n.io) gibt es beim Selbstbetrieb ab der Registered Community, also nach einer kostenlosen Registrierung. Die Evaluation mit Metriken (externe Seite, docs.n8n.io) gehört zur Enterprise-Edition, die Registered Community darf sie für einen einzigen Ablauf nutzen. Die Prüfung, die Kapitel 01 für jeden Modellschritt verlangt, hängt in ihrer eingebauten Form beim Selbstbetrieb also an Registrierung oder Plan.

Was die Lizenz offenlässt

Die Grundregel steht in der dritten Ebene von Kapitel 01. n8n steht unter einer eigenen Lizenz nach dem Fair-Code-Modell. Erlaubt ist der Einsatz für eigene interne Zwecke. Drei Punkte derselben Lizenzseite (externe Seite, docs.n8n.io) kommen für eine Entscheidung über Jahre dazu:

• Kein Open Source nach eigener Aussage. Der Quelltext ist einsehbar. Weil eine Open-Source-Lizenz nach der Definition der Open Source Initiative keine Einschränkung der Nutzung enthalten darf, nennt n8n sich selbst nicht so.
• Die Lizenz kann sich ändern. Wer zum Quelltext beiträgt, unterschreibt eine Vereinbarung, die n8n erlaubt, die Lizenz ohne weitere Zustimmung zu wechseln.
• Sie hat sich schon geändert. Bis zum 17.03.2022 stand n8n unter Apache 2.0 mit der Commons Clause.

Das sind Tatsachen aus der Doku des Herstellers. Was sie für einen Betrieb bedeuten, hängt an der Frist, über die er plant.

Betrieb heißt Takt

Zwischen Juli und September 2026 nennt der Changelog (externe Seite, docs.n8n.io) fast jede Woche eine neue Fassung. Von 2.30 am 07.07. bis 2.40 am 21.09. sind es zehn Fassungen in elf Wochen. Die Seite zum Aktualisieren (externe Seite, docs.n8n.io) rät, oft zu aktualisieren, damit kein Sprung über viele Fassungen nötig wird, und mindestens einmal im Monat.

Der nächste große Schritt ist angekündigt. Mit n8n 3.0 (externe Seite, docs.n8n.io) läuft der Selbstbetrieb nur noch in Docker, eine Installation über npm entfällt. Die Seite zu 3.0 nennt kein Datum. Der Changelog (externe Seite, docs.n8n.io) kündigt das Ende der Installation über npm für Oktober an. Wer heute über npm installiert, zieht vor dem Update auf 3.0 nach Docker um.

Für einen Rechnungseingang heißt Takt: Jede neue Fassung kann einen Knoten ändern, auch den Information Extractor. Die Testsammlung aus der zweiten Ebene ist deshalb auch eine Prüfung nach jedem Update. Läuft sie grün, hat sich an den Testfällen nichts verschoben.

Was andere Werkzeuge an derselben Stelle mitbringen

Zwei andere Hersteller haben für den Rechnungseingang eigene Bauteile. Belegt ist hier, was ihre Doku beschreibt, also ihre Bauform. Wie gut die Bauteile lesen, sagt keine der Seiten mit einer Messung.

Power Automate mit AI Builder. Microsoft bietet ein vortrainiertes Rechnungsmodell (externe Seite, learn.microsoft.com), das übliche Felder wie Rechnungsnummer, Datum und offenen Betrag ausliest. Zu jedem Feld liefert es einen Sicherheitswert, und der Beispielablauf der Seite vergleicht ihn mit der Schwelle 0,65. Die Seite zeigt einen Ablauf, der bei niedrigem Wert für die Gesamtsumme ein zweites, eigens trainiertes Modell fragt. Der Information Extractor liefert Felder ohne einen solchen Wert. In n8n entsteht die Weiche „unsicher, also zum Menschen“ deshalb aus Regeln wie der Summenprüfung. Das Rechnungsmodell ist zugleich ein Beispiel für die Frage aus Kapitel 02: ein Fachmodell an der Stelle eines Sprachmodells.

Auch die Freigabe ist dort weiter ausgebaut. Power Automate kennt Freigaben in fester Reihenfolge (externe Seite, learn.microsoft.com), bei denen jeder Freigebende antworten muss, bevor der nächste gefragt wird, und Freigaben, denen alle zustimmen müssen. Ein Vier-Augen-Prinzip ist dort eine Einstellung. In n8n sind es zwei Wartepunkte hintereinander.

Make. Auch Make beschreibt sich als Plattform für feste Abläufe und Agenten (externe Seite, make.com). Für den Rechnungseingang hat Make ein eigenes Modul, das Rechnungen über Microsofts Azure-Dienste ausliest. Die Seite zu den Datenzonen (externe Seite, help.make.com) nennt je KI-Funktion den Ort der Verarbeitung, für dieses Modul die EU. Sie warnt zugleich, dass die Wahl einer EU-Datenzone allein keine Verarbeitung in der EU sichert. Eine verwaltete Cloud liefert damit eine Auskunft je Funktion, die beim Selbstbetrieb der Betreiber für jeden Knoten selbst zusammenträgt.

Beide Werkzeuge laufen als Dienst ihres Herstellers. Den Betrieb übernimmt dort der Hersteller, die Wahl von Ort und Modell trifft er mit.

Ein Agent als Knoten im festen Ablauf

n8n führt Agenten (externe Seite, docs.n8n.io) inzwischen als eigene Objekte neben den Abläufen eines Projekts, als Vorschau. Die Doku nennt den Anlass: Ein Agent passt, wenn eine Aufgabe zu offen für einen festen Ablauf ist. Die Linie zwischen beiden zieht Agenten und Harness, Kapitel 01.

Für den Rechnungseingang ist eine andere Bauform derselben Seite wichtiger. Ein Ablauf kann einen Agenten als Knoten aufrufen und seine Antwort an ein JSON-Schema binden, damit die Knoten danach feste Felder bekommen. Die Reihenfolge bleibt dann im Ablauf. Der Agent bekommt einen Schritt, etwa die Rückfrage beim Lieferanten zu einer Rechnung, deren Summe nicht aufgeht, und gibt das Ergebnis in fester Form zurück. Das ist die Prüffrage aus Agenten und Harness, Kapitel 01, angewandt auf einen einzelnen Knoten.

Beim Selbstbetrieb nennt die Seite eine Grenze: Agenten laufen noch ohne den Queue-Modus, mit dem eine Instanz die Arbeit auf mehrere Prozesse verteilt. Eine Instanz, die so skaliert, betreibt Agenten vorerst im gewöhnlichen Modus.

Was geschieht, wenn einer dieser Knoten scheitert, gehört in den Fehlerablauf (externe Seite, docs.n8n.io), einen eigenen Ablauf, der startet, wenn eine automatisch gestartete Ausführung scheitert. Wie man ihn baut und warum ein zweiter Lauf nichts doppelt buchen darf, steht in Kapitel 05.