Legal

Data processing agreement

When you issue an invoice you entrust us with your counterparty's data. This is the agreement that says what we may do with it.

Data Processing Agreement — Ksefly

Version: 1.0 (draft) · Drawn up: 22 August 2026 · In force from: ⟨TO BE COMPLETED: the date this agreement is published on ksefly.app⟩

This agreement (the “DPA”) governs Ksefly’s processing of personal data for which you are responsible — the data of the people who appear on your invoices and in your records. We enter into it because art. 28(3) GDPR requires it: anyone who entrusts personal data to someone else must do so under a contract with a prescribed content.

The DPA forms an integral part of the Terms of Service and is complemented by the Privacy Policy, which describes the data we process as a controller — that is, your account data, not your counterparties’ data.

The Polish version controls. This English text (ksefly.app/powierzenie is the Polish original) is provided for information; in case of any discrepancy the Polish wording prevails.

In short — seven things before you read the rest

  1. You are the controller, we are the processor — but only for your counterparties’ data. For your account data we are the controller, and this agreement does not reach there (§ 2).
  2. Not every B2B invoice contains personal data. If your counterparty is a company, its tax number and name are not personal data. This agreement matters when the other side is a sole trader, a natural person, or a named contact person (§ 5).
  3. Your instruction is the way you use the app. Issuing an invoice instructs us to build it and send it to KSeF. Saving a counterparty instructs us to keep their details in the Vault (§ 7).
  4. Invoice content goes to an AI model in the US, and today there is no way to switch it off. Both party names, the amount and the line-item names go to Anthropic so that a one-line invoice description can be produced. We say so plainly, because it is the furthest-reaching element of this processing (§ 7(5) and Annex A).
  5. We say what we do not encrypt. Party names and addresses, all amounts, invoice numbers and your own notes sit in our database as plain text at the column level (§ 9.3). An agreement claiming more would be untrue.
  6. We delete on your request — with exceptions we name. Two kinds of record do not disappear with your account today (§ 16(4)).
  7. Invoices in KSeF are not ours and we cannot delete them. Once a document reaches KSeF, the Ministry of Finance also becomes a controller of that data, on its own statutory basis (§ 11(2)).

§ 1. Parties, scope and how this agreement is concluded

  1. Processor (“we”, “us”, “Ksefly”): developNET Maciej Matysiewski (brand: develop.NET), ul. Nowowiejska 6/6, 00-649 Warszawa, Poland, NIP 1182238190, REGON 521446646 — a sole trader registered in the Polish CEIDG register.
  2. Controller (“you”): a Ksefly user who has connected at least one company (taxpayer context) to their account and uses the service in the course of their business.
  3. The address for every notice under this agreement — instructions, requests, objections to a sub-processor, audit questions and reports: privacy@ksefly.app. We reply from the same address, to the address the message came from, unless you name another.
  4. Conclusion. The DPA is concluded at the moment the Terms of Service are concluded — that is, when you create your account — and binds from the moment you connect your first company. We do not exchange signatures: the text is published, numbered, dated, and can be downloaded, reproduced and stored at any time, which meets the requirement of writing, including electronic form, in art. 28(9) GDPR. On request we will send you a PDF of this version by e-mail. ⟨TO CONFIRM: a lawyer should confirm that publication plus acceptance through the Terms is sufficient in your case, and whether you also want an explicit in-app “I accept the DPA” with the date and version recorded.⟩
  5. Precedence. For the processing of personal data you entrust to us, this agreement prevails over the Terms of Service. In all other matters the Terms apply.

