TAXFINAI (formerly COMPTA AI)

Privacy Policy

Last updated: October 20, 2026

This is an initial version. It will be revised.

1. Who we are

TAXFINAI is published by Shai Laskar (sole proprietor) (“we”, “us”) and made available to accounting practices. You can reach us at laskar.moshe@gmail.com.

Each subscribing practice remains responsible for the accounting data of its own clients. We process that data on the practice’s behalf, as a processor acting on its instructions. This policy describes what the platform stores, who it is shared with, and how long it is kept.

TAXFINAI is a platform used by accounting practices to manage their US tax season workload and to perform month-end and year-end close review. It is not a consumer product and it is not open to the public.

2. Who this policy covers

This policy concerns two groups of people, and it treats them separately throughout.

  • Authorized users. Staff of a subscribing practice. They are the only people who hold accounts. There is no public sign-up and no self-registration: an administrator creates each account and the new user receives an email invitation to set a password.
  • People described in client accounting records. The clients of a subscribing practice, and the customers, vendors, employees and contacts who appear in those clients’ books. These people hold no account and never interact with TAXFINAI. Their data reaches us because an authorized user connects a client’s QuickBooks Online company or uploads a file. The practice that holds the engagement is responsible for this data; we hold it on that practice’s behalf.

3. What we store about authorized users

  • Identity and employment details: email address, full name, initials, position, role, office, hourly rate, active or inactive status, and deactivation date.
  • Authentication: accounts are managed by Supabase Auth. Passwords are set and stored by Supabase; we never see them and never store them ourselves.
  • Work records: time entries attributed to the individual — date, hours, description and whether the time is billable.
  • Content written in the platform: comments, notes, checklist entries, review comments and justification text, each attributed to its author.
  • Notifications addressed to the user, and their email notification preferences.
  • Change history. An audit log records insertions, updates and deletions on the tables that carry a decision: which table, which record, which fields changed with their values before and after, who made the change and when. On an insertion or a deletion, the whole record is written to the log. The audit log does not currently record IP addresses.

4. What we read from QuickBooks Online

When an authorized user connects a client’s QuickBooks Online company, we request the accounting scope Intuit publishes for this purpose and read the following, storing a copy in our database:

  • Chart of accounts — account identifier, number, name, type, detail type and currency.
  • Balance Sheet and Profit and Loss reports — account balances for the period and for the comparative period, including a month-by-month breakdown.
  • General Ledger report — for each entry: date, transaction type, document number, the name of the counterparty (the client’s customer or vendor), the free-text description or memo, the offsetting account, the amount and the running balance.
  • A/R Aging and A/P Aging reports — counterparty names and outstanding amounts by ageing bucket.

Authorized users may also upload files: invoice listings, which may contain counterparty names, memos, dates and amounts; and supporting documents (PDF, images, spreadsheets, Word files), which are held in a private storage bucket with no public URL and are reachable only through short-lived signed links generated by our server. A bank statement uploaded as a supporting document may also be sent to Anthropic, when an authorized user asks the platform to read it (section 8).

Stated plainly: the accounting detail we copy can include the names of individuals and businesses who deal with a practice’s clients, and free-text memos written by those clients’ bookkeepers. We do not attempt to enrich, cross-reference or resolve the identity of these people; we store what the reports contain.

5. We do not write to QuickBooks

Our integration only reads. Every call we make to the QuickBooks data API is a GET request. We never create, modify or delete anything in a connected QuickBooks company, and no code path in the application is capable of doing so. Intuit does not publish a read-only variant of the accounting scope, so the authorization we hold technically permits writing; we do not exercise it.

The only requests we send to Intuit that are not reads are OAuth requests: exchanging an authorization code for tokens, refreshing tokens, and revoking a token when a connection is disconnected.

6. Why we use this data

  • To operate the platform for each subscribing practice: plan engagements, track deadlines, record time.
  • To perform close review: tie account balances to supporting detail, flag review points, and document what was reviewed, by whom and when.
  • To produce work papers and exports for a practice and its clients.
  • To send notifications to authorized users.
  • To keep an audit trail of who changed what.

