by Bennett Quillen
Evaluating and Negotiating
a Softvvare Contract
by Bennett B. Quillen
Bennett B. Quillen
o you are about to
sign a software contract.
Do you know
what to request
from your proposed
vendor and what to look for
in the contract? Do you
know which clauses in the
contract bear the closest
Undoubtedly, you have already
done your homework
on the software itself: thoroughly
reviewed the current
and future capabilities of
the system (or systems) to meet your
needs; determined that the functions
you need-routine reports, accounting
controls, and testing procedures-are
in place; performed due diligence on
the depth and knowledge of the firm
and its staff; checked references (including
recent conversions or installations);
and assessed the firm’s financial
Without question, the amount of
time you invest on software assessment
affects the scope, impact, and relative
difficulty of converting to and installing
the new system.
Now you are in the throes of signing
the contract. Do not minimize the importance
of this step. It could ultimately
mean the future profitability of your
bank and even your job.
You may implicitly trust the software
firm you have chosen and you will no
doubt seek legal assistance, preferably
from attorneys familiar with computer
software contracts. Still, you must reread
the contract to be sure you understand
all of its clauses. Is the contract
relatively straightforward and easy to
understand? Does it include all of the
negotiated or agreed-upon issues?
All software contracts have several
provisions, whether licensed solely for
inhouse or via third-party processing.
All of these provisions must be reviewed
by one or more of your executives.
Depending upon the vendor and
software, the following topics may be
grouped in different ways.Nonetheless,
some of the more important provisions
in any software contract must include
• Terms and conditions
• Warranties/maintenance liability
• ‘Iraining and education
• Acceptance testing
Terms and Conditions
Customers usually pay most attention
to this section of the contract. The
questions to ask are: Are the terms and
conditions currently accurate? Are the
definitions and descriptions correct
and satisfactory to you?
Payments and Term
The schedule of payments and the term
of the contract are dependent upon
each other. You can negotiate for a
lump-sum payment or an installment
schedule. The amount you wish to pay
depends upon your cash flow needs
(with appropriate present value analysis)
and the term of the contract.
If you select a longer term contract
(more than the standard 4 or 5 years),
you can and should expect substantially
lower annual software purchase
It is important that the contract distinguishes
between payments to purSOFTVVARECONTRACT
chase the software and payments to
maintain the software. Some firms will
aggregate the purchase and maintenance
amounts. However, for you to
properly evaluate the cost of the software
and its future maintenance compared
with similar software, the contract
must spell out these two components.
Whether you purchase the software
in a lump sum or with an installment
plan, the contract will require an upfront
payment upon signing, usually
one-half of the first year’s payment.
The other half will usually be due 30 or
60 days after the contract is signed.
This is an important point to resolve
with the vendor: The balance of the upfront
payment, whether on a lump-sum
or an installment basis, should not be
due until after acceptance testing is
completed. More on this later.
Make sure that you may operate the
software on more than one machine.
Perhaps you have little intention of expanding
your centralized mainframe
processing. Nonetheless, you may have
future needs for remote or even correspondent
processing. Either of these
circumstances could require multiple
versions of the software.
If the vendor will not provide this
flexibility at the same cost, ask for a
compromise. Include a clause that provides
the vendor with an equitable percentage
of the proceeds, above some
threshold amount, received from processing
for external customers.
Many of today’s contracts include a
price escalator clause which permits
the vendor to increase the annual purchase
installment (another factor to be
considered in a lump-sum versus an installment
payment) and maintenance
amounts. The escalator is usually based
on some well-known index, such as the
consumer price index.
If you feel your costs more appropriately
reflect another index, such as the
GNP deflator, discuss it with the vendor.
In any case, compute a trend over
the last 12 to 20 quarters of the proposed
indices to determine which
might be the least costly to you.
Often software buyers receive “discounts”
from the “list” price of the
software (sounds like buying a car,
doesn’t it?), provided they purchase
several applications concurrently or
within a limited period of time.
Obviously, check that these discounts
are true reductions in the cost of the
software and not just a means of striking
parity with the vendor’s competition.
Also, do the discounts apply only to
the purchase of the software? This can
be another point of negotiation, particularly
if your bank is acquiring several
applications. Request that the discount
apply to maintenance of the system as
well. Furthermore, does the maintenance
percentage of the current purchase price
(usually between 15% and 20%) apply to
its “list” or “discounted” price?
Be certain the contract specifically
identifies the application or applications
you are acquiring. Be sure that
the modules or other interfaces. which
you may assume are part of the application,
are indeed listed or described in
the text or as an appendix to the
What happens to the bank’s obligations
if it is required to reorganize and be acquired
under a supervisory agreement?
Your bank may want to include wording
in the contract that terminates or reduces
any further obligations, should
Who incurs legal expenses in the event
of a dispute? Are they borne separately?
Is the software firm limited only
to the amount of its out-of-pocket legal
costs and revenues received from your
These are issues you will need to resolve
within your bank and with your
What warranties or maintenance guaranties
are expressed or implied in the
contract? Be certain that these are
The contract should explicitly state that
the software firm is responsible for all
regulatory compliance within the scope
of its application.
Remember that regulatory compliance
includes state as well as federal
regulations. Often a software house
may not have previously sold its applications
in your state. This is of particular
importance with certain applications,
such as payroll, credit card, and
The contract should specify responsibility
for computational errors (not
input errors), for example, incorrect
rounding. The contract needs to define
computational errors, how soon they
need to be identified by the bank, and
the extent of financial damages if software
computational errors occur.
Ownership of Code
Another issue is the ownership of the
source code for the application. Does
the vendor supply you with only the object
code? If so, what is your position of
ownership if the company defaults?
Without a doubt, you need to make
sure that your bank retains complete
rights to the source code in the event of
a vendor bankruptcy or reor.ganization.
The contract should clarify the effect, if
any, of other software interfaces on the
vendor’s system. For example, your
bank may wish to develop, internally or
through a contract programming firm,
its own interfaces to other applications,
such as general ledger and customer information
Nonvendor interfaces may nullify
parts of the warranty, particularly responsibility
for computational errors.
Does the vendor specify the number of
releases during a period of time? This is
usually not necessary, so long as the upgrading
is provided on a timely basis.
However, it is wise to include a proviSOFTVVARECONTRACT
sion that releases will be provided to
meet regulatory (federal and state)
changes and to keep current with market
Who is responsible for installing the
releases? This issue is particularly important
if your bank intends to develop
interfaces or modifications to the system.
The last thing you want is your version
to be “out of sync” with the
How will the vendor support installation
of a new release? Will there be onsite
support or only telephone
communication? What additional costs
are incurred for on-site vendor support?
Obviously, the extent of vendor
support is a combination of your bank’s
data processing resources and the complexity
of the release. Nonetheless, it is
good to defme in the contract the type
and extent of vendor support. In fact,
for a major application, the vendor
should be willing to commit to a specific
number of qualified people to
maintain the system. For any large (e.g.,
demand deposit accounts) application,
at least 10 people should be required.
Training and Education
Ask for contract provisions from the
vendor to schedule and coordinate periodic
user meetings or workshops.
These events will help ensure that your
maintenance payments go toward a system
that is up-to-date.
The contract should specify the amount
of training time the vendor will provide
to your bank. The amount of training
will depend upon the size and number
of applications that your bank acquires.
Training and education should be
quantified for both users-non-data
processing personnel or data processing
customer service staff-and technical
or systems personnel. Training can
be conducted at the vendor’s site, at
your bank, or via the telephone. The
amount, type, and location of the training
should be specified in the contract.
The size and complexity of the application
installation and conversion will
determine the best mix of training and
educational needs. Most vendors will
provide a fairly substantial amount- of
education at the vendor location at no
charge, provided the bank sends limited
numbers of people at anyone time.
A problem may arise when the bank
needs substantial training at its loca-
. tion. Who will pay for it?
As the customer, you can request as
much training as needed at no charge.
You also may request that much of the
user training be conducted on your
bank’s premises. All training involving
an instructor should have an associated
cost. (Training via telephone should be
at no charge.) If your bank exceeds the
contractually allotted training time, the
bank would incur a charge. In addition,
you should ask that any “unused” training
during a specific period (usually a
year), be credited to your training
needs in the forthcoming period or
used to offset the bank’s maintenance
Most software contracts do not provide
a sufficiently complete definition of
when a system or application is actually
“accepted” by the financial institution.
Before a bank accepts a system, it must
conduct an “acceptance test.”
The acceptance. test involves processing.
actual bank production data, not
just vendor data. Selected conversion
programs use the. production data to
produce reports of summarized accruals
and balancing totals, based on daily
and month-end runs. Only after the
bank has validated these reports should
the bank actually accept the system.
Acceptance testing occurs long before
the actual conversion takes place,
but after the physical delivery of the
system. Depending upon the
application’s complexity and the scope
of the conversion, a proper acceptance
test can require 30 to 60 days.
It is vital that the contract define “acceptance
testing” in terms comparable
to those described above. Clearly, the
contract payment schedule-indeed
the entire contract-depends upon a
successful acceptance test. Consequently,
if the application fails the
“test,” the vendor must refund all monies
to the bank.
The signing of the contract is not
merely a perfunctory act which occurs
at the end of software analysis. Instead,
it is a vital step for the well-being of the
bank. Furthermore, there is only one
way for an individual to ensure that he
or she understands the contract and all
its ramifications: Read it!