§ 2. Who is the controller and who is the processor

  1. We are a processor for personal data that reaches the service because you run your business: your counterparties’ data on sales and purchase invoices, the data in your contractor book, the data in queued and scheduled sends, and everything else listed in § 4.
  2. We are a controller — and this agreement then does not apply, the Privacy Policy does — for:
    • your account data (the Sign in with Apple identifier, the Apple refresh token, session tokens, push device registrations),
    • the fact that you are the user of a given company (a context’s tax number is at once your own personal data and the anchor for the processing entrusted to us),
    • our server’s technical logs and telemetry,
    • data we process to meet our own legal obligations (tax, accounting) or to bring or defend claims.
  3. A dual role on one tax number. If you are a sole trader yourself, your NIP, name and address are at once your personal data (we are the controller) and the seller’s data on the document (you are the controller as against the other side). We do not split this artificially; in practice it means you have the rights described in the Privacy Policy as to your own data, and the obligations in § 18 as to your counterparty’s.
  4. Independent controllers. KSeF (the Ministry of Finance), the VAT White List, GUS BIR, VIES, Apple as regards subscriptions and Stripe as regards its own regulatory duties are not our sub-processors — they act as independent controllers on their own legal basis (§ 11(2)).

§ 3. Subject matter, nature, purpose and processing operations

(art. 28(3) GDPR, opening sentence)

  1. Subject matter: processing of personal data contained in your documents and records to the extent necessary to provide the Ksefly service.
  2. Nature: cloud processing, by automated means, on our servers and on your device, comprising in particular: collection, recording, storage, organisation, consultation, retrieval, use, transmission, disclosure by transmission and erasure.
  3. Purpose: solely to provide the service described in the Terms. We do not process entrusted data for our own purposes — we do not build marketing profiles from it, do not sell it, do not disclose it to anyone outside Annex A, and do not use it to train models.
  4. The specific operations we carry out on your instruction:
    • building the FA(3) document from the data you enter and transmitting it to KSeF on your behalf;
    • retrieving from KSeF the invoices issued to your tax number and storing their projection;
    • storing an encrypted copy of your records (the Vault) so they survive the loss of a phone, and synchronising it across your devices;
    • reading the contractor book so that a push notification can show your own name for a counterparty rather than the registered one;
    • checking a counterparty’s tax number against the White List, GUS BIR or VIES when you ask;
    • generating the one-line invoice description and — on your request — a draft booking note, with the involvement of an AI model provider (§ 7(5));
    • issuing a payment link or accepting a payment through the reader in your phone, where the party to the payment services contract is you, not us (§ 11(2)(e));
    • generating PDF visualisations, summaries and the accountant package;
    • deleting data when you ask us to.

§ 4. Types of personal data

(art. 28(3) GDPR)

The processing covers the following types of data — insofar as, in a given case, they concern a natural person:

GroupData
Counterparty identificationtax number (NIP), REGON, name (including a sole trader’s forename and surname), the custom name you give them, legal form, VAT and VIES status
Addressstreet, number, postal code, town, country
Contactcounterparty e-mail addresses (entered by you or fetched from the GUS register)
Settlement databank account numbers (NRB/IBAN) with the White List check result, payment method and due date, split-payment marker
Document contentinvoice number, dates, line-item names and descriptions, quantities, units, prices, VAT rates and amounts, currency, exchange rate, notes, exemption basis, correction details
Official documentsthe KSeF number, the SHA-256 digest of the document, the UPO (official confirmation of receipt) — ⟨TO CONFIRM: whether a UPO carries counterparty data at all. The app’s parser reads only the name of the receiving body in it, and a UPO is the receipt for your submission; if that is so, this row is not entrusted data and leaves this table — which is why the counterparty notice deliberately does not mention UPOs⟩
Your own records about a counterpartythe note you write when accepting a purchase invoice, template content, the footer and signature in your e-mail, your company logo
AI outputthe one-line invoice description generated from the party names and line-item names
Payment dataamount, currency, status, method and wallet type, card brand and last four digits, Stripe receipt URL

Special categories of data (art. 9 GDPR) and criminal-conviction data (art. 10) are not part of this processing. The service has no fields for such data and never asks for it. Note, however, two places where it can end up through content you type yourself: an invoice line-item name and an acceptance note. If your line of work means the description of a service reveals health data, trade-union membership or the like (a medical practice, a law firm), assess this before typing it — all the more so because line-item names are sent to the AI model provider (§ 7(5)). If you enter such data nonetheless, we process it on your instruction and on your responsibility as controller.

§ 5. Categories of data subjects

