When the invoice is overdue and no one follows up
An invoice is overdue, there is no response in the inbox, and accounting spends time on manual allocation. This is precisely where an event-driven approach comes in: webhooks notify in real time when a payment is received, a dunning level changes, or a partial payment is booked. Debentra exposes such events on your own infrastructure and thus enables automated, controlled follow-up processes in ERP, ticketing and monitoring.
Why webhooks for receivables management?
Polling creates delays and extra effort. Webhooks deliver events immediately to your systems, reduce manual steps and ensure consistent documentation on your infrastructure. Important: With Debentra control remains with the user — particularly regarding the approval of payment reminders.
How Debentra delivers webhooks (brief overview)
Debentra sends HTTP(S) POST requests on defined events: payment.received, invoice.reminder_level_changed, payment.partial_received, etc. The payloads contain structured fields such as invoice_id, customer_id, amount, paid_amount, due_date and an event_type. By mapping these fields clearly into ERP or ticketing, automated workflows can be controlled.
Three typical integration scenarios
1) Payment received: direct posting and ticket closure
Scenario: A payment has been posted to the account. The ERP should automatically clear the open item and close an open support ticket.
Example payload (example for the receiving 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" }
Recommended 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
Typical reaction:
- ERP: Automatic allocation and clearing of open items; generate payment receipt.
- Ticketing: If a dunning ticket is open, automatically close the ticket with the comment "Payment received."
- Monitoring: Increment the metric "daily incoming payments."
2) Dunning level change: approval of reminder templates and escalation
Scenario: An invoice reaches dunning level 2. Collections should prepare a reminder, but first hand it over as a draft into a ticket for review.
Example 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" }
Recommended mapping:
- invoice_id → Ticket.subject (e.g. "Reminder level 2: INV-2026-00037")
- new_level → Ticket.priority or tag (e.g. "reminder:level2")
- due_date → Ticket.due_date
Typical response:
- Ticketing: Create a draft ticket using the reminder template and background information; assign to the responsible agent for approval.
- ERP/Finance: Mark the item for increased follow-up; generate a dunning fee calculation as an attachment.
- Monitoring: Increment counters for open reminder levels >1 to track escalation trends.
Important: Despite automation, the approval decision remains with the user — the reminder will only be sent after manual confirmation.
3) Partial payment / installment plan: account statement and installment management
Scenario: A customer makes a partial payment. Installment plans in the ERP must be updated and outstanding balances tracked.
Example 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 } }
Recommended 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
Typical response:
- ERP: Update the installment plan, create a follow-up posting and schedule a reminder.
- Ticketing: Add a comment to the original case with the payment status.
- Monitoring: Trigger an alert if agreed partial payments are not made on time.
Security and retry strategies for on‑prem deployments
On‑prem means full control over the attack surface and retry behavior. Recommended measures:
- Transport encryption: Receive webhooks only over HTTPS.
- Authentication & signature: Sign payloads with HMAC (e.g. SHA256) and verify the signature server‑side. Example HTTP header: X-Debentra-Signature: sha256=....
- Client certificates and IP allowlist: Optional for additional hardening between Debentra and your endpoints.
- Idempotence: Each payload contains a unique event_id or webhook_id. Process events idempotently to avoid duplicate actions.
- Retry strategy: Implement exponential backoff (e.g. 1min, 5min, 20min, 1h) and limit the number of attempts. After X failed delivery attempts: dead‑letter queue and alert to operations.
- Quarantine & manual review: For faulty mappings, automatically categorize into a manual queue instead of immediate escalation.
- Logging & audit trail: Retain full logs of received payloads, signature verification, processing status and manual interventions.
Best practices for field mapping and naming conventions
A consistent mapping avoids misunderstandings when processing events. Suggestions:
- Use unique, immutable keys: invoice_id, customer_id, event_id.
- Use clear status values: "open", "partial", "paid", "overdue" instead of free text.
- Keep amount fields as decimals and specify currency: amount: 1234.56, currency: "EUR".
- Include a field for human_readable_note that contains short context‑sensitive hints (not a substitute for structured fields).
- Document the mapping in the internal wiki, including examples and expected response codes.
Implementation plan in five steps
- Define events: Initially choose payment.received, invoice.reminder_level_changed and payment.partial_received.
- Create endpoints: HTTPS listeners in ERP/Ticketing with HMAC verification and idempotent logic.
- Implement and test payload mappings in a staging environment.
- Rollout with monitoring: Enable retry mechanisms, dead‑letter queue and alerts on delivery failures.
- Operationalize: Regularly review logs, adjust mappings/rules and train operators on the approval routine.
Short example: How control is maintained
Set the rule "reminder.auto_send = false" in Debentra and configure webhook events so that a draft ticket is created when the dunning level changes. The caseworker reviews the template, confirms sending in the ticket and thereby triggers a second API action. This keeps automation efficient while leaving approval responsibility with the user.
Conclusion
Webhooks make monitoring due dates and tracking invoices efficient — provided you define clear mapping, secure transmission and robust retry mechanisms. Debentra provides the on‑prem events, your infrastructure controls ERP postings, ticket flows and monitoring signals. A targeted rollout reduces manual steps without relinquishing control over dunning dispatch or postings.
Act now: Choose the appropriate edition to enable integration tools and automation features. Select edition: https://debentra.de
Next step
Try Debentra yourself
Central overview and process control for open items and payments with full data sovereignty; reduces manual reconciliation work (PRO) and enables integrated accounting (PREMIUM); selectable installation and licensing models.