Data processing agreement

The controller is the company that signs up for Heft ("you"). The processor is Josef Moucachen, trading as Synthropy, Piraeusplein 75, 1019 NM Amsterdam, Netherlands, KvK 94099660 ("Heft", "we"). Write to Heft at support@namequick.app for anything under this agreement.

This agreement covers only the personal data Heft processes for you: your company's payments, receipts, books and what you tell Heft about them. Data Heft processes as its own controller, such as your sign-in and billing, is covered by the privacy policy.

Heft processes personal data to provide the service in the terms of service: collecting your company's receipts and bank payments, reading them, matching them, keeping your books and preparing your VAT figures. Annex 1 lists the kinds of data and the people they concern. This agreement runs as long as Heft processes personal data for you, including after the terms end while Heft still keeps your records for you (section 10).

Heft processes the data only on your documented instructions, unless EU or member state law requires otherwise; in that case Heft tells you first, unless that law forbids it. Your instructions are this agreement, the terms of service, and what your company's members do in Heft: the sources they connect, the steps they approve and the settings they choose. If Heft thinks an instruction breaks data protection law, it tells you and may wait until you confirm or change it.

You are responsible for the lawfulness of the processing you ask for, and for informing the people whose data your records hold, such as your suppliers, customers and staff.

Everyone at Heft who can access the data is bound to keep it confidential. Heft's support can see your company's data only when one of your directors grants that access in Heft: read-only, for 30 days at most, and ended by any director at any time. When a member of your company sends Heft a question to find a tax adviser, a person at Heft sees the payments and receipts that question names, through a link that works for 30 days at most.

Heft takes the technical and organisational measures in Annex 2 to protect the data (Art. 32 GDPR). Heft may change them as technology develops, as long as the level of protection does not drop.

You allow Heft to use the sub-processors in Annex 3. Before Heft adds or replaces one, it tells your company's directors by email at least 30 days in advance. You may object in writing (email is enough) within that time, for a reason based on data protection. If we cannot solve the objection together, you may end the terms with effect from the date the new sub-processor starts, and what you paid for the time after that date is refunded through Polar.

Heft binds each sub-processor by contract to the same data protection duties as in this agreement (Art. 28(4) GDPR), and remains responsible to you for its work. Browserbase is the exception for now: it works under its own terms of use, without such a contract (Annex 3).

Heft transfers personal data to a country outside the European Economic Area only with a safeguard under Chapter V of the GDPR: an adequacy decision, such as the EU-US Data Privacy Framework for a certified company, or the EU standard contractual clauses. Annex 3 says which applies to each sub-processor. For Browserbase none is in place yet, as Annex 3 says.

Heft helps you, as far as it can with the information it has:

• to answer requests from people who use their rights under the GDPR (access, correction, deletion, restriction, portability, objection). Most you can answer yourself in Heft, for example with the export. If a request reaches Heft directly, Heft passes it to you and does not answer it alone;
• with security, breach notices, data protection impact assessments and prior consultation (Art. 32 to 36 GDPR).

Heft may ask for its costs for help that goes beyond what the service offers anyway, if it tells you the cost first.

If Heft becomes aware of a breach of the personal data it processes for you, it tells your company's directors without undue delay, and within 48 hours at the latest. The notice says what Heft knows by then: what happened, which data and roughly how many people are concerned, the likely consequences and what Heft has done or proposes. Heft adds what it learns later. This lets you meet your own duty to report within 72 hours (Art. 33 GDPR).

You can export your company's records at any time while you use Heft. When the terms end, Heft ends all connections and deletes their access keys at once.

Your receipts and books are subject to legal retention periods (see Annex 1). Unless you tell Heft otherwise, you instruct Heft to keep them for you, readable and exportable, until those periods end, and then to delete them. A retention rule keeps original files for 9 years from the day they arrived, and Heft's services cannot delete them while it applies (Annex 2), so Heft deletes them only after that. If you want everything handed over and deleted sooner, tell Heft: it gives you a full export and deletes what the law does not require Heft itself to keep, apart from the original files, which the retention rule keeps until their 9 years have passed.

