1. Purpose and Scope

1.1 This Service Level Agreement (SLA) is an integral part of the respective contract, order form, service description, or requirements specification between K&S Informatik Schweiz GmbH (the Provider) and the customer named in the respective order form (the Customer).

1.2 This SLA defines support availability, the handling of service disruptions, target values for service availability, and mechanisms for service credits for the recorded services. It does not expand the functional scope of the services and does not establish any obligations beyond those expressly set forth in this SLA, the General Terms and Conditions, the applicable order form, and the applicable service description.

1.3 This SLA applies only to production SaaS, hosting, or cloud services that are expressly designated as covered services in the applicable order form or service description (covered services). It does not apply to beta features, test systems, development environments, on-premises installations, customer-operated environments, Professional Services, consulting, change requests, custom developments, migrations, or one-time project work, unless expressly agreed to in writing.

1.4 In the event of a conflict, the order of precedence set forth in the General Terms and Conditions shall apply. This SLA must be read in conjunction with the General Terms and Conditions, the Service Description, the Order Processing Agreement (if applicable), the technical and organizational measures, and any security or backup documentation.

2. Contracting Parties

Provider: K&S Informatik Schweiz GmbH, Switzerland.

Customer: as specified in the applicable order form or individual contract.

For clarity, this SLA applies exclusively to the Swiss provider company. Affiliated companies or subcontractors may assist the Provider in the provision of services only in accordance with the General Terms and Conditions and—to the extent that personal data is processed—in accordance with the applicable Data Processing Agreement.

3. Definitions

Term	Definition
Availability	refers to the percentage of time within the applicable service availability hours during which the SaaS service is available for access and use, excluding any downtime that is specifically excluded.
Business Day	means Monday through Friday, excluding public holidays at the Provider’s headquarters in Zurich, Switzerland.
Business Hours	means 8:00 a.m.–12:00 p.m. and 1:30 p.m.–5:30 p.m. CET/CEST on business days, unless otherwise agreed upon in an extended support package.
Covered SaaS Service	means the production SaaS, hosting, or cloud service expressly covered by this SLA.
Excluded Downtime	means downtime, disruptions, delays, or unavailability that are excluded pursuant to Section 8 of this SLA.
Malfunction	means a reproducible technical malfunction of a covered SaaS service within the Provider’s area of responsibility that substantially prevents or impairs the use of the covered SaaS service in accordance with the applicable service description.
Qualified Outage Report	means a fault report that contains the information reasonably required pursuant to Section 10.1.
Response Target	means the target time within which the Provider will provide an initial substantive response upon receipt of a qualified fault report during business hours.
Recovery Target	means the target time within which the Provider will make commercially reasonable efforts to provide a workaround, damage mitigation, a recovery path, or the restoration of significantly affected functionality. This is not a guaranteed resolution time, nor is it a guarantee of a permanent fix.
Service Availability Hours	refers to 24 hours a day, 7 days a week for productive, registered SaaS services, unless the applicable order form or service description specifies that availability is measured only during business hours or another explicitly defined service window.
Service Credit	refers to a credit applied to future invoices calculated in accordance with Section 12 and constitutes—subject to the General Terms and Conditions and mandatory law—the customer’s sole and exclusive remedy in the event that the availability target is not met.

 

4. Covered Services and Exclusions

4.1 Covered services may include, if expressly agreed, hosted or SaaS access to loggPRO, AppLoggPRO.net, document management functions, cloud hosting, EDI/XML/CSV data exchange, interfaces, and related production software services for logistics, transport documentation, and customs and trade-related processes.

4.2 The Provider is only responsible for the availability and support of the covered SaaS service within its area of responsibility. The Provider is not responsible for customer systems, customer networks, local devices, browsers, ERP/WMS/TMS systems, carrier systems, government systems, customs platforms, internet connections, or third-party services outside its reasonable sphere of influence.

4.3 This SLA does not apply to functional changes, customer-specific developments, data migrations, consulting, training, content-related questions, legal, customs, tax, or trade compliance assessments, pricing decisions, master data corrections, or change requests, unless expressly agreed to in writing. Such services may be provided separately and billed in accordance with the applicable agreement.

5. Support Availability

5.1 The Provider provides standard support during business hours.

5.2 Incident reports received outside of business hours are deemed to have been received at the start of the next business day. Response and resolution targets apply only during business hours, unless an extended support package expressly provides otherwise.

5.3 Support is not available during the lunch break from 12:00 p.m. to 1:30 p.m. CET/CEST, unless expressly agreed otherwise.

5.4 The existence of an escalation contact or an emergency number does not constitute 24/7 support, on-call service, or guaranteed fault resolution outside of business hours, unless this has been expressly agreed upon in an extended support package.

6. Incident Priorities and Target Times

