Late Payment For Work

[Wayne]

I have just experienced my first late paying client. By "late" I mean
that the invoice is now almost 2 months overdue. I don't think that
the client is maliciously withholding payment - rather there has been
an unfortunate series of events which has delayed the payment. The
bottom line for a small time developer is still the same however. I am
confident that I will receive payment for the invoice eventually but
it is now a case of "once bitten twice shy".

I am interested in what measures others employ to avoid or deal with
this situation, short of asking for payment up front which I don't
think would go over too well with most clients.

One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

This could be achieved by hard coding a preset date after which a
critical data entry form would be deleted. If payment is received in
a timely manner, an updated file would be sent to the client before
any disruption to business occurred. Deleting this critical form would
stop the client resetting there computer clock after the fact, thereby
restoring data entry functionality.

Of course this wouldn' t stop them resetting the computer clock before
the expiry date and maintaining data entry functionality, but if I
thought that they were going to be that dodgy I wouldn't deal with
them in the first place.

I'm interested in other people's thoughts on the subject.

[salad]

Wayne wrote:

I have just experienced my first late paying client. By "late" I mean
that the invoice is now almost 2 months overdue. I don't think that
the client is maliciously withholding payment - rather there has been
an unfortunate series of events which has delayed the payment. The
bottom line for a small time developer is still the same however. I am
confident that I will receive payment for the invoice eventually but
it is now a case of "once bitten twice shy".

Did you write this for a large or small company? If small, you should
be able to interact with the owner of the company or someone to expedite
the payment.

I am interested in what measures others employ to avoid or deal with
this situation, short of asking for payment up front which I don't
think would go over too well with most clients.

I doubt you'll find many companies that will pay prior to work being done.

One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

Putting "bombs" in code seems so uncool.

There is a reason for the delay in payment. You haven't given any
reasons beyond "there has been an unfortunate series of events which has
delayed the payment". But there is a reason. Perhaps the company is
strapped for cash and your bill is a bit larger than expected. Maybe
you could negotiate for payments in 2 chunks instead of one.

If you aren't dealing with the owner, you are dealing with a project
manager. You need to bump it up to the next level...his superior.

Not knowing your situation, I think you need to find someone in the
company that can act on your behalf to get things moving.

This could be achieved by hard coding a preset date after which a
critical data entry form would be deleted. If payment is received in
a timely manner, an updated file would be sent to the client before
any disruption to business occurred. Deleting this critical form would
stop the client resetting there computer clock after the fact, thereby
restoring data entry functionality.

Of course this wouldn' t stop them resetting the computer clock before
the expiry date and maintaining data entry functionality, but if I
thought that they were going to be that dodgy I wouldn't deal with
them in the first place.

I'm interested in other people's thoughts on the subject.

[Paul H]

<snip>

>One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

Putting "bombs" in code seems so uncool.

There is a reason for the delay in payment. You haven't given any reasons
beyond "there has been an unfortunate series of events which has delayed
the payment". But there is a reason. Perhaps the company is strapped for
cash and your bill is a bit larger than expected. Maybe you could
negotiate for payments in 2 chunks instead of one.

If you start giving concessions on payment terms you are going down a
slippery slope. Developers are not banks, we should not be expected to give
credit. If the customer is strapped for cash, that is his problem. They
shouldn't order stuff if they can't pay for it on time. They are probably
not buying the software to sell it on; the money they owe is not tied-in to
them getting a check from someone else. If they don't have the money to pay
you because of "bad luck", then as far as I am concerned they are screwing
you over, they have gambled with your livelihood. They are out of order.

Unless you like the client on a personal level and trust him or can be sure
that maintaining a good relationship will ensure future work I would start
pressing for payment.

I have been knocked before so now I always ask for a third up front, a third
on delivery of the first beta and only then do I give the client thirty days
"credit" to pay the final third after the system is in place. I also charge
a to put a proposal together. All of this is negotiable, but that is my
starting point.

