This column is the second of a series on Vendor Finance. Vendor Finance is defined as a program in which the software company (“Vendor”), working together with a bank or leasing company (“Funding Source”), extends credit to its customers to facilitate the acquisition of software products and services by the customers. The first column discussed  the reasons why a Vendor might want to start a Vendor Finance program. It also discussed the distinction between a “Referral Program,” in which the Vendor refers its customers to a Funding Source for financing, and an “Assignment Program,” in which the Vendor generates the receivables in-house and then sells the receivables to the Funding Source. This column continues with a discussion of the documentation between the Vendor and its customer, with the focus on the how to make the receivables under the customer software license attractive to a potential purchaser.

GOALS AND OBJECTIVES OF THE VENDOR FINANCE PROGRAM

Once the decision has been made to start a vendor program, it is important to identify the goals and objectives of the program, and then review the Vendor’s standard form customer documentation to determine if there are improvements that can be made to help achieve those goals and objectives. The principal goals and objectives of a typical vendor program are the following:

  • To make the receivables attractive to a Funding Source If the Vendor does not want to enter into the lending business itself, then it is critical to make sure that the receivables meet the standard criteria required by a Funding Source for any financing transaction. As discussed below, if presented properly to the customer, these standard financing criteria need not be an impediment to closing the license transaction with the customer.
  • To permit revenue recognition In some circumstances, a vendor program may allow the Vendor to accelerate revenue. However, even if the Vendor is not trying to accelerate revenue, it is important not to inadvertently do something that impairs revenue recognition. For example, under SOP 97-2, if the Vendor offers payment terms of more than a year, this raises a presumption that the fees are not fixed and determinable, and that revenue should not be recognized up-front. This presumption can be rebutted with payment history for the customer, but it may be simpler to start out with a Referral Program and let the Funding Source offer the extended payment terms. In any event, the key is to consult with the auditors early-on.
  • To allow for a true sale of receivables In an Assignment Program, it is critical that the sale of receivables constitute a “true sale” under FASB ASC 860-10-40-5 (formerly FAS 140, as amended by FAS 166). This in turn requires, in many instances, that the Vendor obtain a “true sale” legal opinion from its counsel. Such an opinion is not exceedingly difficult to give in a properly structured vendor program, but can be a nightmare for the attorneys in a poorly structured program. One of the most important true sale criteria is that the Funding Source must purchase the receivables without recourse to the Vendor, except for recourse in connection with the breach of certain customary representations and warranties.

Some Vendors are reluctant to change their customer documentation when starting a vendor program. However, some changes can make the receivables much easier to finance and make it easier for legal counsel to give a true sale opinion, without having a significant negative impact on the customer relationship. It is well worth the time, cost, and effort for a Vendor to structure the vendor program properly from the beginning, rather than have to fix it retroactively when the auditors raise issues at year-end. With the above goals and objectives in mind, this column explores the key issues that the parties need to cover in the customer documentation to ensure the success of a vendor program.

PERFORMANCE RISK: WHEN IS THE RECEIVABLE FULLY EARNED?

Perhaps the single most important issue to a Funding Source when purchasing a receivable, is whether or not the receivable is an existing, enforceable, and noncancellable obligation of the customer that is payable come “hell or high water.” If not, it is highly unlikely that a Funding Source will pay full price for the receivable without recourse to the Vendor. (The presence of recourse would be an impediment to true sale treatment and revenue recognition.) Whether the receivable is noncancellable depends in turn on whether the customer has received the products and/or services that it bargained for; that is, has the Vendor performed the obligations that give rise to the receivable? If the Vendor has not yet performed, it is unlikely that the customer will agree to sign up to a noncancellable payment obligation.

The best way to handle the performance risk issue is as follows: (i) identify the different products and services offered by the Vendor under the license, (ii) specify what portion of the total receivable relates to each such product or service, and (iii) specify when each component part of the total receivable is deemed to have been earned by the Vendor. In this way, the customer documentation can clearly state for each product or service offered, how much such item costs and at what point in time the obligation to pay for such item becomes a noncancellable obligation.

  • Equipment If the Vendor happens to offer any equipment to the customer through a lease or other financing arrangement, it is customary in the leasing industry for the payment obligation to become noncancellable upon delivery and acceptance of the equipment by the customer. Upon acceptance of the equipment, the receivable becomes one that a Funding Source would be willing to buy on a nonrecourse basis, because the Vendor has substantially performed.
  • Software In the case of software, although some Vendors use acceptance certificates, many do not. The customer payment obligation often arises upon delivery of the software as opposed to acceptance of the software. If so, this should be spelled out clearly in the license documentation.
  • Services With respect to services, the point at which the obligation to pay for the services becomes noncancellable depends upon the type of services offered. The key is to spell this out clearly in the customer documentation. For example, (i) some services, like routine maintenance, are billed annually in advance, whether or not the customer actually uses the services; (ii) some services are billed net 30 days on a time and material basis as the services are performed; and (iii) in other cases the obligation to pay for services arises as certain milestones are met.

In each case, it is critical to identify at what point in time the payment obligation becomes noncancellable, which is also the point at which most Funding Sources will be willing to purchase the receivable on a nonrecourse basis. As a general rule, this occurs when the Vendor has substantially performed the obligations giving rise to the receivable.

TYPICAL CUSTOMER DOCUMENTATION

