Custom Development Framework Agreement
Versión 1.0 · marzo de 2026
Plantilla estándar · adaptada a cada clienteEste documento solo está disponible en inglés.
Parties
1. Trivle, registered with the Netherlands Chamber of Commerce (KvK) under number 92733689, having its registered office at Zwolsekanaal 35, 7681 EC Vroomshoop, the Netherlands, duly represented by name of representative ("Trivle");
and
2. Customer legal name, a legal form incorporated under the laws of country, registered with trade register under number registration number, having its registered office at address, duly represented by name and position ("Customer");
each a "Party" and together the "Parties".
Recitals
(A) Trivle develops and operates the Trivle platform, a multi-tenant software-as-a-service platform for e-learning, training management, compliance tracking and certification, consisting of an API, web applications and mobile applications.
(B) Customer uses or intends to use the Trivle platform and wishes to engage Trivle from time to time for custom work, in particular integrations and data exchange between the Trivle platform and Customer's systems, authentication and single sign-on, and extensions of and changes to the Trivle platform.
(C) The Parties wish to lay down in this Framework Agreement the terms that apply to all such custom work, with the scope, deliverables, planning and price of each project to be laid down in a separate Statement of Work.
The Parties therefore agree as follows:
Article 1 Definitions
Capitalised terms have the following meaning, in singular and plural:
| Term | Meaning |
|---|---|
| Acceptance | the approval or deemed approval of a Deliverable in accordance with Article 7. |
| Acceptance Period | the period of ten (10) Business Days after delivery of a Deliverable, as described in Article 7.2. |
| Additional Hours | hours ordered in addition to the Service Hours, as described in Article 10. |
| Business Day | Monday to Friday, excluding public holidays in the Netherlands. |
| Change Request | a request to change the agreed scope, specifications, Deliverables, planning or assumptions of a Statement of Work, as described in Article 6. |
| Customer Systems | the software, systems, identity provider, data and infrastructure of Customer or of third parties engaged by Customer, with which an Integration exchanges data or on which it depends. |
| Custom Extension | any functionality, change or extension developed by Trivle within the Platform at Customer's request, including Platform-side endpoints, configuration and code of an Integration. |
| Customer-Specific Connector | software developed by Trivle specifically for Customer that runs outside the Platform (for example middleware or a connector hosted in Customer's environment) and is designated as such in the SOW. |
| Deliverable | any result of the Work that is to be delivered under a Statement of Work. |
| DPA | the data processing agreement between the Parties within the meaning of article 28 of the General Data Protection Regulation (GDPR). |
| Finding | a deviation reported by Customer during acceptance testing or the Warranty Period, classified in accordance with Annex D. |
| General Terms | the General Terms and Conditions of Trivle, as published at https://www.trivle.com/legal/terms-and-conditions. |
| Go-Live | the moment at which a Deliverable is taken into production use. |
| Integration | an automated exchange of data or authentication between the Platform and Customer Systems, including APIs, webhooks, file-based exchange and single sign-on. |
| Integration Specification | the specification of an Integration agreed in accordance with Article 13 and Annex C. |
| Platform | the Trivle software-as-a-service platform, including its API, web applications, mobile applications, infrastructure and all components and improvements thereof. |
| Service Hours | the fixed monthly hours reserved for Customer, as described in Article 9. |
| SLA | Trivle's service level agreement applicable to Customer's use of the Platform. |
| Statement of Work or SOW | a document substantially in the form of Annex A, signed by both Parties, describing a specific project under this Framework Agreement. |
| Warranty Period | the period after Go-Live described in Article 8.2. |
| Work | all services performed by Trivle under this Framework Agreement and any SOW. |
Article 2 Scope and structure
2.1 This Framework Agreement governs all custom Work that Trivle performs for Customer, including:
(a) integrations and data exchange between the Platform and Customer Systems, via APIs, webhooks or file-based exchange;
(b) authentication and authorisation, including single sign-on via OpenID Connect (OIDC) or SAML 2.0, for example with Microsoft Entra ID;
(c) extensions of and changes to the Platform; and
(d) related analysis, design, configuration, testing, documentation and support.
2.2 Work is performed only on the basis of a Statement of Work signed by both Parties, or on the basis of Additional Hours or Service Hours as described in Articles 9 and 10. Each SOW is a separate agreement that incorporates this Framework Agreement.
2.3 This Framework Agreement does not oblige Customer to order Work, nor Trivle to accept a request. Trivle may decline a request, for example where it conflicts with the architecture, security or roadmap of the Platform.
2.4 Customer's subscription to and use of the Platform are governed by the General Terms, the SLA and the applicable order or subscription agreement, and not by this Framework Agreement.
2.5 Unless a SOW expressly provides otherwise, Trivle's obligations are obligations of means (inspanningsverbintenis) and not obligations of result.
Article 3 Applicable documents and order of precedence
3.1 The General Terms apply to this Framework Agreement and to every SOW. The applicability of Customer's general (purchasing) terms is expressly rejected.
3.2 In the event of conflict between documents, the following order of precedence applies: (1) the SOW, (2) this Framework Agreement including its Annexes, (3) the SLA and (4) the General Terms. With respect to the processing of personal data, the DPA prevails over all of these documents.
3.3 A SOW may deviate from this Framework Agreement only if the SOW expressly identifies the provision from which it deviates. A deviation applies only to that SOW.
Article 4 Process
4.1 Each project follows the process below, unless the SOW provides otherwise.
| Step | Description | Trivle | Customer |
|---|---|---|---|
| 1. Request | Customer submits a request in writing via the agreed channel (issue tracker or support@trivle.com). | Confirms receipt | Lead |
| 2. Discovery / intake | Clarification of objectives, requirements, constraints, Customer Systems involved and acceptance criteria. | Lead | Input, decisions |
| 3. Estimate and SOW | Written estimate and draft SOW (Annex A), including an Integration Specification (Annex C) for each Integration. | Lead | Review |
| 4. Approval | Written approval of the SOW. No Work starts before approval. | Signature | Signature |
| 5. Build | Development in iterations, with demos on the staging environment. | Lead | Feedback, test access |
| 6. Acceptance | Acceptance test per Deliverable within ten (10) Business Days (Article 7). | Fixes blocking Findings | Lead |
| 7. Go-Live | Release to production in accordance with the agreed go-live plan. | Lead | Approval, own systems |
| 8. Warranty | Free correction of defects during the Warranty Period (Article 8). | Lead | Reporting |
| 9. Maintenance | Maintenance, support and monitoring through Service Hours, Additional Hours and the SLA. | Lead | Reporting, ordering |
4.2 An initial intake meeting of up to 2 hours is free of charge. Further discovery work (such as workshops, analysis of Customer Systems or a technical proof of concept) is charged at the rates in Annex B, after Customer's prior approval of an estimate.
4.3 Estimates are prepared in good faith on the basis of the information available at the time. Unless a fixed price is agreed, an estimate is an indication and not a fixed price. An estimate is valid for 30 days.
4.4 During the build phase Trivle demonstrates progress at agreed intervals of two weeks and keeps Customer informed of progress, risks and the hours spent.
Article 5 Statements of Work and price models
5.1 Each SOW describes at least: the background and objectives, scope, Deliverables, Integrations, assumptions, items out of scope, planning and milestones, price model and estimate, acceptance criteria, contact persons and any deviations from this Framework Agreement.
5.2 Time and material (default). Unless the SOW states otherwise, Work is performed on a time and material basis at the rates in Annex B. Trivle notifies Customer as soon as it expects the estimate to be exceeded by more than 10% and will not exceed the estimate by more than that margin without Customer's prior written approval. The Parties will then consult on simplifying, phasing or postponing scope.
5.3 Fixed price (optional). For a well-defined scope the Parties may agree a fixed price in the SOW. A fixed price covers only the scope and Deliverables described in the SOW and is based on the assumptions listed therein. Work outside that scope, and the consequences of assumptions that prove incorrect, are handled through the change procedure of Article 6.
5.4 Cap (optional). The SOW may set a maximum number of hours or a maximum amount. A cap is a hard upper limit: Trivle performs no Work that would exceed it without Customer's prior written approval, and a cap never obliges Trivle to perform Work beyond it without payment.
5.5 Planning dates in a SOW are target dates and not strict deadlines (fatale termijnen), unless the SOW expressly designates a date as a strict deadline. Exceeding a target date does not entitle Customer to damages, termination or any other compensation.
Article 6 Change requests
6.1 Either Party may propose a change to a SOW. Customer submits Change Requests in writing via the agreed channel.
6.2 Trivle assesses each Change Request and provides an impact analysis covering cost, planning, risks and the effect on acceptance criteria, in principle within five (5) Business Days. If preparing the impact analysis requires substantial effort, Trivle will inform Customer beforehand and may charge that effort on a time and material basis after Customer's approval.
6.3 A Change Request is implemented only after Customer's written approval of the impact analysis. An approved Change Request forms an amendment to the relevant SOW.
6.4 The following are in any event treated as Change Requests and not as defects: changes to requirements, additional wishes or new insights, changed functionality, additional Integrations or authentication methods, and changes to Customer Systems or third-party interfaces that affect an agreed Integration Specification.
Article 7 Acceptance
7.1 Trivle delivers each Deliverable on the staging or acceptance environment, accompanied by release notes, and notifies Customer that the Deliverable is ready for acceptance testing.
7.2 Customer tests the Deliverable against the acceptance criteria in the SOW within ten (10) Business Days after notification (the Acceptance Period). Customer is primarily responsible for testing, including the preparation and execution of appropriate test scenarios in cooperation with Trivle. For Integrations this includes end-to-end testing with the relevant Customer Systems.
7.3 Customer reports Findings in writing within the Acceptance Period, specified and reproducible, with a proposed classification in accordance with Annex D (P1–P4). The Parties determine the final classification in consultation.
7.4 Customer may withhold Acceptance only on the grounds of P1 or P2 Findings. P3 and P4 Findings do not prevent Acceptance; Trivle corrects them within the indicative timelines in Annex D.
7.5 After correction of blocking Findings, Customer retests within five (5) Business Days. The retest is limited to the corrected Findings and functionality directly affected by them.
7.6 A Deliverable is deemed accepted: (a) when the Acceptance Period expires without Customer having reported a P1 or P2 Finding in writing; or (b) when Customer takes the Deliverable into production use, whichever occurs first.
7.7 Findings are classified as either: (a) a defect: a demonstrable deviation from the specifications and documentation agreed in the SOW, which Trivle corrects without charge; or (b) a change: a modification of requirements, an additional wish, a changed functionality, Integration or authorisation, which is handled as a Change Request under Article 6.
7.8 Trivle is not liable for deficiencies that result (in part) from incorrect, incomplete or subsequently changed requirements, acceptance criteria or Integration Specifications supplied by Customer, or from insufficient testing by Customer.
Article 8 Go-live, warranty and maintenance
8.1 Go-Live takes place after Acceptance, on a date agreed between the Parties. For Integrations, the go-live plan includes at least: the issue of production credentials, verification of the production configuration, activation of monitoring and a rollback plan.
8.2 During a period of 60 days after Go-Live (the Warranty Period), Trivle corrects free of charge any defects in the Deliverable, being demonstrable deviations from the accepted specifications, that Customer reports in writing within that period.
8.3 The warranty does not cover deviations caused by the circumstances described in Articles 12.2 and 12.3, by Change Requests, by use contrary to the documentation, or by modifications made by anyone other than Trivle.
8.4 After the Warranty Period, maintenance is provided through Service Hours (Article 9) or Additional Hours (Article 10). Maintenance comprises security updates, correction of defects and minor improvements that Trivle considers necessary for the stable operation of the Platform and the Deliverables. Functional extensions and changes are not maintenance and are handled as Change Requests or new SOWs.
Article 9 Service Hours (optional retainer)
9.1 Customer may order a fixed number of Service Hours per month, of at least 6 hours, in a SOW or separate written order. Service Hours may be used for maintenance, minor functional changes, configuration, support, analyses and follow-up of Integration monitoring.
9.2 Service Hours are a monthly minimum commitment, invoiced monthly in advance at the hourly rate in Annex B, and are payable irrespective of actual use.
9.3 Unused Service Hours may be carried over until the end of the calendar quarter following the quarter in which they were invoiced, and may also be used for feature requests and further development; where such Work requires a prior estimate, Article 10.3 applies. After that period unused hours lapse without refund, set-off or discount.
9.4 The Parties may increase or decrease the number of Service Hours by written agreement. Customer may terminate the Service Hours with two (2) months' written notice, subject to any minimum term agreed in the SOW.
Article 10 Additional Hours
10.1 For extensions, further development, Integrations and other changes outside maintenance and the Service Hours, Customer may order Additional Hours.
10.2 Additional Hours are ordered in blocks of a half day (4 hours) or a full day (8 hours). Customer determines the interval (for example fortnightly, monthly or incidentally).
10.3 For planning purposes, a request for Additional Hours must be submitted at least fourteen (14) calendar days in advance. Trivle confirms the capacity in writing and provides an estimate in advance, after which Customer gives written approval. Trivle handles requests at shorter notice on a best-effort basis.
10.4 Additional Hours are charged at the rates in Annex B. Work that does not require software development (such as configuration, data corrections, report adjustments, simple content changes or comparable administrative tasks) is charged at the compliance rate.
10.5 Additional Hours are invoiced monthly in arrears on the basis of actual time spent, accompanied by a timesheet.
Article 11 Prioritisation
11.1 Work that is necessary for the continuity, security, availability, stability or performance of the Platform takes precedence over Work under a SOW. Trivle may invoke this precedence only in the event of an actual disruption of or threat to the continuity, security or availability of the Platform, and not to structurally postpone Customer's Work or Findings.
11.2 If Trivle invokes precedence under Article 11.1, it informs Customer as soon as possible. Planning dates and the measurement of resolution times for the affected Work are suspended for the duration of the precedence and resume afterwards. Response times under the SLA remain in force. Precedence is invoked no longer than necessary to remove the disruption or threat.
11.3 Within these limits, Trivle schedules Work in accordance with the planning in the SOW and endeavours to agree a workable planning with Customer.
Article 12 Regressions and changes in Customer Systems or third-party services
12.1 Caused by Trivle. If a change made by Trivle to the Platform or a Deliverable causes a demonstrable regression in the agreed and documented functionality, the correction is treated as a defect and is performed without charge and without consuming Service Hours.
12.2 Caused by a third party. If a malfunction is caused by a change made by a third party (for example an external API, identity provider, browser, operating system or software dependency), the correction is performed within the Service Hours up to a maximum of six (6) hours per incident. Work beyond that, or where no Service Hours have been agreed, is performed as Additional Hours.
12.3 Caused by Customer. If a malfunction results from (i) incorrect or incomplete instructions, requirements or test scenarios of Customer, (ii) acts or omissions of Customer, its users or its suppliers, (iii) changes to Customer Systems, including their APIs, data model or identity provider configuration, or (iv) a change previously implemented as a Change Request at Customer's request, the correction is performed as Additional Hours.
12.4 Customer notifies Trivle at least 30 days in advance of any planned change to Customer Systems that may affect an Integration, and provides timely test access so that the impact can be assessed before the change goes live.
Article 13 Integrations
13.1 Before the build of an Integration starts, the Parties agree an Integration Specification in writing, using the checklist in Annex C. It covers at least: purpose, data objects and data mapping, direction, trigger or frequency, volumes, error handling and retries, ownership of master data, identifiers, authentication, environments and monitoring. The Integration Specification forms part of the SOW; deviations are handled as Change Requests.
13.2 For each data object the Integration Specification designates one leading system (source of truth). Trivle is not responsible for the accuracy, completeness or timeliness of data supplied by Customer Systems.
13.3 Integrations on the Trivle side use the documented APIs of the Platform. Where new endpoints or functionality are required, Trivle may implement these as generic Platform functionality (see Article 20).
13.4 Unless the SOW assigns it to Trivle, Customer is responsible for its side of each Integration, including the availability, capacity, security and configuration of Customer Systems.
Article 14 Authentication, authorisation and security
14.1 API access. Machine-to-machine Integrations authenticate via OAuth 2.0 using the client credentials grant; Integrations acting on behalf of a user use the authorization code grant (with PKCE where applicable). Access tokens are scoped according to the principle of least privilege. Separate credentials are issued per Integration and per environment.
14.2 Secrets. Client secrets, keys and shared secrets are exchanged via a secure channel and never in plain text by e-mail, are stored in a secrets manager, and are rotated periodically and at least annually, and immediately upon suspected compromise or a change of personnel with access.
14.3 Webhooks. Webhook messages are signed with an HMAC signature based on a shared secret. The receiving party verifies the signature and timestamp and rejects messages that fail verification or are replayed.
14.4 Transport. All data exchange takes place exclusively over TLS-encrypted connections (TLS 1.2 or higher).
14.5 Single sign-on. Where specified in the SOW, Trivle implements single sign-on via OIDC or SAML 2.0 (for example with Microsoft Entra ID), including the agreed attribute or claim mapping and user provisioning. Customer manages its own identity provider, including user lifecycle, multi-factor authentication policies, group and role assignments, and the timely renewal of certificates and client secrets on its side.
14.6 Development practices. Trivle develops in accordance with good industry practice, including peer code review, automated tests, a continuous integration pipeline and regular updates of software dependencies.
14.7 Penetration testing. Customer may have a penetration test performed on its Integration, subject to prior written agreement with Trivle on scope, timing, environment (in principle the staging environment) and the testing party. Such tests are at Customer's expense. Results are treated as confidential and shared with Trivle; Findings are classified in accordance with Annex D. Testing on the production environment requires Trivle's express prior consent.
14.8 Security incidents and personal data breaches are handled in accordance with the DPA.
Article 15 Environments and test data
15.1 Development and testing take place against Trivle's staging or sandbox environment, using test data or anonymised data.
15.2 Customer provides Trivle in good time with access to test environments of Customer Systems, including sandbox credentials, test accounts in its identity provider and representative test data.
15.3 Production personal data is not used in test environments, unless the Parties have agreed otherwise in writing under the DPA, including appropriate safeguards.
15.4 Deliverables are promoted to production only after Acceptance. Production credentials are separate from test credentials.
Article 16 API versioning and deprecation
16.1 Trivle documents the public APIs of the Platform in an OpenAPI specification.
16.2 Trivle may at any time make non-breaking changes, such as adding endpoints, optional parameters or response fields. Integrations must be built to tolerate such additions.
16.3 Trivle announces breaking changes to documented APIs at least six (6) months in advance, with migration information. Where reasonably possible, the previous version remains available during that period.
16.4 Trivle may apply a shorter period, or make a change with immediate effect, where this is necessary to address a security vulnerability or to comply with legal requirements. Trivle informs Customer of such a change as soon as possible.
16.5 Undocumented or internal endpoints are not covered by this Article and may change without notice.
Article 17 Data exchange and data protection
17.1 The DPA applies to all processing of personal data in the context of the Work. Unless agreed otherwise in writing, Customer is the controller and Trivle is the processor.
17.2 Integrations exchange only the data fields that are necessary for the purpose described in the Integration Specification (data minimisation).
17.3 Personal data is processed within the European Union. Transfers outside the European Economic Area take place only in accordance with the DPA.
17.4 Integration logs contain no more personal data than necessary for operation and troubleshooting, and are retained in accordance with the DPA.
17.5 Customer warrants that it has a valid legal basis for the personal data it supplies to the Platform via an Integration.
Article 18 Monitoring and support after Go-Live
18.1 After Go-Live, Integrations and other Deliverables are supported in accordance with the SLA, including its support hours, severity levels and response times.
18.2 Trivle monitors the Platform side of each Integration (such as errors, failed deliveries and authentication failures) and notifies Customer of structural failures. Customer monitors Customer Systems.
18.3 Customer provides first-line support to its own users. Trivle provides second-line support to Customer's designated contact persons.
18.4 Findings and requests are reported via the channel agreed in the SOW (issue tracker or support@trivle.com). Customer ensures that reports contain no special categories of personal data and uses anonymised or pseudonymised examples where possible.
Article 19 Customer cooperation
19.1 Customer provides Trivle in good time with all information, decisions, access and cooperation reasonably required for the Work, and designates a contact person with decision-making authority, who is named in the SOW.
19.2 Customer is responsible for specifying and validating complete and correct requirements, acceptance criteria and test scenarios, and for coordinating its own suppliers of Customer Systems.
19.3 If Customer does not or not timely fulfil its obligations, planning dates are extended accordingly. Additional costs resulting from such delay are charged at the rates in Annex B.
Article 20 Intellectual property
20.1 All intellectual property rights in the Platform, including all generic improvements, components, tools and documentation, are and remain vested in Trivle or its licensors.
20.2 Custom Extensions developed within the Platform become part of the Platform and the intellectual property rights therein vest in Trivle, consistent with article 10.2 of the General Terms. Customer receives a non-exclusive, non-transferable right to use the Custom Extensions for the duration of its Platform subscription. Trivle may make (generic versions of) Custom Extensions available to other customers, without disclosing Customer's Confidential Information.
20.3 For Customer-Specific Connectors that are paid in full, the SOW specifies whether the intellectual property rights are transferred to Customer or whether Customer receives a perpetual licence. If the SOW is silent, Customer receives a non-exclusive, perpetual licence upon full payment. A transfer or licence does not extend to Platform components, generic libraries or tools of Trivle, nor to third-party or open source components.
20.4 Upon transfer or at Customer's request, Trivle provides the source code of the Customer-Specific Connector, including dependency descriptions, build and deployment instructions and technical documentation insofar as available. Customer is thereafter responsible for the hosting, operation and further development of that connector, unless agreed otherwise.
20.5 Customer's data, configuration and Customer Systems remain the property of Customer. Customer grants Trivle the right to use these to the extent necessary for performing the Work.
20.6 Trivle remains free to use the general knowledge, experience, methods and techniques acquired in performing the Work, without using Customer's Confidential Information.
20.7 Open source components are subject to their own licence terms.
Article 21 Invoicing and payment
21.1 Unless the SOW provides otherwise: (a) time and material Work and Additional Hours are invoiced monthly in arrears, accompanied by a timesheet; (b) fixed-price Work is invoiced per milestone in accordance with the payment schedule in the SOW; and (c) Service Hours are invoiced monthly in advance.
21.2 A SOW may provide for an advance payment of 30% of the estimate, to be set off against the final invoice under that SOW.
21.3 All amounts are in euros and exclusive of VAT. Invoices are sent electronically. Payment terms and Trivle's right of suspension are governed by the General Terms.
21.4 Objections to an invoice must be submitted to Trivle in writing, with reasons, within fourteen (14) days of the invoice date. After that period the invoice is deemed accepted, save for manifest errors. Customer pays the undisputed part of an invoice in accordance with the payment terms.
21.5 Rates are indexed annually in accordance with article 12.2 of the General Terms.
21.6 Third-party costs (such as licences, hosting of Customer-Specific Connectors or external services) are incurred only with Customer's prior approval and are passed on at cost plus a management fee according to quotation.
21.7 Work is performed remotely unless the SOW provides otherwise. Travel time and expenses for on-site Work are charged as specified in the SOW.
Article 22 Liability
22.1 Trivle's liability is governed by the General Terms, unless the SOW expressly provides otherwise.
22.2 Trivle is not liable for damage resulting from Customer Systems, from incorrect or incomplete data supplied via an Integration, from changes made by third parties, or from requirements, specifications or instructions supplied by Customer.
Article 23 Confidentiality
23.1 Each Party keeps confidential all information of the other Party that is designated as confidential or that it should reasonably understand to be confidential, including source code, security information, credentials, business information and the contents of each SOW ("Confidential Information"), and uses it only for the performance of this Framework Agreement.
23.2 This obligation does not apply to information that is or becomes publicly available other than through breach of this Article, that was already lawfully in the receiving Party's possession, that was independently developed, or that must be disclosed by law or court order, in which case the disclosing Party is informed beforehand where permitted.
23.3 This obligation continues for two (2) years after termination of this Framework Agreement; for credentials and security information it continues indefinitely.
Article 24 Non-solicitation optional
24.1 During the term of this Framework Agreement and for twelve (12) months thereafter, neither Party will employ or otherwise directly or indirectly engage any employee or contractor of the other Party who has been involved in the Work, without the other Party's prior written consent. Delete this Article if not applicable.
Article 25 Term and termination
25.1 This Framework Agreement enters into force on the date of the last signature and is entered into for an indefinite period.
25.2 Either Party may terminate this Framework Agreement in writing with two (2) months' notice.
25.3 Termination of this Framework Agreement does not affect SOWs in progress, which continue under the terms of this Framework Agreement until completed, unless a SOW is terminated in accordance with Article 25.4 or its own terms.
25.4 Either Party may terminate this Framework Agreement or a SOW with immediate effect by written notice if the other Party materially breaches its obligations and fails to remedy the breach within thirty (30) days after a written notice of default, or if the other Party is declared bankrupt or granted a (provisional) suspension of payments.
25.5 Upon termination of a SOW, Customer pays for the Work performed up to the termination date. Trivle delivers work in progress on Customer-Specific Connectors in accordance with Article 20, and cooperates with a data export at the applicable rates.
25.6 Provisions that by their nature are intended to survive termination, including Articles 17, 20, 22, 23, 24 and 26, remain in force after termination.
Article 26 Miscellaneous
26.1 This Framework Agreement and each SOW are governed exclusively by the laws of the Netherlands.
26.2 All disputes arising out of or in connection with this Framework Agreement or a SOW are submitted exclusively to the competent court of the District Court of Overijssel (Rechtbank Overijssel). Arbitration is excluded.
26.3 Amendments to this Framework Agreement and to a SOW require written agreement between the Parties. Approval of estimates, Change Requests and requests for Additional Hours may also be given by e-mail by the contact person designated in the SOW.
26.4 Neither Party may assign its rights or obligations under this Framework Agreement without the prior written consent of the other Party, which will not be unreasonably withheld.
26.5 If any provision is void or voidable, the remaining provisions remain in force and the Parties replace the void or voidable provision with a valid provision that approximates its purpose as closely as possible.
26.6 This Framework Agreement, together with its Annexes, the documents referred to in Article 3 and the SOWs, constitutes the entire agreement between the Parties regarding its subject matter and supersedes all prior oral or written arrangements.
26.7 This Framework Agreement may be signed electronically and in counterparts.
Annex A – Statement of Work template
Each project is laid down in a Statement of Work based on this template. The SOW is part of the Custom Development Framework Agreement between Trivle and Customer name dated date.
A.1 General
| Field | Content |
|---|---|
| SOW number and title | SOW-001 – Project title |
| Version and date | 1.0 – date |
| Framework Agreement | Custom Development Framework Agreement v1.0, dated date |
A.2 Project description
| Section | Content / guidance |
|---|---|
| 1. Background and objectives | Business context, problem to be solved and intended outcome |
| 2. Scope | Functionality and activities in scope, described as concretely as possible |
| 3. Integrations | List of Integrations; for each Integration an Integration Specification based on Annex C is attached |
| 4. Authentication / SSO | e.g. OAuth 2.0 client credentials; OIDC/SAML SSO with Microsoft Entra ID; claim and role mapping |
| 5. Assumptions | Assumptions on which the estimate is based, e.g. availability of Customer test environments, API documentation of Customer Systems, data volumes |
| 6. Out of scope | Explicitly excluded items |
| 7. Customer cooperation | Specific information, access, test environments and decisions required from Customer, with dates |
| 8. Acceptance criteria | Measurable criteria and test scenarios per Deliverable |
| 9. Intellectual property | Custom Extension within the Platform (Article 20.2) / Customer-Specific Connector: transfer or perpetual licence (Article 20.3) |
| 10. Deviations from the Framework Agreement | None / article number and deviating provision |
A.3 Deliverables
| # | Deliverable | Description | Acceptance criteria |
|---|---|---|---|
| 1 | Deliverable | Description | Criteria |
| 2 | Deliverable | Description | Criteria |
| 3 | Deliverable | Description | Criteria |
A.4 Planning and milestones
| Milestone | Content | Target date | Payment (fixed price only) |
|---|---|---|---|
| M1 – Specification | Integration Specification and design approved | date | % / € |
| M2 – Build | Development and demos on staging | date | % / € |
| M3 – Acceptance | Acceptance test completed | date | % / € |
| M4 – Go-Live | Release to production | date | % / € |
A.5 Price model and estimate
| Item | Content |
|---|---|
| Price model | Time and material (default) / Fixed price / Time and material with cap |
| Estimate | number hours × hourly rate = amount excl. VAT |
| Cap (if applicable) | number of hours or amount |
| Advance payment | None / 30% of the estimate |
| Service Hours after Go-Live | None / number of hours per month |
| Third-party costs | None / description and amount |
A.6 Contact persons
| Role | Trivle | Customer |
|---|---|---|
| Contact person / decision maker | Name, e-mail, phone | Name, e-mail, phone |
| Technical contact | Name, e-mail | Name, e-mail |
| Reporting channel | Issue tracker / support@trivle.com | — |
Annex B – Rates
The following rates apply from the effective date of this Framework Agreement. All rates are in euros and exclusive of VAT, and are indexed annually in accordance with article 12.2 of the General Terms.
| Item | Rate (excl. VAT) | Unit | Notes |
|---|---|---|---|
| Hourly rate | according to quotation | Per hour | Development, analysis, design, testing, project management |
| Additional Hours – half day | according to quotation | Block of 4 hours | Article 10 |
| Additional Hours – full day | according to quotation | Block of 8 hours | Article 10 |
| Compliance / configuration rate | according to quotation | Per hour | Work not requiring software development (Article 10.4) |
| Service Hours | 6 hours × hourly rate | Per month, in advance | Optional retainer (Article 9) |
| Third-party costs | At cost + mark-up according to quotation | As incurred | Only after prior approval (Article 21.6) |
Annex C – Integration Specification checklist
For each Integration the Parties complete and agree the items below before the build starts (Article 13.1). The completed checklist is attached to the SOW.
| Topic | Items to specify | Agreed |
|---|---|---|
| 1. General | Name and purpose of the Integration | |
| Systems involved and their owners | ||
| Business process supported | ☐ | |
| 2. Data objects and mapping | Data objects and fields exchanged | |
| Field mapping and transformations | ||
| Validation rules and code lists | ☐ | |
| 3. Identifiers and master data | Unique identifiers used to match records in both systems | |
| Leading system (source of truth) per data object | ||
| Handling of duplicates, merges and deletions | ☐ | |
| 4. Direction, trigger and frequency | Inbound, outbound or bidirectional | |
| Real-time (webhook/API), scheduled batch or on demand | ||
| Frequency and timing | ☐ | |
| 5. Volumes and performance | Expected volumes, peaks and growth | |
| Required latency | ||
| Rate limits on both sides | ☐ | |
| 6. Interface | Protocol (REST API, webhook, file transfer) | |
| Endpoints, message formats and API versions | ||
| Documentation of Customer Systems | ☐ | |
| 7. Authentication and security | OAuth 2.0 grant type and scopes | |
| Webhook signing (HMAC) and verification | ||
| Secret exchange, storage and rotation | ||
| SSO protocol (OIDC/SAML), claims and role mapping | ☐ | |
| 8. Error handling | Retries and back-off | |
| Idempotency and duplicate prevention | ||
| Handling of failed messages | ||
| Alerting and reconciliation | ☐ | |
| 9. Privacy | Personal data fields and necessity (data minimisation) | |
| Legal basis and reference to the DPA | ||
| Logging and retention | ☐ | |
| 10. Environments and test data | Test/sandbox environments on both sides | |
| Test accounts and test data (no production personal data) | ||
| Access arrangements | ☐ | |
| 11. Operations | Monitoring on both sides | |
| Operational contact persons | ||
| Notification of changes to Customer Systems (Article 12.4) | ☐ | |
| 12. Acceptance | End-to-end test scenarios | |
| Acceptance criteria | ||
| Go-live and rollback plan | ☐ |
Annex D – Severity classification for acceptance
Findings during acceptance testing and the Warranty Period are classified as follows. Only P1 and P2 Findings prevent Acceptance (Article 7.4).
| Severity | Definition | Blocks Acceptance | Indicative resolution time |
|---|---|---|---|
| P1 – Critical | Functionality unusable; workflow or Integration blocked; no workaround available. | Yes | Within 5 Business Days |
| P2 – High | Essential functionality works to a limited extent or incorrectly; a workaround is possible but burdensome. | Yes | Within 10 Business Days |
| P3 – Medium | Non-critical deviation without significant impact on core processes. | No | Within 20 Business Days |
| P4 – Low | Cosmetic issues, textual improvements, minor UI/UX inconsistencies. | No | In the next release |
The resolution times above are indicative, apply until Go-Live and do not constitute strict deadlines or service levels. Actual lead times also depend on prioritisation (Article 11), capacity and dependencies on Customer or third parties. After Go-Live the response and resolution times of the SLA apply.
A Finding is classified as a defect only if it is a demonstrable deviation from the agreed specifications and documentation. Changes, additional wishes and new insights are handled as Change Requests (Article 7.7).