Data Processing Agreement

This Data Processing Agreement (the DPA) governs the processing of personal data that the customer submits through the API and that we process solely on the customer's behalf.

The Controller within the meaning of Art. 4(7) GDPR is the customer (the Controller). The Processor within the meaning of Art. 4(8) GDPR is Tobias Satzger, c/o IP-Management #10800, Ludwig-Erhard-Str. 18, 20459 Hamburg, Germany (the Processor or we).

1. Subject Matter and Duration

1.1 Part of the Contract

This DPA forms part of the service contract under our Terms of Service (the Main Contract) and is concluded together with it. It is concluded in electronic form, which satisfies the form required by Art. 28(9) sentence 2 GDPR.

1.2 Subject Matter

The subject matter is the processing of personal data contained in the invoices and invoice data the Controller submits through the API (the Commissioned Data) for the purpose of generating, validating, parsing, and converting electronic invoices. The details are set out in Annex 1.

1.3 Scope Limit

This DPA does not apply to processing for which we are the controller in our own right, in particular the customer account, billing, support, audience measurement, and the operation and security of the service. Our Privacy Policy describes those.

1.4 Duration

This DPA runs for as long as the Main Contract runs and ends with it, with no separate termination required. The obligations under Section 6 (Confidentiality) and Section 13 (Deletion and Return) survive until they are fulfilled.

2. Specification of the Commissioned Processing

2.1 Annex 1

The nature and purpose of the processing, the types of personal data, the categories of data subjects, the duration, and the place of processing are described in Annex 1. Annex 1 forms part of this agreement.

2.2 No Processing for Our Own Purposes

We process the Commissioned Data solely to provide the contractually agreed service and not for our own purposes. In particular, we do not use Commissioned Data to train or improve artificial-intelligence models, and we do not pass it to third parties for that purpose.

2.3 Special Categories of Personal Data

The processing is designed for invoice data. If the Controller intends to submit special categories of personal data within the meaning of Art. 9(1) GDPR, or data under Art. 10 GDPR, it shall inform us beforehand in text form so that we can assess whether the measures under Section 5 are appropriate to the risk.

3. Rights and Obligations of the Controller

3.1 Responsibility

The Controller is solely responsible for the lawfulness of the processing and for upholding the rights of data subjects (Art. 24 GDPR). In particular, it determines the legal basis on which it submits the Commissioned Data and fulfils its information obligations towards data subjects under Art. 13 and 14 GDPR.

3.2 Right to Instruct

The Controller is entitled to issue, amend, and revoke instructions under Section 4.

3.3 Verification

Before processing begins and at regular intervals thereafter, the Controller shall satisfy itself that the technical and organisational measures in place are being complied with. It may exercise the rights under Section 12 for that purpose.

3.4 Notification of Violations

If the Controller identifies a breach of data protection law or of this agreement on our side, it shall notify us without undue delay.

4. Instructions and the Duty to Object

4.1 Processing Only on Instruction

We process the Commissioned Data only on documented instructions from the Controller, including with regard to transfers to a third country or an international organisation (Art. 28(3) sentence 2 lit. a GDPR). Where we are exceptionally required to process by Union or Member State law, we shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

4.2 Form of Instructions

The Controller's ongoing instructions follow from the parameters of its API requests: with each request, the Controller determines which operation is performed on which data and into which target format. Any further individual instruction is issued in text form to hello@beliq.eu. The Controller shall confirm any instruction given orally in text form without undue delay. We document individual instructions and retain them for the term of the agreement.

4.3 Persons Authorised to Issue Instructions

Instructions may be issued by the persons the Controller names to us. Absent a separate designation, the holders of the Owner and Admin roles in the Controller's organisation in the dashboard are treated as authorised.

4.4 Duty to Object

If we consider that an instruction infringes the GDPR or other Union or Member State data protection provisions, we shall inform the Controller without undue delay (Art. 28(3) sentence 3 GDPR). We are entitled to suspend the execution of that instruction until the Controller confirms or amends it.

5. Technical and Organisational Measures

