Skip to content
Bella Pre-Accounting
TR

Your data stays yours

Financial records are the most sensitive data a business holds. This product was designed to keep that data in your own database rather than in a shared cloud pool.

Every customer runs in their own installation

You are not separated from other companies by a row filter inside one shared database. Each business has its own database, its own application process and its own backups. This removes the possibility of data mixing by design: a badly written query cannot reveal another company’s records, because those records are not in the same database.

  • Can be installed on your own server — database and backups stay with you
  • If you run several companies, each gets its own installation
  • If you would rather not run a server, hosting is available — your choice

Permissions are per action, not per screen

Users are granted individual actions rather than broad roles: "view invoices", "approve invoice" and "cancel invoice" are separate permissions. A user who can draft an invoice may not be allowed to approve it.

  • Action-level permissions, enforced on the server and hidden in the interface
  • Two-factor authentication (TOTP) with recovery codes
  • Account lockout after 5 failed attempts; rate limiting on sign-in endpoints

Who changed what, and when

Every change is written to the audit trail: which user, which field, with the old and new value. Deleted records are not physically removed; they are marked and hidden from lists, so history remains queryable.

  • Field-level change record (old value → new value)
  • A separate security log: sign-in attempts, session and device events
  • Approved documents cannot be changed at all; a cancellation reason leaves a permanent trace

An approved invoice cannot be edited

In most pre-accounting software the amount on a finalised invoice can still be corrected afterwards. Here it cannot: the server rejects any update to an approved invoice. Approval and cancellation are separate endpoints from the update endpoint, so there is no path that lets a "save" button touch a finalised document. The only way to correct one is to cancel it and issue a new invoice, and a cancellation reason is mandatory — what remains in the ledger is not just what changed, but who changed it and why.

  • Updates to an approved invoice are rejected server-side; approval and cancellation are separate endpoints
  • A cancellation reason is mandatory; a cancelled invoice cannot be deleted either — it stays as a reversing trace
  • Document numbers are unique at the database level: if two concurrent writes produce the same number, the second is rejected
  • Header and line items are written in a single transaction — no half-written invoice
  • A closed period is locked: no record can be added to or removed from it

Data protection and where the data sits

Data localisation here is not a promise but a consequence of the architecture: when the installation is on your server, financial records are never copied anywhere we can reach. Access to contact records holding personal data is written to a separate security log, and a deleted record is marked rather than physically removed — which is what lets you manage the gap between a retention obligation and an erasure request.

  • The data is in your database; if you host it yourself, we hold no copy
  • Sign-in attempts, denied access and session events are recorded together with the IP address
  • Two-factor authentication (TOTP) and recovery codes; account lockout after 5 failed attempts
  • Deletion is a flag: the record leaves the lists while the audit trail and history stay queryable
  • Backup and restore procedures are provided in writing in YEDEKLEME.md

A backup counts only if it restores

Backup and restore procedures are provided in writing with the installation: a scheduled backup task, a retention recommendation and — most importantly — a restore drill. An untested backup is not a backup.

  • Backup and restore commands for local and Docker installations
  • Scheduled task example and retention policy recommendation
  • A permanent archive backup recommended at each period close

What we do not claim

  • We hold no independent security certification (ISO 27001, SOC 2).
  • We have no penetration test report; security controls are applied at design and code level.
  • Encryption at rest depends on your operating system and database configuration; the application does not encrypt individual fields.
  • Regulatory compliance is not a software feature; the product provides audit trails and access control, the process stays with you.

Request a demo

See the product with your own data. Fill in the form and we will get back to you.

Request a demo