Two-factor sign-in
Two-factor authentication can be required per user, with single-use recovery codes stored encrypted.
Security
Controls you can verify.
This page describes how the application actually protects financial data — the sign-in protections, the permissions model, the records kept of what happened, and how data is kept apart between organizations.
- Two-factor sign-in per user
- Permissions and approval rules
- Audit logging and backup administration
Access
Controls on who gets in and what they may do.
Access is decided per user and enforced by the application, not by convention.
Password policy
Passwords must meet a minimum length with upper-case, numeric and non-alphanumeric requirements, and can be forced to change.
Account lockout
Repeated failed sign-in attempts lock the account for a cooling-off period instead of allowing unlimited guessing.
Roles and permissions
Users hold a role and module-level permissions, and the pages a user may reach are limited to those grants.
Approval rules
Approval rules can require a second approval before an entry is accepted into the books.
Session handling
Authenticated sessions expire on a timeout, and a user can be signed out by policy rather than by closing a browser.
Records
The application keeps the history.
Reviews, audits and disputes all need the same thing: a record of what happened, produced by the system rather than by memory.
| Record | What it holds | Where it is used |
|---|---|---|
| Audit log | Changes and actions with the user, entity and time | Reviewing how a figure or record reached its current state |
| Authentication events | Sign-in activity including failures, lockouts and two-factor steps | Spotting credential problems early |
| Login activity and sessions | Active sessions and their lifecycle | Managing access when people change roles or leave |
| Backup records | Each backup run and its outcome | Proving that a restore point exists before it is needed |
The records above are application features, not certifications. No security certification or external audit statement is claimed anywhere on this site.
Questions
Security questions.
Where is our financial data held?
The application runs against its own database on the deployment you choose. Data stays in that deployment, licence activation binds the installation to it, and it is never pooled with other organizations’ data.
Can we restrict a user to only some modules?
Yes. Permissions are granted per user and per module, so an assistant can be limited to entries and invoicing while an auditor holds read-only reporting access.
Do you publish a penetration test report or compliance certificate?
No, and we will not imply one. What we publish is a description of the controls the application implements — listed above — and we will answer specific technical questions about your deployment directly.
This page describes application behaviour that is present in the product. It makes no claim about hosting providers, third-party audits or certifications, and it is not a substitute for your own security review.
Next step
See it against your own books.
Tell us how your books are kept today and we will show the modules that match — accounting, invoicing, banking, inventory, payroll, fixed assets and reporting.