Security and Data Protection

Controls in the platform

• Authenticated access. Pages and data operations run behind verified sessions; the browser never receives database credentials.
• Role-based permissions. Access rights are assigned per user, per client company, and per module.
• Client-level data isolation. Business tables carry tenant and client identifiers enforced by row-level security on active membership.
• Immutable posted records. Posted journal headers and lines cannot be edited; corrections are made through opposite entries.
• Approval and reversal controls. Posting is serialized and idempotent, with controlled reversals instead of deletions.
• Audit event tracking. Audit records capture actor, action, entity, request, and before and after state.
• Separate PH and SG environments. Each country operates as its own deployment with its own sign-in address.

Separation between countries

The Philippine and Singapore systems are separate deployments. Each has its own database and its own sign-in address, and a client workspace belongs to exactly one of them. A user signed in to one does not thereby have access to the other.

Isolation between clients

Within a deployment, every business table carries tenant and client identifiers, and row-level security policies in the database restrict reads and writes to the clients a signed-in user is an active member of. These policies are enforced by the database itself rather than by application code alone, and the application connects using a restricted role that cannot bypass them.

Integrity of posted records

Posted journal headers and lines are immutable. Database triggers reject journals that do not balance, that carry fewer than two lines, or that carry no value. Repeated posting requests for the same source document are serialized and deduplicated, so a retry cannot double-post. Corrections are made by posting an opposite entry, never by editing or deleting the original.

Audit trail

Audit events record the actor, the action, the entity affected, the originating request, and the before and after state. Login history and activity logs are available to administrators.

What we do not claim

We hold no security certification for this platform and make no claim of one. We do not describe it as compliant with any standard that has not been formally assessed. Where a control is described above, it is because it exists in the system; where a claim is absent, that absence is deliberate.

Reporting a concern

If you believe you have found a security problem, please write to us before disclosing it publicly, and allow reasonable time for a fix.