Platform Availability Service Level Agreement

These are not the current terms and are available for historic reference only. This content went into effect on May 21, 2019. To see the current terms click here.

Service Availability is defined as availability of the Tradeshift Platform to Tradeshift’s customer’s (“Company’s”) authorized users during operational hours. Any unavailability will be aggregated over each month and the below table details and service credits could be triggered. Unavailability does not include (i) periods of planned service, release or maintenance window, (ii) periods of non-availability due to an Event of Force Majeure, (iii) any period of suspension of service by Tradeshift in accordance with the terms of the Agreement.
Tradeshift shall make all commercially reasonable efforts to schedule maintenance during non-peak hours and minimize any such downtime and shall give Company at least five (5) days written notice of any planned maintenance outside of the standard window from the weekly Saturday 00:00 to 04:00 GMT that is expected to result in downtime. Tradeshift agrees to target uptime of > 99.5% for the general availability of the system notwithstanding planned downtime or issues related to force majeure.

Retained Responsibilities

In all cases, the customer remains responsible for the below efforts to assist with troubleshooting any availability issues that appear to be specific to the customer’s use of the platform.

Resolution efforts

• In the case of Urgent Incidents, Customer Contracting Party shall use reasonable efforts to make appropriate personnel available on a timely basis.
• Customer Contracting Party will provide Tradeshift, as soon as reasonably possible, with all relevant information for any given incident, as applicable and known: priority level, rapid response needed by date as appropriate, data integration files, response/failure files, step-by-step screen shots that demonstrate the incident, screencast recordings of the incident where applicable under Customer Contracting Party standards and guidelines, the time of the incident, the amount of time a system action takes to complete (or timeout), users involved in each step, frequency of error, consistency of error, replicability of error, specificity (which specific individual, groups or types of branches, users, suppliers, transactions, or suppliers are impacted), system configuration for impacted users (browser and version, installed browser extensions, operating system, screen resolution, etc), in each case to the extent Customer Contracting Party is permitted to disclose such information to Tradeshift. Customer Contracting Party will provide Tradeshift with any new or changed information regarding the Incident in a timely fashion.
• Customer Contracting Party shall use reasonable efforts to consolidate all further communication about an incident via the method agreed with Tradeshift.
• Customer Contracting Party shall confirm or reject resolution of each incident.

Integration Interfaces

• Customer Contracting Party shall make use of the error reporting and reconciliation interfaces made available by Tradeshift on the integration interfaces that Tradeshift provides, to determine whether the data transferred is syntactically and semantically correct.
• When Customer Contracting Party receives for processing an invoice or a credit note from Tradeshift, it shall respond within a reasonable time frame with an Application Response system message with status “BusinessAccept”. This shall allow for Tradeshift to generate recurring reconciliation reports allowing for the timely discovery of integration regressions.

Configuration Change Control

• Customer Contracting Party shall be responsible for making changes to any of the end-to-end functionality that is within Customer’s control including the ERP, middleware, FTP connections, file mappings etc.
• Customer Contracting Party shall notify Tradeshift when Customer Contracting Party changes any configuration in the end-to-end ERP to/from Tradeshift environment.
• Customer Contracting Party shall test and sign-off on any Tradeshift side configuration changes requested by Customer Contracting Party in the Tradeshift UAT system (currently known as Sandbox) prior to either Tradeshift or Customer Contracting Party migrating such changes to production.
• Customer Contracting Party shall verify that the configuration documentation maintained by Tradeshift is updated prior to Customer Contracting Party signing-off that a configuration change can be migrated to production.