Security and data handling

There is no public sign-up. Staff are invited by a firm admin and authenticate with Google, and a person without an invitation is refused rather than given a reduced view. For a system holding client financial records, an open registration form is a liability, so the product does not have one.

Roles are distinct rather than cosmetic. A platform admin operates the hosted service and manages firm tenants. A firm admin manages that firm's clients, staff, and settings. A bookkeeper works the clients they are assigned to. A client portal user reaches their own uploads and questions and nothing else.

A bookkeeper assigned to six clients cannot reach the other forty-four, because the membership filter is applied when data is loaded rather than by hiding controls from someone who could otherwise request the record directly. Hiding a button is not access control, and a product that relies on it fails the first time somebody edits a URL.

The same principle governs integrations. QuickBooks Online is authorised per client company rather than once for the firm, so a credential cannot reach a client it was not issued for.

Tokens for connected services, including QuickBooks Online and Plaid, are encrypted before they are stored rather than held in plain text in the database. Platform secrets are managed through the admin interface, and revealing one is itself recorded as an audited action, so a credential cannot be read quietly.

Ledger edits are versioned at field level with the previous value retained, so a change to a vendor, a category, or a business-use percentage can be shown rather than reconstructed from memory. Platform activity is written to an audit log with the acting user, the action, the affected entity, and a timestamp.

This matters beyond security. When a firm is asked months later to justify a figure, the difference between a defensible answer and an awkward one is usually whether the system recorded who changed what.

Runs produce drafts and nothing else. No automated process approves a line, files a return, or sends anything to a client. Approval is a human action, so the blast radius of a bad extraction is a draft a reviewer corrects.

Per-client monthly run caps and a global suspend control bound execution. Automation that can be triggered repeatedly should have a ceiling, and a misconfigured folder should produce a stopped run rather than an open-ended cost.

Under PIPEDA, a firm that hands personal information to a service provider remains accountable for it. Veridbooks is a processor in that relationship, not a way to move responsibility, and any vendor implying otherwise is worth treating with suspicion.

Practically, that means your engagement letters and client consents still need to cover the tools you use, and your own retention obligations still apply to the records you keep here.

Some due-diligence questions deserve a specific answer for your firm rather than a marketing paragraph: where data is hosted, which sub-processors are involved in document processing, how long data is retained after an engagement ends, and what happens to your records if you leave.

Ask us during onboarding and we will answer them in writing. A generic reassurance on a web page is not something a firm should accept as diligence, so we are not offering one here.