(art. 28(3) GDPR)

  1. Your buyers — the counterparties you invoice: sole traders, partners in civil-law partnerships and — if you issue the document that way — natural persons not in business.
  2. Your suppliers — the issuers of invoices you receive from KSeF, to the same extent.
  3. People named individually in your contractor book: contact persons, the owners of e-mail addresses and the holders of bank accounts.
  4. People named in the content of a document — if you write them in yourself (in a line-item name or in the notes).

This processing does not cover your employees as such; Ksefly has no HR or payroll functions.

§ 6. Duration of the processing

(art. 28(3) GDPR)

  1. We process entrusted data for as long as the Terms are in force — that is, for as long as your account exists — and end it as described in § 16.
  2. Individual data is deleted earlier when you delete it: deleting a book entry, deleting a company (context) or deleting your account triggers deletion on our side.
  3. We operate no time-based retention today. No mechanism erases data after a fixed period; data lives as long as the account or company it belongs to. We say this plainly, because an agreement silent on the point would imply an order that does not exist. ⟨TO BE COMPLETED: if you want retention periods (e.g. deleting the invoice projection X years after issue), they must be written here together with their basis.⟩
  4. Database backups are kept for 7 days and overwritten automatically; deleted data disappears from backups after that period at the latest.
  5. After this agreement ends we process entrusted data only to the extent the law requires (§ 16(3)).

§ 7. Processing only on documented instructions

(art. 28(3)(a) GDPR)

  1. We process entrusted data only on your documented instructions. Your instructions are:
    • this agreement and the Terms — which describe the operations in § 3(4) as the standing content of the service;
    • the way you use the app — every invoice issued, counterparty saved, send scheduled, tax number checked or accountant package generated is an instruction to carry out that specific operation;
    • a message to privacy@ksefly.app — for anything that cannot be expressed through the app’s functions.
  2. We will tell you immediately if, in our opinion, an instruction of yours infringes the GDPR or other data protection law, and we may suspend carrying it out until the matter is settled (art. 28(3), final sentence, GDPR).
  3. If Union or Member State law requires us to process beyond your instructions (for example, an authority’s demand), we will inform you before processing — unless that law prohibits it on important grounds of public interest. This does not extend to demands from third-country authorities, to which we are not subject and which we do not act on without a basis in Union or national law.
  4. We do not process entrusted data for our own purposes. In particular we do not use it to train or fine-tune models — ours or anyone else’s; in our contracts with the AI model provider we require such use to be excluded ⟨TO BE COMPLETED: confirm and state what retention terms Anthropic operates under today⟩.
  5. The exception you must know about: the AI-generated invoice description. To show the one-line description (“what is this invoice for”) under a row in the list, we send the AI model provider the seller’s name, the buyer’s name, the gross amount, the currency and the names of up to 20 line items. This happens automatically after each invoice is synchronised and today there is no way for a controller to switch it off: the “Ksefly Intelligence” switch in the app governs a different feature (the Pulse sentence) and does not cover this path. Treat entering into this agreement as an instruction to run this operation too, and record it in your own record of processing activities. ⟨TO BE COMPLETED: the owner must decide whether the feature gets a controller-facing switch or stays an inherent part of the service. If it gets a switch, this paragraph then describes how to use it rather than its absence.⟩
  6. The two other AI features work differently and we list them for completeness: the draft booking note is produced only when you tap for it and sends the seller’s name, the amount and the line-item names; the Pulse sentence runs only with consent (off by default) and sends no names and no document numbers — only aggregate figures and behavioural traits. Details: § 4 of the Privacy Policy.

§ 8. Confidentiality

(art. 28(3)(b) GDPR)

  1. We ensure that every person we authorise to process entrusted data has committed to confidentiality or is under a statutory obligation of confidentiality — including after the engagement ends.
  2. The position as at the date of this agreement: Ksefly is run by one person, and only that person has access to production systems. We employ no staff and engage no contractors with access to entrusted data.
  3. If that changes, every new access will be preceded by a written confidentiality undertaking and an authorisation limited to the minimum necessary; we keep a register of such authorisations.
  4. Access to production data happens only to keep the service running, to diagnose a failure or to carry out your request — never out of curiosity and never for our own purposes.

§ 9. Security of processing

