When Clients Disappear Without Paying

When starting a business, there’s a lot of things to think about. For example:

  • The idea of working for yourself is exciting
  • The challenges of managing your own retirement can be tough
  • Navigating the tax code can be tougher (get a CPA!)
  • Keeping your own books can be tedious
  • Working with clients can be a lot of fun, but also tough
  • …and so on.

A lot of it is exciting, some of it is scary, and some of the it you might expect but don’t really know how to handle until it actually happens.

Case in point:

When working with a client, what do you do when you’ve completed a project, they disappear, and they don’t pay the final invoice?

This is when self-employment gets a little tougher.

When Clients Disappear

Despite my pessimistic (and sometimes cynical) personality, I try to believe the best rather than assume the worst.

When Clients Disappear

That is, if I’ve yet to hear from a client for days or weeks-on-end, then I try to believe something personal has come up and it’s a matter of time before I hear from them.

Sometimes I’m right, sometimes not. And when it’s the latter. It sucks because I’ve essentially wasted my time. The longer I work for myself and the more I try to establish Pressware, the more I’m trying to prevent that from happening.

I’d like to think this is a phase all businesses go through.

Not Getting Paid

This is one of the worst feelings. It’s frustrating. It can incite anger. It means you’ve wasted your time. It means someone got something for nothing.

Easier said than done, but try to keep your emotions in check. It doesn’t do a lot of good to sulk in it. Instead, there are things we can do to protect ourselves.

First, I’ll admit in the few years or so I’ve been working for myself, this has only happened twice. Some may consider that a good record, some may consider that a bad record. I opt to go with the former.

Anyway, in those situations there are a few things that we often think we may do to prevent this from happening:

  1. In your contract, have the client sign to receive the final work upon final payment.
  2. In your contract, note failure to receive final payment may result in taking down the site.
  3. Break payments up into installments.
  4. Considering charging by the hour or charging by the week.

Here’s the thing: In situations like this, seek advice from wiser, more experienced types. It’s what I’ve done and it’s what I continue to do.

For example, one of the things you may feel like doing is throwing up a landing page that reads something like:

When the client has resumed payment for their services, the site will launch.

But every successful business person in this industry says that’s a no go. If nothing else, that can result in a law suit even if you’re in the right. Do you want to spend your time and money fighting that?

Instead, other advice I received:

  • Ask a lawyer to send a letter demanding payment and threaten to take the client to small claims court. This works well if they have assets in the same state as you.
  • Move 100% of your payment up front with the promise of a refund. I know two friends who have done this and it has worked out well.
  • Determine if you need the money. Is the time you’d spend going after this money worth the amount of time you could spend on another project?

And I’m sure there’s more and I’d love to read your take in the comments, as well.

Avoid Rush Jobs

The biggest advice I can give to you is to watch out for jobs that need to be done quickly. You’ll likely see this manifest itself in emails or phone calls in which people say they need something done as fast as possible because they are short on time.

Usually, this plays out in you – or us – seeing a paycheck on something that’s expected to be done quickly.

I’ve yet to see it play out like this.

Instead, we end up doing the work quickly – possibly forgoing time we could be spending with family or other hobbies – and they end up getting the result and never pay.

It’s as simple as avoiding these types of projects. Unfortunately, it’s easier said than done and it’s something that many of us end up having to learn the hard way.

What Do You Do?

I hope the information above helps in your freelancing or self-employment endeavors. As I mentioned, much of what you’ve read above has come from my own experience as well as working with others.

And I’m sure I’m going to have more to learn in the future.

In the meantime, if you have your own questions and or comments on things to improve about this process, don’t hesitate to add them to the comments.