Heft gives you the information you need to show that this agreement is kept. You may audit this, yourself or through an independent auditor bound to confidentiality, once a year, or more often after a breach or on a supervisory authority's request. Tell Heft at least 30 days ahead. An audit should first rely on documents and reports Heft provides; an inspection on site follows only if those are not enough. Each party bears its own costs.

Liability under this agreement follows the terms of service, except where Art. 82 GDPR says otherwise. If this agreement and the terms of service conflict on data protection, this agreement wins. This agreement is governed by the same law as the terms of service: Dutch law, with the competent court in Amsterdam.

These are the measures Heft takes under Art. 32 GDPR, grouped by what they protect.

Where the data lives

• All servers, the database, files, backups, keys and logs are in one Google Cloud project in Frankfurt (europe-west3). Backups run daily, with 7 days of point-in-time restore, and stay in Frankfurt.
• The database has only a private network address. Services reach it over Google's private network, and every connection is encrypted.
• Data is encrypted at rest by Google Cloud and in transit with TLS.
• Heft's servers check every outgoing connection against a fixed list of providers, plus suppliers' own public websites (for their logo, and for sign-ins you start), and refuse any other before it opens.

Records that cannot be changed

• Original files are stored so that Heft's own services cannot change or delete them: the API can add and read files, the worker can only read them. A retention rule in Google Cloud keeps each file for 9 years from the day it arrived; only Heft's owner can change that rule, and Google Cloud logs every change to it.
• The books are an append-only log. A correction is a new entry that says who made it, when and why; nothing is overwritten.
• Each step a person approves is stored with the exact text they were shown and a checksum of it.

Secrets and access keys

• Access keys for connected sources are sealed with AES-256-GCM, each under its own data key, wrapped by a master key held in Google Secret Manager in Frankfurt. Only the background worker's code opens a key, to read. Until the master key moves to Google Cloud KMS, the API service holds it too.
• Sign-in codes, session tokens and invitation links are stored only as cryptographic hashes.
• Access keys never appear in logs, model calls or answers from Heft's interfaces. An access key typed into the chat is refused before it is stored or sent anywhere.

Who can access what

• Each Heft service runs with its own account and only the rights it needs: the API can add original files but not delete them; the worker can only read them; only the set-up job holds the database owner's password.
• Within a company, roles decide who may see and approve what. Directors are told when a member, an access or a login is added.
• Heft's support sees a company's data only with a director's grant, read-only and for 30 days at most, or the payments and receipts named in a question a member sends Heft for a tax adviser, for 30 days at most.
• Sign-in is by a one-time email code. Under the permission given at sign-up, Heft records receipts and matches them to payments on its own when it is sure. Anything it is not sure of, locking a month and changes to the company's details wait for a person: a tap, a typed yes, or a standing rule that person set for one supplier and can end. Every change says who or what made it and can be undone until the month is locked.

AI models

• Each model call gets only what its step needs. In the text of a chat request, the company's own email addresses are replaced by their domain; files and photos go as they are.
• Model providers are bound by contract not to train on the data.

Watching and recovering

• Technical logs are kept in Frankfurt for 30 days. Error reports have email addresses, IBANs and access keys removed first.
• Uptime checks and alerts tell Heft when the service fails. Earlier versions can be redeployed from the image registry.
• Every change to Heft's code is reviewed and tested before it is deployed.

Heft uses these sub-processors for your company's data. Version: 2026-11-09, in force from 9 November 2026.

Not sub-processors: the services your company connects itself (its bank, finAPI or Stripe Financial Connections where it connects its bank through them, Google for Gmail, supplier websites), which Heft reaches on its behalf under their own terms; OpenStreetMap's Nominatim, which gets only a merchant's name, a town and a country; and supplier websites, which get only their own domain when Heft fetches their logo.