Data Processing Addendum (DPA)

This Data Processing Addendum under Article 28 GDPR forms an integral part of the Parsurai Terms of Service where Parsurai processes personal data on the Customer’s behalf.

Last updated: 21 September 2026

Dr. Sadjad Sadeghi, JadayLix Studio, Schieferkamp 41, 30455 Hannover, Deutschland, contact@parsurai.com

Owner-approved wording. No external legal review has been performed. External legal review remains recommended before material enterprise use, significant scale, or a material dispute.

The German version is authoritative. The English and French versions are translations provided for information.

§ 1 Subject matter, incorporation and precedence

This DPA applies to personal data Parsurai processes on the Customer’s behalf through the extraction API and enabled accounts-payable or document workflows. It is an integral part of the main agreement. For processor data, this DPA prevails over conflicting provisions of the main agreement. Processing for which Parsurai determines its own purposes and essential means – including account administration, contract administration, billing, security, abuse prevention and Parsurai’s own statutory records – is outside this DPA. Hosted external reviewer sessions are disabled and outside its scope.

§ 2 Subject matter and duration of processing

Processing covers the contracted document-processing services, including receipt and technical processing of invoices and business documents, OCR, content analysis, extraction and structuring, classification, format normalisation, duplicate and anomaly checks, enabled accounts-payable workflows and agreed exports. Processing starts when the Customer uses an in-scope feature and generally ends when the main agreement ends and processor data are returned or deleted as agreed.

§ 3 Controller instructions

Parsurai processes processor data only on documented instructions from the Customer unless applicable law requires otherwise. Instructions arise from the main agreement and DPA, selected product functions and settings, submitted documents, API calls and documented additional instructions. Where legally required processing applies, Parsurai informs the Customer in advance where permitted. Parsurai promptly informs the Customer if it considers an instruction unlawful and may suspend it pending clarification. Processor data are not used for advertising, sale of personal data, cross-customer model training or other independent purposes.

§ 4 Controller obligations

The Customer is responsible for the lawfulness of the personal data it provides, an applicable legal basis, and required transparency obligations. This includes assessing Article 14 duties for data not collected directly from the data subject. The Customer limits submitted data to what is necessary and does not knowingly issue unlawful instructions.

§ 5 Special categories of personal data

Parsurai is not designed specifically for processing special categories of personal data under Article 9 GDPR. Such data may nevertheless appear incidentally or unintentionally depending on document content. Where the Customer provides such data, the Customer remains responsible for satisfying Articles 6 and 9 GDPR. Parsurai processes such data only under documented instructions and may refuse or restrict processing where additional security or compliance measures would be required.

§ 6 Confidentiality

Parsurai ensures that persons authorised to process processor data are bound by confidentiality or an appropriate statutory duty of secrecy. Access is limited to persons and systems that need it to provide or secure the service. Confidentiality obligations continue after the relevant activity ends.

§ 7 Security of processing

Taking into account the state of the art, implementation costs and the nature, scope, context and purposes of processing, Parsurai implements appropriate technical and organisational measures under Article 32 GDPR. Current measures are described in Annex 2. Measures may evolve provided the agreed overall level of protection is not reduced; material changes are documented.

§ 8 Sub-processors

The Customer grants Parsurai general written authorisation to engage sub-processors. Current providers are listed in the published Subprocessors list and are approved when this DPA is concluded. New or replacement sub-processors are normally notified in text form at least 14 days before use. The Customer may object on reasonable data-protection grounds. Parsurai imposes Article 28(4) GDPR obligations on sub-processors and remains responsible to the extent required by law.

§ 9 International transfers

Third-country transfers take place only under documented instructions or through approved sub-processors and in compliance with Articles 44 et seq. GDPR. Depending on the recipient, this may include an adequacy decision or appropriate safeguards such as Standard Contractual Clauses. Applicable transfer mechanisms are identified in the sub-processor documentation.

§ 10 Assistance with data-subject rights

Taking into account the nature of processing, Parsurai assists the Customer where possible through appropriate technical and organisational measures with requests under Chapter III GDPR. Requests received directly by Parsurai concerning processor data are normally forwarded to the responsible Customer. Parsurai does not independently answer them as controller unless required by law or instructed by the Customer.

§ 11 Assistance with security, breaches and impact assessments

Taking into account the nature of processing and information available to it, Parsurai assists the Customer with obligations under Articles 32 to 36 GDPR. Breaches involving processor data are notified without undue delay after becoming known; available information may be provided in stages. Assistance includes, where required, security assessment, supervisory-authority notifications, data-subject notices, data protection impact assessments and prior consultations.

§ 12 Deletion and return

