How to bill for contract software development

Question

I have been contracting with a company for about a year and a half and am pretty unhappy how the billing/payment cycle works. The system was already in place when I started, but now that I am the sole developer I would like to rethink it, so I wanted to get some feedback how you guys would approach it.

Here is the current system:

• They contact me with vague, general ideas about a new software project

• I spend a few days researching technology, creating a rough estimate of the time required

• They say okay to my estimate

• I begin work

• Every month I send them an invoice of the time I've spent working

• After two or three reminders by me
  (over the course of about a month)
  they finally send me a check

• The standard requirement changes
  apply of course

Everything is very unofficial and undocumented, sort of like handshake agreements. I don't necessarily have a problem with that, but they almost never pay on time, and yet expect me to continue to work. With this system months go by without me being paid. I don't like it.

What I had thought to do was to create a new system where I would come up with a good rough estimate of the time required for the project. If they approve this estimate they pay me half of the estimated time upfront so I can get started, then I would only receive the other half upon completion. I like this idea, and it seems fair, but the fact that estimates are rarely correct sort of messes it up, because if I underestimate by half the time it will actually takes, then what do I do?

So what do you guys recommend? Do you think the system in place now is okay? Do you have any better ideas? I enjoy the work that I do - I just wish things were a bit more structured when it comes to the billing/payment.

Thanks, Daniel

EDIT: After seeing some answers it seems clear I need a real contract for my work. Who can help me write a good contract? I don't have much experience in this arena. Would any lawyer do? I don't really care to do it myself.

Answer 1

Hi Daniel.

I think that what you are doing at the moment is totally wrong.

I read an interesting article on SitePoint the other day about subcontracting and I think it applies the same to what you are doing.

You should let your client know that late payment = no work and deadlines will be pushed back. It is unfair that you work, carrying on with what you do, when you still don't have any security over your work.

Of course, it seems like you have some kind of convention in place with this client, which is why you are not so concerned, but you can't continue this way.

Have a look at the site point article.

http://www.sitepoint.com/blogs/2010/02/13/the-first-rule-of-outsourcing-to-contractors/

I think asking for half up front is natural, maybe you should not phrase it like 'half' though. Just say that you need $XXX to reserve your services. The final payment will then be due on date X. Or in installments. If you have a late payment then you will need to work on another job. If they are reasonable they understand that programmers need money for food too!

Goodluck.

Answer 2

Actually, what are you listing as your terms on the invoice? You should put down NET 30 Days.

http://en.wikipedia.org/wiki/Net_30

In addition, you should inform them that beyond 30 days you will charge a late fee. 5% is a good penalty, but sometimes it's better to just inform them of a penalty on the invoice and only use it if necessary. It is a good way to get them to pay sooner.

Answer 3

I like to start with a payment up front, which gets me started - typically with requirements gathering.

Requirements gathering gives me a much better idea of what's involved what are the deliverables etc., which I can turn into a better estimate for review. Then I break it out into deliverables with portions of payment due after each piece (based on % of project completion) or regular intervals if breaking it out into deliverables doesn't make sense. It's important to get documented sign off on the development plan and estimates laid out.

The contract should specify when payments are due, what to do in the case of cost overruns, and you pause work when you haven't been paid on time.

Answer 4

I agree with Laykes.

When I started doing contract work I got burned with a deal where I got paid based upon the code passing a test. Once the code was complete and tested by myself to pass the test - verification of the test by the company took weeks and included the free addition of new features. The only way I was to get paid was to do as told sense the contract was very one-sided.

Now I write my own contracts. It is important to have everything in writing - the development and ongoing support of the solution with an hourly rate for each task and a billing cycle (net 15, net 30, etc...) with late fees if the bill has not been paid by the due date.

Answer 5

It is common practice that companies do NOT pay invoices when they receive them, but wait until the invoice is due according to the terms... it means they get to leave the $$$'s in the bank and earn that much more interest on their own money before they pay it out to vendors. You need to make sure your terms are clear on both any agreements you have in place and your invoices.

Answer 6

Either stop work after a payment is two weeks late, or build in an incentive system; the payment is 10% more for every month it's late. Make sure this is well discussed beforehand.

Changes in requirements always happen; that's the way the world works. Either budget for it when you make the bid, or move to an hourly payment model, and bill them for the actual hours worked.

Answer 7

I have been doing contract work for a medium sized company for a couple of years (working on multiple projects at a time). Because of this close relationship I bill every week. This helps to flatten out the payments and helps everyone with budgeting and seeing how projects are progressing.

But yeah .. slow payments suck.

Edit

After seeing your edit about where to get advice on contracts, check out NoLo They have a bunch of services and books that are designed to help small businesses

Edit #2

Specifically check out this link at NoLo: Self employed Consultants/Contractors

Answer 8

I worked at an engineering consulting company for the last 2.5 years. I'd recommend doing the following:

• Establish a proposal for the work, and identify if they are looking for a fixed bid contract or a hourly rate contract. Be careful with fixed bid contracts, requirements have to be much more concrete for these to work out well.
• Establish payment terms (e.g. Net 30 as described above) in this contract
• If its deemed to be a large contract, establish milestones for the project where work can be measured and determined if it makes sense to move forward, e.g. if you're developing an app that deals with product selection, product checkout and confirmation e-mails, the first milestone might be after the product selection area is finished, or all 3 areas are mocked up in a UI.
• Identify what you can/will do if payments are late. For example, you could write code that locks the user out of the app after X days if you're truly concerned about payment. Its more overhead, but sometimes its necessary. You have to decide the cost/benefit of this situation - e.g. if you're single-sourced for work and are only working for a couple of people, you have very little bargaining power.
• As for writing the contract, you could possibly contact a labor and employment lawyer.

Good luck.

Answer 9

I used to bill monthly, but you can really get yourself in the hole this way. If you work 30 days, send an invoice in that is due in 30 more days, and then give them an extra 2 weeks before you get mad, you may have already put in 10-11 weeks of work before you find out they might stiff you - so I gave up monthly billing and went to weekly instead; I bill each week, and expect to get paid by the end of the next week and that helps a lot.

In the past for some clients I asked for money upfront (which nobody likes to do), but since I have went to weekly billing it is not as important.

I have dropped several clients that habitually paid late; I don't make my clients chase me down to do work or support them, and I expect that I won't have to chase them down to get paid.

Answer 10

I second Michael Bray's answer and add:

Many accounting / finance departments feel that it is part of their "value add" to the company to delay payments (accounts payable) until there is no further choice but to pay the bill.

Don't plan on charging a penalty after 30 days either, the account departments will simply refuse to pay. And it doesn't matter what the contract says--just because you might prevail in court doesn't mean that you will bring it to court--way too expensive, time consuming and bridge-burning to do so for a single contractor.

(Or for most such disputes. If the penalty amount was over $100K, then you could bring it to court but you'd still be saying goodbye to any future business.)

I'd be very careful about paying a lawyer to draft a contract--not because the lawyer won't do a good job, but because you'll be flushing good money in the lawyer's direction for not much to show for it. --paying money (to the lawyer) that doesn't cause anything to change is a waste of money, by definition.

Instead, here are some ideas:

Make sure that you know who the real culprit is. Often accounting departments are blamed when the reality is that the business unit manager (your hiring manager or a colleague) has not authorized the accounting dept to pay the bill.

To check this, call the accounts payable clerk and ask him if he/she has all the paper work they need to pay you. Even better, if you have office access, go visit him or her. Be friendly, bring a box of cookies for the accounting staff. I kid you not. Be on his/her side.

Discuss with your hiring manager. Is he/she on your side? If so then it's you and the manager against the accounting department. In that case, with the manager's help, figure out how you can game the company's accounting system. Eg, charge deposits, create a retainer account that you maintain, charge via a service that includes escrow service, etc.

Or it could be that your hiring manager is slow to approve payments because they want to be sure that th ejob is 110% finished before payment. In that case, go back to fundamentals with him/her. -- You are trustworthy, you deliver, you need to be paid during the course of the job as you reach various milestones, etc.

And of course, you should have a clear project plan before you start that shows what the various milestones are, the tests that confirm they've been reached, documentation, etc.

You should always structure your work so you can reach testable, definable milestones at least once per month and get paid accordingly.

Last piece of advice: build on your relationship, don't tear it down. You are a valuable partner to them and they to you. This is a bump in the relationship that can and should be repaired.

Answer 11

Hi Daniel, we had a very similar system to you, and successfully converted to a better system.

I think that you have two problems rolled into one question : the pay for your contact work, and the contracts for your contract work. I can't help you much on the first, but for the second, it sounds like de-ja-vou! We instated two documents, from business management concepts, that dramatically made our lives easier in regards to never-ending-projects and clients expecting the whole world.

• Specifications Document

  This is a doc that you type up for a new project, or a new phase/whatever. It specifies in detail what you understand the requirements to be and what you will deliver. Coding doesn't start until this doc has been read and signed by the client and yourself. What is on the document is what the client gets, no exceptions - unless they do a change request form. It includes your initial hourly estimate and pay rates.

• Change Request Form

  Changes do happen, but this ensures that everyone is on the same page. Whenever the client wants a change, you type this up, exactly specifying what changes and how, and then they read and sign, in person. It includes whatever necessary price negotiations for the changes.

Behind the scenes, these documents do two good things: slay scope-creep, and cut unrealistic expectations. Because clients have to read and physically sign and return these documents, which is less convenient than barking out half-baked ideas as orders, their changes are usually fewer, but definitely more well-thought out, and clients understand exactly what they are getting.

We keep to a more higher-level view in these docs so clients don't have to read gorey details about TextBox_A and TextBox_B, etc. Just these two docs have made our lives so much easier.

Answer 12

Word to the wise - if you choose to use a contract, you must stick to exactly what the contract says, including the Specification and Change Request provisions. Often the client is 'loose' on the contract details during the work phase, suggesting we can ignore the Change Request and have an informal agreement, and casually add and subtract items from the original specification.

But then, when you are just about to 'go live', after spending many hours working on items that were never in the original contract, they will pull out that contract and the Specification and hold you to all the details you 'agreed to' when you signed the contract. And, since you ignored the Change Request process, anything you did in addition to what was on the original Specification, is considered a free gift.