38 Replies to “When Clients Disappear Without Paying”

  1. Thanks for sharing Tom.

    I always break payments into installments. 1/3rd right at the start (the “are you really serious about this” payment), 1/3 in the middle (the “we’ve done this much work – are you still committed?” payment), and the final 1/3 at the end. This approach has generally worked well for me, particularly on short-term projects, and helps make sure time and effort is actually paid for. Even if the client decides to end it part way through, I’ve at least got some payment for my work.

    For longer-term projects, I still suggest an up-front payment of some sort – it shouldn’t be more than a 1/3rd of the estimated cost, but it should be big enough cost to show true commitment to the project. Nothing in business clarifies commitment more than a down payment. As for billing the rest, breaking the last 2/3rds of the payment into “billed weekly or biweekly” would probably be a good solution.

    Proven clients get a bit more leeway in when they pay just as they provide me with a bit more leeway on deadlines. That’s because we’ve built up a relationship of trust with one another and we have clear and open communications that allow for this flexibility and trust.

    1. The way you’ve laid this out is really close to how I’ve done it, too. Even down to this:

      Proven clients get a bit more leeway in when they pay just as they provide me with a bit more leeway on deadlines. That’s because we’ve built up a relationship of trust with one another and we have clear and open communications that allow for this flexibility and trust.

      Once that’s been established, you can afford to be more flexible because you’ve got that relationship established, as you said.

  2. For smaller projects, I collect 100% up front.

    For larger projects, I break it up, usually 50% up front, 50% before launch.

    For long-term or ongoing work, I break it into phases.

    If I get a funny feeling about a potential client, I try to pass on the work, or if I do ignore my instinct and take them on, I break everything into individual project phases, so I minimize risk to myself.

    1. If I get a funny feeling about a potential client, I try to pass on the work, or if I do ignore my instinct and take them on, I break everything into individual project phases, so I minimize risk to myself.

      This is smart.

      It’s funny how you can begin to develop a bit of intuition about projects the longer you end up working in a field. At this point, nearly every time I get a weird feeling about taking on a project, it’s normally been supported by something that happens during (or after) the course of the project.

  3. Installments are surely the safest strategy. At least you get some payment, perhaps most of it. It also fits in with quality control steps where the job doesn’t proceed unless the client signs off at agreed points. Then if they come back at you much later for retrospective changes you can cite their earlier approval and charge additional fees.

    Several termination-of-service type clauses also help if your back is to the wall and you decide to take the site down.

    Another option is to deploy the fully constructed site on your own server and require final payment before transferring to production. Not releasing superuser logins to the client does the same thing.

    Taking full payment up front is a nice thought but usually unrealistic: you’re asking the client to trust you when you are essentially saying you don’t trust them. That’s why step payments are so good as they’re an exercise in mutual respect. Perhaps for quite small projects it works. I’ve taken 100% for plugins that required just a few hours work. Although that’s kind of counter-intuitive as it’s the big money jobs that require the most payment protection.

    [Tom, a reply edit button would be a good addition: no matter how much we check for errors, they still happen]

    1. Everything you’ve said is spot on and are things that I’ve slowly begun to add to contracts and agreements over the years. It’s one of those things that I wish I had not learned the hard way (or maybe I was bull headed and just ignored it?), but it’s taken care of now.

      Taking full payment up front is a nice thought but usually unrealistic: you’re asking the client to trust you when you are essentially saying you don’t trust them. That’s why step payments are so good as they’re an exercise in mutual respect.

      +1 to this.

      That’s why step payments are so good as they’re an exercise in mutual respect. Perhaps for quite small projects it works. I’ve taken 100% for plugins that required just a few hours work

      I’ve rarely taken 100% upfront. For smaller projects, I still try to split 50/50 with the final 50% being paid just before delivery (when it’s on my staging server).

      [Tom, a reply edit button would be a good addition: no matter how much we check for errors, they still happen]

      You’re not the first to ask — I’ll see about taking care of this when I get some time to focus on the administrative stuff for the blog :).

  4. Well, it’s really funny how often I see and read about freelance developers (especially open source stuff like WordPress, php, etc.) and money. People are giving away work and expertise for free, as if software development is some kind of charity free-for-all. Or they’re giving away work too cheaply: $20 per hour? $40 per hour? Absurd. No wonder clients bail without paying. Charging too little says “I don’t value myself” and the unscrupulous sharks can smell that blood in the water for miles.

    Allowing clients to not pay for weeks and “assuming it must be a personal problem” is absurd. Worst of all, developers are “letting go” of the time and effort instead of going after the client to be paid – or better yet – creating a system that prevents it from happening in the first place. If a client doesn’t pay me, I call a collection agency and give them half the money they recoup. At least I get half. 50% is way better than 0%.

    Here’s how I manage my receivables and billable hours:

    Contract language that is rock solid. Period.

    Fixed Price Small projects are 50% up front and 50% prior to deployment, with the following rules spelled out so a five year old can understand them:

    Your site won’t be on your URL until you pay.
    You don’t get access to the backend until you pay.
    You don’t get username, passwords, URLs, or anything else for any services I set up or created to compliment your site (JetPack, Akismet, WordPress.com login, etc.) until you pay.
    I will promise in writing to complete the work of deploying the staging site to production and releasing URLs and Credentials to all associated sites and services AFTER the project is paid.
    I don’t use their email address when setting up the accounts: I create a forwarding email address in my own email system that forwards to ME ONLY until they pay and then I add them to the forward and instruct them on which services they need to change their email address on once they have the credentials to log in.
    If I set up hosting for them, I don’t even give them their login credentials for that account either until after the agreed fixed price is paid.
    I don’t guarantee anything. I can’t guarantee they’ll love my work any more than an Attorney can guarantee you’ll win a case or a Surgeon can guarantee you’ll live through the operation. I expect them to make an informed decision after reviewing other work and talking to other clients.

    Large projects are usually trickier to estimate so I create milestones and budgetary estimates with clear language that the estimate is only that: an estimate. Each stage of the development comes with due-on-receipt billing and the next stage doesn’t happen until it’s paid.

    I offer financing to my clients for website and web app projects and if they take advantage of it, 100% of the price tag gets paid up front and they get 6 months interest free financing. I get paid and the relationship is very harmonious when money isn’t involved anymore.

    For fixed price projects everything that will be done is listed in writing. Anything the client asks for that isn’t listed will NOT be done as part of the project budget. This controls scope creep very effectively. The contract states this in plain english and states that anything they ask for that isn’t expressly listed will be billed at my normal hourly rates and invoiced weekly with Net-10 Terms. I do not tell them that what they are asking for will incur additional billing. It’s in the contract and it’s their responsibility to understand what they signed. We’re all adults here. “I forgot” is something I haven’t used since 5th grade, and I don’t expect my clients to use it either. And if they do, I just refer them to the contract.

    Hourly work is tracked very carefully, reported to the client alongside an invoice for the hours worked the previous week, every Monday morning. I bill my clients even if I worked for 30 minutes that week. I never give away time, but occasionally I will take something upon myself to do for them and I don’t charge them, but that time is still tracked and invoiced, only at a rate of $0 (this way they can see that I am actually giving them something other than a big bill).

    All clients get a very tight Net-10 terms to start out with, and contractually I give them 3 late payments in a 12 month rolling period. If they are abusively late, they are reduced to Due on Receipt. I don’t warn, cajole, plead, bargain, or anything. I simply send the next invoice “Due on Receipt” with a note in the email that they’ve exceeded the 3 strike rule. “Due on Receipt” is defined contractually as “I don’t work, answer emails, phone calls, emergencies, etc.” until all open invoices are paid. And I expect Due On Receipt invoices to be paid on the same day they are received or I consider them late and holding up the project and my ability to maximize my potential billable hours. So if the client doesn’t pay on the same day they get the invoice, another 3 strike rule exists. After 3 times they get converted to Retainer Only. They must purchase hours in advance.

    I invoice my clients with an online invoicing system that allows them to pay with a bank card or credit card. I consider electronic payments paid on the date of the transaction. But with checks, I clearly state in the contract that the check must be deposited and cleared by the due date. Post dated checks aren’t accepted. The date on the envelope isn’t considered. It’s only paid on time when the funds are cleared in my bank account prior to or on the due date.

    And finally, if I have to have a confrontation with a client that feels they should somehow be exempt from the rules, I simply tell them very assertively that we have a contract, I expect it to be honored, it’s just business – not personal. I ask them if they aren’t paying on time because they don’t value my work or if they don’t trust me, because if either is the case I can no longer work for them. And if it continues, I fire them.

    I’ve been in business for nearly 14 years and worked for a Microsoft Certified Partner consulting firm before that. The majority of how my contracts are written hasn’t changed since I started my business in 2002, but I’ve added a lot of language over the years to deal with circumventing these types of issues for future clients. In all, I’ve only actually fired one client that was habitually and ridiculously late all the time, which prompted me to institute all of the above mentioned “short leash” measures.

    And I’ve only had one client disappear on me without paying. It was a prior client that had to pull the plug on a huge ASP.NET project because he ran out of money before we reached 40% of his original budget. He told me he found someone way cheaper. What could I do? I told him good luck. A year later, he called me freaking out because his “cheap” developer had totally trashed the software because he didn’t have a clue what he was doing and asked me to look at the codebase and see if I could fix a few problems. I spent a few hours, found and fixed it, and sent him an invoice for about $600 which he never paid. From that experience, I no longer do that type of ad-hoc work without getting a credit card #, expiration date, CCV, and an email confirmation that I will be charging that card at the end of the session.

    This is a business. Not a hobby. Too many hobbyist programmers decide they can become consultants or freelancers with no idea how to actually manage the most important part of the business: Accounts Receivable.

    Be Awesome!

    Jerry Boutot, CEO

    AppDataWorks, LLC

    1. Wow, Jerry! Thank you for sharing in detail your process and experience with managing clients and contracts. This should be required reading for all aspiring freelance web developers. I include myself in that group.

  5. This comment surprised me: ” When the client has resumed payment for their services, the site will launch.

    But every successful business person in this industry says that’s a no go. If nothing else, that can result in a law suit even if you’re in the right. Do you want to spend your time and money fighting that?”

    What if a client hasn’t paid the last 25% of the cost of the project. Could you hand over 75% of the finished project (what he has paid for) and withhold the last 25% until you get your payment. This will probably result in a non-functionning application or sub-par application and hence provide incentive for the client to make that last 25% payment.

    That way, the client has received what he has paid for, and can’t really sue I think.

    1. Ok, so I missed the paragraph before that suggested a landing page with that notice. And that is probably the part the will result in a law suit. I would never publicly shame a client. You may be closing doors that way.

      1. Exactly! It’s not that the urge doesn’t exist or that the desire to do so isn’t justified.

        It’s about the future implications of what could come from that, you know? It’s gotta be handled with care in order to make sure it’s handled correctly :).

  6. I like payment by project or task, or based on short sprints to accomplish a particular end result within a set chunk of time.

    This has worked well for me for clients I’ve used it with, and it works well for me when I’m a client, too – because it removes risk by establishing a set deliverable for a set price.

    It helps cut down on scope creep and justification time spent vs. hourly billing.

    Hourly billing does not take into account that you know how to do something in 5 minutes because of your experience, but instead rewards those who are inexperienced and take longer to accomplish the same task.

    To prevent nonpayment, I’ve found this effective:

    “Company reserves the right to suspend website from public view until all outstanding project fees and assessed penalties are paid in full.”

    1. Hourly billing does not take into account that you know how to do something in 5 minutes because of your experience, but instead rewards those who are inexperienced and take longer to accomplish the same task.

      Hmm, that’s the “charge by value not by time” method. I suppose it can work if you’re in high demand, but could backfire due to the subjective evaluation you need to make as to the level of your experience.

      I’m partial to the idea that if your hours can’t meet your demand, put your rate up. If the demand is still there, say, six months later, put it up again. Rinse and repeat until demand for your services is balanced against your rate.

      But that’s getting off topic.

    2. I like payment by project or task, or based on short sprints to accomplish a particular end result within a set chunk of time.

      This is my preferred method for doing work as well. It breaks the work into manageable pieces that allows both parties to know what’s going on and allows for budgeting of both time and money.

      And, as you said, it absolves risk on all involved, too, which is a nice feeling.

      Hourly billing does not take into account that you know how to do something in 5 minutes because of your experience, but instead rewards those who are inexperienced and take longer to accomplish the same task.

      This is one of those things that’s especially true in programming (I’m not putting programming on a pedestal, I’m just speaking against what I know :). Sometimes you know how long something is going to last, sometimes you don’t.

      For this:

      “Company reserves the right to suspend website from public view until all outstanding project fees and assessed penalties are paid in full.”

      I think it’s something that is, unfortunately, necessary – and probably has been for a long time – but it’s only going to become more so as more people enter the field.

  7. When my wife took over billing/invoicing, we made more money without doing more client work than normal. As a developer that likes to sit in a dark room and not talk to people and who is constantly saying “I will just take care of that, it’s not a problem” to clients, tons of work wasn’t being billed in the first place and not much follow up on uncollected bills was happening. When my wife took over, she moved things to Freshbooks so things like late payments were automatically being added, hosting was setup on automatic recurring billing cycles, easier time tracking system for myself meant more things got recorded (but she often still has to remind me “Hey, you I heard you talk to John the other day – did you record your 30 min call as billable consult time?”).

    Basically, having someone who doesn’t feel uncomfortable doing billing is important. I think most designers/developers don’t have the right personality to do the money stuff.

    1. Basically, having someone who doesn’t feel uncomfortable doing billing is important. I think most designers/developers don’t have the right personality to do the money stuff.

      Some don’t, some do. Regardless, though — you’re right. If your personality doesn’t fit it, then you absolutely need to have someone step in and help manage all of that so you aren’t basically working for free.

      Otherwise, the hard truth, is that you (or we or others) are being taken advantage of and that’s no good.

  8. Oh, and our agreement says 50/25/25. In reality we invoice 50% up front and 50% upon completion because 3 invoices in a 4-5 week span is a bit excessive. We use the 3 invoices when a client starts to become unresponsive and feels like they are disappearing a bit. Having to make another payment refocuses them back onto the project because then in their head they are thinking “Hey, I just sent another $XXXX – I should do my part to get this website done”

    1. This is a smart strategy.

      I’ve not had to employ things like this yet as I normally have check points setup that will allow clients to know what will be done and what will be due and when.

      Most of the time, this has been perfectly fine.

      There are, of course, one-off exceptions, but it’s not been anything detrimental.

  9. I had to repossess a theme and plugins yesterday. That’s the first time I’ve done that but all the niceties and understandings and exceptions in the toolbox have been expended.

    The client has a talent agent whom I informed of the situation so maybe they will have some influence.

  10. Usually, I develop local and show the results on my server before I hand them over to the client. I hand them over after payment. This strict handling I do usually with new clients. As soon as I know a client and he knows me, they don’t tend to disappear.

    The other thing: When a client comes, whom I dont know and wants a big project, I tend to milestones. After I finish milestone 1 I get the first payment, after milestone 2 and so on. By this, I can figure out quite quickly, if the client pays and the amount of wasted times shrinks.

    But, although this method’s worked out quite good, I experience disappearing clients too from time to time. So, I had a very small plugin, I’ve finished. The guy said he will check it out (on my server) and I’ve never heard of him again. Although I am able to keep the amounts/hours low, its quite a pain in the ass. Not so much because of the money but because of being treated like shit.

    1. Usually, I develop local and show the results on my server before I hand them over to the client.

      Yeah, this is a good strategy and it’s something I think most experienced people do. Unfortunately, there’s always that deadlock that can come:

      • “I’ll pay you when I get the deliverable.”
      • “I’ll give you the deliverable when you pay.”

      Trust is so important, but hard to develop early on.

      The other thing: When a client comes, whom I dont know and wants a big project, I tend to milestones. After I finish milestone 1 I get the first payment, after milestone 2 and so on. By this, I can figure out quite quickly, if the client pays and the amount of wasted times shrinks.

      Wisdom.

      Although I am able to keep the amounts/hours low, its quite a pain in the ass. Not so much because of the money but because of being treated like shit.

      Agreed. It’s such a bad feeling that ends up creeping up in your mind from time-to-time if you don’t let stuff go and move forward.

  11. Hi Tom

    This is indeed a great Alert!

    Good tips to overcome such nasty situations.

    I am sure this will be a good guide to many of the newbies in this field.

    Of course good tips and suggestions.

    Keep sharing.

    And ha, beware “Don’t Rush” LOL

    Have a blessed weekend

    Best Regards

    ~ Philip

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.