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.

[Chuck]

On Fri, 09 Feb 2007 13:43:03 -0330, Tim Marshall
<TI****@PurpleP andaChasers.Moe rtheriumwrote:

>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.

A little off topic. I had a Canon 6000 printer. I came with some graphics
editing software. The 6000 got old and died. Bought a Canon 850. It came
with software. Wife liked old software better. Install old software. Virus
warning. Don't believe. Install anyway. When Installation was finished hard
drive was wiped out. Partitioned drive. 3 primary each with a different OS. 3
extended for data. ALL gone. Had to do a low level format before could do a
normal format then repartition then use backups to get all OSs and Data back.
Use XXcopy to clone OS. But it still lot of work. Unplug C850. Plug in old
C600. Old software installed without a glitch. That was over kill on Canon's
part. Could simply refuse to install without any explanation why. OK.
Getting tired with Canon products anyhow.

Chuck
--

[Bill]

On Fri, 9 Feb 2007 11:39:09 +0100, "Arno R" <ar***********@ tiscali.nl>
wrote:

>
"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

This is an excellent point.

Bombs are bad business and are really an accident waiting to happen.
If it goes off for one customer when it shouldn't have, it will cost
you way more than it ever saved you.

Bill

[Bill]

On 9 Feb 2007 12:54:44 -0800, "Wayne" <cq*******@volc anomail.com>
wrote:

>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.

Sometimes, stuff happens. Sometimes it doesn't and people say it
does.

I'm all in favor of progress payments if you can establish reasonable
metrics that you can both agree on. That way, the entire sum is not
at risk and you have some money as you go along.

In general, the telephone is your friend. There is nothing wrong,
once a bill is overdue, with calling every step of the way.

It's also good to have a mix of customers, but when it's just a single
programmer, that can be hard to do.

[Paul H]

<snip>

....and don't forget, if diplomacy, discounts and time-bombs don't work,
there's always one more tool in the box; the threat of extreme merciless
violence.

"OK Bob, so accounts have said they can't raise a cheque until the MD gets
back from Prague?....I know where you live." CLICK!

;o)

Paul