Escrow: sieben Schritte von "Deal Agreed" zu "Money in the Bank"

Jeder B2B Deal hat einen Moment, in dem eine Seite zuerst gehen muss. Entweder shipped der Seller, bevor er bezahlt ist, oder der Buyer bezahlt, bevor er die Goods gesehen hat. Ohne eine dritte Partei, die das Netz hält, geht jemand ein Risiko ein, das er mit €45,000 fremdem Geld wahrscheinlich nicht eingehen sollte.

Der Escrow Flow ist diese dritte Partei. Es ist kein Third-party Service — es ist Teil der Plattform — aber funktional tut er, was ein Escrow Agent tut: Funds halten, releasen wenn beide Seiten zufrieden sind und adjudicaten, wenn sie es nicht sind.

Die sieben Steps

1. Deal Agreed. Ein Market Deal schließt (negotiation accepted) oder eine Auction settles (winner determined, deposit captured). Der H2 Trigger feuert, wenn der Deal auf closed_won wechselt, und erstellt die Escrow Row, die Deposit Address und eine numbered Escrow ID (ESC-YYYY-NNNNN). Der Buyer erhält eine Payment Request mit IBAN und structured reference.

2. Funds Held. Der Buyer wired die Funds. Die Plattform reconciled den incoming transfer gegen die Escrow Reference, markiert das Escrow als held und notified den Seller. Der Seller sieht nun, dass die Funds confirmed sind, und kann shippen.

3. Goods Shipped. Der Seller shipped. Die H3b Ship-guard verhindert, dass der Seller die Order als shipped markiert, bevor das Escrow held ist — kein "ich habe shipped, dann sagte der Buyer, er zahlt morgen, und dann tat er es nicht" mehr. Tracking hängt an der Order und ist für beide Seiten sichtbar.

4. Goods Received. Der Buyer markiert delivery received. Das startet die Inspection Clock — das Auto-release Window, pro Tenant auf der H7 Policies Page konfiguriert (default: 7 days).

5. Inspection. Der Buyer inspectet. Er hat drei Optionen: accept (Funds früh releasen), nichts tun (Auto-release bei Window Expiry) oder eine Dispute öffnen. Die meisten Cases laufen über Option 2: Der Buyer ist zufrieden, die Clock läuft aus, die Plattform released die Funds.

6. Dispute (if raised). Wenn der Buyer eine Dispute öffnet, pausiert der H4 Auto-release Cron, und der H5 Dispute Flow übernimmt. Der Buyer filed den Claim mit Photos und References zur original Grading. Der Seller antwortet mit seiner Evidence. Ein Adjudicator (platform staff) reviewt und entscheidet: full release to seller, full refund to buyer oder split. Die Decision schreibt Settlement Rows mit dem Fee Snapshot, berechnet vom H6 Fees Engine.

7. Funds Released. Ob durch Acceptance, Auto-release oder Dispute Resolution, der Final State ist derselbe: eine Settlement Row, Fee Deduction, Seller Payout, Buyer Refund (falls applicable) und ein Audit Trail jedes Events in escrow_events. Die Escrow Row wechselt auf released / refunded / split. Der Deal schließt. Beide Seiten gehen weiter.

Was recorded wird

Jede State Transition schreibt eine immutable Row nach escrow_events. Triggers verhindern Updates und Deletes — wenn ein Event landet, bleibt es für Audit dort. Der H9 Evidence-package Endpoint bündelt alle Events für ein Escrow in eine downloadbare ZIP: Timestamps, Amounts, Deposit Reference, Ship-guard Release, Inspection Acceptance, Settlement Breakdown. Wenn der Compliance Officer des Buyers fragt "was ist bei dieser Transaction passiert", ist die Antwort ein Klick.

Mutual waiver

Manche Deals zwischen Long-time Partners wollen kein Escrow. Das H10 Mutual-escrow-waiver PDF ist für diese Cases. Beide Parties signen im Deal Room, der Waiver hängt am Deal, und der Escrow Flow wird für diese eine Transaction bypassed. Es ist die seltene Ausnahme — die Documentation existiert, damit der Escrow Flow überall sonst strict bleiben kann.