(art. 28(3)(c) and art. 32 GDPR)

9.1. The measures we apply

  1. In transit: all communication between the app and our server, and between our server and third parties, runs over TLS; the server enforces HSTS.
  2. Database: PostgreSQL on Microsoft Azure, reachable only through a private endpoint from our virtual network — with no public access from the internet. Authentication is by managed identity (Microsoft Entra) only; password authentication is disabled, so there is no database administrator password that could leak.
  3. Secrets (API keys, the signing key, credentials) live in a managed key vault, not in code or in application configuration.
  4. Column-level encryption (AES-256-GCM) covers: tax numbers, the entire contents of the Vault (contractor book, products, payment accounts, templates, settings, logo), the full content of scheduled and queued sends, push device tokens, and the Apple identifier and refresh token.
  5. KSeF credentials are envelope-encrypted (a data key wrapped by a platform key, AES-GCM) — no plaintext token material exists in the database.
  6. Session tokens: the access token lives 30 minutes, the refresh token 30 days; only their hashes are stored. Reuse of a spent refresh token revokes the whole token family for that device.
  7. On the device: the app’s data store carries iOS file protection (completeUntilFirstUserAuthentication), keychain items use the “after first unlock, this device only” class, with no iCloud sync. The user may additionally turn on a Face ID lock.
  8. Backups: automatic, 7 days, in the same region.
  9. Environment separation: the development/test environment runs against the KSeF test sandbox and is separate from production.
  10. Minimisation: the invoice XML document itself is not stored by us — we fetch it from KSeF on demand. Invoice line items do not sit on our server other than inside the encrypted content of scheduled sends.

9.2. Assessment of appropriateness

The measures in 9.1 were chosen taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing, as well as the risk to the rights and freedoms of natural persons (art. 32(1) GDPR). The data we process is of low sensitivity but high commercial value, and voluminous per controller, so the emphasis is on access control and storage encryption rather than anonymisation, which would make the service impossible.

9.3. What we do not do — said plainly

  1. Not everything is encrypted at the column level. Sitting in our database as plain text are: both parties’ names and addresses, all amounts, the invoice number, the KSeF number, your acceptance note, the AI-generated description, the entire UPO document and the payment transaction records (including card brand and last four digits). They are protected by Azure’s storage encryption, the private endpoint and access control — but not by column encryption.
  2. Encrypting identifiers is not full pseudonymisation: a deterministic blind index sits beside the encrypted tax number, so exact-value matching remains possible server-side. The rest of the entrusted data is not pseudonymised at all.
  3. Backups are not geo-redundant — a whole-region Azure failure means the service is unavailable and cannot be restored from backup until the region returns. This is a deliberate cost trade-off and material under art. 32(1)(b) and (c) GDPR.
  4. ⟨TO BE COMPLETED: regular testing and evaluation of the effectiveness of the measures (art. 32(1)(d)) — today we have no documented penetration test and no scheduled recurring backup restore test. Either write the adopted cycle here (e.g. a restore test each quarter, an access review twice a year), or do not claim it at all.⟩
  5. This section describes the measures at a level of detail sufficient to assess them and insufficient to defeat them. Configuration detail is disclosed under § 17 (audit), subject to confidentiality.

§ 10. Sub-processors — general authorisation and objection

(art. 28(2) and (4) GDPR)

  1. You give us a general written authorisation to engage sub-processors. The current list is Annex A and is published at ksefly.app/powierzenie with a version number and date.
  2. Changes. We will tell you at least 30 days in advance of an intention to add a new sub-processor or replace an existing one — by a notice in the app and by updating Annex A with a new version and date.
  3. Objection. Within 30 days of the notice you may raise a reasoned objection to privacy@ksefly.app, stating grounds relating to data protection. We will consider it within 14 days and will either:
    • drop the change or propose an alternative, or
    • if the change is necessary for the service to work, tell you so — and you may then terminate with immediate effect by deleting your account before the change takes effect.
  4. An honest caveat to (3): terminating gives you no refund from us, because Apple sells you the subscription, not us — cancellation and any refund go through your Apple Account. We have no power here and do not want to obscure it.
  5. Our liability. We impose on every sub-processor data protection obligations no less onerous than those this agreement imposes on us. If a sub-processor fails to fulfil its obligations, we remain fully liable to you for the performance of those obligations (art. 28(4) GDPR). ⟨TO CONFIRM: the obligation in (5) is discharged by entering into a DPA with each sub-processor. Accepting the Microsoft, Anthropic, Stripe and Apple DPAs is an owner task — until then this paragraph states a commitment, not a fact.⟩

