Wenn eine Rechnung im Postfach untergeht — und Liquidität plötzlich sichtbar wird
Sie kennen das: Eine Rechnung ist überfällig, niemand hat nachgefasst, Erinnerungen kommen verspätet oder Antworten gehen im allgemeinen E‑Mail-Postfach verloren. In kleinen und mittleren B2B‑Unternehmen entsteht so schnell ein blinder Fleck für die kurzfristige Liquidität. Ein strukturierter Offene‑Posten‑Workflow schafft Transparenz – und wenn Sie diesen Workflow mit einem On‑Premises‑Monitoring koppeln, lassen sich kritische Fälligkeiten automatisiert und lokal überwachen, bevor sie zu Engpässen werden.
Worum es konkret geht
Dieser Beitrag zeigt praxisnah, wie Sie Debentra so einrichten, dass zentrale Kennzahlen zu offenen Posten an einen Prometheus‑Stack geliefert werden und Alertmanager automatisierte Benachrichtigungen an Buchhaltung und IT auslöst. Zwei konkrete Vorteile stehen im Mittelpunkt:
- Frühzeitige Liquiditätsalarme: Benachrichtigungen bei drohenden Engpässen oder ungewöhnlich vielen überfälligen Posten.
- Volle Datenhoheit: Die gesamte Überwachung läuft auf Ihrer Infrastruktur, Zugriff und Freigaben der Erinnerungen bleiben kontrolliert beim Anwender.
Voraussetzungen und Architekturüberblick
Benötigt werden:
- Eine Debentra‑Instanz auf Ihrer Infrastruktur (Self‑hosted).
- Ein On‑Premises Monitoring‑Stack: Prometheus zum Sammeln von Metriken, Alertmanager für das Routing von Alarmen. Optional: Grafana zur Visualisierung.
- Netzwerkzugriff zwischen Prometheus und der Debentra‑Instanz oder Zugriff auf einen Pushgateway, falls Push‑Mechanik genutzt wird.
Architekturvarianten:
- Prometheus‑Scrape: Debentra stellt eine Prometheus‑kompatible Metrik‑Endpoint (z. B. /metrics) bereit, Prometheus fragt periodisch die Metriken ab.
- Pushgateway: Debentra pusht Metriken an einen Pushgateway, den Prometheus abfragt. Diese Variante ist sinnvoll, wenn Debentra hinter restriktiven Firewalls läuft oder Scraping nicht möglich ist.
Schritt 1 — Metriken auswählen: Was Sie wirklich brauchen
Konzentrieren Sie sich zunächst auf zwei bis drei Kennzahlen, die direkten Einfluss auf Entscheidungen der Buchhaltung haben:
- Anzahl offener Rechnungen (nach Fälligkeitskategorie).
- Gesamtbetrag der offenen Posten (Summen nach Fälligkeit oder Kundensegment).
- Anzahl bzw. Betrag der in Kürze fälligen Rechnungen (z. B. Fälligkeit innerhalb 3–7 Tagen).
Debentra kann diese Kennzahlen als Prometheus‑kompatible Metriken ausliefern; typische Bezeichner könnten z. B. debentra_open_invoices_total und debentra_open_amount_cents sein. Passen Sie Metriken und Labels an Ihre internen Klassifizierungen (z. B. Kunde, Buchungskreis, Mahnstufe) an, damit Alerts aussagekräftig sind.
Schritt 2 — Prometheus konfigurieren
Wenn Debentra einen /metrics‑Endpoint bereitstellt, fügen Sie in Prometheus einen scrape_job hinzu. Beispielkonzept (an Ihre Umgebung anpassen):
scrape_configs:
- job_name: "debentra"
static_configs:
- targets: ["debentra-internal-host:PORT"]
Alternativ konfigurieren Sie einen Pushgateway: Debentra pusht regelmäßig oder ereignisgesteuert die aktuellen Kennzahlen an den Pushgateway, den Prometheus dann abfragt. Wählen Sie den Mechanismus, der zu Ihrer Netzwerktopologie passt.
Schritt 3 — Alerts formulieren (PromQL‑Beispiele)
Formulieren Sie aussagekräftige Alerts, die bei echten Risiken auslösen. Hier drei praktikable Beispiele als Vorlage (Begriffsnamen als Beispiele):
- Hohe Summe überfälliger Posten: sum(debentra_open_amount_cents{age=">30d"}) > 5000000
- Viele überfällige Rechnungen: sum(debentra_open_invoices_total{age=">14d"}) > 20
- Zunahme kurz bevorstehender Fälligkeiten: increase(debentra_open_amount_cents{due="<=3d"}[24h]) > 1000000
Diese PromQL‑Ausdrücke sind Beispiele; passen Sie Schwellenwerte an Ihre Umsatzgrößenordnungen und Risikopräferenzen an. Legen Sie zudem jeweils eine minimale Dauer (for:) fest, damit kurzfristige Schwankungen keine Flut von Fehlalarmen auslösen.
Schritt 4 — Alertmanager & Routing
Richten Sie in Alertmanager Routing‑Regeln nach Verantwortungsbereich ein:
- Finanz‑Alerts → E‑Mail/Slack/Teams an Buchhaltung; erhöhte Transparenz mit Direktlink zur relevanten Debentra‑Ansicht.
- Infrastruktur‑Alerts (z. B. fehlende Metriken, Erreichbarkeit Debentra) → IT‑Ops.
- Escalation‑Policy: Wenn Alarm nach definierter Zeit keine Bestätigung erhält, eskaliert er an Team‑Leads.
Wichtig: Alerts sollten Informationen enthalten, die eine rasche Einordnung erlauben (Summe, Anzahl, betroffene Kundensegmente, Link zur Debentra‑Transaktion). So kann die Buchhaltung entscheiden, ob eine Erinnerung freigegeben wird – die Kontrolle bleibt beim Anwender.
Integration in operative Abläufe
Ein Monitoring‑Alarm ist kein automatisches Mahnschreiben. Ideal ist folgender Ablauf:
- Alert schlägt bei Überschreitung der Schwelle an → Benachrichtigung an Buchhaltung + IT.
- Buchhaltung prüft in Debentra den Kontext (Teilzahlungen, Ratenpläne, offene Klärfälle) und entscheidet über die Freigabe einer Erinnerung.
- Bei Freigabe: Debentra erstellt und sendet die Erinnerung; der Vorgang wird in Debentra dokumentiert.
So bleibt trotz technischer Automatisierung die Freigabehoheit beim Menschen – gemäß Ihrer Compliance‑Anforderungen.
Mehrwert durch Debentra‑Editionen
Debentra ist in drei Editionen verfügbar. Für das beschriebene Szenario sind zwei Punkte relevant:
- PRO: Reduziert manuelle Zuordnungsarbeit, wodurch die Metriken sauberer und damit aussagekräftiger werden. Saubere Daten verbessern die Qualität der Alerts.
- PREMIUM: Integrierte Buchhaltungsfunktionen liefern zusätzliche Kontext‑Metriken (z. B. Zahlungsabgleich, Ratenpläne), die Sie ebenfalls in Prometheus‑Alerts einbeziehen können.
Welche Edition zu Ihnen passt, hängt davon ab, wie tief Sie die Überwachung in Ihre Finanzprozesse integrieren möchten.
Praktische Tipps für den Betrieb
- Starten Sie mit konservativen Schwellenwerten und verkleinern Sie die Alarmintervalle, wenn Sie Routine haben.
- Nutzen Sie Labels (z. B. buchungskreis, kundengruppe), damit Sie gezielte Alerts für hohe Risiko‑Segmente definieren können.
- Sichern Sie Netzwerkzugänge zwischen Monitoring und Debentra verschlüsselt und mit eingeschränkten Zugriffsrechten.
- Dokumentieren Sie die Reaktions‑ und Eskalationswege für jeden Alert‑Typ, damit Buchhaltung und IT wissen, wer wann handelt.
Kurze Checkliste vor dem Go‑Live
- Prometheus kann Debentra erreichen (Scrape oder Pushgateway) und sammelt die erwarteten Metriken.
- Alertmanager hat passende Routing‑Regeln und Kontaktziele konfiguriert.
- Die Buchhaltung hat Prüfabläufe definiert und weiß, wie Erinnerungen in Debentra freigegeben werden.
- Dashboards in Grafana zeigen die wichtigsten Kennzahlen für tägliche Lagebilder.
Fazit: Früher informieren, Entscheidungen behalten
Die Verbindung von Debentra mit einem On‑Premises Monitoring‑Stack wie Prometheus und Alertmanager verschiebt die Informationskurve nach vorne: Statt plötzlich auf Liquiditätsengpässe zu reagieren, erhalten Buchhaltung und IT frühzeitige, aussagekräftige Hinweise. Entscheidend bleibt dabei die Kontrolle beim Anwender – Alerts sind Entscheidungshilfen, nicht automatische Mahnläufe. Nutzen Sie die PSA‑Funktionalitäten der Debentra‑Editionen (PRO für bessere Zuordnung, PREMIUM für tiefer integrierte Buchhaltung), um die Qualität Ihrer Metriken zu erhöhen und damit verlässlichere Alarme zu erhalten.
Jetzt handeln: 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.