What we hold, why, and how to get it deleted.

Who we are

Suma Limited builds and runs this software, and is registered in Hong Kong. Our Business Registration number is 80851441.

We are the data user for everything described here. If you are an existing client, your own staff and patient records inside your app are held on your instructions and we act on them for you.

What we collect, and why

Five things, and nothing else:

• Contact details. Your name, your company name, your email address and your phone number, taken from the first page of the application form. We use them to reply to you, to send the messages the form promises (a confirmation, a receipt, a note when your build starts, a note when it is ready) and to open your account when the build lands. We also ask how you heard about Suma, picked from a short list on the application form and on the book a call form, and we use that answer only to see which ways of finding us work.
• Your answers to the questionnaire. Free text you type about how the business runs. We use it to scope and build your software, and a founder reads it.
• The accounting files you upload. Spreadsheets, CSV exports, PDFs, and photos or scans of paper. We use them to understand the shape of your books and to import the opening data your app starts from.
• Recordings and transcripts of your scoping meetings. When we meet you to scope and price the build, the meeting may be recorded and transcribed, and the recording and transcript are kept in Google Workspace with your onboarding files. We use them to build what was agreed.
• Website analytics. On the marketing pages of this website, PostHog counts pageviews and clicks and notes which advert or link brought a visitor. We use it to see which pages are read and which adverts work.

We do not buy data about you, we do not sell or rent anything you give us, and we run no advertising or profiling on it. Payment card details are never seen by us at all: the card form is Stripe's, hosted by Stripe, and what comes back to us is a payment reference and a yes.

An AI model reads part of it

AI models read some of what you give us, in three places. This is exactly how, because we would rather say it here than leave you to guess:

• The assistant in your app. When you ask it a question, real names are swapped for stable placeholders before the question leaves your app, and a second filter on our server strips anything else personal that is recognisable by its shape, such as email addresses, phone numbers and identity or card numbers. Only then does the model see the question. The model is not shown the rows of your books: it reads your question, and our own software looks up and calculates the answer. The assistant runs on Google's Gemini models in Vertex AI.
• Documents you upload. When you upload a document to be read, such as a receipt, or the files you send with your application, the document is sent to the model as it is, because reading it is the task. Passwords, bank credentials and sign-in details are never sent to a model.
• Eugene, our internal operations service. It runs on Anthropic's Claude models. It reads the PDFs and images you upload with your application, and it can read your books to answer a founder's questions about your engagement.
• No training. Nothing you give us is used to train any model, ours or anybody else's, and every AI supplier we use runs under terms or account settings that forbid training on your data.
• No writing. The model never writes to your books. Every figure in your accounts is posted by ordinary deterministic code, and a person signs off anything that leaves Suma.

Who processes it for us

This is the whole list. Each one is a supplier we actually call, not a category, and our Terms of Use treat this list as the current one.

• Vercel hosts the website and your app and runs the server code, in the United States. Its environment settings hold a copy of our master key, the key that protects every company's own key.
• Neon hosts the encrypted Postgres database your application and your books are stored in, in Singapore.
• Google Cloud does three things for us. Vertex AI, in the European Union, runs the Google Gemini models behind the assistant. Cloud Run hosts Eugene, our internal operations service, and its environment settings hold a copy of our master key. Google Cloud Storage holds the encrypted backups of the database in Google's Hong Kong region (asia-east2), apart from the live database; backups are encrypted before they leave Suma, and older ones are deleted within 30 days.
• Anthropic provides the Claude models, in the United States. We use them in the AI coding tools we build and maintain your app with, and in our onboarding and internal operations services, which read the PDFs and images you upload with your application and answer founders' questions about client engagements.
• Hetzner runs our build server in Finland. It holds regularly refreshed test copies of the books of clients whose apps are in use, so that we can test a change against real data before we release it.
• Google Workspace runs our email and stores onboarding files, meeting recordings and transcripts.
• GitHub holds our source code, including your app's configuration, which holds your business's name and may hold the names of your staff.
• Resend sends the email our services send (invitations, receipts, build notices, password resets).
• Stripe takes payments and holds the card details we never see.
• Finverse runs the bank feed, where your app has one.
• Calendly books meetings with us.
• PostHog runs the analytics on parts of our website, in the United States.
• Telegram carries internal messages between our founders and our internal operations service, which may concern client engagements.
• Meta's WhatsApp carries the same kind of internal messages between our founders and our internal operations service, which may concern client engagements.

If we ever add one, this list changes before the supplier is called, not after.

Google account data

A clinic can connect its Google account to its Suma app. Nothing here happens unless the clinic chooses to connect. When it does, this is what we ask Google for and what we do with it:

• Calendar events, read and write. Appointments in the calendar linked to your app are read into your app's diary, and the sessions you book in the app are written to that calendar.
• Spreadsheets, read and write. The accounting sheet linked to your app is read so it can be reconciled with your books. If you ask, we create that sheet for you and write your transactions to it.
• Your Google account address. Signing in with Google (OAuth) also tells us which account is connecting. We do not store that address.

Mail is a separate permission, and it is optional. We ask for it only when a clinic turns on PayMe reconciliation, and its token is stored on its own, apart from the calendar one. Google's read-only mail permission technically covers your whole mailbox, because Google offers nothing narrower. So the limit is enforced in our code:

• We run one fixed search, for PayMe notification senders over a bounded date window. Nothing anyone types can widen it.
• Only the messages that search finds are opened. Each is read in memory and four things are kept: the amount, the date, the payer's name and the reference, plus the message id so a payment is never counted twice. The rest of the message is discarded.
• Attachments are never fetched. A message we cannot read is dropped, not kept.

We use this data only to provide the bookkeeping, diary and payment reconciliation features you see in your app, and for no other purpose.

The permission Google gives us is a long-lived token. It is held only on our servers, encrypted under your company's own key, and it is never sent to your browser. The calendar token and the mail token are stored separately. Anything read from Google that becomes part of your books is held in the same encrypted store described under Where it is held, and how, below.

We do not sell Google user data, and we do not use it for advertising. We do not transfer it to anyone except the suppliers listed above, Vercel and Neon, as each needs it to run these features. We do not use it to train any AI model.

Google user data is never sent to the AI model described above, which runs on Google Vertex AI. The assistant in your app sends that model your question, with names masked, and the shape of your records, never the records themselves.

You can stop it at any time. In your app, open Settings and press Disconnect Google: that deletes our copy of the token at once and unlinks your calendar and sheet. The PayMe mail connection has its own Disconnect button, on the PayMe card of the Payments page. Disconnecting in the app deletes what we hold, but it does not by itself withdraw the permission at Google. To revoke it there, remove Suma from your Google account's third-party access. To have us delete what we hold that came from Google, write to sales@suma.hk.

Suma's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Where it is held, and how

Your application, your answers and your uploaded files are encrypted at rest with a key unique to your company. Apart from the backups, which Google Cloud Storage holds in Hong Kong, your data is processed outside Hong Kong. Vertex AI runs the assistant's model in the European Union. Anthropic, PostHog and Vercel process it in the United States. Hetzner holds our build server in Finland. Neon holds the database in Singapore. The other suppliers above process it outside Hong Kong, on their own infrastructure. We pick suppliers who commit to protection at least equivalent to what the Personal Data (Privacy) Ordinance requires of us. How we protect it sets out the engineering.

Retention: how long we keep it

Each kind of data has its own retention limit, and these are the same periods our Terms of Use set:

• Your application files. The files you upload with your application, anything we extracted from them, and the recordings and transcripts of your scoping meetings are deleted within 90 days after the start date of your paid engagement, or sooner if you ask. Deleting the uploaded files is automatic and needs nobody to remember it.
• Your app's data, after a paid engagement. When it ends we keep all of the data held in your app for 12 months after the engagement ends, and you can ask for an export at any time in that period. Then we delete it.
• Your app's data, after a trial you do not continue. If a trial is not paid for or is cancelled, you keep 30 days of read-only access to view and download everything. Then we delete all of it, including your application files, the recordings and transcripts of your scoping meetings and the test copies on our build server. If an engagement ends before we hand the app over, we delete your data within 30 days.
• Test copies on our build server. Up to five test copies of your books, each replaced by a newer one, deleted within 30 days after the engagement ends.
• Backups. Copies in our backups are deleted as the backups expire, within 30 days.
• Operational records. Pictures and clips we attach to our answers to your requests are kept for 60 days. Attachments you send with a request are kept while the request is on your requests desk. Crash reports and assistant audit records are kept for 90 days, per-client usage counts for 90 days, screenshots sent to our internal operations service for 30 days, and that service's conversation records about your engagement for 90 days.
• The record of the engagement. If you paid any fee, your reference number, contact details, questionnaire answers, the version of our terms you accepted, the payment record and the dates the build moved are kept for as long as you are a client and for 7 years afterwards, which is what Hong Kong company and tax law expects. If you paid nothing, we keep only your reference number, contact details, the version of our terms you accepted and when, and the dates the build moved, for 2 years after the engagement ends, and then delete them.

If you have asked us to delete your files early, the same rules apply to what is left.

Deleting your files, and asking what we hold

You can have your uploaded files deleted at any time, before or after your build, paid or unpaid. Ask us and we run it the same working day; the files and the bytes behind them are removed from the database, and we write an audit line saying we did. You do not have to give a reason and it costs nothing.

You can also ask us what we hold about you, ask us to correct it, or ask us to stop using it. Under the Personal Data (Privacy) Ordinance we have 40 days to answer a data access request. Write to sales@suma.hk with your reference number and we will confirm what we are doing.

The one thing we will not delete on request is the engagement record described above while a legal or tax obligation still requires it. If that applies to you we will say so plainly and tell you when it lapses.

Cookies

We set a signed session cookie when you sign in, and a signed cookie that identifies the application you are filling in so you can come back to it. Both are functional.

On the marketing pages of this website, PostHog sets a first-party analytics cookie. It counts pageviews and clicks and notes which advert or link brought you. Session recording is off, and it is used for no advertising. There is no advertising cookie on this domain.

When this changes

The consent you gave is stamped with the version of this notice that was in force on the day, and that stamp is never rewritten: it is the record of what you agreed to. A new version applies to consents given from the day it is published, and if a change matters we will tell existing clients rather than quietly reposting the page.

Ask us anything about this

A privacy notice you cannot get an answer about is a document, not a promise. Write to sales@suma.hk, or get in touch, and one of the founders answers.