§ 11. Annex A and recipients who are not sub-processors

  1. The list of sub-processors, with what reaches each of them, where they sit and on what basis any transfer outside the EEA takes place, is Annex A to this agreement.
  2. Not our sub-processors — they receive data as independent controllers on their own legal basis:
    • KSeF / the Ministry of Finance — the complete invoice document; the basis is the Polish VAT Act and the transmission discharges your legal obligation. We cannot delete or alter a document once it is in KSeF; the only corrective mechanism is a correction invoice.
    • The VAT White List (Ministry of Finance) — a tax number, and for an account check also a bank account number.
    • GUS BIR — a tax number; the reply carries the name, address, REGON, legal form, PKD codes and sometimes an e-mail address.
    • VIES (European Commission) — an EU VAT number.
    • Apple — as regards the sale of Pro and Ultra subscriptions (that contract is between you and Apple).
    • Stripe — as regards its own regulatory duties as a payment service provider and the contract you enter into with it directly when your connected account is created. For the data we send to Stripe on your behalf (the invoice number as a line item, the amount, our correlation identifiers, the business address when a terminal location is created), Stripe acts as a sub-processor and is listed in Annex A. This dual role is real and cannot be simplified without misleading you.
    • NBP (the National Bank of Poland) — receives only a currency code and a date; no personal data.

§ 12. Transfers outside the EEA

(art. 44–49 GDPR)

  1. The primary place of processing is Poland (the Azure Poland Central region) ⟨TO BE COMPLETED: confirm the production environment’s region⟩.

  2. Data leaves the EEA in three cases — each described in Annex A:

    • Anthropic — party names and line-item names (the AI description and booking-note paths);
    • Apple — the device token, and when notification details are on, the counterparty’s name and the amount;
    • Stripe — settlement data, if the contracting entity sits outside the EEA. ⟨TO BE COMPLETED: settle which Stripe entity is the contracting party — one lookup in the Stripe dashboard. Until then this point is conditional, and a sole trader asked to accept this agreement cannot evaluate “depending on which Stripe entity”.⟩

  3. The legal basis for each of these transfers is still to be established. ⟨TO BE COMPLETED: for each of the three, record: the contracting entity (e.g. Stripe Payments Europe Ltd or Stripe Inc.), the standard contractual clauses in place (module and date), any EU–US Data Privacy Framework certification, and the outcome of a transfer impact assessment. Until those facts exist, this document must not claim that the transfer is safeguarded — a wrongly asserted adequacy decision is worse than an honest blank.⟩

  4. We do not transfer entrusted data to a third country on our own initiative beyond the cases in (2). Were that to happen, we would inform you before the transfer (art. 28(3)(a) GDPR).

§ 13. Personal data breaches

(art. 28(3)(f) and art. 33(2) GDPR)

  1. On becoming aware of a breach affecting entrusted data we notify you without undue delay and no later than 24 hours after becoming aware — to the e-mail address on your account and, where possible, by a message in the app.
  2. The notification contains at least: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken and proposed, and a contact point. Where all the information cannot be given at once, we provide it in phases, without undue delay.
  3. Notifying the Polish supervisory authority (PUODO) and communicating with the data subjects is yours as controller (art. 33(1) and art. 34 GDPR). We give you the information you need for it and do not notify on your behalf unless you expressly ask us to.
  4. We keep internal breach documentation and make it available on request, to the extent it concerns your data.
  5. Vulnerability reports are received at privacy@ksefly.app.

§ 14. Assistance with data subject rights

