Security

The client’s ledger: the chart, the journals, the open bills and invoices, the bank and card lines it holds and the entries on them. The client’s banks and cards. Orders and settlements from the shop and the marketplaces. Where a client has sales tax with you, the state portals too, for what has been filed and paid in the client’s name.

Each is read through that system’s own connection, with the narrowest permission the system offers, and the permissions are listed on the client’s own screen in that system. On a shop, a marketplace or a bank feed the write permissions are not requested at all, so they are not there to be misused. Every read is logged with what it read and when.

• The client’s ledger. The coding of a bank or card line, to an account the ledger itself has used before. The match of a payout to its orders, a payment to its bill, a transfer to its other side. The reconciliation of an account. The month-end journals, prepared from the evidence. Where a client has sales tax, the accrual, the entry that books a return and the match of the state’s debit. Every entry is claimed before it is made, dated to its period, never inside a closed period, recorded with exactly what was sent, confirmed by the state a person would see in the ledger afterwards, and correctable from Pursor through an authorized path that keeps the trail.
• The state, for clients on sales tax. The return and the instruction on it that tells the state to debit the client’s account. Pursor files as the preparer, under the authority the client signs. The money goes from the client’s account to the state; Pursor never holds it and has no account for it to pass through.
• Nowhere else. Pursor cannot move money, pay a bill, approve a payment, change a price or alter an order in any system it connects to.

Every write goes through one path in our code. It plans the whole write before making it and stops rather than guesses: an account code that is not in the client’s chart, a date inside a closed period, a figure that does not tie, and the item is held for a person instead. A writer runs unattended only once it has been proven against a live ledger, for that ledger and that kind of entry, and each task is a switch per client that your firm turns on and can turn off with one press. Your firm can ask what Pursor has ever written to a client’s ledger or filed in their name and get a list, not a promise.

Banks and cards connect through Stripe Financial Connections, read-only. The client goes through the bank’s own login in the bank’s window; Pursor never sees, holds or stores a bank credential, and the connection can be removed from both ends in one step.

The shop and the marketplaces connect through their own consent screens: Shopify’s app install, Amazon’s Seller Central authorisation under the finance role, PayPal’s. Each lists what Pursor may read, and each can be withdrawn there without asking us.

The ledger connects through its own API. On Fulfil and NetSuite, Pursor is a user or an integration the client created and can disable, and what it may do there is the client’s to set. On QuickBooks the client authorises Pursor through Intuit’s own sign-in and can remove it from QuickBooks’ Apps page or from Pursor.

The state portals, for clients on sales tax, are the one place Pursor holds a credential, because filing needs one. Wherever a state offers preparer access Pursor takes that under its own login. Where a state does not, the client’s login is held encrypted under a key kept outside the database and separate from every other key, bound to that client, and every time it is opened the event is recorded with who and why.

There is no shared master credential. Each connection is the client’s, and each can be cut without asking us.

Pursor keeps what an entry or a return is built from and what proves it: the ledger’s journals, lines and account balances as read; the bank and card lines; the orders and the marketplaces’ settlements; the record of every read and every write; and, for clients on sales tax, every return as filed with the state’s confirmation and every notice with what was done about it.

It does not use the client’s customers’ names, does not copy the ledger, and does not build anything that could be mistaken for a second set of books. The client’s ledger stays the ledger.

Pursor uses Anthropic’s Claude through its commercial API to read a document, a notice or a provider’s bill and say what it means, and to write the description an entry carries. No figure in a journal or on a return is produced by a model: every entry is made from the client’s own records and the ledger’s own history, and the arithmetic can be shown. Anthropic states that, by default, it does not use inputs or outputs from its commercial products to train its models. We have not opted in to any feedback or training mechanism, and we never will.

The model has no memory between requests. Each call is one document and what Pursor already knows, and nothing is retained by the model afterwards. Anything Pursor remembers about a client is written deliberately into our own database, and your firm can read it.

The people at your firm attached to the client, as your firm decides. The client’s own people, as your firm adds them: a connector who links a system, a user who answers what is theirs, an admin, and a Controller, who alone on the client’s side sees person-level payroll. The people at Pursor who operate the platform. Nobody else.

Every client’s data is scoped to that company at the query level. A firm sees the clients it has been attached to and no others, and seeing a client’s books is not permission to act in them: posting, tax approval and sign-off belong to named people with the right to hold them.

• Connection tokens and portal logins are encrypted with AES-256-GCM before they are stored, under keys held outside the database.
• All traffic runs over TLS. Data is encrypted at rest by our database provider.
• Every sign-in to Pursor takes a password and a second step, with no exception for our own staff.
• Pursor never asks for, holds or stores a password to a client’s bank, shop, marketplaces or ledger. Those are reached through their own connection flows, never by a login anyone hands over.
• Billing is by bank debit through Stripe. Pursor never sees a bank account number.

Fulfil, Oracle NetSuite and Intuit (the ledgers, through their own APIs), Shopify, Amazon and PayPal (the shop and the marketplaces), Ramp (cards), Stripe (bank connections and billing), Anthropic (the model), Neon (the database), Vercel (hosting) and Postmark (the emails Pursor sends). For clients on sales tax, the states’ own filing portals, in the client’s name. Plus any other system a client connects, through its own API. We do not sell data, we do not share it with anyone else, and there is no advertising or analytics product anywhere near it.

Disconnecting a source removes the connection at both ends and deletes what Pursor read from it. That is a button, and it does not need our permission. Bank and card transactions are the one exception: they are the history the cashflow is built from and a bank will not always hand them over again, so they stay until the client is closed, and reconnecting the same bank picks them back up. The entries Pursor made are in the client’s ledger, which they keep. For a client on sales tax, every return and its confirmation is handed to the client when they go, because a state can ask about one years later, and only then deleted. Closing a client deletes what Pursor holds about the company; today that is done on request, by a person, and is not yet a button of its own.

Pursor does not yet hold SOC 2 or ISO 27001. Independent audit is planned, and the report will be published on this page when it exists. We will not describe a policy document as a certification in the meantime.

Until then, everything above is checkable without taking our word for it: the scopes on the client’s own developer console, the connection screens, and the vendors’ published policies. If a client’s assessment needs more than that today, we would rather you told us than found out later.