I try to bill more frequently. Don't wait for big # of hours or big $$. However, even that doesn't guarantee payment. Remember to NOT continue work if payment is not made?
Good responses Beverly and siplus!
I've never time-bombed a piece of software, but I do keep the backend 100% locked down until the project is 100% complete.
We sell our product in monthly installments. When the payment date is due the system asks for an activation key, which we provide once we confirm the payment was made. Harsh but 100% effective.
Of course, we explain this to our customers even before they are our customers, at the pre-sales stage.
Before that I practically had to beg my customers to make payments on time, or wait until they need tech support to make pressure and force them to pay.
Likewise. This keeps us from getting "too far out on a limb". We also ensure we review progress with the client on the same frequency (in our case, weekly) so that we can find out quickly if we're heading in a direction that a client doesn't agree with.
For contractual dev work, we bill monthly. Be careful with time-bombing. In some legal systems this can backfire.
New customers and bad payers are billed upfront for license keys.
It really helps being very clear on what you are agreeing to do and what the rate will be (hourly / project ), and what the terms of payment will be. Good communication up front often minimizes problems down the road. And sometimes put yourself in your client's shoes. They want to know how much they are committing too and are generally afraid of open ended agreements where you can just keep adding as many hours as you want without confirming with them. One way I offer clients a solution to this is to just have them give me a PO for a several thousand and when it is used up, I have to ask for another PO, but do not continue to work past the amount authorized in a PO. Most corporations work this way, but often smaller businesses don't think of this as a way to control expenses and assure they know what they are on the hook for. And as Beverly said, stop work when you are not paid timely.
I've seen invoices that some FM developers send that just gives a number of hours done at the end of the month and asks for payment. That is not very helpful. Providing details on what you did each day you worked for them makes the accountants and auditors much happier and better confirms that work was actually done. Just like good documentation is important in your scripts and calcs, likewise good invoicing documentation is important and minimizes problems when demanding payment.
One lesson I have learned is that if you have problems getting paid the first time, it almost always is indicative of continued "issues" with getting paid down the road. I usually low prioritize such clients and only work on them when other clients don't need me. And when they need something and I'm not available, I refer them to the FM consultants web page.
It depends on whether you're doing new development or working on someone else's system. And what you agree on. It's important to have some things in writing, too.
If we do new development, we charge for estimating the work and usually take the full amount in 2-3 chunks. This way we know the client understands the commitment and the timeline. We also only hand over the finished database once the balance has been paid.
If we work on ongoing development in a live system we usually have a retainer, until we trust the client, then we bill bi-weekly or monthly. I've had a client who was months and months late with bills and got slammed with late fees, but I trusted they will pay and they apologized for switching the accounting system and I was reassured that the delay was not a reflection on the quality of work.
I realize after being in this business for awhile that if prospective clients spend more time on bargaining than planning the software, they are not the right client. As a friend said, not every client is "happiable".
Civil conversation until not possible.
Pursue legal action if you have the resources ($$) and patience.
Notify BBB (has actually helped me once).
Chalk it up to experience and never let it happen again (see Agnes Riley's post).
Don´t think of taking legal action unless your client really has a large debt (which should not/never happen).
Going to court seldomly results in something you will like regarding software, because:
- your lawyer doesn´t understand your business and what you are doing
- the advocate of your client doesn´t want to understand you at all
- the judge is completely overcharged by the facts and arguments
- therefor you will have to pay for a damn expensive official expert to make your point. Hopefully he understands the case and makes the points you hope for.
- Probably the judge will propose something like "meet in the middle", so that he doesn´t have to judge himself
- If you get half your money, pay the expert and your lawyer you will probably have won nothing. Instead it took one or two years of your life and cost lots of hours of your work for explaining the facts to your own lawyer, to the opposite advocate, to the judge and the expert.
- If you have bad luck, you fail or have to fight for your case again on a higher court.
You could ask for the reasons why he does not pay you. If the client is not satisfied with the work is a different situation from not being able to pay you right now because of a temporary financial problems.
Recently I've started developing all solutions using a cloud based provider of my choosing, under my control, even if the finished project is going to be hosted by the client themselves. It's not fool-proof, as the client can still just walk away, but at least you know that they're not going to be able to continue using the solution you've made for them until they've paid for it.
Because of exactly this same issue, c0nsilience, contracts I've drawn up for new clients in the past several years shifted payment to up front. So let's say I have a $30,000 project slated to take 6 months, the client pays $5K to start the project and $5K at the start of every subsequent month. The last month will be $2,500 up front and $2,500 on project completion. I didn't know how new clients would respond when I first implemented the policy, but I've yet to lose a project because of this policy.
If payment is late, work goes on hiatus until payment is made. Once they've established a good payment history and the project is complete, I shift to logging hours and billing after the fact. One client with a struggling payables department I continued to make pay up front.
Ultimately, I chose this policy to be sure it doesn't happen again to me and because I know that I will deliver on the project. I don't have the same confidence that a new client will pay in a timely manner. The payment problems I've had are rarely due to disputes over the work. Some businesses have cash flow issues. Some businesses have inefficient payables departments or inflexible payment terms different from what I agreed to with the client.