Enterprise Security Without the Enterprise Bill

Most ERP vendors treat security as a sales lever. The controls that actually protect your financial data — hardened authentication, audit logging, fine-grained permissions — get fenced off behind an "Enterprise" tier that costs several times the base plan. The message is unsubtle: pay up, or run your books on the insecure version. LedgerQ rejects that framing. The controls below aren't add-ons or upsells. They're how the platform is built, for every tenant, on day one. A quick note on honesty, too: this post describes the mechanisms LedgerQ actually implements — token lifetimes, RBAC, audit trails, tenant isolation, encryption — not a wall of compliance badges. Real controls beat claimed certifications.

In summary: LedgerQ ships the security controls that protect financial data to every tenant, not just the top plan: 15-minute access tokens with httpOnly refresh cookies, bcrypt-hashed passwords, granular role-based access with segregation of duties, complete audit trails, soft delete, optimistic locking, encryption of secrets at rest, and structural tenant isolation that returns nothing — never another company's data — when a filter is missing.

What makes LedgerQ's authentication hard to steal?

Authentication is the front door, and the way most apps hold it open is a long-lived session token. Steal it once and you're in for weeks. LedgerQ uses a custom JWT scheme split into two parts: a 15-minute access token and a 30-day refresh token. The access token is what actually authorizes a request, and it goes stale almost as fast as you can read this paragraph. If one leaks — from a logged URL, a compromised device, a misconfigured proxy — the window of exposure is minutes, not weeks. That short lifetime is the single most effective way to shrink the blast radius of a stolen credential.

The refresh token keeps people logged in without re-typing passwords all day, but it lives in an httpOnly cookie, which means JavaScript on the page can't read it — closing off the most common token-theft path (a cross-site script scraping storage). Passwords themselves are hashed with bcrypt, never stored in the clear, so even a database compromise doesn't hand an attacker usable passwords. And the login endpoint is rate-limited, so nobody can sit there machine-gunning credential guesses. None of this is exotic. It's just done correctly, by default, for everyone.

How do permissions mirror how your team actually works?

The principle is simple: nobody should be able to do something their job doesn't require.

Role-Based Access Control (RBAC) in LedgerQ is granular — permissions are defined per module and per action, not as a blunt "admin or not." A sales clerk can create orders without touching the general ledger. An AP specialist can enter bills without approving them. Role templates let you stand up consistent roles across the org instead of hand-assigning permissions one user at a time and hoping you got it right — which is exactly how permission sprawl and accidental over-access creep in.

Pair that with segregation of duties (SoD) enforced through approval workflows, and you get the control auditors look for first. The person who creates a payment isn't the person who approves it. The person who drafts a journal entry isn't the one who posts it — in the general ledger, an entry's own creator is blocked from posting it, in code, not policy. SoD is what stops a single compromised account — or a single dishonest employee — from running a transaction end to end with nobody watching. It's the difference between "we trust our people" and "we don't have to rely on trust alone." These same gates are what let Sebee, the AI CFO, propose entries safely — the AI approves nothing itself; its proposals route through the human approval chain like everyone else's.

Why does financial data integrity need more than a database?

A ledger isn't a to-do list. You can't just overwrite rows and move on, because next quarter someone will ask what did this number look like in March, and who changed it? LedgerQ answers that with three layers that work together.

• Audit trails. Every create, update, and delete is recorded with the user who did it and the timestamp. This is the SOX-style "who changed what, and when" history regulators and external auditors expect — built into the platform, not reconstructed after the fact from server logs.
• Soft delete. Nothing is ever truly destroyed. A "deleted" record is marked, not erased, so historical data and the relationships that depend on it stay intact. You can't accidentally — or maliciously — vaporize a year of transactions.
• Optimistic locking. Every record carries a version number. If two people open the same invoice and both try to save, the second write is rejected instead of silently clobbering the first. Concurrent edits can't quietly corrupt a balance.

Together these mean your financial history is durable and attributable. That's not a nice-to-have for a system of record — it's the whole point of one. It's also why the authoritative ledger can be trusted as the single source of truth: the history behind every posted number is intact and attributable.

Is tenant isolation actually a security guarantee, or just a diagram?

When one platform serves many companies, the scariest failure isn't downtime — it's Company A seeing Company B's books. Plenty of products treat multi-tenancy as an architecture footnote. LedgerQ treats it as a security property that has to be true on every single request.

Every query is filtered by company. The tenant context is validated on each request, not assumed from a stale session. And crucially, the design fails safe: the default for a missing filter is to return nothing, not everything. There's no "be careful not to leak" convention for a developer to forget, because the isolation is structural — the tenant filter is injected at the data-access layer, and cross-tenant isolation is exercised as a first-class test rather than left as a hope. For a CTO doing diligence, that's the distinction that matters: isolation you can point at in the architecture, not a promise in a sales deck.

What protects secrets, uploads, and exports?

Beyond the front door and the row-level guarantees, a system of record has to protect the sensitive material around the edges:

• Encryption at rest for secrets. Sensitive settings — integration keys, credentials — are encrypted, not sitting in plaintext columns, and they're masked when displayed so a stored secret isn't casually readable over someone's shoulder or in a screenshot.
• Hardened file uploads. Uploaded documents are validated by their actual content (magic bytes) and re-encoded rather than trusted by filename, and they're served through an authenticated proxy — not exposed on a public static path — so an upload can't smuggle in something executable or leak to anyone with the URL.
• Export logging. Every export of your core financial statements is recorded to a report audit trail, so there's a defensible record of who pulled what data — the kind of trail SOX and regulatory reviews ask for.
• GL posting controls. Entries can only hit authorized accounts through the account-assignment layer, preventing the off-book postings that derail a clean audit.

Why shouldn't this be a premium upsell?

Here's the thing that should bother every buyer: the features in this post are the ones that protect your money and your reputation, and the industry has spent years teaching customers to expect them locked behind the most expensive plan. That's backwards. Short-lived tokens, real RBAC, segregation of duties, full audit trails, durable financial history, encrypted secrets, and bulletproof tenant isolation aren't luxuries for the few who can afford them — they're the baseline a financial system owes everyone who trusts it with their books. In LedgerQ, that baseline is just included.

Frequently asked questions

Does LedgerQ store my password? Not in a readable form. Passwords are hashed with bcrypt and never stored in plaintext, so even a database compromise doesn't expose usable passwords. Sessions use a short-lived 15-minute access token plus a 30-day refresh token kept in an httpOnly cookie, and the login endpoint is rate-limited against guessing.

What stops one company from seeing another company's data? Structural tenant isolation. Every query is filtered by company, the tenant context is validated on each request rather than trusted from the session, and the design fails safe — a missing filter returns nothing, never another tenant's data. Cross-tenant isolation is exercised as a first-class test, not left as an assumption.

Is there an audit trail of who changed what? Yes. Every create, update, and delete is recorded with the user and timestamp, giving the SOX-style "who changed what, and when" history auditors expect. Records are soft-deleted rather than erased, and optimistic locking prevents concurrent edits from silently overwriting each other — so financial history stays durable and attributable.

Do I need an enterprise plan to get these security controls? No. Short-lived tokens, granular RBAC with segregation of duties, audit trails, soft delete, optimistic locking, encryption of secrets at rest, and tenant isolation are built into the platform for every tenant on day one — not fenced off behind a premium tier.

How are integration keys and other secrets protected? Sensitive settings and secrets are encrypted at rest rather than stored in plaintext columns, and they're masked when displayed so a saved key isn't casually readable. Uploaded files are validated by content and served through an authenticated proxy, and report exports are logged to an audit trail.