Security overview

We keep the books for accounting firms and their clients, so protecting your financial data is central to how LedgerHub is built — not an afterthought. This page summarizes the technical and organizational measures we use. If you have a question, see “Reporting a concern” at the bottom.

All traffic to and from LedgerHub is encrypted in transit with TLS (HTTPS), and HTTP Strict Transport Security is enforced so browsers will not fall back to an unencrypted connection.

The most sensitive secrets we hold — your linked-bank access tokens, two-factor and authenticator secrets, and payment-provider keys — are encrypted at the field level with AES-256-GCM before they are written to the database, using keys held only on the application host.

• Passwords are stored only as salted, one-way hashes — never in plaintext.
• Passwordless sign-in with passkeys (Face ID, Touch ID, or a security key) via WebAuthn.
• Two-factor authentication with authenticator apps (TOTP) and one-time email codes, with optional trusted devices.
• Role-based permissions — only Owner and Accountant roles can post or change financial records; client-portal access is limited to viewing and uploading.
• Per-user company access and strict multi-tenant isolation, so each set of books is visible only to the people granted access to it.
• Sign-ins, sign-outs and failed sign-in attempts are recorded in the audit trail, so access to the books is itself part of the books’ history.

Bank and card feeds are powered by Plaid. When you connect an account, you enter your bank credentials directly with Plaid — they never pass through or get stored on LedgerHub. We receive a Plaid access token (encrypted, as above), account metadata, read-only transactions and balances, and available bank statements when statement access is connected. These connections cannot be used to move money.

Invoice payments are processed by Stripe and PayPal. Card details are entered on their secure, PCI-compliant systems; LedgerHub never sees or stores full card numbers.

LedgerHub runs on Amazon Web Services — application compute plus an Amazon RDS for MySQL database — in the United States, behind Cloudflare for TLS termination and network protection. This system is operated by I&S ACCOUNTING SVCS, LLC. In the firm-managed, invitation-only access model, the service is used by the firm and its invited clients. If self-service signup is enabled, customers can create separate workspaces on the shared service. Company data is scoped in the database; workspace ownership, roles and the configured access model determine which books a user can open.

LedgerHub is operated by I&S ACCOUNTING SVCS, LLC and is not itself SOC 2 certified. The providers below support the implemented data paths. Optional connections and features apply when configured; the list does not mean every provider receives every company’s data.

When configured and used, these optional AI features send data to the Anthropic API:

• Bank-feed categorization: Transaction descriptions and amounts, chart-of-accounts entries, vendor and customer names, classes, and examples of how the company coded previous transactions are sent to suggest coding.
• Ask your books: Your question and conversation history, company context, and the report or ledger results retrieved to answer the question are sent to generate an answer. The reporting tools available to the assistant are read-only.
• Vendor-bill extraction: The complete bill image you select, including text and personal or financial information visible in it, is sent to extract proposed vendor-reference, date, amount and line-item fields.
• Bank-document reading: The complete image or PDF you select for AI reading is sent to extract payer or payee, date, amount and check-reference details from checks, receipts, bills and statements for matching and coding bank transactions.

Document extraction sends the selected file contents, not just report totals. You can enter and review records without using AI. Anthropic describes API content as excluded from model training by default in its commercial data-use policy. Provider retention and any account-specific arrangements are separate from that training policy.

You own your books. At any time you can export your full chart of accounts, transactions, and financial statements to CSV and Excel from the admin tools, and take them with you if you ever leave. There is no lock-in.

Changes to the books are recorded — who made them, when, and what the record looked like before and after. Bulk operations are recorded the same way, record by record: a bulk reclassification or a bulk register edit writes a separate entry for each affected line, with that line’s own before-and-after values, so a record’s history includes the bulk changes that touched it. The trail is scoped per company, so you see the history for your own books and nobody else’s, and it covers the ordinary edits that matter in an accounting system: posted entries, reclassifications, voids, and deletions.

History is kept at the line level, not just the record level: a journal entry, invoice, or bill records its individual lines when it is created, what each edit added, removed, or changed on each line, and what the lines were when it was deleted. Every record links to its own history timeline, so “what happened to this transaction” is a page you can open, not a request you have to make.

Finished periods can be locked. Once a month or a year is closed, transactions dated inside it stop accepting silent edits — which is what makes a closed period actually mean something at review time.

Your books live in Amazon RDS, which takes automated backups and continuously archives the database transaction log — so the database can be restored to a chosen point in time rather than only to last night’s copy. Backups and snapshots inherit the instance’s encryption, so they are AES-256 encrypted at rest under a managed key.

Uploaded documents and branding files are stored on the application server and copied to Cloudflare R2 by the upload-backup job, scheduled hourly. Changed files have their previous backup versions archived; deleting a file in the app does not delete its backup copy. The backup job does not automatically expire those copies.

File backups and database recovery are separate: an upload can be absent if it was created after the last successful file backup, and the file mirror is not an exact database point-in-time snapshot. Recovery requires the appropriate database, file versions and keys.

The service exposes a health endpoint that is verified on every deploy, and application errors are logged on the host for diagnosis.

We track published security advisories against the libraries LedgerHub is built on and apply patches on a regular cadence, prioritizing anything reachable from the parts of the app exposed to the internet.

If you believe you have found a security issue, please contact us at info@iandsaccountingsvcs.com so we can look into it promptly. We appreciate responsible disclosure, and we will not pursue action against anyone who reports a genuine issue to us in good faith and gives us a reasonable chance to fix it before disclosing it publicly.

Machine-readable contact details are published at /.well-known/security.txt.

Happy to answer them directly — write to info@iandsaccountingsvcs.com, or go back to LedgerHub.