Automatisierung des Drei-Wege-Abgleichs: Tabellen und Workflow für Zahlungs-Holds

Welches Problem der Drei-Wege-Abgleich wirklich löst

Die Automatisierung des Drei-Wege-Abgleichs ist einfach: Sie bezahlen eine Rechnung nur, wenn sie mit dem übereinstimmt, was Sie bestellt haben und was tatsächlich angekommen ist. Die drei Dokumente sind die Bestellung (PO), der Wareneingang (Receipt) und die Lieferantenrechnung.

Ohne diese Prüfung kann die Kreditorenbuchhaltung auf Grundlage eines einzelnen, falschen oder unvollständigen Dokuments bezahlen. Ein Lieferant könnte für mehr Einheiten abrechnen, als geliefert wurden, einen anderen Preis als vereinbart verwenden oder eine doppelte Rechnung schicken, die in einem E-Mail-Thread wie neu aussieht.

Diese Fehler fallen selten am ersten Tag dramatisch auf. Sie zeigen sich als kleine Lecks: ein Positionseintrag, der doppelt berechnet wird, eine Lieferung, bei der ein paar Einheiten fehlen, eine nicht genehmigte Preiserhöhung oder falsch berechnete Fracht. Mit der Zeit werden diese kleinen Fehler zu echtem Geldverlust.

Der Punkt ist nicht, „Rechnungen freizugeben“. Der Punkt ist, die Zahlung zu stoppen, bis die von Ihnen festgelegten Schlüsselfelder (in der Regel Menge, Stückpreis und Summen) über PO, Wareneingang und Rechnung hinweg übereinstimmen. Wenn sie nicht übereinstimmen, darf die Rechnung nicht in E-Mails versinken. Sie sollte in einer Ausnahmewarteschlange landen mit einem klaren Grundcode und den exakten Feldern, die abweichen.

Der Drei-Wege-Abgleich zieht außerdem eine klare Grenze zwischen den Teams. Procurement/ Einkauf ist verantwortlich für das, was bestellt wurde (Bedingungen und Preis). Der Wareneingang bestätigt, was eingetroffen ist (Mengen und Daten). Die Finanzabteilung steuert, was bezahlt wird (Rechnungsprüfung und Freigabe).

Setzen Sie Erwartungen früh: Das ist ein Prozess- und Datenproblem, kein bloßer Freigabe-Button. Wenn PO-Zeilen vage sind, Wareneingänge nicht erfasst werden oder Rechnungen keiner PO-Zeile zugeordnet werden können, hilft Ihnen Automatisierung nicht.

Dokumente und Rollen: PO, Wareneingang, Rechnung und wer wofür verantwortlich ist

Der Drei-Wege-Abgleich funktioniert nur, wenn jedes Dokument einen klaren Besitzer hat. Wenn „wer was aktualisiert" unklar ist, blockiert das System entweder gute Zahlungen oder lässt schlechte durch.

Ein praktisches Ownership-Modell ist:

• Der Anforderer erstellt die Bestellanforderung und bestätigt den Bedarf.
• Procurement/Einkauf erstellt und pflegt die PO (Lieferant, Preis, Konditionen).
• Lager/Empfänger (oder der Service-Owner) bucht den Wareneingang oder die Abnahme.
• AP/Finanzen erfasst die Rechnung und steuert die Zahlung.

Jedes Dokument braucht außerdem eine Mindestmenge an Feldern, damit das Abgleichen kein Raten wird.

PO (Purchase Order) benötigt Lieferanten-ID, PO-Nummer, Positionen (SKU oder Leistung), bestellte Menge, Stückpreis, Währung, Steuerregeln und Zahlungsbedingungen.

Wareneingang (Receipt) benötigt eine PO-Referenz, Empfangsdatum, empfangene Mengen pro PO-Zeile und wer entgegengenommen hat. Bei Dienstleistungen behandeln Sie das als Abnahme und erfassen den Genehmiger.

Rechnung benötigt Lieferanten-Rechnungsnummer, Rechnungsdatum, PO-Referenz (oder eine verlässliche Methode, die PO zu finden), Positionsdetails (Menge, Stückpreis), Steuern/Versand und die Gesamtsumme.

