When was the last time you bought something? Today? A few days ago? Do you have the item in your possession now, or did you order it online? At what point in the transaction did you pay for it? I keep twisting these questions over in my head each time I read payment language that wants payment for software at the time of signature.
Of course I can see the vendor’s point. They are granting immediate license to use the product, thus I should pay now as I can have immediate benefit of the license. But for the vast majority of products, some kind of implementation or installation must occur first… and almost always, the vendor is the installer.
In such a case, when should I have to pay? My gut feeling is that I don’t pay until I receive value from that which I have purchased (or will be immediately able to receive value – for those items that are being shipped to me). Which means, in the case of most software – that I shouldn’t pay until installation/implementation is completed.
Again, on the vendor’s side, this is a huge problem. Some implementations can take months. Cash flow is a serious concern for everyone, especially for smaller software vendors. So how do I address the vendor’s concerns of getting paid promptly, while still making sure that I get what I’m paying for?
Know first that this is all a matter of personal preference and corporate choice. Your organization may have no qualms about paying 100% upfront vs 100% at acceptance. But if you do HAVE the choice, I recommend considering the following things:
1. Software which requires installation should not be more than 50% paid for prior to acceptance. If you can’t use it in its un-installed form, it’s not worth anything to you yet.
2. Installations or implementations that take an extended period of time protract the risk for both parties. Decide upon a payment schedule that makes sense given the apportionment of the risk. This means understanding thoroughly the complete deal and where responsibility lies for each task.
3. ALWAYS, ALWAYS, ALWAYS have an acceptance testing procedure and tie the bulk of the fees/payment obligations to successful completion of the LAST acceptance test. My favorite analogy for this is the one about building a house. If everything else is done on the house but the roof isn’t put on properly, do you still want the house? Of course not. Make sure you end up with a completed project.
4. Payment breakdowns can be whatever you wish them to be. Milestone based is my preference.
5. Added to #3 above, make sure you also have the ability to get a full refund in the event that the project is never finished due to the vendor’s behavior. My vendor audience will cry bloody murder about this, but let’s be honest and depersonalize it for a moment. If I was selling you a car, but was doing so in pieces that could only come from me, would you want the body if I didn’t give you the wheels? I doubt it. The same is true with software. Those products which require vendor assistance to install need to be fully installed or the product isn’t worth anything to the buyer.
At the end of the day, however, and like everything else in the contract world, these points are all negotiable. Giving up payment terms for lowered cost – or the inability to get a full refund for a fixed price installation, for example, might be worth the risk.
What odd payment agreements have you made to close your deals? Comment below and lets learn from each other!