Don't sell yourself short. I got out of the printing industry because every
printer tries to undercut their neighbour, thus encouraging the print buyers
to screw them down even further. I have seen so many print firms go bankrupt
because of this. Competitors should look out for one another but still
maintain a healthy competition. We shouldn't strive to be the cheapest or
the quickest; we should strive to be the best we can be. Ultimately the
market will benefit from that ethos over all others. You services are of
great value, don't allow them to be arbitrarily borrowed by unorganised or
unethical customers.

There should be law in place that states that you can not receive credit on
capital expenditure, that would stop all this nonsense.

No one would ask for credit when buying a car or a house; if you don't have
the cash you get a loan to buy these things...polite ly tell the customer to
take his problems to the bank, not you.
Rant over.

:O)

Paul

[Arno R]

"Wayne" <cq*******@volc anomail.comschr eef in bericht news:11******** *************@a 75g2000cwd.goog legroups.com...

>I have just experienced my first late paying client. By "late" I mean
that the invoice is now almost 2 months overdue. I don't think that
the client is maliciously withholding payment - rather there has been
an unfortunate series of events which has delayed the payment. The
bottom line for a small time developer is still the same however. I am
confident that I will receive payment for the invoice eventually but
it is now a case of "once bitten twice shy".

I am interested in what measures others employ to avoid or deal with
this situation, short of asking for payment up front which I don't
think would go over too well with most clients.

One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

This could be achieved by hard coding a preset date after which a
critical data entry form would be deleted. If payment is received in
a timely manner, an updated file would be sent to the client before
any disruption to business occurred. Deleting this critical form would
stop the client resetting there computer clock after the fact, thereby
restoring data entry functionality.

Of course this wouldn' t stop them resetting the computer clock before
the expiry date and maintaining data entry functionality, but if I
thought that they were going to be that dodgy I wouldn't deal with
them in the first place.

I'm interested in other people's thoughts on the subject.

I am doing work for relatively small companies.
I always know the person who has to approve the payment.
I know the person that receives my bill.
When payment is late (4 weeks late) I send the invoice again. (It could be lost or forgotten)
If I don't get payed within two weeks after that, I will call them and simply ask "what's the problem?"
This happened only once. Maybe I am lucky.

But: I would advise you to NEVER 'mess' with the databases functionality.
What if the client actually does pay the bill, and you get an accident a day before that...
Time bomb still explodes ??

Arno R

[Tom van Stiphout]

On 8 Feb 2007 23:03:32 -0800, "Wayne" <cq*******@volc anomail.com>
wrote:

Paul is right: you are not a bank, and client should not expect you
can give him credit. Politely ask for payment every week, if possible
in person. Your rates should include a buffer to be able to extend
some credit, and to occasionally get stiffed altogether. Such is life,
and we prepare to the extent possible.
In a slightly larger company like ours, we assess a client's credit
worthiness before signing the contract, and we will adjust payment
terms accordingly. Thus we have some clients that are pre-pay, and
others that get 90 day credit.
We don't give source code unless all bills are paid.
We won't start new work until all past-due invoices are paid.

-Tom.

>I have just experienced my first late paying client. By "late" I mean
that the invoice is now almost 2 months overdue. I don't think that
the client is maliciously withholding payment - rather there has been
an unfortunate series of events which has delayed the payment. The
bottom line for a small time developer is still the same however. I am
confident that I will receive payment for the invoice eventually but
it is now a case of "once bitten twice shy".

I am interested in what measures others employ to avoid or deal with
this situation, short of asking for payment up front which I don't
think would go over too well with most clients.

One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

This could be achieved by hard coding a preset date after which a
critical data entry form would be deleted. If payment is received in
a timely manner, an updated file would be sent to the client before
any disruption to business occurred. Deleting this critical form would
stop the client resetting there computer clock after the fact, thereby
restoring data entry functionality.

Of course this wouldn' t stop them resetting the computer clock before
the expiry date and maintaining data entry functionality, but if I
thought that they were going to be that dodgy I wouldn't deal with
them in the first place.