We do not use any of this data for advertising or profiling, we do not sell it, and we do not share it with anyone other than the service providers listed in section 8.

7. How the data is protected, and where that protection stops

  • QuickBooks tokens are encrypted by the application with AES-256-GCM before they are written to the database. The key lives only in the server environment — outside the database and outside our source code — so the database never holds a token in the clear. Key rotation is supported.
  • The OAuth flow is signed. The state parameter carries an HMAC-SHA256 signature verified in constant time, and the post-authorization return path is restricted to an internal allow-list.
  • Access is enforced by the database itself, through row-level security policies rather than by the interface alone. Authorized users hold one of three roles; a user on the most restricted role sees only the engagements they own, supervise or are currently responsible for. The close review module, which holds the data read from QuickBooks, is restricted to administrators, and that restriction is applied three times over: at the network layer, again when the page is rendered on the server, and again by the database policies — so a direct API call from a non-administrator is refused.
  • What we do not encrypt. Apart from the QuickBooks tokens described above, we do not apply our own encryption to what we store. Accounting records, counterparty names, memos and user details are held as ordinary database values, and rely on the encryption at rest and in transit provided by our hosting providers.

8. Service providers

We rely on the following providers. Each is bound by its own terms and privacy policy, and hosting regions are determined by their configuration.

  • Supabase — database, authentication and file storage. Holds all of the data described in this policy.
  • Vercel — hosting and execution of the application, including scheduled jobs. Processes incoming requests and produces server logs.
  • Intuit (QuickBooks Online) — the source of the accounting data we read. We send authentication requests and read requests; we do not send Intuit any of the data described in this policy.
  • Resend — delivery of notification emails. Recipients are authorized users only; no email is ever sent to a client or to a third party. Each message carries a notification title, a short message and a link back to the platform.
  • Anthropic — used by two features only: the review assistant, and the reading of bank statements. See below.

The review assistant and Anthropic

When an authorized user asks the review assistant a question, or asks it to draft a justification comment, we send the following to Anthropic’s API: the engagement name — which is the client entity’s name — the closing date, the review cycle being worked on, and the computed state of that cycle. That computed state includes balances, variances, comparative figures, invoice-listing totals, month-by-month differences, and the account numbers, account names and reviewer comments for the accounts in that cycle.

Apart from the bank statements described below, we do not send the general ledger line by line, the invoice listing line by line, counterparty names, or any uploaded document. Each exchange with the review assistant is recorded in our database so that it can be reviewed later.

The assistant never writes to the platform. It returns text; an authorized user reads it and decides whether to use it.

Supporting documents and AI service providers

Supporting documents — bank statements, invoices, receipts, contracts, spreadsheets and similar engagement materials — may contain financial, identifying and transaction information. They may be processed by contracted AI service providers, solely to provide the platform feature an authorized user has requested. The provider is contractually restricted from using them for its own purposes or to train its models. This processing is restricted to the United States. Zero data retention applies, subject to the limited exceptions in the provider’s applicable terms, described below.

Bank statements and Anthropic

When an authorized user asks the platform to read a bank statement that has been uploaded as a supporting document, we send the whole statement to Anthropic’s API, exactly as it was uploaded, with fixed instructions. Nothing else from the platform is sent with it: not the engagement name, not a balance, not an account from the client’s books.

A bank statement typically shows the client entity’s name and address, the bank, account numbers, and for each transaction its date, amount and description. Those descriptions often name the client’s customers, vendors and employees, and can contain free text written by whoever made or received the payment. All of it reaches Anthropic.

The statement is sent inside the request itself. We do not use Anthropic’s file storage service, which is outside the zero data retention arrangement described below.

Anthropic returns what it reads — the bank, the last four digits of the account number, the currency, the statement period, the opening balance, the totals of credits and debits, and the closing balance — and, for each value, the page and the passage it was read from. We ask for no more than the last four digits of the account number, and the platform masks any other digit of it in what Anthropic returns. Where a page has a text layer, the platform checks each value against the text of that page and discards any value it cannot find there, and it checks that the opening balance, plus credits, minus debits, gives the closing balance. A value that cannot be checked is shown as not checked, and is never filled in for the user. The values are not recorded in the engagement until an authorized user reviews them and decides to; the questions the platform raises about a statement, which may cite the values concerned, are kept until someone answers them.