6.1 The customer assigns an initial priority to a fault report upon submission. The Provider may reclassify the priority based on the actual impact, urgency, number of affected users, availability of workarounds, reproducibility, and whether the issue falls within the Provider’s area of responsibility.

6.2 Response targets and resolution targets apply only to qualified incident reports and only during business hours. Resolution targets are target values and do not constitute guaranteed resolution times or contractual penalties.

Priority	Description	Response Target	Recovery Target
P1 – Critical	The SaaS service is unavailable to virtually all users, or a critical security or data integrity risk prevents productive use, and no adequate workaround is available.	4 business hours	Commercially reasonable efforts to provide a workaround, mitigation, recovery path, or substantial recovery within 1 business day.
P2 – High	Important productive functions are severely impaired for a significant number of users. Productive work is substantially restricted; however, an adequate workaround exists, or only a portion of the affected SaaS service is impacted.	8 business hours	Commercially reasonable efforts to provide a workaround, mitigation, recovery path, or substantial recovery within 2 business days.
P3 – Normal	Non-critical functions are affected; workflows are disrupted but remain functional. The disruption affects a limited number of users, modules, or non-critical functions.	1 business day	Commercially reasonable efforts to address, mitigate, or plan a correction for the disruption within 5 business days.
P4 – Low / Inquiry	General questions, cosmetic issues, minor inconveniences, documentation or configuration questions, change requests, feature requests, or other issues with no significant impact on productive use.	2 business days	As agreed. P4 requests do not constitute availability disruptions and are not subject to service credits or recovery targets, unless expressly agreed otherwise.

 

6.3 Target times are suspended for any period during which the Provider is awaiting information, cooperation, access, log files, screenshots, test data, decisions, access credentials, third-party contributions, or other assistance from the Customer or a third party.

6.4 If a permanent correction requires a software release, a change by a third party or a government agency, a data correction, migration, a change on the customer’s part, an infrastructure change, or a security investigation, the Provider may meet the applicable recovery objective by providing a workaround, mitigation, a recovery path, or a reasonable action plan.

7. Availability Target and Measurement

7.1 Unless otherwise agreed in the applicable order form or service description, the Provider aims to achieve 99.9% availability per calendar month for the productive, recorded SaaS service during the applicable service availability hours.

7.2 Availability is calculated as follows:

Availability (%) = ((Total service availability time during the measurement period – Downtime within the Provider’s area of responsibility) / Total service availability time during the measurement period) × 100

7.3 Downtime is only taken into account if the SaaS service is substantially unavailable due to a cause within the Provider’s scope of responsibility and the disruption is confirmed by the Provider’s monitoring or support records. Partial service reductions, slow performance, non-critical errors, local disruptions, customer-specific configuration issues, or the unavailability of individual non-essential functions do not count as downtime, provided they do not substantially prevent the use of the tracked SaaS service as a whole.

7.4 The Provider’s monitoring, support, and operational logs constitute the primary basis for determining availability and service credits. The Provider is not obligated to disclose raw monitoring data, internal logs, security-sensitive information, or information about other customers.

7.5 Scheduled maintenance and emergency maintenance are considered excluded downtime. The Provider shall use commercially reasonable efforts to perform scheduled maintenance outside of business hours and to notify the Customer—to the extent reasonably possible—at least three business days in advance. Emergency maintenance may be performed without prior notice if required for reasons of security, stability, legality, operation, or data integrity.

8. Excluded Downtime and Excluded Disruptions

8.1 The following circumstances are not counted toward availability targets, response targets, recovery targets, or service credits:

• scheduled maintenance, emergency maintenance, updates, upgrades, patches, backups, security enhancements, system changes, or other maintenance activities;
• events of force majeure, including outages affecting utilities, telecommunications providers, Internet backbone providers, cloud providers, data centers, DNS providers, or other infrastructure beyond the Provider’s reasonable control;
• outages, interruptions, delays, or disruptions caused by the customer, its users, systems, networks, devices, browsers, access credentials, configurations, data, instructions, integrations, or third-party providers;
• Unavailability, delay, malfunction, error message, format change, certificate issue, authentication change, maintenance window, access restrictions, policy changes, or other disruptions to customs, government, carrier, logistics, banking, ERP, WMS, TMS, SFTP, email, mapping, communications, or other external systems, including e-dec, ATLAS, PASSAR, and successor systems;
• changes to laws, regulations, government requirements, message formats, customs declarations, certificates, authentication mechanisms, API requirements, or third-party terms and conditions that require an adjustment to the services;
• unsupported environments, outdated browsers, local installations, unauthorized modifications, misuse, excessive API calls, penetration tests, vulnerability scans, load tests, bots, or automated tools not approved by the Provider;
• disruptions caused by customer data, incomplete or incorrect master data, incorrect declarations, erroneous shipping, customs, tax, tariff, origin, value, product, or transaction data, or inadequate customer workflows;
• Suspension of services in accordance with the Terms and Conditions, this SLA, or applicable law, including suspension due to late payment, misuse, security risks, sanctions risks, or breach of contract;
• Beta features, test systems, development environments, non-production systems, customizations, and customer-specific projects, unless these are expressly included in the covered services;
• Periods during which the Provider is prevented from taking action because the Customer or a third party has failed to provide the necessary cooperation, information, access, approvals, access credentials, or decisions.

