Data Processing Addendum (Service Provider Addendum)

4.1 Security Measures.

Provider will implement and maintain appropriate technical and organizational measures designed to protect Customer Data, including encryption in transit and at rest, least‑privilege access, multi‑factor authentication for administrative access, database Row‑Level Security (RLS), logging/monitoring, environment separation, secrets management, vulnerability remediation on a risk basis, and incident response, as summarized in the Security Schedule.

4.2 Hosting & Location.

Provider’s primary application hosting, database, and object storage are located in the United States. Certain AI model providers used to process invoice content may operate global infrastructure. Provider configures such providers per Section 6 (no training; retention disabled or minimized).

4.3 Default retention during term.

4.4 Return/Deletion upon instruction or termination.

During the Term, upon Customer’s written instruction, Provider will export available Customer Data in a commercially reasonable, machine-readable format and delete such data from active systems, subject to (i)–(ii) below. Following termination/expiration, Customer may request export within 30 days; thereafter, Provider will delete Customer Data from active systems within 60 days, subject to (i) provider-managed backups rotating out on standard cycles and (ii) retention required by law. On request, Provider will confirm deletion in writing. Provider will instruct relevant Subprocessors that process Customer Data to delete such data from their active systems within their standard deletion windows consistent with this Section, with deletion from backups occurring per each Subprocessor’s standard rotation cycles, currently ~7 days for the managed database snapshots.

5.1 Definition.

A “Security Incident” means a confirmed breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data transmitted, stored, or otherwise processed by Provider. Unsuccessful attempts or activities that do not compromise security (e.g., pings, port scans, blocked malware, failed logins) are not Security Incidents.

5.2 Notice.

Provider will notify Customer without undue delay and no later than 48 hours after becoming aware of a confirmed Security Incident affecting Customer Data in Provider-controlled systems, and will provide updates reasonably available, including: (a) a summary of the event and timeline; (b) the types of Customer Data reasonably believed affected; (c) steps taken or planned for containment and remediation; and (d) a contact point.

5.3 Subprocessor incidents.

Where a subprocessor experiences a Security Incident affecting Customer Data, Provider will promptly request and relay available information and subsequent updates from the subprocessor to Customer as they are made available.

5.4 Cooperation; scope & costs.

Provider will provide reasonable cooperation to support Customer’s investigation and required notifications to the extent related to Provider’s processing, taking into account Provider’s organization size; out-of-scope work (e.g., bespoke forensics, regulator responses unrelated to Provider’s systems) may be at Customer’s expense. The parties will use commercially reasonable efforts to preserve privilege and protect sensitive security information (e.g., detailed forensics) under confidentiality.

5.5 No admission; notification responsibility.

Notices are not an admission of fault or liability. Unless law requires Provider to notify individuals or authorities directly, Customer is responsible for regulatory and individual notifications.

6.1 Purpose-limited use.

Provider may transmit invoice content, prompts, and extraction context to vetted AI model providers solely to perform extraction as instructed by Customer. For clarity, model outputs and derived fields are Customer Data under Section 1.4.

6.2 No training or secondary use.

Provider will not permit AI model providers to (a) train or fine-tune models on Customer Data, or (b) use Customer Data for advertising, profiling, or any purpose other than providing the requested inference.

6.3 Retention controls.

Provider will configure provider settings to disable data retention where available, or otherwise rely on short, provider-imposed retention windows required for abuse prevention/debugging. Upon written request, Provider will summarize current configurations for active providers within a reasonable time.

6.4 Contractual & technical controls.

Provider will impose written terms on AI model providers consistent with Section 3 (service-provider/processor restrictions, including no sale/share and purpose limitation) and will use encrypted channels for such transmissions.

6.5 Provider selection & notice.

Provider may select among AI model providers to deliver the Services; changes are subject to Section 3.3 (Subprocessor notice and Customer’s objection/termination rights).

7.1 Routing.

If Provider receives a privacy/consumer request relating to Customer Data, Provider will promptly notify Customer and will not respond except per Customer’s instructions, unless legally required. Where legally permitted, Provider will forward the request to Customer and include any information reasonably available; if legally prohibited from notifying, Provider will notify Customer promptly after the prohibition lifts.

7.2 Assistance.

Taking into account the nature of processing and Provider’s organizational size and resources, Provider will provide commercially reasonable assistance for Customer to respond to verifiable consumer requests (e.g., access, deletion) and to meet applicable security/privacy obligations that relate to Provider’s processing of Customer Data. Such assistance is limited to Customer Data in Provider’s systems and is provided at Customer’s expense where requests are excessive, repetitive, unfounded, or require measures beyond Provider’s standard tooling and records.

