In Part 1, we discussed what a dependency in a technology integration is and how to deal with it in a contract. In this installment, we’ll consider how to address the risk of the assisting party not providing required information or assistance.
Causation: Sole Cause vs Primary Cause of Default
When a responsible party cannot proceed with the integration because of failure on the part of the assisting party to provide agreed assistance, the responsible party should be relieved from liability. But what if the responsible party contributed to the breach?
Imagine a scenario where the process of integration was delayed by the following two factors:
- Assisting party fails to provide required assistance
- Responsible party does not complete previous dependency on time
In technology integration deals, the assisting party would likely push for sole cause language, so the breach of assistance obligations would only trigger the relevant remedy if such breach was the sole cause of the responsible party’s failure to proceed with the integration.
Conversely, the responsible party would likely push for primary cause language stating that the responsible party would be relieved of liability if the breach by the assisting party was the primary cause of the responsible party’s failure to perform.
Non-Monetary Remedies: Time Shift, Deemed Acceptance, Service Credit Freeze
Let’s consider non-monetary remedies that may be used to address the failure of the assisting party to provide agreed support.
Integration obligations of the responsible party are usually time bound, which means the responsible party would be in breach if the integration—or specific integration milestone—is not completed on time. It is reasonable then for the parties to agree that the relevant deadline will be automatically extended when the assisting party is in breach of its obligations to provide agreed assistance. Sometimes the parties may agree to add extra days to allow the responsible party to resume the integration activities that were put on hold.
Time-shift provisions are more appropriate for contracts where the transferor is responsible for the integration. In contracts where the recipient acts as a responsible party, time-shift clauses are of little help unless the parties agree to defer some part of the consideration, and the payment obligation of the responsible party is postponed in case of a breach.
Sometimes the assistance from the recipient is so crucial for a successful integration that it is reasonable for the responsible party to push for a deemed acceptance remedy. In this case, the responsible party would claim that its integration obligations are deemed fully and duly performed if the assisting party materially breaches its assistance obligations.
Service Credit Freeze
In complex integration projects, the parties may negotiate a service level agreement (SLA) for integration services. In this instance, it’s not uncommon for the responsible party to insist that no service credits will accrue if the assisting party remains in breach of its assistance obligations.
Monetary Remedies: Liquidated Damages, Service Credits, Price Adjustment
Where non-monetary remedies are insufficient, parties may consider introducing monetary remedies, i.e., liquidated damages, service credits, or price adjustments.
Liquidated damages are most appropriate for contracts where the recipient acts as the responsible party. When drafting a liquidated damages clause, make sure the liquidated damages represent a reasonable forecast of the actual damage caused by the breach. If the amount of liquidated damages is found to be excessive—or if the damage would have been easy to calculate at the time of contracting—the related contract provision may be considered a penalty and voided. See our prior post on liquidated damages for more details.
When the scope of assistance is so broad that it is comparable to the scope of integration services, it may be prudent to agree on an SLA. In this case, service credits may be an appropriate remedy. However, be mindful of tax and accounting rules, as treating assistance obligations as a separate service may result in unexpected tax consequences.
Price adjustments are a mechanism where the recipient seeks to create an incentive for the transferor to achieve a specific result of the integration. It is especially helpful where the success of the integration depends on the transfer of something that, strictly speaking, cannot be sold—e.g., active users or employees. In this scenario, the failure of the assisting party to provide the required assistance would result in an adjustment to the purchase price. For the price adjustment mechanism to work, the parties must first agree on specific key performance indicators (KPIs) for the integration—or separate KPIs for separate integration workstreams—and incorporate them into the price adjustment formula.