8.2 In the case of excluded disruptions, the Provider may provide support on a best-effort basis. Such support may be billed separately unless it is expressly included in the applicable agreement.

9. Security Incidents and Urgent Protective Measures

9.1 Security incidents, suspected unauthorized access, vulnerabilities, risks to data integrity, or unlawful use may be handled outside the standard prioritization process for disruptions, to the extent reasonably necessary to protect the services, customer data, the Provider, other customers, or third parties.

9.2 The Provider may take urgent protective measures, including temporary suspension, isolation of affected components, reset of access credentials, blocking of interfaces, emergency maintenance, deactivation of compromised accounts, log analysis, and other containment measures. Such measures shall be deemed excluded downtime to the extent that they are reasonably necessary for security, stability, legal compliance, or data integrity.

9.3 Data protection notifications are governed, where applicable, by the applicable Data Processing Agreement, the technical and organizational measures, and the security incident response process. This SLA neither replaces nor modifies any statutory notification obligations nor any contractual notification obligations under the Data Processing Agreement.

10. Incident Reporting and Escalation

10.1 The Customer shall report incidents via email or through a support channel designated by the Provider. A valid incident report must, if available, include the following information:

• Description of the problem and desired priority;
• Affected module, service, function, interface, or customer process;
• Time of occurrence, duration, and number of affected users;
• Steps to reproduce the problem;
• Screenshots, error messages, log files, sample data, reference numbers, and relevant transaction IDs;
• Information about recent changes to customer systems, configurations, data, access credentials, or integrations;
• Confirmation of whether a workaround is available and whether the issue impacts production use.

10.2 The Provider shall acknowledge receipt, assign or confirm the priority, and provide initial substantive feedback within the applicable response target.

10.3 If the customer believes that the applicable response target has not been met, the customer may escalate the issue to the first escalation level designated by the Provider. If the issue remains unresolved after the applicable resolution target has expired, the Customer may escalate to the second escalation level designated by the Provider.

10.4 Escalation contact information may be provided separately and updated by the Provider from time to time. The escalation process is intended to improve the handling of qualified incidents; it does not expand the scope of services, business hours, availability targets, or contractual remedies.

11. Monitoring and Reporting

11.1 The Provider may monitor the services provided using internal or third-party monitoring tools. Monitoring may take place at the system, platform, application, interface, or infrastructure level.

11.2 Upon reasonable request, the Provider may provide a monthly or incident-specific report containing relevant information on availability, reported incidents, priorities, response and resolution times, scheduled maintenance, and significant unplanned downtime, provided such information is available and not security-sensitive.

11.3 Reports are intended solely for operational transparency and do not constitute an acknowledgment of liability or an agreement that a service credit is owed. Service credits must be requested and reviewed in accordance with Section 12.

12. Service Credits

12.1 If the availability target for a recorded SaaS service is not met in a calendar month due to downtime within the Provider’s area of responsibility, the Customer may, subject to the terms of this Section 12 and the General Terms and Conditions, request a service credit as the sole and exclusive remedy.

12.2 Service credits are calculated based on the monthly recurring fee attributable to the affected recorded SaaS service in the relevant calendar month. The following are not included: setup fees, project fees, professional services fees, support fees not attributable to the relevant recorded SaaS service, taxes, passing-through costs, and third-party costs.

12.3 If no separate monthly fee is specified for the relevant SaaS service in question, the service credit shall be calculated based on the portion of the monthly recurring fee that the Provider reasonably allocates to the relevant SaaS service in question.

Monthly Availability	Service Credit	Maximum Monthly Credit
99.9% or higher	No service credit	Not applicable
Below 99.9% through 99.0%	5% of the applicable monthly recurring fee	15%
Below 99.0% to 98.0%	10% of the applicable monthly recurring fee	15%
Less than 98.0%	15% of the applicable monthly recurring fee	15%

 

12.4 The total service credit for all SLA violations in a calendar month may not exceed 15% of the monthly recurring fee attributable to the affected SaaS service.

12.5 The customer must request a service credit in writing within 30 days after the end of the calendar month in which the alleged breach occurred and provide reasonable details regarding the alleged downtime. If the request is not submitted by the deadline, the service credit for that month will be forfeited.