The customer documentation in a software Vendor Finance transaction typically includes the following:

  • License Agreement The license agreement contains the standard terms and conditions that apply to all license transactions.
  • Product Quotation or Schedule The Product Quotation or Schedule sets forth the list of particular products and/or services licensed or contracted for by the customer. Each Product Quotation or Schedule (i) should constitute an independent contract and (ii) should incorporate by reference the terms and conditions of the master license agreement. This allows the Vendor to finance each Product Quotation or Schedule independently. This is a well-established principle in the world of equipment leasing, but has yet to take hold universally in the software industry.
  • Installment Payment Agreement (IPA) IPAs or promissory notes are recommended, but not always used. When using an IPA, the Product Quotation or Schedule should quote a cash up-front price and all of the extended payment terms should appear in the IPA. The advantages of using an IPA are many, including the fact that there is a stronger argument that the payment obligation is independent from the license, noncancellable, and not subject to claims of set-off arising under the license. Often an IPA will contain a grant of a security interest in the licensed software. While the security interest may not provide any material benefit to the software Vendor, it may be of value to a Funding Source assignee, in that (i) the Funding Source would have a security interest in any customer rights to cash refunds, and (ii) in a customer reorganization in bankruptcy, the Funding Source would have a security interest in any proceeds from the sale of assets, to the extent that the proceeds relate to the software license. If the customer will not sign an IPA, the Vendor may still be able to sell the receivables under the Product Quotation or Schedule, but using an IPA is the preferred approach.
  • Financing Addendum to License Usually the Funding Source will require an addendum to the license that contains a cross-default provision stating that a default under the IPA constitutes a default under the license. The Financing Addendum also makes the Funding Source a third-party beneficiary of the cross-default provision, so that the Funding Source can require the parties to terminate the license if the customer is in default of its payment obligations under the IPA.

PRINCIPAL ISSUES TO COVER IN THE CUSTOMER DOCUMENTATION

The following are the principal issues that the parties need to address in the software financing documentation:

  • Noncancellable; must pay come “hell or high water” As discussed earlier, perhaps the most important issue to the Funding Source is that the customer payment obligation must be noncancellable. It is important to make sure that upon delivery of the software, the customer payment obligation with respect to the software is noncancellable. If the Vendor later breaches a service obligation, such a breach might allow the customer to avoid paying the related service fees, but it should not allow to customer to avoid paying for the software that was previously delivered.
  • Assignment of receivables by the software Vendor The Vendor should be expressly permitted to sell and assign the receivables under the License, Product Quotation or Schedule, and IPA.
  • Waiver of defenses against assignees It is standard practice in financing transactions for the customer to waive as against the Vendor’s assignees, any defenses to payment that the customer may have against the Vendor. Such waiver of defense provisions are reasonable, so long as the receivable in question has been substantially earned. Problems tend to arise when the Vendor requests the customer to waive defenses as to payment for future services that have not yet been performed. This problem can be avoided through careful drafting and clearly stating when the payment obligation in question becomes noncancellable.
  • No assignment by the customer From a financing perspective, the customer should not be able to assign or delegate its obligation to pay under the license or IPA. The reason for this is that the Funding Source approved the credit of the original customer, not the assignee. Various compromises can be negotiated with the customer, but the starting point should be that no assignment or delegation by the customer is permitted, even in a merger or sale of assets.
  • Cross-default between the IPA and the License This is often covered in the Financing Addendum to License that amends the license in those instances in which the customer chooses to finance its acquisition of software by signing an IPA. Alternatively, some Vendors include the cross-default language right in their standard form license.
  • Default Interest Funding Sources typically look for a provision requiring the customer to pay interest on late payments. In Vendor Finance arrangements, it is not unusual, however, to find long cure periods of up to 30 days.
  • Acceleration Upon Termination or Default A provision that is often overlooked by Vendors is an acceleration clause. If a customer defaults, it is essential that there be an acceleration clause stating that the present value of the remaining payments becomes immediately due and payable in full. Otherwise, the Funding Source may have to sue separately for each payment as it becomes due.
  • Notification of Assignment Although vendor programs can be operated on a non-notification basis where the customer is not told of the assignment of receivables, there are numerous legal advantages to providing the customer with notice. For example, providing notice to the customer makes it much easier to give a true sale legal opinion in an Assignment Program.

WILL THE CUSTOMER AGREE TO THE FINANCING TERMS?

Sometimes the Vendor is concerned that the customer will not agree to the financing terms, which may at first blush seem onerous. However, if the only options the customer has are (i) to pay cash up-front, (ii) to borrow money from a third-party lender pursuant to a 20-page loan agreement, or (iii) to finance over time with a two-page IPA through the vendor program, then the IPA may very well start to look like the most attractive option. In fact, an IPA in a typical  vendor finance program is usually more customer-friendly than the typical loan agreement offered by a third-party lender outside of a vendor program, which may contain onerous financial covenants and/or negative covenants. The important point to remember is to avoid, whenever possible, offering extended payment terms in a license transaction unless the customer signs an IPA.

CONCLUSION

In summary, it is critical to the success of a software vendor program that the Vendor review its standard form customer documentation and make those changes that will allow the Vendor to sell the customer receivables on a nonrecourse basis. Although this may seem like a daunting task at first, it is possible to draft customer documentation that is both palatable to the customer and attractive to a Funding Source interested in purchasing receivables on a nonrecourse basis.