Wenn eine Rechnung überfällig ist und niemand nachfasst
Sie öffnen Ihr Postfach: mehrere unbeantwortete Bestätigungen, eine überfällige Rechnung, Erinnerungen, die zu spät versendet wurden – und niemand kann schnell sagen, ob eine Zahlung eingegangen ist. Solche Alltagssituationen kosten Zeit und Cashflow. Eine einfache Möglichkeit, das zu ändern, ist eine direkte, on‑premise Anbindung zwischen Ihrem Debentra‑System und der internen Finanzbuchhaltung (FiBu) – ganz ohne Cloud‑Dienstleister.
Warum ein lokaler Connector?
Ein On‑prem‑Connector verbindet Debentra und Ihre FiBu über das interne Netzwerk (LAN). Vorteile im Kurzüberblick:
- Volle Datenhoheit: Keine Drittanbieter, keine Cloud‑Zwischenspeicherung.
- Direkter Datenaustausch: schnellere Erkennung von Zahlungen und geringere manuelle Nacharbeit.
- Feinsteuerung: Sie behalten Kontrolle über Freigaben, z. B. bei Zahlungserinnerungen.
Architekturoptionen – drei praktikable Muster
Wählen Sie die passende Variante je nach vorhandener Infrastruktur und Sicherheitsrichtlinien:
1) SFTP‑basierter Datei‑Export
Debentra exportiert regelmäßige CSV/JSON‑Dateien auf einen internen SFTP‑Server, die FiBu‑Software importiert diese Dateien automatisiert.
- Vorteile: Einfach zu implementieren, kompatibel mit vielen FiBu‑Tools.
- Nachteile: Latenz durch Batch‑Verarbeitung (z. B. alle 5–15 Minuten).
2) Interner Webhook über LAN
Debentra sendet bei Ereignissen (z. B. neue offene Posten, Zahlungseingang) HTTP‑POSTs an eine interne, geschützte Adresse, die Ihre FiBu entgegennimmt.
- Vorteile: Echtzeit‑Benachrichtigung, geringere Verzögerung.
- Nachteile: Erfordert dauerhaft erreichbaren Endpunkt und Authentifizierungslayer.
3) Lokale API‑Bridge (Middleware)
Eine kleine, eigengehostete Bridge liest Debentra‑Exporte oder API‑Endpunkte und transformiert die Daten in das FiBu‑Format; oft in einem Docker‑Container betrieben.
- Vorteile: maximale Flexibilität beim Mapping und bei Validierungsregeln.
- Nachteile: erhöhter Entwicklungsaufwand, dafür langfristig anpassbar.
Vorbereitung: Anforderungen und Prüfungen
Bevor Sie starten, klären Sie diese Punkte:
- Welche Exportmöglichkeiten bietet Ihr Debentra‑System? (Dateiexport, Event‑Webhook, lokale API)
- Welche Importmethoden akzeptiert Ihre FiBu? (SFTP‑Ingest, HTTP API, manuelle Dateiimporte)
- Sicherheitsrichtlinien: VLAN‑Segregation, Firewall‑Regeln, Authentifizierungsverfahren (SSH‑Key, mTLS, API‑Keys).
- Verantwortlichkeiten: Wer genehmigt Zahlungserinnerungen? Wer prüft fehlgeschlagene Transfers?
Praktische Umsetzung: Schritt‑für‑Schritt
1. Use‑Case definieren und Datenmapping
Definieren Sie, welche Ereignisse und Felder übertragen werden sollen. Typische Felder:
- Rechnungs‑ID, Kundennummer
- Rechnungsdatum, Fälligkeitsdatum
- Offener Betrag, Teilzahlungen / Ratenstatus
- Zahlungsstatus und Buchungsreferenz
- Dokument‑IDs oder PDF‑Pfad (zur Ablage in FiBu)
Erstellen Sie ein Mapping‑Dokument: Debentra‑Feld → FiBu‑Feld. Fügen Sie Validierungsregeln hinzu (z. B. Pflichtfelder, zulässige Werte für Statuscodes).
2. Beispiel: SFTP‑Konfiguration (Dateibasierter Export)
Schritte im Überblick:
- Auf dem internen SFTP‑Server einen dedizierten Systemuser anlegen (z. B. debentra_sync), SSH‑Key‑Authentifizierung erzwingen.
- Debentra so konfigurieren, dass es periodisch (z. B. alle 5 Minuten) CSV/JSON mit offenen Posten in einen definierten Ordner auf dem SFTP legt.
- In der FiBu einen Importjob einrichten, der neue Dateien konsumiert, validiert und verbucht. Fehlgeschlagene Dateien werden in einen Quarantäne‑Ordner verschoben und per Mail an das Team gemeldet.
Praktische Hinweise:
- SSH‑Key auf dem Debentra‑Host generieren: ssh-keygen -t ed25519 -f /var/lib/debentra/keys/debentra_sync
- Public Key auf SFTP‑Server in ~/.ssh/authorized_keys des debentra_sync‑Users eintragen.
- Rechte: Zielordner nur für debentra_sync schreibbar, Leserecht für Importprozess der FiBu.
3. Beispiel: Internes Webhook (Echtzeit über LAN)
Schritte:
- FiBu stellt über ein internes Interface (z. B. http://fibu-internal.local/api/sync) einen Endpunkt bereit.
- Debentra konfiguriert einen Webhook, der für definierte Events Payloads an diesen Endpunkt sendet.
- Sichern Sie den Kanal: mTLS oder ein starker API‑Key, IP‑Allowlist und kurze Token‑Lebensdauer.
Designtipp: Implementieren Sie in der FiBu eine idempotente Verarbeitung (z. B. anhand Rechnungs‑ID), sodass wiederholte Webhook‑Aufrufe keine Duplikate erzeugen.
4. Beispiel: Lokale API‑Bridge (Middleware)
Konzept:
- Deployen Sie eine kleine Bridge‑App (z. B. Node.js, Python) in Ihrem LAN als Docker‑Container.
- Bridge ruft Debentra‑Exporte oder API‑Endpunkte ab, mappt Felder und ruft die FiBu‑API auf oder legt Dateien ab.
- Logging, Retries und Dead‑Letter‑Queue (DLQ) für Fehlerfälle einbauen.
Beispiel‑Komponenten:
- Scheduler / Event‑Listener
- Mapper‑Modul mit Validation
- Transportmodul (SFTP Client, HTTP Client mit mTLS)
- Monitoring: Exportstatistiken und Fehleralarme per E‑Mail/Teams
Sicherheit und Betrieb
- Netzwerk: Nur interne IPs zulassen, Firewall‑Regeln auf Engstellen anwenden.
- Authentifizierung: SSH‑Keys, mTLS, kurzlebige API‑Tokens.
- Logging & Aufbewahrung: Export‑Logs und Transferprotokolle mindestens so lange aufbewahren, wie Ihre internen Policies vorsehen.
- Backups: Konfigurationen und Mapping‑Templates versionieren, Bridge‑Container als Image archivieren.
- Überwachung: Health‑Checks der Connector‑Komponenten und automatisierte Benachrichtigung bei Fehlern.
Prozessintegration: Freigaben und Kontrolle behalten
Selbst mit Automatisierung bleibt die Kontrolle beim Anwender. Setzen Sie Regeln, die eine manuelle Freigabe auslösen, bevor Zahlungserinnerungen versendet werden (z. B. bei hohen Beträgen oder strittigen Posten). Debentra ermöglicht es, Erinnerungen vorzubereiten und zur Freigabe an verantwortliche Personen zu senden — Ihre Connector‑Lösung sollte diese Freigabeinformation weiterleiten und respektieren.
Fehlerfälle und Recovery
Planen Sie für typische Probleme:
- Netzwerkausfall: Queuing im Debentra‑Export oder in der Bridge, automatischer Retry.
- Mapping‑Fehler: Quarantäne mit Benachrichtigung an das Buchhaltungsteam.
- Duplikate: Idempotente Verarbeitung anhand eindeutiger IDs.
Praxisbeispiel kurz
Ein mittelständisches Unternehmen setzt Debentra ein. Sie wählen die SFTP‑Variante: Debentra exportiert alle 10 Minuten offene Posten als JSON in /outgoing/openitems/. Ein systemd‑Timer auf dem FiBu‑Server zieht neue Dateien, validiert sie und bucht automatisch oder markiert zur manuellen Prüfung. Bei strittigen Posten wird die Datei in einen Quarantäneordner verschoben und per Ticket an das Team übergeben. So sinkt die manuelle Zuordnungsarbeit und die FiBu behält die volle Datenkontrolle.
Fazit
Eine on‑prem‑Buchhaltungsanbindung zwischen Debentra und Ihrer FiBu ist technisch gut machbar und verbessert Transparenz sowie Prozesssicherheit, ohne Daten in fremde Clouds zu geben. Wählen Sie die Architektur (SFTP, interner Webhook, lokale API‑Bridge) passend zu Ihren Anforderungen und dokumentieren Sie Mapping, Sicherheitsregeln und Ausfallszenarien. Wichtig: Automatisieren, aber Freigabepunkte für kritische Aktionen behalten.
Interessiert an einer Lösung, die zentrale Übersicht, Prozesssteuerung und Datenhoheit vereint? Debentra ist als Self‑hosted Software verfügbar in den Editionen BASIS, PRO und PREMIUM — PRO reduziert manuelle Zuordnungen, PREMIUM bietet zusätzliche Buchhaltungsintegration. Edition wählen
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.