8.1 Confidentiality.

Provider will ensure that persons authorized to process Customer Data are bound by confidentiality obligations, on a need-to-know basis, and receive appropriate security awareness.

8.2 Personnel.

“Personnel” means Provider’s employees (including the founder) and vetted contractors engaged by Provider. Provider will ensure such Personnel are subject to written confidentiality and data-protection obligations (e.g., employment agreements or policy acknowledgments for employees, services agreements for contractors) no less protective than those in this DPA, and that access to Customer Data is promptly removed upon role change or termination.

9.1 Documentation & questionnaire.

No more than once per 12 months and with reasonable prior notice, Customer may (a) review Provider’s then‑current written security documentation (e.g., Security page, retention settings summary, subprocessor list), and (b) submit a reasonable security questionnaire (e.g., SIG Lite/CAIQ‑Lite) which Provider will complete in good faith within a commercially reasonable timeframe.

9.2 On-site audits.

On-site inspections or intrusive technical audits (including remote vulnerability scanning or penetration testing) are not permitted unless (i) required by Applicable Laws that expressly override this DPA, or (ii) following a confirmed Security Incident primarily attributable to Provider’s controls. Any permitted audit must: (a) be preceded by reasonable prior written notice; (b) be limited to records and systems within Provider’s control that process Customer Data; (c) exclude access to Provider’s subprocessors’ premises, systems, or data; (d) avoid disruption and occur during normal business hours; (e) not require disclosure of other customers’ data, trade secrets, or security-sensitive information; (f) be conducted by Customer or an independent, non-competitor auditor bound by confidentiality; and (g) be at Customer’s expense. Provider may satisfy audit requests by making available existing security documentation and third-party reports or summaries to the extent they address the scope.

9.3 Remedial steps.

If Customer reasonably determines Provider has violated this DPA, Customer may direct Provider to take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Data.

Provider will promptly notify Customer of any legally binding request by a court, law-enforcement, or other public authority for disclosure of Customer Data and, where legally permissible and feasible, prior to disclosure, unless legally prohibited. Provider will (a) request that the authority seek the data directly from Customer where appropriate; (b) if the request appears facially overbroad, unlawful, or lacking proper legal process, ask the authority in writing to narrow or withdraw it; and (c) disclose only the minimum Customer Data necessary to comply. Provider is not required to take further steps to challenge a request (e.g., litigation, administrative appeals, or retaining outside counsel).

Provider may process aggregated service metrics (e.g., usage volumes, performance, error rates) that do not include Customer Data and cannot reasonably be used to identify any consumer, household, or Customer, and may create deidentified datasets derived from Customer’s use of the Services solely for internal analytics and service improvement. Provider will (a) implement technical safeguards that prohibit reidentification and remove direct/indirect identifiers and linkage keys; (b) maintain a public commitment to process deidentified data only in deidentified form and not to attempt to reidentify; and (c) will not disclose deidentified datasets to any third party other than Provider’s subprocessors acting on Provider’s behalf.

The Services are not designed for PHI. Provider does not act as a HIPAA Business Associate and will not sign a BAA. Customer agrees not to submit PHI or other sector‑regulated data (e.g., PCI DSS cardholder data, GLBA, FERPA) unless separately agreed in writing.

12A. No Consumer Health Data.

The Services are not designed to process “consumer health data” as defined by Washington’s My Health My Data Act, RCW 19.373, and materially similar U.S. state laws (including Nevada SB 370). Provider does not act as a processor of consumer health data and will not sign CHD-specific processor terms. Customer will not submit CHD unless the parties first execute a signed addendum that expressly enables such processing and sets out required instructions. If CHD is submitted without such addendum, Provider may promptly delete it and suspend the affected task, and such submission is a material breach of this DPA.

13.1 Liability.

This DPA is subject to the limitations of liability in the Agreement; it adds no separate indemnities.

13.2 Precedence.

In case of conflict between this DPA and the Agreement regarding data protection, this DPA controls; otherwise, the Agreement controls (including liability caps).

14.1 Effectiveness.

This DPA is effective upon execution of the Agreement or this DPA, whichever occurs later. This DPA may be executed in counterparts, each of which will be deemed an original, and all of which together constitute one and the same instrument. Signatures delivered electronically (including via e-signature service or PDF scan) are deemed originals.

14.2 Contacts.

Privacy/data requests: [email protected]. Security/incidents: [email protected].