I'm interested in other people's thoughts on the subject.

[salad]

Paul H wrote:

<snip>

>>>One method that I have thought of would be to include a "late payment"
clause in the initial quote which spells out that if payment is more
than x weeks overdue, data entry functionality for the database would
no longer be available.

Putting "bombs" in code seems so uncool.

There is a reason for the delay in payment. You haven't given any reasons
beyond "there has been an unfortunate series of events which has delayed
the payment". But there is a reason. Perhaps the company is strapped for
cash and your bill is a bit larger than expected. Maybe you could
negotiate for payments in 2 chunks instead of one.

If you start giving concessions on payment terms you are going down a
slippery slope. Developers are not banks, we should not be expected to give
credit. If the customer is strapped for cash, that is his problem. They
shouldn't order stuff if they can't pay for it on time. They are probably
not buying the software to sell it on; the money they owe is not tied-in to
them getting a check from someone else. If they don't have the money to pay
you because of "bad luck", then as far as I am concerned they are screwing
you over, they have gambled with your livelihood. They are out of order.

See, I don't know who is not paying him. It could be a good
aquaintance, a large company, or medium. Going after payment with a
Ford or GM and getting them to move on something might be like moving a
snowball up the hill. If a small company, you should be able to talk
to someone in authority.

We don't know the reasons for non-payment. Was the invoice sent late?
Some companies have some rules that all invoices must be recieved by a
certain date. Were there disputes on the invoice? Did the person that
writes checks die? We only know "there has been an unfortunate series
of events which has delayed the payment". And there are two sides to a
story.

The person should be paid for his work. I disagree with putting in time
bombs. I would not compromise on the pay, but would on payment options,
if I weren't getting paid. I would never put a bomb in a program on the
off chance a person isn't going to pay up. Maybe you would, but I wouldn't.

If he isn't getting paid, he needs to work on getting paid. And, in my
opinion, that means changing the rules to get paid, then so be it. In
the post, the originator said he expects to be paid. So that's not the
problem, its the time in getting the check to him for work performed.

Unless you like the client on a personal level and trust him or can be sure
that maintaining a good relationship will ensure future work I would start
pressing for payment.

I have been knocked before so now I always ask for a third up front, a third
on delivery of the first beta and only then do I give the client thirty days
"credit" to pay the final third after the system is in place. I also charge
a to put a proposal together. All of this is negotiable, but that is my
starting point.

Don't sell yourself short. I got out of the printing industry because every
printer tries to undercut their neighbour, thus encouraging the print buyers
to screw them down even further. I have seen so many print firms go bankrupt
because of this. Competitors should look out for one another but still
maintain a healthy competition. We shouldn't strive to be the cheapest or
the quickest; we should strive to be the best we can be. Ultimately the
market will benefit from that ethos over all others. You services are of
great value, don't allow them to be arbitrarily borrowed by unorganised or
unethical customers.

There should be law in place that states that you can not receive credit on
capital expenditure, that would stop all this nonsense.

No one would ask for credit when buying a car or a house; if you don't have
the cash you get a loan to buy these things...polite ly tell the customer to
take his problems to the bank, not you.
Rant over.

:O)

Paul

[Paul H]

<snip>

The person should be paid for his work. I disagree with putting in time
bombs. I would not compromise on the pay, but would on payment options,
if I weren't getting paid. I would never put a bomb in a program on the
off chance a person isn't going to pay up. Maybe you would, but I
wouldn't.

Bombs are fine as long as they are clearly explained well in advance to the
client. I put a bomb in a db recently and explained why to the client (they
were a new start up company), they where perfectly amicable about it.

I agree that a "secret" bomb is not good business, neither is late payment.

Paul

[Tim Marshall]

salad wrote:

The person should be paid for his work. I disagree with putting in time
bombs. I would not compromise on the pay, but would on payment options,
if I weren't getting paid. I would never put a bomb in a program on the
off chance a person isn't going to pay up. Maybe you would, but I
wouldn't.

I agree, that's gross.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

[Wayne]

