Payment structure
From NZ PHP User's Group
Contents |
Payment structures
There are generally three payment structures available
- Payment upfront
- Payment after delivery of service or goods.
- A mixture of both. This method may include some or all of a sign up fee, the deposit, progress payment and a final payment.
General market behaviour
Generally payment terms depend on negotiation and therefore on the negotiation power of the parties involved. A supplier or contractor may achieve better terms if he has a good reputation, if he is busy or booked out for a long period, if his service is specifically in demand or if the service is generally unavailable.
For the client, they may achieve better terms, if they can point out weaknesses in the suppliers setup, their project is generally seen as interesting, the project could create good experience for the supplier or the project is generally bigger than what the supplier is usually used to at the point of negotiation.
Note that these upsides and downsides are purely based on perception. A service might be perceived unavailable, because the client has not looked around enough or generally restricts his choice of suppliers to local staff or people recommended by businesses associates of the client. Of course any such reason is a good reason based on the values and experiences of either party in the deal.
Development of relationship
Payment terms will usually be negotiated at the beginning of a relationship and will likely change over the time of the supplier and client working together. At the beginning the supplier may require a deposit, hence only extending credit for a smaller amount of a project. For future projects or maintenance items, he may not require a deposit, based on the payment history of the client. Of course a bad payment history may also convince the developer to require upfront payment of all charges.
Sign up fee
If a project is not due to start for a significant amount of time, for example 6 weeks or more, it may be suitable to require the client to pay a sign up deposit. The reason for this is that a client may be serious at the time of committing to a project and sign a contract, however a significant change to the circumstances of the client (insolvency, terminal illness of senior staff or their family) may make them decide to change their mind. While a contractual agreement may be in place it is always unnecessarily difficult to enforce this. A payment in the bank to cover a period where a new project needs to be found for the developer is always a safer option. From a developers perspective consider that you may of course refund this amount in exceptional circumstances or if there is actually no damage caused, i.e. if other project can be moved forward. In this case the sign up fee acts as a bond.
Deposit
At the beginning of a new supplier-client relationship a deposit can have a number of positive effects for both the supplier and the client. Firstly, it creates a serious commitment for the deal. A client that has paid 30% of a project price is certainly going to keep on moving forward with a project, even if the project gets into difficulties somewhere in the middle of the development time. Such difficulties could be due to the nature of the project - some projects are difficult to show progress for until a certain critical mass of code is reached. Also, staff issues at the client as well as at the supplier may cause difficulties. Consider also that a deposit puts client and supplier on a equal footing: Especially in the web development industry in New Zealand development houses are confronted with a much bigger client that has much better legal and financial leverage.
From experience [1], deposits usually range between 25% and 50% of the total project cost. A variant of this is described below in "upfront payment"
Of course with all deposits, refunds should be excluded unless required by law.
Upfront payment
A variant of a deposit is described in the book "Million Dollar Consulting" by Alan Weiss. He suggests to work towards a deposit of 90% with 10% discount for the project that the client never has to pay. The additional benefits are a better (total) client commitment, a high development pressure on the supplier, which can naturally push the project along better and a total elimination of invoicing, finance and debt collection costs. It also creates a cost saving for the client.
There a number of other reasons why upfront payment may be a suitable structure.
Firstly all services that are onsold in some or another way and are paid upfront should require upfront payment. This includes for example hosting, domain registration and similar and rent payments.
It is also common to charge retainers, that is a monthly payment to be available to work on something upfront, after all you can't decide after the month ends if you should have been available.
Further, upfront payment can be rephrased as a prepayment discount. Such a structure reduces the developers risk in return for a lower total cost for the client.
Finally, an upfront payment may simply make sense with small scale sales or sales by credit card or Paypal. The costs of collecting debt on a number of sales is obvisouly much bigger in terms of percentage, if the price tag of the development or item reduces. Therefore this model should also suit strongly productised offerings, such as preconfigured CMS systems and the like.
Progress payments
Progress payments create a fair playing field again in a later part of a project. After a deposit has been paid, the developer may expect to work a further 3 months on a project. This may put them into serious cash flow difficulties and also place all risk at their end.
A progress payment can be calculated based on the actual progress or the time passed since the project started. From experience [1], project based progress is more common and this would also be the only option if project scope constantly changes or the project is based on a pure time and materials cost calculation. If there is a fair process of the client and the developer accepting change to the scope and the developer does not suffer downtime from the decision making process of the client this works well.
There are cases however, where clients do not follow a structured decision making process or are unwilling or unable to make a final decision. This can be worked against by either requiring a limited time to decide on a specific question or by progress payments that are based on time passed since development. In the latter case payments would be simply due, no matter what progress is.
There may also be a situation when only a small amount of a development stays unresolved and further progress payments could not be based on the actual progress of the site. In this case it is fair to ask for the final payment, as a client can not defer a decision indefinitely. In fact, the reality may be that the decision does not make sense to make and the missing functionality should not be developed at all.
Final payment
The final payment can be seen as the last progress payment of the project and the same rules as above apply.
A caution should be considered when the project involves a new venture, either of a new or an existing business. In a lot of cases, the developer may agree to make the website or system available for use for the client before final payment is received. In a new venture a situation may then develop, where the focus of the client moves from developing of a website to marketing it, hence redirecting funds from the developer into a new channel. This is then explained with "having to spend on marketing, otherwise we won't recoup our money for this website either". This is an unacceptable variance of the "we pay you when we get paid" idea described further below.
Final approval of a development may also take much longer, mainly because many clients have not gone through an actual testing and approval process at earlier progress payments. Because of this it is recommended to push for acceptance or bug reports once a development has been completed or otherwise push for payment if no answer is received.
Invoice date vs payment date
Obviously the close the payment ate is to the invoice date the better for the developer. There are a number of considerations however that affect how different payment types work out in reality.
Sign up fee, deposits and upfront payment need of course be received before the service is provided. It is therefore not advisable to start work on a project where a deposit is required, but not received. Similarly if the deposit is paid on the 20th of the month, the developer may work in fact between 20 and 50 days without any deposit, exposing themselves to the same risk of not asking for a deposit at all.
It could be argued (and has been successfully [1]) that payments should be received immediately after invoice - or taking the clients accounting processes into account after 7 days. This makes sense as otherwise a progress payment may be delayed so much that again a large amount of work is performed without having a balance payment against it.
Some clients will argue that all suppliers are paid on the 20th of the month. This is firstly never true - they pay plumbers, electricians, the power company, Telecom and domain registrars on shorter terms. Secondly, nearly all website development work is part of capital expenditure (unless it is resold), hence the client shoukd have budgeted for it and have the money sitting and waiting in any case.
If the development is onsold it is common in some industries to only pay for the development once payment has been received from the end user. The developer does take some significant financial risk with the client in this case, for which he should be rewarded with additional gain. However this is rarely possible, as it is unlikely that the client will pay interest in this case or give the developer shares in his company. This is therefore an unacceptable arrangement. According to general legal advice [2], this may also not hold up in legal proceedings if put into a contract.
On the other hand such payment request may be perceived as a nuisance and may in fact in the corporate and government sector be a deal breaker. A possible way to get around this is to pass the invoice on to a factoring company for finance. In this case the client would have to sign off the invoice as accepted, but would be able to pay the invoice on their terms. The cost of this finance is likely to lie with the developer.
Late payment and debt collection fees
The development contract between developer and client may include provisions for interest and fees for late payment and debt collection costs. Interest is usually paid, however the developer extends further credit to the client in this case. The client may be in a situation where they cannot receive (rightfully) credit anywhere else, hence the developer becomes effectively a bank, but without the risk management procedures of a bank.
Debt collection costs can also be included, however based on general legal advice [2], a client may also dispute deliverables in a genuine case of not being able or willing to pay. A realistic scenario in this case is to simply meet somewhere in the middle and debt collection costs may not be a helpful part to negotiate over.
[1] Experience of Jochen Daum, Automatem Ltd.
[2] ChambersCraigJarvis Lawyers To Automatem Ltd