5.1 Measures under Art. 32 GDPR

We implement the technical and organisational measures described in Annex 2. They ensure a level of protection appropriate to the risk to the rights and freedoms of data subjects. Annex 2 forms part of this agreement.

5.2 Further Development

The measures are subject to technical progress. We may adapt them as long as the agreed level of protection is not reduced. We document material changes and communicate them to the Controller on request.

5.3 Review

We review the effectiveness of the measures at regular intervals (Art. 32(1) lit. d GDPR). The procedure is described in Annex 2, section 5.

6. Confidentiality

6.1 Commitment of Personnel

We ensure that persons authorised to process the Commissioned Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3) sentence 2 lit. b GDPR). The obligation survives the end of their activity.

6.2 Instruction of Personnel

Authorised persons are familiar with the data protection provisions relevant to them and with their obligation to act only on instructions (Art. 29, Art. 32(4) GDPR).

6.3 Restriction of Access

Only persons who need it to perform this agreement have access to the Commissioned Data. That circle is limited to the Processor itself; we currently employ no staff.

7. Assistance with Data Subject Rights

7.1 Duty to Assist

We assist the Controller by appropriate technical and organisational measures in fulfilling its obligation to respond to requests from data subjects under Art. 12 to 23 GDPR (Art. 28(3) sentence 2 lit. e GDPR).

7.2 Forwarding

If a data subject contacts us directly, we forward the request to the Controller without undue delay and do not answer it ourselves unless the Controller instructs us to.

7.3 Extent of the Assistance

Commissioned Data is processed in memory and discarded once the request completes (Annex 1, section 5). No body of data ordered by data subject, from which information could be provided, which could be rectified, or from which data could be erased, therefore accumulates with us. Parts of Commissioned Data can be contained in error reports and logs, which are deleted within the periods of Annex 1, section 5. Our assistance accordingly consists primarily of information about how the processing runs and about where and for how long such parts can be held.

8. Assistance with Art. 32 to 36 GDPR

8.1 Extent

Taking into account the nature of the processing and the information available to us, we assist the Controller in complying with its obligations under Art. 32 to 36 GDPR (Art. 28(3) sentence 2 lit. f GDPR), in particular with

• the security of processing (Art. 32 GDPR),
• notifying a personal data breach to the supervisory authority (Art. 33 GDPR) and communicating it to data subjects (Art. 34 GDPR),
• a data protection impact assessment (Art. 35 GDPR) and prior consultation of the supervisory authority (Art. 36 GDPR).

8.2 Information

For a data protection impact assessment we make available the information we hold on the processing workflow, the protective measures, and the sub-processors engaged. This agreement including its annexes already covers the standard case.

9. Personal Data Breaches

9.1 Notification to the Controller

We notify the Controller without undue delay of any personal data breach affecting Commissioned Data after becoming aware of it (Art. 33(2) GDPR). Notification is given in time for the Controller to meet its own 72-hour deadline under Art. 33(1) GDPR. No fixed period replaces the standard of acting without undue delay.

9.2 Content of the Notification

The notification contains, as far as it is known to us,

• a description of the nature of the breach, where possible with the categories and approximate number of data subjects and records concerned,
• the name and contact details of a contact point,
• a description of the likely consequences,
• a description of the measures taken or proposed to address the breach and to mitigate its possible adverse effects.

Where not all of that information is available at once, we notify what is known and supply the remainder without undue delay.

9.3 Documentation and Cooperation

We document personal data breaches including the measures taken, and we assist the Controller with its notification to the supervisory authority and with any communication to data subjects. The Controller makes the notification to the supervisory authority.

10. Sub-Processors

10.1 General Authorisation

The Controller grants general written authorisation to engage further processors (Art. 28(2) sentence 1 GDPR). The sub-processors engaged at the time this agreement is concluded are listed exhaustively in Annex 3 and are thereby authorised. Annex 3 forms part of this agreement.

10.2 Notice and Objection