For each statement sent, we record that a statement was sent: which supporting document it was, a fingerprint of the file, its file type, size and number of pages, the date and time, the model and the processing region used, the outcome of the request, and the authorized user who made it. That record does not include the statement or what Anthropic returned. This record is kept in accordance with our retention policy, including after the engagement is deleted. The statement itself remains a supporting document of the engagement until someone deletes it.

How Anthropic handles what we send

Since October 1, 2026, the data we send to Anthropic is handled as follows:

  • Processed in the United States. Every request asks Anthropic to run it on infrastructure in the United States only, and the platform discards any reply that reports it was processed elsewhere.
  • Zero data retention. Our account with Anthropic is set up for zero data retention: Anthropic does not store what we send, or its reply, once the reply has been returned to us. Anthropic sets one limit on this, whatever the arrangement: it may keep data where the law requires it, or where its automated trust and safety systems flag a request, in which case the request and the reply may be kept for up to two years.
  • Not used for training. Anthropic does not use this data to train its models.

These points concern Anthropic only. On our side, each exchange with the review assistant is still recorded in our database, as stated above and in section 10; for a bank statement, we keep only the record described above. For everything else, the data is handled under Anthropic’s commercial terms for API use.

9. Cookies and tracking

We set a session cookie so that a signed-in user stays signed in; it is set by Supabase Auth. We keep a small amount of interface state — a running timer, a chosen filter — in the browser’s local storage. We use no analytics, advertising or tracking service of any kind, and the pages carry no third-party script.

10. How long we keep data

No automatic retention or deletion schedule is implemented. Data we hold stays until someone deletes it. The platform runs scheduled jobs that generate recurring tasks and send deadline reminders; none of them deletes anything.

Deletion happens only when someone asks for it:

  • In the close review module, a client can be deleted only once nothing remains attached to it: no engagement, and none of its accounts, invoice listings or other client-level data. An engagement cannot yet be deleted from the platform: until it can, we delete an engagement on the written request of an authorized user of the practice, together with the records attached to it, except the records listed below.
  • Deleting a supporting document removes its record and its stored file. The preview image generated for a PDF is not yet deleted with it, nor is a file whose removal from storage fails.
  • Disconnecting a QuickBooks company revokes our authorization with Intuit and then deletes the stored connection — but it does not delete accounting data already imported from that company. That data remains until it is deleted separately.

Three things are kept on purpose, and we would rather say so:

  • Audit log entries survive the deletion of the record they describe, so that the history of a deleted engagement is not itself erased.
  • Deactivating an authorized user prevents them from signing in, but does not delete their record, their time entries or the content they wrote.
  • The record of each request sent to an AI service provider (section 8) — which supporting document, if any, its fingerprint, the date and time, the model, the region, the outcome and the authorized user — survives the deletion of the engagement. It is kept in accordance with our retention policy.

11. Requests about your data

There is no self-service way to export or delete data — not for authorized users, and not for anyone else. If you want to know what we hold about you, obtain a copy of it, or have it deleted, write to laskar.moshe@gmail.com and we will handle the request by hand.

We cannot commit to a fixed response time. Some records may not be deletable on request: audit log entries exist precisely so that history cannot be rewritten.

For anything concerning accounting data, address the practice, not us. The subscribing practice that holds the engagement is responsible for the accounting data of its clients; we hold it on that practice’s behalf and act on its instructions. If you are a client of a practice, or a customer, vendor or contact appearing in a client’s books, that practice is the one that can decide what happens to the data — and, where the data came from a QuickBooks company, the client who owns those books controls them.

12. Changes to this policy

We update the date at the top of this page when the text changes. There is no mechanism that notifies anyone of a change, so please check this page when it matters to you.

13. Contact

Questions about this policy, or requests concerning your data: laskar.moshe@gmail.com.