(art. 28(3)(e) GDPR)

  1. If a data subject exercises a right under Chapter III GDPR (access, rectification, erasure, restriction, portability, objection), we help you comply — insofar as possible, by appropriate technical and organisational measures.
  2. Much of that help is built into the app: you can display, correct and delete a contractor record yourself at any time, and delete a company or account in full. For those requests you do not need to come to us.
  3. Where a request cannot be met inside the app, we answer your message within 7 working days, so that you can meet your own one-month deadline under art. 12(3) GDPR.
  4. If a request reaches us directly from a data subject, we do not answer it on the merits — we pass it to you without undue delay and tell the sender who the controller is, unless you direct otherwise.
  5. Limits you need to know before you promise anything to a third party:
    • we cannot delete or correct an invoice in KSeF — the document belongs to the Ministry of Finance’s system; rectification happens only through a correction invoice;
    • data your counterparty already received with the invoice cannot be recalled;
    • data covered by your obligation to keep tax documentation may be exempt from the right to erasure (art. 17(3)(b) and (e) GDPR) — assessing that exemption is yours.
  6. This assistance is included in the price of the service. If the volume of requests becomes grossly disproportionate, we will agree reasonable remuneration with you in advance — never after the fact.

§ 15. Assistance with articles 32–36 GDPR

(art. 28(3)(f) GDPR)

Taking into account the nature of the processing and the information available to us, we assist you in complying with:

  1. art. 32 — security: § 9 of this agreement is a description of the measures in a form you can attach to your own documentation; on request we will add detail under § 17.
  2. art. 33–34 — breaches: the procedure and content of the notification are in § 13.
  3. art. 35 — data protection impact assessment (DPIA): on request we provide a description of the data flows, categories of data, sub-processors and transfers. This agreement together with the Privacy Policy was written to be sufficient as DPIA input — in particular § 7(5) (AI), § 9.3 (what we do not encrypt) and § 12 (transfers) are the points your assessment should weigh.
  4. art. 36 — prior consultation with the authority: we provide the information needed for the application and answer the authority’s questions put through you.
  5. ⟨TO CONFIRM: whether the owner has carried out their own DPIA and whether a data protection officer is appointed. For a sole trader at this scale a DPO is probably not required (art. 37 GDPR), but the document must say something definite rather than stay silent.⟩

§ 16. Deletion or return of data at the end

(art. 28(3)(g) GDPR)

  1. The choice is yours. After the provision of services ends — as you decide — we either delete all entrusted data or return it to you and then delete existing copies. You tell us at privacy@ksefly.app; no decision within 30 days of the end is treated as choosing deletion.

  2. Return is performed with the tools built into the app: the CSV export, the accountant package and the ZIP export are available on the paid plans; on the free plan a PDF visualisation is saved one invoice at a time. Whatever the plan, on a request made before you delete the account we will prepare a dump of your data (see below). Export before you delete your account — afterwards it cannot be reconstructed. On a request made before account deletion we will additionally prepare a machine-readable dump of your data within 14 days.

  3. Deletion covers: all companies (contexts), the stored invoice projection, scheduled and queued sends, historical import jobs, encrypted KSeF credentials, the entire Vault and device registrations. Data disappears from backups after 7 days at the latest. We do not delete data to the extent Union or national law requires it to be stored — and if that happens, we will tell you what remains and on what basis.

  4. Two exceptions we do not delete today — said plainly:

    • UPO documents (official confirmations of receipt, held by us as the full XML, without column encryption),
    • payment transaction records (amount, our fee, status, card brand and last four digits, the Stripe receipt URL).

    No mechanism removes them when a company is deleted or when an account is deleted; after account deletion they remain as orphaned records. ⟨TO BE COMPLETED: the owner must decide whether this is deliberate retention (in which case a legal basis — e.g. an obligation to keep settlement documentation — and a period must be written here) or a defect (in which case it must be fixed and this paragraph removed). Until that is settled it stays here in this form, because the agreement cannot promise a deletion the code does not perform.⟩

  5. Signing out is not deletion. Signing out clears the phone but does not erase the Vault on the server — signing back in restores your records. Data is deleted only by deleting a company or the account.

  6. We do not delete invoices in KSeF — see § 14(5).

§ 17. Information and audits