If we intend to add or replace a sub-processor, we give the Controller notice in text form at least four weeks in advance. Within that period the Controller may object on substantiated data protection grounds. If it objects, we are entitled not to provide the affected part of the service; the Controller is entitled to terminate the Main Contract with immediate effect if this materially impairs the service for it.

10.3 Obligations towards the Sub-Processor

We impose on each sub-processor, by contract, the same data protection obligations as are set out in this agreement, in particular sufficient guarantees of appropriate technical and organisational measures (Art. 28(4) GDPR). Where a sub-processor fails to fulfil its data protection obligations, we remain fully liable to the Controller for the performance of those obligations.

10.4 What Is Not Sub-Processing

Ancillary services that involve no processing of Commissioned Data are not sub-processing within the meaning of this Section. Annex 3, section 2 lists the providers concerned nonetheless, for transparency.

11. International Transfers

11.1 Processing within the Union Only

Commissioned Data is processed exclusively in Member States of the European Union. No transfer to a third country or to an international organisation takes place. That also applies to access for maintenance, error analysis, and support purposes.

11.2 Conditions for Any Future Transfer

A transfer to a third country requires an instruction from the Controller under Section 4.1 and a basis under Chapter V GDPR, in particular an adequacy decision under Art. 45 GDPR or appropriate safeguards under Art. 46 GDPR. Until then it does not take place. Moving to a sub-processor that processes outside the Union additionally requires notice under Section 10.2.

12. Evidence and Audit Rights

12.1 Evidence

We make available to the Controller all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR (Art. 28(3) sentence 2 lit. h GDPR). As a rule this is done through this agreement including its annexes, the description of the technical and organisational measures, and information provided in text form.

12.2 On-Site Inspection

Where the evidence under Section 12.1 does not suffice in a particular case, we allow for and contribute to audits, including inspections. The Controller may conduct them itself or mandate an auditor who is bound to confidentiality and is not a competitor of ours.

12.3 Conduct of Audits

Audits take place after reasonable notice, as a rule two weeks, during our normal business hours and without disproportionate disruption to our operations. They take place once a year as a rule. Where there is specific cause, in particular following a personal data breach or on the order of a supervisory authority, the Controller may audit more frequently and shorten the notice period.

12.4 Costs

Each party bears its own costs arising from an audit.

12.5 Supervisory Authorities

The powers of the competent supervisory authorities to investigate and to obtain information remain unaffected. We permit and cooperate with inspections by the Controller's supervisory authority (Art. 31 GDPR).

13. Deletion and Return

13.1 During Processing

Commissioned Data is processed in memory and discarded once the respective request completes. Temporary files created during processing are deleted immediately afterwards. No persistent body of Commissioned Data accumulates. Parts of Commissioned Data that reach error reports or logs are deleted within the periods of Annex 1, section 5.

13.2 After the End of the Agreement

After the end of the provision of processing services we delete or return all Commissioned Data at the Controller's choice and delete existing copies, unless Union or Member State law requires storage (Art. 28(3) sentence 2 lit. g GDPR). Since no persistent body of data accumulates under Section 13.1, that choice is generally moot; parts in error reports and logs are deleted under Annex 1, section 5. On request we confirm deletion in text form.

13.3 Metadata

The metadata stored for each operation (Annex 1, section 3) contains no Commissioned Data. Its deletion is governed by our Privacy Policy.

13.4 Backups

Backup copies of our database contain parts of Commissioned Data where such parts are in the database, in particular in error reports in our error tracker (Annex 1, section 5). They are deleted after 45 days.

14. Liability

14.1 Liability towards Third Parties

Liability towards data subjects and administrative fines are governed by Art. 82 and Art. 83 GDPR. This agreement cannot derogate from those provisions.

14.2 Liability between the Parties

As between the parties, the liability regime in Section 9 of the Terms of Service applies. It does not apply to claims by data subjects under Art. 82 GDPR, nor to the apportionment between the parties under Art. 82(5) GDPR.

15. Contact Points

15.1 On Our Side

The contact point for data protection is Tobias Satzger, reachable at hello@beliq.eu. We have not appointed a data protection officer; we are not required to under Art. 37 GDPR in conjunction with § 38 BDSG.