Entscheiden Sie auch, wann der Abgleich ausgeführt wird. Er sollte kein Einmalereignis sein. Triggern Sie ihn, wann immer sich die Realität ändert:

1. Wenn eine Rechnung erfasst wird (damit Sie sofort zwischen Bezahlen und Hold entscheiden).
2. Wenn ein Wareneingang gebucht wird (damit eine auf Hold befindliche Rechnung zahlbar werden kann).
3. Wenn eine PO geändert wird (damit offene Rechnungen erneut geprüft werden).

Teillieferungen und mehrere Rechnungen sind normal. Eine PO-Zeile kann in drei Lieferungen eintreffen und über zwei Rechnungen abgerechnet werden. Ihre Logik sollte kumulativ erhaltene vs. kumulativ fakturierte Mengen pro PO-Zeile vergleichen, nicht nur ein Dokument auf einmal.

Regeln, die Sie festlegen sollten, bevor Sie etwas bauen

Bevor Sie Tabellen oder Workflow-Schritte anfassen, einigen Sie sich auf die Regeln, die das gesamte System steuern. Vage Regeln erzeugen vorhersehbare Fehler: Entweder blockiert das System zu viel (so dass Leute es umgehen), oder es blockiert zu wenig (so dass schlechte Rechnungen trotzdem bezahlt werden).

Wählen Sie das Abgleichniveau. Nur Kopfzeilen-Abgleich prüft Summen auf Dokumentenebene. Das klingt einfacher, bricht aber schnell bei Teillieferungen, Rückständen, Fracht-Positionen oder gemischten Steuersätzen zusammen. Zeilenbasierter Abgleich braucht länger zur Einrichtung, ist aber der sichere Standard, weil Sie das Gleiche über PO, Wareneingang und Rechnung vergleichen: die spezifische Zeile, ihre Menge und ihren Stückpreis.

Definieren Sie harte Blocks vs. Warnungen. Ein harter Block bedeutet, dass die Zahlung erst nach Klärung fortgesetzt werden kann. Eine Warnung erlaubt, dass die Rechnung weitergeht, aber jemand das Risiko bestätigen muss.

Typische Ausgangspunkte:

• Harte Sperre: fakturierte Menge übersteigt die empfangene Menge (bei Waren).
• Harte Sperre: Stückpreis überschreitet den PO-Preis über die Toleranz hinaus.
• Warnung: kleine Rundungsdifferenzen.
• Warnung: erwartete Abweichungen bei Steuern oder Versand, die separat codiert sind.

Halten Sie Toleranzregeln explizit. Definieren Sie die Methode (Prozent, absoluter Betrag oder das höhere von beidem) und wer dafür verantwortlich ist. Beispiel: +/- 1 % oder +/- $5 pro Zeile erlauben, wobei nur die Finanzabteilung Toleranzen mit einem Audit-Vermerk ändern darf.

Verwenden Sie ein kleines, gemeinsames Status-Set. Vermeiden Sie team-spezifische Status. Ein sauberes Set reicht meist: Matched, Hold, Exception, Approved. „Hold" bedeutet zahlungsblockiert. „Exception" bedeutet, ein Mensch muss überprüfen. „Approved" bedeutet, eine namentlich genannte Person hat die Abweichung akzeptiert und dokumentiert, warum.

Datenmodell: die Tabellen, die Sie brauchen (und warum)

Die Automatisierung des Drei-Wege-Abgleichs funktioniert nur, wenn Ihr Datenmodell eine PO-Zeile, das, was empfangen wurde, und das, was fakturiert wurde, gegenüberstellen kann. Jede Rechnungszeile sollte einer spezifischen PO-Zeile zuordenbar sein (oder als non-PO gekennzeichnet), und jede Empfangszeile sollte die verbleibende Menge auf dieser PO-Zeile reduzieren.

Starten Sie mit den Kern-Tabellen:

• Vendors: eine Zeile pro Lieferant (Name, Konditionen, Steuerinformationen).
• ItemsServices: optional, verbessert Konsistenz (SKU, Beschreibung, Mengeneinheit).
• PurchaseOrders: PO-Header (vendor_id, currency, requested_by, status).
• PO_Lines: der Abgleich-Anker (po_id, item_id/description, ordered_qty, unit_price).

