Wenn die Rechnung überfällig ist und niemand nachfasst
Eine Rechnung ist überfällig, im Postfach liegt keine Rückmeldung und die Buchhaltung verbringt Zeit mit manueller Zuordnung. Genau hier setzt ein eventgesteuerter Ansatz an: Webhooks melden in Echtzeit, wenn eine Zahlung eingeht, sich eine Mahnstufe ändert oder eine Teilzahlung gebucht wird. Debentra stellt solche Events auf Ihrer eigenen Infrastruktur bereit und ermöglicht so automatisierte, kontrollierte Folgeprozesse in ERP, Ticketing und Monitoring.
Warum Webhooks für das Debitorenmanagement?
Polling erzeugt Verzögerungen und Mehraufwand. Webhooks liefern Ereignisse sofort an Ihre Systeme, reduzieren manuelle Schritte und sorgen für konsistente Dokumentation auf Ihrer Infrastruktur. Wichtig: Bei Debentra bleibt die Kontrolle beim Anwender – insbesondere bei der Freigabe von Zahlungserinnerungen.
Wie Debentra Webhooks liefert (Kurzüberblick)
Debentra sendet HTTP(S) POST‑Requests bei definierten Ereignissen: payment.received, invoice.reminder_level_changed, payment.partial_received u.ä. Die Payloads enthalten strukturierte Felder wie invoice_id, customer_id, amount, paid_amount, due_date und ein event_type. Durch ein klares Mapping dieser Felder in ERP oder Ticketing lassen sich automatische Workflows steuern.
Drei typische Integrationsszenarien
1) Zahlungseingang: Direktbuchung und Ticket‑Schließung
Szenario: Eine Zahlung wurde auf das Konto gebucht. Das ERP soll den offenen Posten automatisch ausbuchen und ein offenes Support‑Ticket schließen.
Beispiel‑Payload (Beispiel für das empfangende System):
{ "event_type": "payment.received", "timestamp": "2026-10-27T09:32:15Z", "invoice_id": "INV-2026-00042", "customer_id": "CUST-1001", "amount_due": 1200.00, "paid_amount": 1200.00, "currency": "EUR", "payment_reference": "SEPA-TRX-12345" }
Empfohlenes Mapping:
- invoice_id → ERP.invoice.number
- customer_id → ERP.customer.accountId
- paid_amount → ERP.payments.amount
- payment_reference → ERP.payments.reference
- timestamp → ERP.payments.date
Typische Reaktion:
- ERP: Automatische Zuordnung und Ausbuchung offener Posten; Zahlungsbeleg erzeugen.
- Ticketing: Wenn ein Mahnticket offen ist, Ticket automatisch mit Kommentar "Zahlung erhalten" schließen.
- Monitoring: Metrik "tägliche Zahlungseingänge" inkrementieren.
2) Mahnstufenwechsel: Freigabe von Erinnerungsvorlagen und Eskalation
Szenario: Eine Rechnung erreicht Mahnstufe 2. Das Mahnwesen soll eine Erinnerung vorbereiten, diese aber zur Kontrolle zunächst als Entwurf in ein Ticket übergeben.
Beispiel‑Payload:
{ "event_type": "invoice.reminder_level_changed", "timestamp": "2026-10-27T10:05:00Z", "invoice_id": "INV-2026-00037", "customer_id": "CUST-1260", "old_level": 1, "new_level": 2, "due_date": "2026-10-01" }
Empfohlenes Mapping:
- invoice_id → Ticket.subject (z. B. "Mahnstufe 2: INV-2026-00037")
- new_level → Ticket.priority oder Tag (z. B. "mahnung:level2")
- due_date → Ticket.due_date
Typische Reaktion:
- Ticketing: Erstelle Entwurfsticket mit Erinnerungsvorlage und Hintergründen; Zuweisung an Sachbearbeiter zur Freigabe.
- ERP/Finanzen: Kennzeichne den Posten zur erhöhten Nachverfolgung; erzeuge eine Mahnkostenberechnung als Attachment.
- Monitoring: Erhöhe Zähler für offene Mahnstufen >1, um Eskalations-Trends zu tracken.
Wichtig: Trotz Automatisierung bleibt die Freigabeentscheidung beim Anwender – die Erinnerung wird nur nach manueller Bestätigung versendet.
3) Teilzahlung / Ratenplan: Kontoauszug und Ratenverwaltung
Szenario: Ein Kunde leistet eine Teilzahlung. Ratenpläne im ERP müssen aktualisiert und offene Restbeträge nachverfolgt werden.
Beispiel‑Payload:
{ "event_type": "payment.partial_received", "timestamp": "2026-10-27T11:20:40Z", "invoice_id": "INV-2026-00081", "customer_id": "CUST-3007", "paid_amount": 400.00, "remaining_amount": 800.00, "installment_plan": { "plan_id": "PLAN-9001", "next_due": "2026-11-27", "installment_amount": 400.00 } }
Empfohlenes Mapping:
- paid_amount → ERP.accounting.partialPayments[]
- remaining_amount → ERP.openItems.amount
- installment_plan.plan_id → ERP.customFields.ratenplanId
- installment_plan.next_due → ERP.customFields.nextInstallmentDate
Typische Reaktion:
- ERP: Aktualisiere Ratenplan, erstelle Folgeverbuchung und Terminerinnerung.
- Ticketing: Kommentar zum ursprünglichen Vorgang mit Zahlungsstatus ergänzen.
- Monitoring: Warnung auslösen, wenn vereinbarte Teilzahlungen nicht fristgerecht erfolgen.
Sicherheits‑ und Retry‑Strategien für on‑prem Deployments
On‑prem bedeutet volle Kontrolle über Angriffsoberfläche und Retry‑Verhalten. Empfohlene Maßnahmen:
- Transportverschlüsselung: Webhooks nur über HTTPS empfangen.
- Authentifizierung & Signatur: Signieren Sie Payloads mit HMAC (z. B. SHA256) und prüfen Sie die Signatur serverseitig. Beispiel HTTP‑Header: X-Debentra-Signature: sha256=....
- Client‑Zertifikate und IP‑Allowlist: Optional für zusätzliche Absicherung zwischen Debentra und Ihren Endpunkten.
- Idempotenz: Jede Payload enthält ein eindeutiges event_id oder webhook_id. Verarbeiten Sie Events idempotent, um doppelte Aktionen zu vermeiden.
- Retry‑Strategie: Implementieren Sie exponentielle Backoff (z. B. 1min, 5min, 20min, 1h) und beschränken Sie die Anzahl der Versuche. Nach X fehlerhaften Zustellversuchen: Dead‑letter Queue und Alarm an Operations.
- Quarantine & Manual Review: Bei fehlerhaften Mappings automatische Kategorisierung in eine manuelle Queue, statt direkte Eskalation.
- Logging & Audittrail: Vollständige Logs der empfangenen Payloads, Signaturprüfung, Verarbeitungsstatus und manueller Eingriffe aufbewahren.
Best Practices für Feld‑Mapping und Namenskonventionen
Ein konsistentes Mapping vermeidet Missverständnisse beim Verarbeiten von Events. Vorschläge:
- Verwenden Sie eindeutige, unveränderliche Schlüssel: invoice_id, customer_id, event_id.
- Nutzen Sie klare Statuswerte: "open", "partial", "paid", "overdue" statt freier Texte.
- Halten Sie Betragsfelder als Dezimalzahlen mit Währung angeben: amount: 1234.56, currency: "EUR".
- Integrieren Sie ein Feld für human_readable_note, das kurze kontextsensitive Hinweise enthält (nicht als Ersatz für strukturierte Felder).
- Dokumentieren Sie das Mapping im internen Wiki, inklusive Beispielen und erwarteten Antwortcodes.
Implementierungsplan in fünf Schritten
- Definieren Sie Events: Wählen Sie initial payment.received, invoice.reminder_level_changed und payment.partial_received.
- Erstellen Sie Endpunkte: HTTPS‑Listener im ERP/Ticketing mit HMAC‑Prüfung und idempotenter Logik.
- Implementieren und testen Sie Payload‑Mappings in einer Staging‑Umgebung.
- Rollout mit Monitoring: Aktivieren Sie Retry‑Mechanismen, Dead‑letter‑Queue und Alarme bei Zustellfehlern.
- Operationalisieren: Regelmäßige Überprüfung von Logs, Anpassung von Mapping/Rules und Schulung der Sachbearbeiter in der Freigabe‑Routine.
Kurzbeispiel: Wie Kontrolle erhalten bleibt
Setzen Sie in Debentra die Regel "reminder.auto_send = false" und konfigurieren Sie Webhook‑Events so, dass bei Mahnstufenwechsel ein Ticket mit Entwurf erzeugt wird. Der Sachbearbeiter prüft die Vorlage, bestätigt den Versand im Ticket und löst damit eine zweite API‑Aktion aus. So bleibt Automatisierung effizient, aber die Freigabeverantwortung beim Anwender.
Fazit
Webhooks machen Fälligkeiten überwachen und Rechnungen nachverfolgen effizient — vorausgesetzt, Sie legen klares Mapping, sichere Übertragung und robuste Retry‑Mechanismen fest. Debentra liefert die on‑prem Events, Ihre Infrastruktur steuert ERP‑Buchungen, Ticketflows und Monitoring‑Signale. Ein gezielter Rollout reduziert manuelle Arbeitsschritte, ohne die Kontrolle über Mahnungsversand oder Buchungen abzugeben.
Handeln Sie jetzt: Wählen Sie die passende Edition, um Integrationstools und Automatisierungsfunktionen zu aktivieren. Edition wählen: https://debentra.de
Nächster Schritt
Debentra selbst ausprobieren
Zentrale Übersicht und Prozesssteuerung für offene Posten und Zahlungen bei vollständiger Datenhoheit; reduziert manuelle Zuordnungsarbeit (PRO) und ermöglicht integrierte Buchhaltung (PREMIUM); wählbare Installations- und Lizenzmodelle.