15.2 On the Controller's Side

The Controller names its data protection contact point to us on request. Absent a separate designation, the email address held in the account is treated as the channel.

16. Final Provisions

16.1 Precedence

In the event of conflict between this DPA and the Main Contract, this DPA prevails in so far as it concerns the processing of Commissioned Data.

16.2 Amendments

Amendments to this DPA are made under Section 13 of the Terms of Service. Amendments necessary to adapt to changed data protection requirements may also be made where they affect the scope of the service.

16.3 Governing Law and Jurisdiction

German law applies. Section 14.2 of the Terms of Service governs jurisdiction.

16.4 Severability

If a provision of this agreement is invalid, the remainder of the agreement stays in force. The statutory rule takes the place of the invalid provision.

16.5 Language

The German version of this agreement is authoritative. This English version is a non-binding translation.

Annex 1: Description of the Processing

1. Subject Matter

Processing of personal data contained in the invoices and invoice data the Controller submits through the API, in the course of providing the Beliq API.

2. Nature and Purpose of the Processing

• Generating: creating an electronic invoice from the structured data the Controller submits, including producing a PDF rendering.
• Validating: checking submitted documents against EN 16931 and the national profiles selected, including returning validation messages.
• Parsing: turning submitted documents into a structured representation and returning it to the Controller.
• Converting: turning submitted documents from one supported format into another.
• Delivering the result: returning the processing result to the Controller through the API response or through a webhook it has configured.

The purpose is solely to provide those services to the Controller, including the analysis of faults that affect them (section 5).

3. Types of Personal Data

Which personal data is processed is determined by the Controller through the content it submits. Invoice data typically contains:

• names and contact details of invoice issuers, invoice recipients, and their contact persons (address, email address, telephone number),
• details of the invoice and the supply (invoice number, line items, amounts, period of supply, order and contract references),
• tax and payment details (VAT identification number, tax number, bank details including IBAN),
• identifiers for electronic invoicing (such as Leitweg-ID or a Peppol participant identifier).

The metadata we store for each operation covers the operation type, the standard and profile, the input and output format, the status, validation results, processing time, and the assignment to the Controller's organisation. Validation results are stored without the text of their messages, with only the rule, severity and location. When an operation fails, we also store the message that gives the reason. Before storing it, we remove quoted values and some recognisable identifiers such as email addresses; it can still contain names, addresses and other details from a submitted invoice. Beyond that, the metadata contains no Commissioned Data.

4. Categories of Data Subjects

• customers and suppliers of the Controller,
• employees and contact persons of the Controller,
• employees and contact persons of the Controller's customers and suppliers,
• any other natural persons whose data is contained in the submitted content.

5. Duration of Processing and Storage

Commissioned Data is processed in memory for the duration of the respective API request and discarded afterwards. It is not stored persistently. Temporary files created during processing are deleted immediately after the request. Otherwise the duration follows Section 1.4 of this agreement.

Error reports and logs. Where an error report or a log line of our services reproduces parts of Commissioned Data, such as a name or an address from a submitted invoice, those parts remain there: in our error tracker for at most 90 days, in the encrypted backup copies of its database until they are deleted (Section 13.4), and in the logs of the services in the cluster until rotation overwrites them or they are deleted with the respective service instance. They do not reach our central log store: warnings and errors of the services that process invoices and of our error tracker reach it only without their text, and messages of the database only without the values they reproduce.

Fault analysis. When a fault occurs, we also analyse it with the help of a language model. For this we read error reports and logs of our services and our infrastructure, metrics, and the configuration and state of the cluster. These contain IP addresses and requested paths, and error reports can contain parts of Commissioned Data. The fault analysis has no access to the database or to credentials. What it reads is transmitted to Scaleway SAS in Paris for the analysis of the fault (Annex 3, section 1). Under its terms Scaleway does not store the request by default; if it detects abuse or a fault that affects its service, it may store the content for up to two weeks according to its documentation. The content is not used to train models. The fault analysis is run from a workstation in Germany (section 6); the records of an analysis created there are deleted after 30 days.