Der Wareneingang braucht eigene Aufzeichnungen, auch wenn ein „Receipt" nur eine Bestätigung ist. Heben Sie Receipts von Rechnungen ab, damit Sie beweisen können, was wann angekommen ist:

• Receipts: Receipt-Header (vendor_id, received_date, location, status).
• Receipt_Lines: jede Zeile referenziert die PO-Zeile (receipt_id, po_line_id, received_qty, notes).

Das Rechnungswesen spiegelt den Wareneingang wider. Speichern Sie, was der Lieferant auf Positionsniveau berechnet hat und verbinden Sie es mit der PO-Zeile, die dafür zuständig sein sollte:

• Invoices: Invoice-Header (vendor_id, invoice_number, invoice_date, due_date, status).
• Invoice_Lines: (invoice_id, po_line_id falls zutreffend, invoiced_qty, unit_price, tax, line_total).

Schließlich erstellen Sie ein zahlungsorientiertes Objekt, das Ihr Workflow blockieren kann. Manche Teams nennen das Bill, PaymentRequest oder PayRunItem:

• PaymentRequests (oder Bills): Verknüpft mit invoice_id und enthält payment_hold (true/false) plus hold_reason.

Für Audits und saubere Ausnahmebehandlung fügen Sie den Headern (POs, Receipts, Invoices, Payments) konsistente Lifecycle-Felder hinzu: status, created_at/created_by, approved_at/approved_by, posted_at und (optional) source_document_id für Importe.

Schlüssel-Felder und Beziehungen, die Abgleich zuverlässig machen

Abgleich funktioniert am besten, wenn jedes Dokument auf dieselbe Position zurückverfolgt werden kann. Das bedeutet stabile IDs, saubere Verknüpfungen und Summen, die aus den Zeilen neu berechnet werden können.

Stellen Sie sicher, dass jede Tabelle sowohl eine stabile interne ID als auch die externe Nummer hat, nach der Leute suchen:

• PO-Header: po_id, po_number, vendor_id, currency, status, po_date
• PO-Zeilen: po_line_id, po_id, item_id oder description, ordered_qty, unit_price, tax_rate, line_total
• Receipts: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Invoices: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors und Items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

Die wichtigsten Verknüpfungen sind zeilenbasiert:

• invoice_line.po_line_id sollte auf die PO-Zeile verweisen.
• receipt_line.po_line_id sollte auf dieselbe PO-Zeile verweisen.

Das ermöglicht den Vergleich von Menge und Preis ohne Rätselraten.

Um mit Teilmengen umzugehen, berechnen Sie laufende Summen pro PO-Zeile: received_qty (Summe der Receipt-Lines) und invoiced_qty (Summe der Invoice-Lines). Dann berechnen Sie remaining_qty = ordered_qty - received_qty und open_to_invoice_qty = received_qty - invoiced_qty. Diese Werte zeigen klar, ob eine Rechnung zu früh, zu spät oder überfakturiert ist.

Überschreiben Sie die Historie nicht, wenn eine PO geändert wird. Speichern Sie eine PO-Revision-Nummer und behalten Sie entweder alte PO-Zeilen (mit einem active-Flag) oder führen Sie ein Änderungsprotokoll (wer hat was geändert, wann, alter Wert, neuer Wert).

Fügen Sie grundlegende Guardrails hinzu, um Duplikate und falsche Joins zu verhindern:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number und po_number
• Not null auf currency, quantities und unit_price
• Check-Constraints wie qty >= 0 und unit_price >= 0
• Foreign Keys von invoice_line und receipt_line zur po_line

Schritt-für-Schritt-Workflow: vom Rechnungseingang bis zum Zahlungs-Hold

Die Automatisierung des Drei-Wege-Abgleichs hat meist drei Einstiegspunkte: Eine Rechnung trifft ein (E-Mail, Upload, EDI), ein Wareneingang wird gebucht oder eine PO wird geändert (Preis, Menge, Status). Der Workflow sollte auf alle diese Events reagieren, damit eine Rechnung so schnell wie möglich von Hold genommen werden kann, sobald das fehlende Stück da ist.