Thanks for all the feedback. The "unfortunat e series of events" goes
something like this: the safety manager that I did the work for who
needed to sign off on the invoice went on leave and apparently no-one
else could sign it. When he eventually signed it, the invoice then
got bogged down in the accounts department waiting for the cheque to
be raised. After the cheque was raised, the general manager needed to
sign it and he was unavailable for a period of time.

The company is a medium sized mining company that I have dealt with
before. The last time I did work for them, payment was a few weeks
late, but nowhere near as late as this time. Their system for paying
suppliers like myself that aren't regular suppliers seems to be very
slow and convuluted. I have a good relationship with the safety
manager over the telephone and he seems to be as unhappy as I am that
I have not been paid yet and seems to be embarrassed by the fact.

The main thrust of my original post was not to get advice on how to
secure payment because I am confident that payment will be forthcoming
in the next couple of weeks. This isn't a fly by night company and
they aren't about to go bust in the next couple of weeks. This
situation has been unexpected and my main question was how to avoid a
similar situation in the future with other clients.

I know that time bombing an application is uncool, but having an
invoice that is almost 2 months overdue is also uncool and
unacceptable as well. My original suggestion was not to secretly time
bomb an application but to spell it out in black and white in the
original quote that if payment is more than so many weeks late
critical database functionality will cease. Paul H seems to have done
this successfully, and if the client has a problem with it, then it
can be negotiated before the quote is accepted.

I am sure that I have read on this forum before (but can't find the
posts now) about how other developers have similar procedures in place
to ensure that payment is forthcoming before a fully functional
application is handed over to the client. It may not have involved a
time bomb, but from memory, the outcome was the same.

[Larry Linson]

I have not generally had to do this, but a few times have "encouraged prompt
payment" by setting a higher rate, and giving a significant discount for
very prompt payment, a lesser discount for normally prompt payment, no
discount for slightly late payment, and an X% per month penalty for any
later payment.

On the other hand, I recently had a client that prided themselves on prompt
payment. If the invoice was submitted by Thursday, the check would be mailed
on Monday (barring holidays or catastrophe). Needless to say, they didn't
have any trouble finding contractors to work for them.

Larry Linson
Microsoft Access MVP

"Wayne" <cq*******@volc anomail.comwrot e in message
news:11******** **************@ s48g2000cws.goo glegroups.com.. .

Thanks for all the feedback. The "unfortunat e series of events" goes
something like this: the safety manager that I did the work for who
needed to sign off on the invoice went on leave and apparently no-one
else could sign it. When he eventually signed it, the invoice then
got bogged down in the accounts department waiting for the cheque to
be raised. After the cheque was raised, the general manager needed to
sign it and he was unavailable for a period of time.

The company is a medium sized mining company that I have dealt with
before. The last time I did work for them, payment was a few weeks
late, but nowhere near as late as this time. Their system for paying
suppliers like myself that aren't regular suppliers seems to be very
slow and convuluted. I have a good relationship with the safety
manager over the telephone and he seems to be as unhappy as I am that
I have not been paid yet and seems to be embarrassed by the fact.

The main thrust of my original post was not to get advice on how to
secure payment because I am confident that payment will be forthcoming
in the next couple of weeks. This isn't a fly by night company and
they aren't about to go bust in the next couple of weeks. This
situation has been unexpected and my main question was how to avoid a
similar situation in the future with other clients.

I know that time bombing an application is uncool, but having an
invoice that is almost 2 months overdue is also uncool and
unacceptable as well. My original suggestion was not to secretly time
bomb an application but to spell it out in black and white in the
original quote that if payment is more than so many weeks late
critical database functionality will cease. Paul H seems to have done
this successfully, and if the client has a problem with it, then it
can be negotiated before the quote is accepted.

I am sure that I have read on this forum before (but can't find the
posts now) about how other developers have similar procedures in place
to ensure that payment is forthcoming before a fully functional
application is handed over to the client. It may not have involved a
time bomb, but from memory, the outcome was the same.