Introduction: When an invoice fails, the process often fails too
You know the situation: an invoice is overdue, reminders are sent late or replies get lost in the email inbox. In such moments it becomes clear how dependent receivables processes are on consistent data. For companies with their own IT infrastructure the responsibility is clear: keeping control of your data also means systematically managing outage risks. This checklist focuses on Backup & Disaster Recovery for your Debentra instance — in short: Debentra Backup DR — and gives IT teams concrete instructions on how dunning runs, open items and all related documents can be restored quickly.
Basic principles in advance
- Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for receivables processes together with Finance and Operations.
- Keep control: automations may create notifications, but approvals for reminders should remain with the user.
- Back up both structured data (database) and unstructured data (invoice PDFs, correspondence, logs) and metadata.
1. Backup strategy: intervals and types
Choose a combination of full backups, incremental backups and transaction-log backups so that you can restore consistently in an emergency.
- Full backup: Regularly create complete backups of the Debentra database and the document store. Frequency depends on business requirements — at least weekly is recommended.
- Incremental backups: Daily or more often, depending on transaction volume. They reduce storage needs and speed up backup jobs.
- Transaction logs: For relational DBMS, back up transaction logs so that point-in-time recovery is possible.
2. Documents and attachments: file system, object storage, metadata
Invoices, proof of payments and email attachments must meet the same recovery objectives as the database.
- Back up documents in their original structure plus exported indexes/metadata (e.g. invoice recipient, open-item ID, amount, status).
- Use versioned object storage or snapshot-capable file systems so you can return to a consistent point in time.
3. Encryption and offsite snapshots
Protect backups from misuse and loss.
- Encrypted snapshots: All offsite snapshots must be stored with server‑side encryption; operate key management separately from the production system.
- Offsite locations: At least one physically separated site or a trusted cloud object store. Ensure encryption at rest and in transit.
- Document key rotation and access rights; test decryption regularly.
4. Recovery Procedures (Runbook)
The runbook is the central working sheet for emergencies. Keep individual, tested steps ready so that a technician can act according to a clear procedure.
Basic Recovery Workflow
- Emergency communication: Notify responsible parties, take services offline in a defined mode (e.g., Debentra in read‑only mode).
- Database restoration: Restore full backup → apply incremental backups → apply transaction logs (point‑in‑time). Document commands/tools per DB type (Postgres, MySQL, etc.).
- Filesystem/object storage: Restore snapshot or recover objects from offsite storage and verify path structure.
- Integrity checks: Perform consistency checks (checksums, record counts, integrity reports from Debentra exports).
- Functional test: Run dunning processes in an isolated environment and check the checklist for open items.
- Handover to the business unit: Finance reviews critical open‑item records; release for productive restart is granted by designated persons.
5. After Recovery: Data Reconciliation and Dunning Runs
After recovery, the focus is on correctly matching payments, partial payments and installment plans so that dunning runs are not sent twice or incorrectly.
- Reconciliation with bank exports: Check which payments were received during the outage and reconcile them manually.
- Lock mechanism for reminders: Set Debentra flags so that reminder templates in the first run are sent only to responsible parties for review.
- Document every recovery action in Debentra logs, including timestamps and responsible persons.
6. Test Scenarios You Should Conduct at Least Biannually
Regular tests are essential. Schedule the following scenarios in separate test environments:
- Full recovery: Restore the complete database and documents into a test instance and simulate an entire dunning run.
- Point‑in‑time recovery: Simulate recovery up to a specific transaction time, e.g. immediately before a failure event.
- Partial restore: Restore only open‑item records for a customer‑segment period and verify that mappings and installment plans are correct.
- Key‑loss recovery: Test the scenario where a backup exists but the access key needs to be rotated.
- Document integrity: Perform a stochastic sample of invoice PDFs: file size, readability, metadata consistency.
7. Monitoring, alerting and roles
Automatic monitoring detects failed backups early.
- Instrument backup jobs: report success/failure, runtime, size, and verification hashes to your monitoring tool.
- Define alerts for failed checksums, expired offsite snapshots or missing transaction logs.
- Assign roles clearly: who is allowed to start recoveries, who approves dunning runs after recovery, and who is responsible for key management.
8. Documentation and change management
Document all processes in writing: backup plans, recovery procedures, test logs and responsibilities. Changes to backup schemas or storage locations must be versioned and approved.
9. Integration with Debentra and edition note
Debentra is designed as self‑hosted software, so you can implement backup and DR strategies fully on your infrastructure and retain data sovereignty. Practical benefits:
- BASIS: Centrally secure core functions and rely on standard recovery processes.
- PRO: Additional automations for mappings reduce manual reconciliation after recovery.
- PREMIUM: Integrated accounting features simplify reconciliation of open‑item data and accounting entries after a restoration.
Use Debentra export functions and APIs to integrate regular data exports into your backup procedures. Note: automated dunning runs should be reviewed and approved after recovery — control remains with the user.
Checklist (short version)
- Define and document RTO/RPO.
- Full backups (weekly), incremental backups (daily/several times daily), transaction‑log backup.
- Back up documents with versioning + export metadata.
- Encrypted offsite snapshots, separate key management.
- Runbook for recovery with clear responsibilities.
- Tests: full restore, point‑in‑time, partial restore, key loss, document integrity (at least semiannually).
- Monitoring & alerts for backup failures and checksums.
- Schedule release routines for dunning runs after recovery.
- Regular documentation and change management.
Conclusion and next step
A robust Debentra instance requires clear backup and recovery processes that treat the database, documents and metadata with equal importance. Plan intervals, encrypted offsite snapshots and tested runbooks so that dunning runs and open items resume reliably and quickly after an outage. Start by defining RTO/RPO and immediately perform a test run in an isolated environment.
Act now: Choose the appropriate Debentra edition and secure your accounts receivable processes. Choose edition
Next step
Try Debentra yourself
Central overview and process control for open items and payments with full data sovereignty; reduces manual allocation work (PRO) and enables integrated accounting (PREMIUM); selectable installation and licensing models.