When an invoice is overdue and no one follows up
You open your inbox: several unanswered confirmations, an overdue invoice, reminders that were sent too late — and no one can quickly say whether a payment has been received. Such everyday situations cost time and cash flow. A simple way to change that is a direct, on‑premise connection between your Debentra system and the internal financial accounting (FiBu) — entirely without a cloud provider.
Why a local connector?
An on‑prem connector links Debentra and your FiBu over the internal network (LAN). Advantages at a glance:
- Full data sovereignty: No third parties, no cloud intermediate storage.
- Direct data exchange: faster detection of payments and less manual rework.
- Fine control: You retain control over approvals, e.g. for payment reminders.
Architecture options – three practical patterns
Choose the appropriate variant depending on existing infrastructure and security policies:
1) SFTP‑based file export
Debentra exports regular CSV/JSON files to an internal SFTP server, which the FiBu software imports automatically.
- Advantages: Easy to implement, compatible with many FiBu tools.
- Disadvantages: Latency due to batch processing (e.g. every 5–15 minutes).
2) Internal webhook over LAN
Debentra sends HTTP POSTs to an internal, protected address that your FiBu receives when events occur (e.g. new open items, payment receipt).
- Advantages: Real‑time notification, lower delay.
- Disadvantages: Requires a continuously reachable endpoint and an authentication layer.
3) Local API bridge (middleware)
A small, self‑hosted bridge reads Debentra exports or API endpoints and transforms the data into the FiBu format; often run in a Docker container.
- Advantages: Maximum flexibility for mapping and validation rules.
- Disadvantages: Increased development effort, but adaptable in the long term.
Preparation: requirements and checks
Before you start, clarify these points:
- What export options does your Debentra system offer? (file export, event webhook, local API)
- Which import methods does your FiBu accept? (SFTP ingest, HTTP API, manual file imports)
- Security policies: VLAN segregation, firewall rules, authentication procedures (SSH key, mTLS, API keys).
- Responsibilities: Who approves payment reminders? Who checks failed transfers?
Practical implementation: step‑by‑step
1. Define the use case and data mapping
Define which events and fields should be transmitted. Typical fields:
- Invoice ID, customer number
- Invoice date, due date
- Open amount, partial payments / installment status
- Payment status and booking reference
- Document IDs or PDF path (for storage in accounting system)
Create a mapping document: Debentra field → accounting field. Add validation rules (e.g., required fields, allowed values for status codes).
2. Example: SFTP configuration (file-based export)
Steps at a glance:
- Create a dedicated system user on the internal SFTP server (e.g., debentra_sync), enforce SSH key authentication.
- Configure Debentra to periodically (e.g., every 5 minutes) place CSV/JSON files with open items into a defined folder on the SFTP.
- Set up an import job in the accounting system that consumes new files, validates them and posts entries. Failed files are moved to a quarantine folder and reported to the team by email.
Practical notes:
- Generate SSH key on the Debentra host: ssh-keygen -t ed25519 -f /var/lib/debentra/keys/debentra_sync
- Enter the public key on the SFTP server into ~/.ssh/authorized_keys of the debentra_sync user.
- Permissions: target folder writable only by debentra_sync, read permission for the accounting system's import process.
3. Example: Internal webhook (real-time over LAN)
Steps:
- The accounting system exposes an endpoint via an internal interface (e.g., http://fibu-internal.local/api/sync).
- Configure Debentra to send payloads to this endpoint via a webhook for defined events.
- Secure the channel: mTLS or a strong API key, IP allowlist and short token lifetimes.
Design tip: Implement idempotent processing in the accounting system (e.g., based on invoice ID) so repeated webhook calls do not create duplicates.
4. Example: Local API bridge (middleware)
Concept:
- Deploy a small bridge app (e.g., Node.js, Python) in your LAN as a Docker container.
- The bridge fetches Debentra exports or API endpoints, maps fields and calls the accounting API or writes files.
- Include logging, retries and a dead-letter queue (DLQ) for error cases.
Example components:
- Scheduler / event listener
- Mapper module with validation
- Transport module (SFTP client, HTTP client with mTLS)
- Monitoring: export statistics and error alerts via email/Teams
Security and operations
- Network: Allow only internal IPs, apply firewall rules at choke points.
- Authentication: SSH keys, mTLS, short‑lived API tokens.
- Logging & retention: Keep export logs and transfer records for at least as long as your internal policies require.
- Backups: Version configurations and mapping templates, archive bridge containers as images.
- Monitoring: Health checks for connector components and automated notifications on errors.
Process integration: retain approvals and control
Even with automation, control remains with the user. Set rules that trigger a manual approval before payment reminders are sent (e.g., for high amounts or disputed items). Debentra allows preparing reminders and sending them to responsible people for approval — your connector solution should forward and respect this approval information.
Error cases and recovery
Plan for common issues:
- Network outage: queuing in the Debentra export or in the bridge, automatic retry.
- Mapping errors: quarantine with notification to the accounting team.
- Duplicates: idempotent processing based on unique IDs.
Short practical example
A medium‑sized company uses Debentra. They choose the SFTP variant: Debentra exports open items as JSON to /outgoing/openitems/ every 10 minutes. A systemd timer on the accounting server pulls new files, validates them and posts automatically or marks them for manual review. For disputed items the file is moved to a quarantine folder and handed over to the team via a ticket. This reduces manual matching work while the accounting department retains full control of the data.
Conclusion
An on‑prem accounting connection between Debentra and your accounting system is technically feasible and improves transparency and process reliability without sending data to external clouds. Choose the architecture (SFTP, internal webhook, local API bridge) to fit your requirements and document mapping, security rules and failure scenarios. Important: automate, but keep approval points for critical actions.
Interested in a solution that unites centralized overview, process control and data sovereignty? Debentra is available as self‑hosted software in the BASIS, PRO and PREMIUM editions — PRO reduces manual matching, PREMIUM offers additional accounting integration. Choose an edition
Next step
Try Debentra yourself
Central overview and process control for open items and payments with full data sovereignty; reduces manual matching work (PRO) and enables integrated accounting (PREMIUM); selectable installation and licensing models.