12.6 No service credit will be granted if the Customer is in default of payment, has materially breached the Agreement, has contributed to the downtime, has failed to provide the necessary cooperation, or if the downtime in question constitutes an excluded downtime event.

12.7 Service credits will be applied toward future invoices. They will not be paid out in cash, do not accrue interest, and cannot be offset against disputed or overdue invoices unless the Provider consents in writing.

12.8 Service credits are the customer’s sole and exclusive remedy in the event that availability targets or other service levels are not met, unless mandatory law provides otherwise or the provider has acted with intent or gross negligence.

13. Obligations of the Provider

The Provider undertakes to:

• to provide and operate the services covered in accordance with the applicable agreement, the service description, and this SLA;
• to employ qualified personnel or appropriately supervised subcontractors for support and incident handling;
• to make commercially reasonable efforts to resolve incidents according to their priority;
• to document major incidents and corrective actions in a commercially reasonable manner;
• to inform the customer of scheduled maintenance and significant disruptions in accordance with this SLA, to the extent reasonably possible;
• implement appropriate technical and organizational measures in accordance with the applicable security documentation and data processing agreement.

14. Customer’s Obligations

The Customer agrees to:

• to use the services in accordance with the contract, documentation, reasonable instructions, and applicable law;
• to maintain a stable internet connection, compatible devices, browsers, local infrastructure, and customer-side systems;
• to designate a central point of contact and ensure that users submit support requests through the agreed-upon channels;
• to submit qualified trouble tickets and to cooperate promptly in the analysis of the issue;
• to provide all information, access, login credentials, logs, screenshots, test data, reference numbers, sample transactions, and decisions reasonably required for support;
• to promptly implement appropriate instructions, workarounds, updates, configuration changes, patches, changes to access credentials, or security measures provided by the provider;
• ensure that customer data, master data, registrations, documents, shipping data, customs data, tax data, and other entries are complete, accurate, and lawful;
• ensure that the customer’s systems, integrations, third-party services, and external connections do not interfere with the services;
• ensure that login credentials and access rights are managed securely and that users who have left the company are deactivated immediately;
• not to conduct any penetration tests, vulnerability scans, load tests, scraping, excessive API calls, or similar activities without the Provider’s prior written consent.

Delays on the part of the customer, lack of cooperation, or breaches of the customer’s obligations will suspend the applicable service levels and may preclude service credits.

15. Backup, Restoration, and Recovery

15.1 Backup and recovery services, if available, are governed by the applicable backup documentation, the security policy, the technical and organizational measures, the order form, or the service description.

15.2 This SLA does not include or imply any Recovery Time Objective (RTO), Recovery Point Objective (RPO), backup frequency, backup retention period, or restoration time, unless expressly agreed to in writing.

15.3 The Provider is not responsible for the recovery of data that has been deleted, overwritten, damaged, or incorrectly entered by the Customer or third parties, unless and to the extent that this has been expressly agreed in writing. To the extent technically feasible, such support may be provided separately and billed in accordance with the applicable rates.

16. Data Protection and Security Documentation

16.1 To the extent that the Provider processes personal data on behalf of the Customer, the applicable data processing agreement governs the processing of personal data, including security measures, support access, subcontractors, incident reporting, and the return and deletion of personal data.

16.2 The public privacy policy on the Provider’s website does not replace the data processing agreement for production customer data processed as part of the Services.

16.3 Technical and organizational measures, encryption, access control, backup, recovery, logging, monitoring, and security processes may be described in separate security documentation. This SLA does not expand upon this documentation unless expressly stated otherwise.

17. Suspension and Operational Protection

The Provider may temporarily suspend or restrict the Services in accordance with the General Terms and Conditions, this SLA, or applicable law if this is reasonably necessary due to late payment, misuse, excessive use, security risks, suspected unauthorized access, vulnerabilities, risks to data integrity, sanction risks, legal requirements, governmental orders, third-party requirements, or risks to the Services, other customers, or third parties. Such a suspension or restriction shall be deemed excluded downtime to the extent necessary.

18. Amendments to This SLA

18.1 This SLA is valid for the term of the respective agreement and cannot be terminated separately from the underlying agreement, unless expressly agreed otherwise in writing.

18.2 The Provider may amend this SLA with effect for future renewal periods, future service packages, or new orders, provided that the Customer is notified reasonably in advance.

18.3 Material changes that reduce agreed-upon service levels for existing covered services entitle the Customer to terminate the affected covered service effective as of the date the change takes effect, unless the change is necessary for legal, security-related, technical, third-party, regulatory, or operational reasons beyond the Provider’s reasonable control.

18.4 Individually agreed-upon extended service levels, including extended support hours, on-call service, dedicated response times, RTOs, RPOs, or expanded reporting, require an express written agreement between the parties. The Provider may also assert claims at the Customer’s place of business or before any other competent court.