Security you can read, not just trust.

1. Overview and scope

This paper describes security controls that are built into the Xetuu ERP product and how it is operated. It is written for IT, security and finance leaders who need to understand how the system protects business data.

It describes what the software does. It is not a certification statement: it does not claim any third-party audit or attestation. If your procurement process needs a security questionnaire answered, contact us and we will respond in writing.

2. Tenant isolation

Every customer workspace (tenant) has its own PostgreSQL database. Business data is never stored in the shared platform database. A request is only served after the tenant in the user's signed session is checked against the tenant being addressed.

• Database-per-tenant: one customer's data does not share tables with another's.
• Company scoping: within a tenant, every business query is filtered by the company in the user's session. The company is never taken from the request body.
• Bounded connections: each tenant database uses a small, capped connection pool so one workspace cannot exhaust the database server.
• New workspaces are provisioned by cloning a tested template database.

3. Identity and sessions

Passwords are hashed with bcrypt at cost factor 12 and are never stored or logged in plain text. New sign-ups confirm their email address with a one-time code.

• Access tokens are short-lived (15 minutes). Refresh is session-based: a session lasts up to 7 days with a sliding expiry.
• Administrators set an idle timeout per workspace (default 8 hours, or never).
• Every sign-in creates a session record with device and IP. Users can list their sessions and revoke any device, or sign out everywhere else.
• Rate limiting applies to the API, with much stricter limits on sign-up and verification endpoints.

4. Authorization

Access is role-based. Permissions are named in the form module.resource.action (for example accounting.invoices.post), and every API endpoint is guarded by one.

• Roles are granted sets of permissions; users can belong to groups.
• Access requests and delegated access let administrators grant temporary or scoped access with a record of who approved it.
• The interface hides what a user cannot do, but enforcement happens on the server.

5. Financial integrity and audit

Controls that auditors look for are built into the product rather than left to policy.

• Posted financial documents are immutable. A correction is a second, opposite entry; the original stays visible in the ledger.
• Lock dates close a period for everyone, including API callers.
• The audit log is append-only. Each mutation records user, IP address, before and after values and a timestamp, and the log cannot be edited or deleted through the application.
• Reports drill from a figure to the ledger to the journal entry to the source document.

6. Data protection

The service is accessed over HTTPS. Sensitive credentials that the platform must store, such as payment-gateway keys, are encrypted at rest with AES-256-GCM before they are written to the database, and are only shown through an audited reveal action.

Secrets such as signing keys and database passwords live in server environment configuration, never in the source repository.

7. Application security

• All input is validated against declared fields; requests containing undeclared properties are rejected.
• Database access goes through a parameterised ORM. The application does not build SQL from user input.
• Payment callbacks are verified in layers: a secret in the callback path, the gateway signature, a confirmation call back to the gateway, an amount and currency match, and an atomic once-only transition. Unknown tenants, providers or secrets receive an identical not-found response.
• User-editable formula features run in a restricted evaluator that denies loops, functions and global access.

8. Operations and releases

Changes ship through two environments. Every change is deployed first to a staging server and verified there; only the exact verified build is promoted to production.

• Promotion refuses to run unless staging is healthy and running the exact commit being released.
• Production builds beside the live version, applies database schema changes to every tenant, reloads processes without downtime and rolls back automatically if the health check fails.
• Production servers allow key-based SSH only.

9. Shared responsibility

Xetuu operates the platform and its controls. You decide who has access: create roles with least privilege, review the user list, set the session timeout, and revoke access when people leave. Choose strong passwords and protect the devices people sign in from.

10. What this paper does not cover

This paper does not describe certifications, penetration-test reports or contractual service levels, and a public status page has not been published yet. For those, or for data-residency questions, ask the team. See also our Security & Data Sovereignty and Privacy Policy pages.