After processing ends, Parsurai deletes or returns processor data at the Customer’s choice and deletes existing copies unless applicable law requires continued storage. Unless the Customer documents a different instruction, deletion is the default instruction. Technically necessary backup or point-in-time-recovery copies may remain until the end of their rotation window and are not used for ordinary product purposes during that period. Parsurai’s own statutory retention as controller – for example billing records or narrowly limited evidence of legal-document acceptance – is not retention of processor data under this DPA.

§ 13 Information and audits

Parsurai provides information reasonably necessary to demonstrate compliance with Article 28 GDPR and permits audits, including inspections, by the Customer or an independent auditor bound by confidentiality. Existing security documentation, certifications or other suitable evidence should be used first where they reasonably meet the audit purpose; this does not exclude a necessary additional audit. Planned audits should be conducted with reasonable notice and with due protection of security, confidentiality, trade secrets and other customers’ data.

§ 14 Responsibility and liability

Each party fulfils the GDPR obligations applicable to its role. The liability provisions of the main agreement apply additionally unless mandatory data-protection law, including Article 82 GDPR, requires otherwise. Nothing in this DPA restricts rights of data subjects or powers of supervisory authorities.

§ 15 Term and changes

This DPA applies for the duration of processor processing and ends when Parsurai no longer processes processor data for the Customer and § 12 has been fulfilled. Material amendments are published through the contractual change mechanism and, where required, must be re-accepted before continued use of affected features. Changes to the Subprocessors list are governed by § 8.

§ 16 Final provisions

The law agreed in the main agreement applies. Jurisdiction follows the main agreement where legally permissible. If a provision is invalid, the remaining provisions remain effective; the statutory rule applies where a valid interpretation preserving the lawful purpose is not possible.

Annex 1 — Description of processing

Subject matter: automated processing of invoices, receipts and other business documents supplied by the Customer, together with associated structured results and workflow data. Purposes: document intake, OCR and content analysis, extraction of structured invoice information, classification, normalisation, duplicate and anomaly checks, accounts-payable workflows, enabled exports and directly related technical processing. Operations: transmission, receipt, reading, OCR, analysis, extraction, structuring, classification, comparison, temporary or feature-dependent storage, output, export and deletion. Data subjects: in particular the Controller’s customers and business partners, suppliers, service providers, sole traders, contacts, employees, case handlers, approvers, signatories, invoice issuers and recipients. Data types: names, business contact details, addresses, email addresses, phone numbers, functions/job titles, invoice and contract information, order/service information, payment information, bank details including IBAN/BIC, tax information, amounts, line items, approval information, derived structured data and technical processing metadata. Special categories: not a target of the service but may occur incidentally; lawfulness of providing such data remains the Customer’s responsibility. Retention behaviour: extraction-API document payloads are generally processed transiently unless a storage feature is used. Structured extraction results may be stored where invoice history is enabled; product visibility windows are not automatically physical deletion periods. Accounts-payable source documents and derived workflow artifacts currently use 0 days for Free/Hobby/Starter, 30 days for Pro and 90 days for Business and are removed through the implemented purge process after expiry. Other structured records and metadata may follow separate documented retention mechanisms.

Annex 2 — Technical and organisational measures

Transport encryption: customer and server connections are provided over HTTPS/TLS. Authentication: API keys are not retained as retrievable plaintext after issuance; persisted keys are hashed with bcrypt. Production secrets are managed through environment/secret configuration rather than committed production values. Access separation: customer data are logically separated through user/tenant association, database relationships, ownership checks and application controls. Data at rest: databases and object storage use encryption-at-rest mechanisms provided by the relevant infrastructure providers. Data minimisation/retention: extraction API document payloads are generally transient; workflow artifacts and temporary exports have defined retention and deletion periods. Monitoring: document contents should not be stored as ordinary application logs. Sentry uses send_default_pii=False; server-side scrubbing, default scrubbers, IP-storage prevention and Enhanced Privacy are enabled. Availability: point-in-time recovery is documented for the production database; backup/restore processes have been operationally tested. Background processing is separated from web processing. Abuse protection: rate limits and limits on document size, page count and concurrency protect public and resource-intensive processing. Change management: version control plus automated unit, integration, configuration and build checks are used for relevant changes. Privacy by configuration: incompletely assessed features can be disabled server-side; Hosted External Reviewer Sessions remain disabled for MVP. Sub-processors: providers, contractual bases and relevant transfer mechanisms are documented. Incident response: a documented incident/breach-response process and monitoring/logging systems support investigation and notification.

Annex 3 — Parsurai processing as independent controller

Processing outside this DPA includes account creation and administration, authentication and account security, API-key administration as an account feature, contract/version acceptance, invoicing and payment administration, platform abuse/fraud prevention, Parsurai’s own statutory documentation and retention duties, and support/service administration. The Parsurai Privacy Policy and applicable law govern these activities.

Data Processing Addendum (DPA) — Parsurai | Parsurai