The processor terms we will sign, published in full.

1 · Parties and roles

Processor: FIT PUP LTD, 3rd Floor, 86-90 Paul Street, London, England, EC2A 4NE (company no. 15766852). Controller: the customer named in the order. PayHQ processes personal data only on the controller’s documented instructions, which the customer agreement and product configuration constitute.

2 · Subject-matter and duration

Subject-matter: processing supplier invoices and records to detect changed payment details and fraud signals. Duration: the term of the customer agreement. Nature and purpose: intake, extraction, verification, review, and audit. Categories of data subject: the customer’s staff and its suppliers’ contacts. Categories of personal data: business-contact details, bank-account identifiers, invoice content, the customer’s user accounts, and the audit record of their actions.

Special categories. The service is not intended to process special-category data (UK GDPR Art. 9), and the controller should not upload documents whose purpose is to convey it. Where an invoice line item nonetheless contains incidental Art. 9 content (for example a medical or union-related description), PayHQ processes it only as part of the invoice under the same technical and organisational measures and the same retention and deletion as other invoice content — it is not singled out for any further use.

3 · Processor obligations (Art. 28(3))

• Process only on the controller’s documented instructions, including for transfers, unless required to process by UK or applicable law — in which case we inform the controller of that legal requirement before processing, unless the law prohibits such notice on important grounds of public interest.
• Run invoice extraction on infrastructure we operate. Invoice content is not routed to any third-party AI, OCR, or analytics provider, and customer data is never used to train any model; the extraction worker enforces this in code, failing closed unless the OCR or model endpoint is self-hosted or on our explicit allowlist — which in our own deployment contains only self-hosted hosts. (This is distinct from the network and email sub-processors in §4.)
• Ensure personnel authorised to process the data are bound by confidentiality.
• Implement appropriate technical and organisational measures (Art. 32) — see the Security Whitepaper and Security Status, which describe both the current control set and the controls still on our roadmap.
• Assist the controller with data-subject requests and with Arts. 32–36.
• At the controller’s choice, delete or return all personal data at the end of the service, and delete existing copies unless retention is required by law; we complete this within 30 days of termination and confirm in writing on request. Today this is carried out as a manual operational process; self-serve export and purge tooling is on our roadmap. This covers the data in systems we operate; it does not reach copies retained by an opt-in provider outside our control — for example an inbound email held by Resend under its own retention, or a forwarded document left in the user’s Telegram chat and Telegram’s storage — which are governed by that provider’s policy (see the Sub-processors page). Note also that raw uploaded invoice files are held only transiently: each is stored with a temporary-upload retention (default 30 days) and deleted by our retention sweeper once review is matched or resolved, so PayHQ may no longer hold the original file by the end of the service. Your own system remains the authoritative copy of the original invoice; the extracted records and audit trail persist for the term and are covered by the deletion above.
• Make no solely-automated decision producing legal or similarly significant effects on an individual — our trust and fraud signals are advisory and a human approver always decides (see the Pilot Terms). The controller is responsible for the lawful basis for those signals, including any Data Protection Act 2018 condition for criminal-offence-related (suspected-fraud) data.
• Immediately inform the controller if, in our opinion, an instruction infringes UK GDPR or other applicable data-protection law.
• Maintain a written record of the categories of processing carried out on behalf of the controller (Art. 30(2)), available on request. This record is currently being formalised as part of our compliance work; ahead of that we provide the processing information a controller reasonably needs on request.
• Make available the information needed to demonstrate compliance.

3a · Controller obligations

The controller warrants that it is the controller of the personal data it processes through PayHQ, that it has a lawful basis for the processing, and that it has given the transparency information required by UK GDPR Arts. 13–14 to the relevant data subjects — including a supplier’s contacts, who do not sign up with us directly. The controller further warrants that its instructions are lawful, and it indemnifies PayHQ against claims arising from breach of these obligations.

4 · Sub-processors

The controller gives general authorisation for the sub-processors PayHQ engages, listed under “Current sub-processors” at /trust/subprocessors. We give at least 30 days’ notice of any addition or replacement and honour a reasonable, good-faith objection. We require each such sub-processor to be bound by data-protection terms no less protective than these, and we are completing and recording the signed DPAs/SCCs with our current providers as part of our compliance onboarding. Where a sub-processor fails to meet its data-protection obligations, PayHQ remains fully liable to the controller for the performance of those obligations (Art. 28(4)). If we cannot accommodate a good-faith objection to a new sub-processor, the controller may terminate the affected processing (or this agreement) without penalty as its sole remedy. This clause does not cover the customer-connected data paths on that page (a customer’s own Microsoft 365 or Google mailbox): those providers are the customer’s own, engaged under the customer’s agreement, not Article 28 sub-processors PayHQ engages. Two opt-in alert/transport paths are also outside this “bound by terms no less protective” commitment and are enabled at the workspace’s choice: the Telegram integration (PayHQ holds no Article 28 DPA with Telegram) and a customer-configured alert webhook (typically Slack, but the destination is whatever URL the workspace sets). Both are disclosed on the sub-processor page so a workspace can decide with full knowledge before enabling them.

5 · International transfers

Customer data is stored in the EU (Hetzner, Finland). Some paths reach a non-EU sub-processor PayHQ engages: the always-on Cloudflare edge; Resend inbound (which carries invoice content, only where a customer enables it); and outbound email alerts via Resend (which carry alert metadata plus the recipient’s email address and the invoice’s original filename — not the invoice documents). Where such a sub-processor is established outside the UK/EEA, transfers are made under the UK IDTA or the UK Addendum to the EU SCCs, and the EU SCCs for the EU leg, with any supplementary measures required — as we complete and record those provider terms (see §4, which notes this is in progress). Separately, the opt-in Telegram integration (invoice intake and the alert channel), a customer-configured alert webhook (typically Slack), and a customer-connected mailbox (Microsoft 365 where an operator enables it; Google is planned) are paths the workspace itself chooses; as noted in §4 they are outside PayHQ’s Article 28 sub-processor commitment, and PayHQ does not provide an IDTA/SCC transfer basis for them — invoice content retrieved through a customer’s own mailbox provider may sit outside the UK/EEA under that provider’s agreement with the customer, and a workspace accepts this when it enables the path.

Pending legal confirmation: for a pilot with an EU-established customer (for example our Swedish pilot), the full chain — EU controller → UK processor → any US sub-processor — is being confirmed with counsel per leg, including the EU→UK adequacy position, before we sign. We do not rely on the generic wording above for that scenario.

6 · Breach notification

We notify the controller of a personal-data breach affecting their data without undue delay and no later than 24 hours after becoming aware, with the information the controller needs to meet its own 72-hour obligation to the ICO.

Being finalised: the internal breach-detection runbook and notification routing that operationalise this commitment are still being established as part of our governance work (one of the draft-for-review points above). The 24-hour figure is the target we are building to and the timeframe we will confirm at signing.

7 · Audit

We make available records to demonstrate compliance and contribute to audits, including inspections, conducted by the controller or an appointed auditor on reasonable notice. Where available, published artefacts and this Trust Center satisfy routine due-diligence requests.

Requesting a signable copy

Email [email protected] for a signable DPA. Governing law: England & Wales.