1) Validieren Sie zuerst die Rechnungs-Basics. Bestätigen Sie, dass der Lieferant aktiv ist, die PO existiert, die Währung mit der PO übereinstimmt und die Summen intern konsistent sind (Zeilensummen ergeben die Gesamtsumme, Steuern sind plausibel, keine negativen Mengen, außer Sie unterstützen Gutschriften). Wenn das fehlschlägt, senden Sie die Rechnung direkt auf Hold mit einem klaren Grund.

2) Abgleichen pro Zeile, nicht nur auf Kopfzeile. Für jede Rechnungszeile finden Sie die zugehörige PO-Zeile und die bis dato empfangenen Mengen. Vergleichen Sie:

• Fakturierte Menge vs. empfangene Menge (oder empfangen minus bereits fakturiert)
• Fakturierter Stückpreis vs. Stückpreis auf der PO
• Toleranzregeln
• Ob die PO-Zeile noch zum Fakturieren offen ist

3) Status setzen und Blockierung durchsetzen. Ein gängiges Muster:

• Matched: alle Zeilen bestehen die Prüfungen, keine offenen Ausnahmen.
• Hold: mindestens eine Zeile schlägt fehl oder erforderliche Daten fehlen.

Wenn Hold gesetzt wird, erzeugen Sie einen Payment-Hold-Eintrag, den der Zahlungslauf beachten muss. Halten Sie Holds getrennt von der Rechnung, damit Holds hinzugefügt, freigegeben oder ersetzt werden können, ohne die Rechnungs-Historie umzuschreiben.

4) Erfassen Sie belastbare Grundcodes für Finance. Vermeiden Sie ausschließlich Freitext bei Holds. Nutzen Sie Codes wie PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH oder CURRENCY_MISMATCH und eine kurze Notiz.

Design der Ausnahmewarteschlange für Finance (was zu speichern und was angezeigt werden sollte)

Eine Ausnahmewarteschlange macht Abgleich nützlich, sie ist nicht nur strikt. Die Finanzabteilung sollte nur Rechnungen sehen, die eine Entscheidung brauchen, mit genügend Kontext, um schnell zu entscheiden und eine saubere Auditspur zu hinterlassen.

Ein üblicher Ansatz ist eine dedizierte Tabelle wie ExceptionCases. Jede Zeile repräsentiert eine blockierte Rechnung (oder Rechnungszeile) und verweist auf die Invoice-, PO- und Receipt-Datensätze. Die Matching-Engine sollte hier read-only sein. Die Queue dient für Entscheidungen und Dokumentation.

Was in ExceptionCases zu speichern ist

