How this is built
How one firm is kept from another, where portal passwords sit, and what we have not done. Written for the person doing the due diligence.
Accounting firms hold the most sensitive material their clients have. If you are going to keep it in someone else's software, you are entitled to know exactly how it is kept. This page is the honest version, including what we have not done yet.
Every record carries the workspace that owns it, and PostgreSQL row-level security refuses reads and writes across workspaces. This is a database rule, not a filter in the page — a user who reached past the interface and called the API directly would be refused just the same.
We did not take this on trust. It was tested with two live accounts on the real database: a second firm querying the first firm's client list gets nothing back, not an empty page but an empty result set.
| Level | May | May not |
|---|---|---|
| Owner | Everything, including the subscription | — |
| Admin | Everything except billing: settings, custom fields, workload, activity log | Change the subscription |
| Manager | Assign clients, review, approve, archive, see the activity log | Change firm settings |
| Accountant | Edit any client, prepare returns, upload statements, close books | Reassign clients, approve, see the audit log |
| Advisor | Read everything except portal passwords | Change any record at all |
Each of these is a policy in the database. An advisor who tried to write through the API is refused by PostgreSQL, not by JavaScript.
EmaraTax and accounting-software credentials are the sharpest thing in the system, so they are handled differently from everything else:
An append-only audit log records who changed what, on which record, and when — written by the database itself, so it cannot be edited from the application. Managers and admins can read it and export it. It is what you hand an auditor who asks who filed a return and when.
| Encryption | TLS 1.2 or better in transit; AES-256 at rest |
| Hosting | Supabase on AWS, Mumbai, India (AWS ap-south-1) |
| Backups | Automatic daily, with point-in-time recovery. Restores are tested, not assumed. |
| Application delivery | A content security policy pinned to the SHA-256 of the exact application script — a tampered page will not run |
| Authentication | Email and password with a leaked-password check; multi-factor available on every account and required on ours |
| Shared-desk lock | An idle timeout that re-locks the desk with a PIN, for firms where people leave a screen open |
We hold no ISO 27001 or SOC 2 certificate. We are a small Dubai firm and we would rather tell you exactly how the system works than point at a badge. If your procurement requires a certificate, say so early — we would rather know than waste your time.
We also do not offer a contractual uptime guarantee at these prices. What we publish instead is our actual state, at status.
If you believe you have found a vulnerability, email security@accountive.ae. We will acknowledge within one working day and keep you posted until it is closed. We will not take legal action against anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before publishing.