Was dieser Service genau ist
Das Angebot ist bewusst zweigeteilt: ClawLedger hält Finanz-, Stamm- und Prozessrealität in ERPNext/Frappe. helpifyr-wire hält providernahe Delivery- und Connector-Logik aus dem ERP-Kern heraus. Genau diese Trennung macht Finance-Automation nachvollziehbar, updatebar und auditierbar.
ClawLedger als ERPNext/Frappe-Backbone
- ERPNext v15 auf isoliertem Stack als kanonisches Ledger- und Stammdatensystem
- Eigene Frappe-App für Revenue Events, Supplier Intake, Approval Packets, Sync Cursor und MCP-Finanztools
- Geeignet für Finance, Buying, Stock, Assets, HR-Grundlage, Subscriptions und approval-sensitive Folgeprozesse
helpifyr-wire als Delivery-Bridge
- Getrennte n8n- und Connector-Schicht für SEPA Submit, Bank Sync, XRechnung Dispatch, ELSTER und Entity Screening
- Provider-spezifische Glue-Logic bleibt aus dem ERP-Kern draußen und wird Git-gesteuert versioniert
- Signed callbacks, Fehlerabbildung und isolierte Laufzeit sorgen für reproduzierbare Delivery statt hidden magic
Wie die ERPNext/Frappe-Schicht praktisch aussieht
Die UI darunter ist kein abstrakter Backend-Block, sondern eine echte ERPNext/Frappe-Oberfläche mit Finance-, Approval- und Dispatch-Kontext. Für die Seite zeigen wir bewusst die zwei Sichtachsen: das ERP-System of Record und die getrennte Delivery-Bridge daneben.
ERPNext/Frappe als Arbeitsoberfläche
Accounts, Selling, Buying, Stock und die zusätzlichen ClawLedger-Objekte wie Revenue Event, Supplier Intake oder Approval Packet sitzen in einer nachvollziehbaren ERP-Oberfläche statt in verstreuten Einzeltools.
helpifyr-wire als getrennte Delivery-Bridge
Die delivery-kritische Connector-Logik lebt separat: Dispatch Job aus ClawLedger, n8n-Workflow, Provider-Aufruf und signierter Callback zurück ins ERP. So bleibt Accounting sauber und Integrationslogik austauschbar.
Was der Service heute schon kann
- Revenue- und Supplier-Flows in ERP-Dokumente überführen, ohne direkte Fremdschreibzugriffe auf Accounting-Tabellen
- OpenClaw-Approval-Pakete und callback-sensitive Finanz- oder Subscription-Prozesse in ERPNext halten
- SEPA, finAPI VoP, Bank Sync, Storecove XRechnung, ELSTER und Aleph Entity Screening über getrennte Delivery-Pfade fahren
Wofür das gedacht ist
- Subscriptions, Revenue Intake und approval-sensitive Rechnungs- oder Zahlungsabläufe
- Supplier Intake, Procurement, strukturierte Rechnungszustellung und regulatorische Dispatch-Wege
- Unternehmen, die KI- oder OpenClaw-nahe Betriebslogik wollen, aber Buchhaltung und Nachweisbarkeit bewusst im ERP halten
Wodurch sich das von generischer ERP-Automation abhebt
ERP first statt Chat first
- Finanzielle Wahrheit bleibt in ERPNext, nicht in Chat-Kontexten oder temporärem Workflow-State
- OpenClaw erklärt und entscheidet, aber ERPNext schreibt die finalen Records
- Append-only Evidence und Approval-Pfade bleiben auditierbar
Getrennte Delivery-Bridge statt ERP-Glue
- Provider- und regulatorische Dispatch-Logik lebt in helpifyr-wire, nicht als unsichtbarer ERP-Anbau
- n8n-Workflows bleiben Git-geführt und per Re-Import reproduzierbar
- Fehlerabbildung, Retry-Politik und signed callbacks sind Teil des Betriebsmodells, nicht Nachgedanke