Speichern Sie, was falsch ist, wie groß die Abweichung ist, wer zuständig ist und was als Nächstes passiert:

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) plus eine benutzerfreundliche Begründung
• Owner (Person oder Team) und Status (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Variance-Snapshot als sortierbare Zahlen (Rechnungsbetrag, abgeglichener Betrag, Preisdelta, Mengendelta)
• SLA-Felder (Fälligkeitsdatum, Eskalationsflag, reassigned_at, reassignment_reason)

Speichern Sie außerdem Kollaborations- und Auditdaten: Kommentare (Autor, Zeitstempel) und Attachment-Metadaten (Dateiname, Typ, uploaded_by, uploaded_at). Selbst wenn Dateien anderswo liegen, gehören die Metadaten in den Case, damit die Historie intakt bleibt.

Was Finance sehen (und tun) sollte

Die Queue-Ansicht sollte eine kompakte Arbeitsliste sein: Lieferant, Rechnungsnummer, Ausnahme-Typ, Schweregrad, Betrag, Fälligkeitsdatum, Owner und eine klare „Warum geblockt"-Nachricht.

Das Öffnen eines Falls sollte eine Side-by-Side-Zusammenfassung zeigen: PO-Zeilen, empfangene Mengen, Rechnungszeilen und die exakten Felder, die fehlgeschlagen sind.

Begrenzen Sie Aktionen auf sichere, erforderliche Schritte:

• Receipt anfordern (geht an Receiving, setzt Status auf waiting)
• Gutschrift anfordern (geht an den Lieferanten, erfasst erwartete Anpassung)
• Override genehmigen (erfordert Grund, erfasst Genehmiger und Zeitstempel)
• Neuzuweisen (aktualisiert Owner, behält Reassign-Historie)
• Als gelöst schließen (nur nachdem Änderungen den Abgleich bestehen lassen)

Beispiel: Eine Rechnung wird geblockt, weil 8 Einheiten empfangen wurden, aber 10 berechnet sind. Finance kann eine korrigierte Rechnung anfordern oder einen Override für die 8 empfangenen Einheiten genehmigen und die übrigen 2 auf Hold belassen.

Realistisches Beispiel: Teillieferung und eine nicht übereinstimmende Rechnung

Ein Einkäufer erstellt eine PO für 100 Einheiten von Artikel A zu je 10,00. Die PO-Summe beträgt 1.000,00. Zwei Tage später bucht das Lager einen Wareneingang über 80 Einheiten.

Dann kommt eine Rechnung über 100 Einheiten zu je 10,00. Der Abgleich sollte die Rechnungszeilen mit dem vergleichen, was empfangen wurde, nicht nur mit dem, was bestellt wurde.

Auf dieser Zeile:

• Bestellt: 100 Einheiten
• Empfangen: 80 Einheiten
• Fakturiert: 100 Einheiten
• Abgeglichene Menge: min(Empfangen, Fakturiert) = 80 Einheiten
• Nicht abgeglichene Menge: Fakturiert - Abgeglichen = 20 Einheiten

Die Rechnung geht auf "On hold", weil für 20 Einheiten kein Wareneingang existiert. Finance sieht einen Case mit klarem Grund (Mengenabweichung: +20) und den wichtigsten Zahlen nebeneinander.

Benachrichtigungen sollten an die Personen gehen, die das am schnellsten beheben können: üblicherweise den Empfänger (um zu prüfen, ob ein Wareneingang fehlt) und den Einkäufer (um beim Lieferanten nachzufragen, falls die Lieferung tatsächlich fehlt).

Wenn die verbleibenden 20 Einheiten eintreffen, bucht das Lager einen zweiten Wareneingang über 20 Einheiten. Das System läuft erneut: received wird 100, unmatched wird 0, die Rechnung wechselt zu Matched und der Hold wird aufgehoben.

Fügen Sie nun eine Preisabweichung hinzu. Wenn der Lieferant 100 Einheiten zu 10,50 statt 10,00 in Rechnung stellt, stimmt die Menge, aber der Preis nicht. Erwartetes Ergebnis: Rechnung bleibt auf Hold und wird mit einem Grund wie „Price variance: +$0.50/unit (+$50 total)" weitergeleitet.

Häufige Fehler, die Drei-Wege-Abgleich-Workflows kaputtmachen

Die meisten Abgleichfehler sind nicht mathematisch. Sie entstehen durch schwache Datenverknüpfungen und lose Kontrollen über gebuchte Dokumente.

Nur auf Gesamtrechnungssumme abgleichen. Eine Kopfzeile kann korrekt aussehen, während eine Position überteuert oder zu kurz berechnet ist. Führen Sie zeilenbasierten Abgleich durch und legen Sie explizit fest, was abweichen darf (oft Fracht) und was nicht (empfangene Menge und Stückpreis).

Annehmen, dass es eine Empfangs- und eine Rechnung pro PO gibt. In der Realität gibt es Split-Lieferungen und Teilrechnungen. Unterstützen Sie viele Receipts und viele Invoices gegen dieselben PO-Zeilen und verfolgen Sie die verbleibende offene Menge pro Zeile.

Erlauben, gebuchte Receipts oder Invoices ohne Nachweis zu bearbeiten. Wenn jemand Mengen später stillschweigend ändert, verliert der Abgleich seinen Beweischarakter. Sperren Sie gebuchte Datensätze und korrigieren Sie über Anpassungsdokumente, die die Historie erhalten.

Fehlende Duplikat-Prävention. Dieselbe Lieferantenrechnungsnummer kann zweimal erfasst werden oder ein PDF kann von einer anderen Person erneut hochgeladen werden. Führen Sie frühzeitig Unique-Checks ein (vendor + invoice number und optional Datum/Betrag) und zeigen Sie klare Meldungen bei doppelter Erfassung.

Vage Ausnahmegründe. Finance sollte nicht raten müssen. Verwenden Sie Grundcodes, die sauber routen: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch.

Schnell-Checkliste bevor Sie Zahlungs-Blocking aktivieren

Zahlungs-Blocking ist der Punkt, an dem Abgleich vom Reporting zur Kontrolle wird. Wenn die Basics nicht stimmen, erzeugen Sie Lärm für Finance und späte Zahlungen für Lieferanten.

Testen Sie mit einer kleinen Auswahl an Rechnungen, die unterschiedlich aussehen: ein sauberer Match, eine Teillieferung, eine Preisänderung und ein Steuerunterschied. Wenn eine davon nicht sauber abgeglichen werden kann, beheben Sie zuerst Daten und Regeln.

Checkliste:

• Referenz-Vollständigkeit: Jede Rechnung hat einen Lieferanten und eine PO-Referenz, und jede Rechnungszeile kann einer spezifischen PO-Zeile zugeordnet werden (nicht nur „PO-Total"). Entscheiden Sie, was passiert, wenn ein Lieferant nur eine PO-Header-Nummer sendet.
• Konsistente Mathematik: Mengen, Stückpreise und Summen lassen sich jederzeit gleich berechnen. Seien Sie explizit bei Steuern, Fracht, Rabatten und Rundungen (z. B. Runden pro Zeile vs. nur auf Gesamtrechnung).
• Statuses blocken früh genug: Setzen Sie "on hold" bevor ein PaymentRequest oder Payout-Datensatz erstellt wird.
• Strukturierte Ausnahmen: Jeder Hold speichert einen Grundcode und einen Owner (AP, Einkäufer, Empfänger). Fügen Sie Fälligkeitsdaten hinzu, damit Holds nicht ewig liegen bleiben.
• Echter Audit-Trail: Overrides protokollieren, wer genehmigt hat, wann und was genehmigt wurde (inkl. Originalwerte). Wenn Sie Bearbeitungen erlauben, loggen Sie Vor- und Nachwerte.

Nächste Schritte: Pilotieren Sie den Prozess und bauen Sie ihn visuell

Behandeln Sie die Automatisierung des Drei-Wege-Abgleichs wie jede Kontrolle: Beweisen Sie auf einem kleinen Auszug des Spendings, dass sie funktioniert, und rollen Sie dann aus.

Starten Sie mit einem Pilot, der leicht zu überwachen ist. Wählen Sie eine Geschäftseinheit, eine kleine Lieferantengruppe, die saubere Rechnungen sendet, oder eine einzelne Warengruppe. Halten Sie die Regeln anfangs strikt (exakte Übereinstimmung von Menge und Preis), damit Datenqualitätsprobleme schnell sichtbar werden.

Messen Sie den Erfolg mit einer einfachen Finance-Ansicht: Holds pro Woche, Top-Grundcodes, Zeit von Hold bis Freigabe, wie viele Holds echte Abweichungen waren und welche Lieferanten wiederholt Ausnahmen verursachen.

Wenn Sie schnell prototypen wollen, kann eine No-Code-Plattform helfen, weil Sie Tabellen, Abgleichregeln und Routing modellieren können, ohne Code zu schreiben. Zum Beispiel können Sie in AppMaster (appmaster.io) die PO-, Receipt-, Invoice- und Exception-Tabellen bauen und die Hold-Logik in einem visuellen Geschäftsprozess verbinden, sodass dieselben Regeln bei jedem Trigger laufen.

Testen Sie mit echten Rechnungen aus der Pilotgruppe, einschließlich Teillieferungen und gängiger Lieferantenfehler. Erwarten Sie, die Abgleichschlüssel anzupassen und kleine Toleranzen erst nach dem Erkennen von Mustern hinzuzufügen. Sobald die Holds angemessen sind und die Lösungszeiten besser werden, erweitern Sie den Umfang und fügen Sie reichere Regeln hinzu (Steuern und Fracht, Mengeneinheiten-Umrechnungen, Split-Lieferungen), ohne die Kernkontrolle zu verlieren: keine Zahlungsfreigabe, bis der Abgleich geklärt ist.