(art. 28(3)(h) GDPR)

  1. We make available all information necessary to demonstrate that we comply with our obligations under art. 28 GDPR. The first source is this agreement, the Privacy Policy and the published sub-processor list.
  2. Written questions go to privacy@ksefly.app; we answer within 14 days. You may use this route to ask for, among other things, the list of security measures, the location of processing, the status of sub-processor contracts, and breach documentation concerning your data.
  3. Audits. We allow for and contribute to audits, including inspections, conducted by you or by an auditor you mandate. The rules, scaled to a one-person firm:
    • the default form is a remote, documentary audit (questionnaire, interview, review of documentation) — because only that form shows anything real in a service with no server room of its own;
    • an on-site inspection is possible once every 12 months, on 30 days’ notice, on business days, at reasonable hours, after the auditor signs a confidentiality undertaking and provided the auditor is not a competitor of ours;
    • an additional inspection outside that limit is available without restriction after a breach affecting your data, and where a supervisory authority requires it;
    • you bear the cost of the audit, except where the audit reveals a material breach of this agreement on our side, in which case we bear it;
    • an audit must not compromise the confidentiality or security of other controllers’ data; access to other customers’ data is excluded.
  4. A limit we must state honestly: we cannot give you physical access to Microsoft’s, Anthropic’s, Apple’s or Stripe’s data centres — they are not ours. To that extent we pass on our sub-processors’ reports and certifications insofar as we hold them. ⟨TO CONFIRM: today we hold none. Once the sub-processor DPAs are in place, record which reports (e.g. SOC 2, ISO 27001) you can pass on.⟩
  5. We inform you immediately if, in our opinion, an instruction of yours infringes the GDPR (§ 7(2)).

§ 18. Your obligations as controller

  1. The legal basis and the information duty towards your counterparties are yours. We process that data only on your instruction and do not assess the lawfulness of how it was obtained.
  2. You are responsible for the accuracy and currency of the data you enter — including for making sure a line-item name or a note does not contain data you would not want disclosed (§ 4, final paragraph).
  3. You secure access to your device and your Apple Account; giving them to another person gives that person all the entrusted data.
  4. You record your use of Ksefly as a processor in your own record of processing activities (art. 30(1) GDPR) — including the transmission of invoice content to the AI model provider disclosed in § 7(5).
  5. You tell us when the e-mail address on your account changes; that is the address to which we send breach notifications and sub-processor list changes.

§ 19. Liability

  1. We are liable for damage caused by processing where we have not complied with obligations the GDPR directs specifically at processors, or where we have acted outside or contrary to your lawful instructions (art. 82(2) GDPR).
  2. Liability towards data subjects and towards the supervisory authority cannot be excluded or limited by contract and we do not attempt it. The limitations of liability in the Terms (§ 17 of the Terms) govern only the relationship between us and you, and do not apply to third-party claims or to administrative fines imposed on us for our own infringement.
  3. We remain fully liable for our sub-processors’ performance of their obligations (§ 10(5)).

§ 20. Changes to this agreement

  1. We may change this agreement where the scope of the service changes, where the law changes, where the sub-processor list changes, or where a supervisory authority’s guidance requires it.
  2. We give 30 days’ notice of a change in the app and publish the new version with a number and date. If you do not accept a change, you delete your account before it takes effect — subject to the honest note in § 10(4) about the subscription being sold by Apple.
  3. Changes consisting solely of an update to Annex A follow § 10, not this section.
  4. Every version remains available in the change log at the end of this document.

§ 21. Final provisions

  1. This agreement is governed by Polish law and the GDPR.
  2. It is in force for as long as the Terms are in force and expires once § 16 has been performed.
  3. § 8 (confidentiality), § 13 (breaches), § 16 (deletion or return) and § 19 (liability) survive expiry, to the extent their nature requires.
  4. If any provision is invalid, the remainder stands and the relevant GDPR provision applies in place of the invalid one.
  5. The Polish version controls; this English text is provided for information.

Annex A — list of sub-processors

List version: 1.0 · Date: 22 August 2026

A sub-processor is an entity that processes entrusted data on our instructions and on our behalf. Entities acting as independent controllers (KSeF, GUS, the White List, VIES, NBP, Apple as regards subscriptions) are listed in § 11(2) and are not in this table.

