In my estimation, I’ve negotiated close to a thousand software source code escrow contracts. The purpose of an escrow contract is to establish an agreement between the developer of software (or other technology) and the user, or licensee, of that software. This agreement establishes a business contingency plan for the licensee’s business-critical software in case there are unforeseen circumstances with the developer. It also lets the developer provide assurances to its customers. On average, a typical escrow relationship will last up to six years. Each year, like children returning to school after a long summer break, there’s often a new person in the department or organization that will inherit the task of managing the software escrow account – sometimes this is an account they never knew existed.

The “changing of the guard” is where you’ll find the most mistakes in an escrow relationship. I’ve seen clients mismanage the escrow agreement, simply because they didn’t understand their responsibility or the process for monitoring the account’s activity.

For example, I’ve seen escrow accounts released, when the developer never responded to a release request within the standard 10 business days, and the escrow materials were delivered to the licensee according to the contract provisions. Only to find out later, the developer had resolved the problem with the licensee but did not pay attention to the escrow agent notices. I have also seen escrow accounts terminated for “non-payment” simply because the contact or billing information changed and the third-party escrow provider (like Iron Mountain) was never notified.

In my opinion, the most common mistake that I’ve seen made with a legacy agreement (older than three years) would be a poorly managed escrow deposit schedule. The developer is usually under the impression that the licensee will request updates, just like they requested the escrow agreement. The licensee is usually under the impression that the third-party provider and the developer are working together to ensure the accuracy of the deposit account. In a nutshell, they’re both wrong. (For more information on this subject please reference my previous blog series). For the record, according to your basic three-party escrow agreement, the licensee has the responsibility of monitoring the escrow deposits, and the depositor has the responsibility of submitting all of the applicable information (Intellectual Property) for the intended purpose of the licensing agreement. A good escrow agent with provide tools for the licensee to set alerts in their escrow management portal, provide notices to the parties upon receipt of deposits and even twice a year provide notices to confirm all the parties are accurate, the developer and licensee have to engage with the escrow agent.

Unfortunately, the cardinal rule when it comes to working with a third-party escrow provider is, if the developer and licensee are not engaged in the process and aware of their responsibilities in the escrow arrangement, regardless of the efforts of the escrow agent, a neutral third party has limited ability to force either party into action. Like, updating the deposit material so the source code in the escrow account is up-to-date or on the other hand, how critical it is to verify the contents of an account that has never been tested.

Bottom line: The common denominator in all of these situations is simple. The people that establish the escrow relationship are almost never the same people managing the escrow agreement after the first year.

In your standard escrow agreement, you will typically find three primary sections dedicated to each party’s responsibility in the relationship. An escrow agreement is approximately six pages of terms and conditions with four to six pages of supporting documents, depending on the type of agreement (standard vs. master). Although the escrow process appears to be straight forward, both parties (developer and licensee) tend to experience challenges over time when it comes to figuring out standard questions, such as:

  • What’s the escrow agreement for?
  • Who should be the authorized contact?
  • Who should the billing contact?
  • When will I receive a deposit?
  • How do I know what’s in the escrow account?
  • How do you amend or make changes to an existing agreement?

Although none of these questions are unique, they’re absolutely understandable. That’s what inspired this blog series on What to Expect When You’re Expected to Manage an Escrow Relationship.

In this series, I will introduce best practices for managing an existing escrow agreement. This will include establishing a software asset management team to ensure the escrow agreement is running parallel with the business agreement. I will provide guidance for newcomers to the escrow relationship, by walking them through the anatomy of the escrow contract, to ensure the agreement is in compliance with …. Then we will review a checklist for validating escrow activity, within the escrow account, by ensuring the essential components have been submitted into the escrow deposit. To round out the series, we’ll review the process for amending the escrow agreement so that it mirrors business changes taking place in the software licensing arrangement. Finally, this series will also discuss suggestions for course-correcting a neglected escrow account.

I hope by the end of this blog series, developers will have a better understanding for submitting the appropriate information into the escrow account and the licensee will have a better understanding for the importance of the escrow relationship and their responsibility to monitor the escrow activity.