Legal

Security

How access to a Client's financial systems is obtained, how credentials and tokens are held, who can see a Client's records, and how access is withdrawn.

Last updated 28 August 2026

1. Credentials are never held

At no point in the process does a Client enter a password for QuickBooks, or for any other connected system, into anything operated by CountCore. Access is granted as an invitation issued by the Client from within each system, under the Client’s own administrator account.

A credential that was never disclosed to CountCore cannot be disclosed by CountCore, and access granted from the Client’s own console may be withdrawn from that console without CountCore’s involvement.

2. What each grant permits

  • Connecting a sourcethrough the provider’s standard sign-in permits CountCore to read the Client’s records, so that they appear on the Client’s screens.
  • Inviting CountCore as an accountant useris what permits a correction to be posted. Corrections are queued for approval by a person; nothing is posted to a Client’s ledger automatically.

These are two distinct grants and the first does not imply the second. A Client requiring reporting only may grant the connection and not the invitation.

3. Connection tokens

Tokens issued by a connected provider are encrypted at rest using AES-256-GCM with a per-value initialisation vector and an authentication tag, under a key held separately from the database. A token that has been altered fails authentication and is rejected rather than used.

Disconnecting a source revokes the token with the provider rather than only discarding the local copy.

4. Revocation

Access may be withdrawn by the Client immediately, without notice and without CountCore’s involvement, by removing the CountCore user in the connected system, or by disconnecting the source in the application under Settings, then Connections.

5. Hosting and transport

The application is hosted by Vercel and the database by Neon, both in the United States. A Client’s accounting records remain in the Client’s own accounting system, which is the system of record; CountCore reads from it and writes back approved corrections. Records are not migrated into CountCore.

All traffic is served over TLS, with HTTP Strict Transport Security enabled. Authentication uses a password chosen by the user and stored only as a scrypt hash, together with a signed session cookie re-verified on each request. No third-party identity provider is used.

6. Who can see a Client’s records

Access to a Client’s financial records is limited to CountCore personnel who require it in order to perform the Services, and is removed when it is no longer required. Records are not accessed for any purpose other than performing the Services, and are not accessed at all where a question can be answered without doing so.

Every synchronisation, correction, review and approval is recorded with the account that performed it. That record is visible to the Client on its own audit trail rather than held only by CountCore.

7. Incidents

Where CountCore becomes aware of unauthorised access to, or unauthorised disclosure of, a Client’s information, it will notify the affected Client without undue delay and in any event within the period required by applicable law. The notification will describe what is known, what is not yet known, and what the Client should do.

Notification is made whether or not the incident is judged to require it by statute. A Client whose records were exposed is entitled to know, and deciding otherwise is not CountCore’s decision to make on that Client’s behalf.

8. Reporting a vulnerability

Reports of suspected vulnerabilities may be submitted through the contact form, which requires no account. CountCore will not pursue action against any person who reports a suspected vulnerability in good faith and does not access, alter or retain data belonging to others in the course of doing so.