Sub-processorRole and scopeWhat reaches themWhere they sitTransfer mechanism outside the EEA
Microsoft (Azure App Service, PostgreSQL Flexible Server, Key Vault, Log Analytics, Application Insights)The infrastructure the whole service runs onAll entrusted data stored on our side, plus technical telemetryPoland Central region (Poland) ⟨TO BE COMPLETED: confirm the production region⟩The data plane stays in Poland, so this is not a transfer. ⟨TO CONFIRM: whether Microsoft support can access it from outside the EEA and which DPA/clauses govern that⟩
Anthropic PBC (the Claude model)Generating the one-line invoice description and — on your tap — a draft booking noteThe seller’s name, the buyer’s name, the gross amount, the currency and the names of up to 20 line items. For the Pulse sentence: aggregate figures and behavioural traits only, no names and no identifiersUnited States (api.anthropic.com)⟨TO BE COMPLETED: contracting entity, standard contractual clauses in place (module and date), any EU–US DPF certification, retention terms and training exclusion, transfer impact assessment. Not established today.⟩
Apple Inc. (APNs — push notifications)Delivering notifications to your deviceThe device token always; where “invoice details in notifications” is on (the setting is on by default) also the counterparty’s name and the invoice amountUnited States (api.push.apple.com)⟨TO BE COMPLETED: the transfer basis. Presumably the Apple Developer Program Licence Agreement, but this is not established today.⟩
Stripe (Connect, Terminal)Handling payments for your invoices — as regards the data we send on your behalf; otherwise Stripe is an independent controller and your own counterparty (§ 11(2))The business address when a terminal location is created, the amount, currency, our fee, the invoice number as a line item, our correlation identifiers (including the Ksefly user id). We never see the card number — card data goes from the device straight to Stripe. Device location reaches Stripe through the Terminal SDK⟨TO BE COMPLETED: contracting entity — Stripe Payments Europe Ltd (Ireland) or Stripe Inc. (US). Whether there is a transfer at all depends on this⟩⟨TO BE COMPLETED: DPA and SCCs — not established today⟩

Entities deliberately NOT on this list, although they appear in our infrastructure:

  • Azure Static Web Apps (West Europe region) — hosts only the ksefly.app marketing site; the site sets no cookies, has no analytics and never touches entrusted data.
  • Azure Communication Services — sends only an internal technical reminder to ourselves (an approaching key expiry); no user data goes there.

Annex B — where to find each element of art. 28 GDPR in this agreement

This table exists so that you (or your lawyer, or an authority) can check the agreement is complete without reading all of it.

GDPR requirementWhere
Subject matter of the processing§ 3(1)
Duration of the processing§ 6
Nature and purpose of the processing§ 3(2)–(4)
Type of personal data§ 4
Categories of data subjects§ 5
Obligations and rights of the controller§ 2, § 17, § 18
art. 28(3)(a) — processing only on documented instructions, including as regards transfers§ 7, § 12(4)
(b) — confidentiality commitment of authorised persons§ 8
(c) — security measures under art. 32§ 9
(d) — conditions for engaging sub-processors (art. 28(2) and (4))§ 10, § 11, Annex A
(e) — assistance with data subject rights§ 14
(f) — assistance with articles 32–36§ 13, § 15
(g) — deletion or return of data at the end§ 16
(h) — information and audits§ 17
Duty to flag an instruction that infringes the GDPR§ 7(2), § 17(5)
art. 28(9) — form of the contract§ 1(4)
art. 33(2) — notifying the controller of a breach§ 13
art. 82 — liability§ 19

Change log

VersionDateWhat changed
1.0⟨TO BE COMPLETED: publication date⟩The first data processing agreement in Ksefly’s history. Until now the service processed its users’ counterparties’ data without the contract art. 28(3) GDPR requires. The document discloses in particular: the transmission of invoice party names and line-item names to an AI model provider in the US with no controller opt-out, the list of fields not encrypted at column level, the absence of any time-based retention, and the fact that UPO documents and payment transaction records are not deleted with an account today.