6. Place of Processing

Processing takes place exclusively within the European Union: in data centres in Germany, for the fault analysis and the encrypted backup copy in a second location also in France, and on the workstation in Germany from which we run the fault analysis. Access for maintenance and error analysis likewise takes place exclusively from within the European Union.

Annex 2: Technical and Organisational Measures

Measures under Art. 32 GDPR, grouped by protection objective. We operate no data centres of our own; the structural and physical measures are provided by the sub-processors named in Annex 3, section 1, whose evidence we pass on upon request.

1. Confidentiality

Physical access control. Access to the data centres is controlled by the sub-processors under their own measures. We maintain no server rooms of our own. The disk of the workstation from which we run the fault analysis is fully encrypted.

System access control. Access to systems only through personal accounts secured with a second factor. Administrative access to the infrastructure exclusively through key pairs; password authentication is disabled. Session tokens are signed, valid for at most seven days, and revoked immediately on a password change or an account lock.

Data access control. Role and permission based control in the dashboard. In the database, row-level security per organisation and least-privilege database roles; the application role does not own the schema. API key secrets are stored only as a SHA-256 hash, passwords as an Argon2id hash.

Separation control. Tenants are separated in the database by row-level security; services are separated in the cluster by network policies; test and production environments are separate, as are the keys used for test mode.

2. Integrity

Transfer control. Transmission exclusively encrypted over TLS 1.3. Sensitive fields at rest (email addresses, secrets, PDF templates) encrypted with AES-256-GCM. Backups encrypted and held in two locations, both in the European Union.

Input control. Metadata recording the time, the operation type, and the assignment to the organisation is kept for every processing operation. Security-relevant account events (sign-in, key changes, role changes) are logged.

Data minimisation. Commissioned Data is processed in memory and not stored persistently. It reaches metadata only through the message of a failed operation, from which we remove quoted values and some recognisable identifiers before storing it; validation messages are stored without their text (Annex 1, section 3). Text in messages that can reproduce parts of it is removed before the message reaches the central log store (Annex 1, section 5).

3. Availability and Resilience

• operation on a Kubernetes cluster across two data centres with auto-scaling,
• database with replication and automatic failover to the standby,
• regular encrypted backups in two locations, both in the European Union, deleted after 45 days,
• rate limiting and abuse detection to protect availability,
• monitoring of logs, metrics, and errors on our own installations in the European Union; secrets are not captured, and parts of Commissioned Data only under Annex 1, section 5.

4. Pseudonymisation and Encryption

• encryption in transit with TLS 1.3,
• encryption of sensitive fields at rest with AES-256-GCM,
• passwords as an Argon2id hash, API key secrets as a SHA-256 hash, verification codes as a keyed one-way hash,
• lookup of encrypted email addresses through a keyed hash, without decrypting the stored set.

5. Procedure for Regular Review

• Changes to the application pass an automated pipeline with tests and static analysis before they ship.
• Dependencies are continuously checked for known vulnerabilities and updated.
• The effectiveness of the measures is reviewed on every material change to the architecture or to data handling, and at least annually.
• Procedures for restoring from backup and for switching the database instance are exercised in practice.
• Channels for reporting vulnerabilities are published at security.txt.

Annex 3: Authorised Sub-Processors

1. Sub-Processors with Access to Commissioned Data

The following sub-processors are authorised under Section 10.1. Commissioned Data, or parts of it in the course of the fault analysis, are processed with them; how long such parts remain is governed by Annex 1, section 5.

2. Other Providers without Access to Commissioned Data

We use the following providers for ancillary services. They do not process Commissioned Data. They are not sub-processors within the meaning of Section 10 and are listed here purely for transparency. Our Privacy Policy describes their role in the processing for which we are the controller in our own right.

Google, GitHub, and Microsoft act as independent controllers when used to sign in through a third party, and are neither sub-processors nor processors. They are involved only where the user expressly chooses that route.