Project Management

Independent contractors: Make sure your contract protects your interests

Writing a contract can help independent contractors and clients iron out project details ahead of time and avoid potential disputes down the line. Meredith Little outlines what verbiage and clauses to include in your contract and explains why you should clearly state your independent status.

 When you're a contractor, your contract is what defines your relationship with your client. Although you or the client may be eager for the project to begin, you should never start work without an agreement that clearly defines the terms of the assignment.

Whether you're a support professional, a network or systems engineer, a programmer, a trainer, a writer, or a consultant, be sure to include certain clauses. In fact, it's a good idea to have a standard contract that can be modified to fit any particular project.

Why you need a written contract

When things go well, you'll rarely need to refer to your contract. Yet a contract is something you can't afford to go without. At best, it forces you and the client to scrutinize the project ahead of time.

While agreeing on the contract's terms can prevent a lot of disputes, you'll also have a well-written contract for reference in the unfortunate instance when you and your client disagree.

Many verbal agreements are binding and can be upheld in court, but you really don't want to go there.

Title and preliminaries

Your contract needs a title, something like Independent Contractor Agreement or Consulting Service Agreement. Just don't use the word employment anywhere, as this term contradicts your independent status.

After your title, specify that the contract be between you and the client. Use your name (your business name if you have one or Sole Proprietor if you don't) and the address of your place of business (never use the client's address as your place of business -- even if you will be doing significant work there). Then, add the same information for your client.

Scope of Work

The Scope of Work clause is what work will be judged by, so make it as specific as possible. In as much detail as possible, spell out what you're supposed to do, the deliverable milestones and dates, and the requirements for each milestone. The only thing you don't want to specify is how the work will be done. The client has the right to accept your finished work but not how you will do it.

You do want very detailed specifications of what will constitute an acceptable finished product, and you should be able to show that your finished work meets these specifications. You may want to provide this clause as an attachment to the contract that's more like a detailed proposal based on your analysis of the client's needs.

Here are two examples:

  • Bad: Contractor will perform programming services for client.
  • Better: Contractor will develop a database back-end solution using Application X that will interface with client Application Y to perform Goal Z. Review schedules and dates, and the exact fields, keys, and data elements to be included are specified in Attachment A of this agreement.

Revisions and changes

If you've started with a standard contract that your client uses, you might find a phrase like "contractor will make all revisions required by client." Don't use this! It's so vague that the client could completely change the scope of the project six months in and expect you to scrap all your work and start over at no charge. This could devastate your pocketbook if you're working on a flat fee.

Ideally, you want to include the following points regarding project revisions:

  • The Client is entitled to one revision within the original scope of the contract at no charge.
  • The Client will compensate Contractor for additional revisions at an hourly rate of $x or a flat fee to be negotiated.
  • Revisions outside the original scope of the project (as defined in the Scope of Work clause) will be negotiated separately.

You're probably beginning to see the importance of that Scope of Work clause. If your client wants you to increase the number of revisions, don't agree to more than two or three. Don't give ground on the third point unless you enjoy working for free.

Client responsibility

If you rely on certain input from the client, be sure to specify that any delay in receiving it will affect your deliverable items or dates. You may want to stipulate that an extended period of non-responsiveness is grounds for you to terminate the contract.

If the project is lengthy and you've built in review periods (which I highly recommend), specify the following:

  • The name of the person to whom you'll deliver the work and who has the authority to accept or reject it (make sure this person literally signs off on every review).
  • The time in which the reviewer must accept or reject the review.
  • Work submitted for review will be considered accepted unless it's rejected in writing within the time period specified. In the rejection notice, Client will clearly spell out all changes required.

Payment and terms

Be sure to have in writing not only what you'll be paid, but when you'll be paid. If you're to be paid a flat fee for the project, get at least a fourth to a half of the fee up-front. You could get the next fourth halfway through and the last half or fourth on completion.

If it's a very long project, you may want to receive 10 or 20 percent or more up-front and another 10 to 20 percent every month. Only agree to payment on completion for very short projects. Consultants and contractors who must supply clients with new hardware and systems components should receive deposits when the equipment is ordered and the remaining balance when the equipment is delivered to the client's site.

If you will be paid on the basis of a unit of time, specify what that unit is (hourly, weekly, monthly) and the period for which you will bill. For example, if you bill hourly, specify whether you will submit an invoice weekly, twice a month, or monthly.

Note that if it comes up, the IRS is more likely to question your independent status if you bill based on unit of time rather than on a flat fee. If it's standard for your trade, that's okay. However, as long as other conditions support your status, do what's right for you on the project. For example, if you don't believe at the time of signing the contract that you can sufficiently define the scope of work, you'll probably be more comfortable stipulating payment by the hour. You may want to add an option to renegotiate once the scope becomes clearer.

Independent contractor status

Clearly state your independent status with a simple clause along the lines of, "Contractor is an independent contractor and is not an employee of Client."

Beyond that, here are the other salient items that establish you as an independent. You can bullet these under the "independent status" clause or list them separately if a project requires greater detail on any particular point.

  • Control: Contractor has sole discretion to determine how, when, and where to perform services required to achieve the final result specified in the Scope of Work clause.
  • Non-exclusive: Contractor has right to perform services for other clients during the term of the contract.
  • Assignment: Contractor has the right to use employees or subcontractors to perform some or all of the duties required. (Your client has a right to know who will be performing the work, so this may raise eyebrows. If so, address it in a separate clause that retains your right of assignment but also notes that the Client has the right to approve subcontractors or employees who perform significant services.)
  • Taxes: Client will not withhold any income or FICA taxes from any payments to Contractor. Contractor is responsible for paying all applicable state, federal, and local income taxes.
  • Insurance: Client does not provide workman's compensation or unemployment insurance for Contractor.
  • Benefits: As an independent contractor, Contractor is not eligible for and has no claim to medical benefits, profit sharing, vacation pay, sick pay, or other benefits offered by Client to employees.
  • Expenses: Contractor is responsible for expenses and materials necessary to perform services required in Scope of Work. (If you anticipate large expenses, such as travel or expensive software, you should factor these into your bid and make sure you'll charge enough to cover them. However, if you meet most other independent status conditions, you could stipulate that the client will reimburse you for certain large expenses.)
  • Training: Client will not provide training to Contractor or employees or subcontractors of Contractor. Or, if training is part of the project, specify how many hours and what materials the training includes.

Why independent status is so critical

The independent status concept largely serves to establish to the IRS that you are not an employee of the company. If the IRS decides that the relationship is employee/employer instead of contractor/hirer, you'll both suffer.

For starters, the hiring firm will be hit with back taxes and penalties. As the contractor, you'll have to re-file your tax returns for the period covered by the contract. You won't pay additional taxes, but you'll lose the right to deduct your business expenses for that period. In addition, your client is unlikely to want to continue working with you given the hassle.

In addition to clarifying matters for the IRS, these stipulations also spell out your status as an independent to any company that may not be used to working with contractors. Especially on longer contracts, a more management-prone client may begin treating you as an employee. Your contract establishes your expectations up-front and can serve as a gentle reminder if necessary.

Term of contract and termination

When does the contract begin and end? Under what circumstances can either party terminate the contract before that end date? What, if any, obligation does the terminating party owe to the other? Unlike declaring your independent status, there's no set formula for addressing these questions.

Instead, the scope of the project should dictate the term. Don't make the term extremely long -- it leans toward an employee relationship. For a long project, you could specify a six-month term with the option to renew. (This also can provide a window for either side to renegotiate certain terms of the contract if desired.)

Generally, termination of a contract is for cause -- there's a reason for ending it before the end date. Otherwise, it can look more like an employee relationship (yes, contractors have more rights than employees). However, you can specify the reason, which may include the following:

  • Breach of contract: If either party does not fulfill their obligations under contract, the other party should be able to terminate immediately without further obligation.
  • Nonpayment: If the client doesn't pay you within a specified period of time, you should be able to terminate the agreement.
  • Any business reason: For greatest flexibility, you can specify that either party can terminate the contract for business-related reasons, which essentially means any reason. Specify a minimum 30-day period of notice to avoid looking like an employee.

Kill fees

If you're working on a project for a set fee, you may want to stipulate a "kill fee" for early termination. For example, if the client terminates the agreement in the third month of a six-month project, the client will pay you 50 percent of your total compensation minus any payments you may have already received.

This may be unnecessary if you've set up an incremental payment schedule, such as 20 percent up-front and 10 percent monthly. This shouldn't be a punitive clause. Instead, you simply want to avoid a situation in which a client can cancel a project toward the end and pay you almost nothing for the work you've already completed or the materials you've already supplied.

Standard legal wording

The following points should be included in any contract as standard legal fodder. These clauses are the ones that are least likely to change from project to project. Your best source for their wording is to find a standard contract and lift them as necessary.

  • Exclusive agreement: This is the complete and only agreement between Contractor and Client. (You may want to stipulate that any modifications to the contract must be in writing, signed by both parties, and attached to the original agreement.)
  • Liability: What are the limits of liability for you and the client? A full discussion of this clause is beyond the scope of this item, but try to limit your total liability to no more than your compensation for the project.
  • Resolving differences: Specify resolution of disputes. You may want to specify that mediation is to be pursued prior to litigation. You may also want to consider who pays legal expenses.
  • Applicable law: What state's law will govern the agreement? Usually, this is simply the state where you and the client do business. If you're doing some work out of state or you and the client are located in different states, pick one or the other state, preferably your home state.
  • Confidentiality: The client has a right to expect that you will keep private information confidential. It makes you look more professional if you include this clause up-front.
  • Work-for-hire: You should use this clause to assure the client that the client will own the work you do for them. You do this by defining the work you produce under the agreement -- whether it's a database, a manual, or a set of training materials -- as a work-for-hire: The client will retain title and rights to the work you create for client.
  • No partnership: State that neither party has the authority to enter into agreements on behalf of the other party.
  • Notices: Are notices to be delivered in person (to whom?), in the mail, via e-mail, or so on? Basically, what constitutes a notice as being delivered?
  • Enforceability: State that if any one clause of the contract is found to be unenforceable, all other clauses remain binding as they are.

What else?

This contract belongs to both you and your client. If you believe your project warrants clauses that I haven't discussed, add them. However, some clauses may not be legally enforceable, even if you both agree. For example, you might stipulate a late fee if your client doesn't pay an invoice within a certain amount of time. You won't be able to collect if this rate is considered excessive (the legal term is "usurious") in your state.

Above all, always have an attorney review sample agreements, forms, and contracts before presenting them to clients. There's no better protection, so make this a common (if not annual) exercise.

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

If you haven't figured this out, stay a wage slave. GET A LAWYER!


One of the downloads Techrepublic has/had was a short letter style contract. The reason I point it out is that most consultants/contractors need several different contracts depending on the type of work to be done. For example, a contractor may need: 1. An agreement letter for single shot small jobs. 2. An estimate acceptance agreement/work order for really short jobs. This is the small print on most work orders ... the stuff on the back page. 3. A single use contract which has been designed for a single engagement. (This is what is being suggested in the article). 4. A multiple use or revolving contract (Chip is suggesting this above). What a consultant/contractor really needs is to look at his/her business and identify the various types which are needed. Glen Ford, PMP


Your coverage of the topic is generally reasonable but I don't know why you seem to feel a need to put in language that the client should negotiate for .. or demand, as the case may be. The one that sticks out is the "work for hire" clause; while I may ultimately not care if the client owns the work I don't generally believe in just giving things away and that's what you're doing here. You may need the WFH clause as a bargaining chip if the client gets edgy about some other issue .. wouldn't it be nice to be able to say, "ok, if we can agree to on-site not more than two days per week, I'm ok with the work-for-hire" ?? Of course if you know in advance that the client will absolutely insist upon the clause it may be wise to just put it in in the first place and avoid any additional hassle. > I'm not going to argue too strenuously here as I know some contractors have a bit of a fetish for written contracts, and indeed sometimes they come in handy .. BUT, personally, over many years and many projects I don't think I've used a written contract more than half the time and each time was at the insistence of the client. Why? Because I know that the kind of clients I have will ALWAYS have the upper hand in the negotiations; I'm a licensed attorney but that really doesn't help a whole lot against a big bureaucracy with an ARMY of licensed attorneys and rules which stretch from here to hell. I don't really expect to influence the "have to have a contract" gang on the issue; I raise it only as something to think about, and, to say that in case anyone should find themselves mid-stream in a project without one, don't panic .. there are other legal grounds for recovery when you've actually delivered something of value.

Sterling chip Camden
Sterling chip Camden

Good article, but I have to disagree with the statements under "Scope of work", unless the engagement is intended to be short. Most of mine tend to be ongoing for years, with an annual contract renewal. Trying to specify everything in detail that I will provide for them over the next year is impossible. Then again, I bill by the hour -- so scope creep doesn't bother me at all ;)

Sterling chip Camden
Sterling chip Camden

... but not any more. Those big companies with all the lawyers also know how to squeeze out of some verbal agreements. IMHO it's better to protect yourself. I agree with you on the WFH clause -- I like to retain some ownership of some of my work, in order to be able to reuse it. I make it clear in my contract that there are two types of software that I'll supply: a "work product", which is theirs, and additional software that was not first developed for the project to which they have an unrestricted license but I retain copyright.


And if you do a good job, it's inevitable.


> sounds nice but it can be hard to identify which is which ... the whole thing is typically academic: most clients really need nothing more than a non-exclusive, unrestricted license (no matter what they THINK or SAY they need) ... and I've never actually seen the dreaded scenario of a developer not being able to make use of common routines in other project work; how are they going to know? If there's a chance they will, there's always another way to express your code. If this stuff actually DOES get thick, as a fallback position, developers should consider some kind of cross-licensing agreement where you get back whatever rights you need to maintain use of your libraries.


That's a common error. In a similar discussion a few years back a manager up here stated that he always owns the work. Section 13 gives the original author ownership by default. Section 13 (3) says the owner is the employer and is the section which is misread as work-for-hire. (BTW ... important note that up here, T4/W2 contracting is unusual since it is not considered to be contracting but rather employment). Section 13(2) says the purchaser is the owner but only applies to photography. HOWEVER, the key is that section 13 only applies to licenseable rights. Section 14.1 applies to moral rights and grants the author of the work moral rights to the work. Note - the author of the work - not the copyright owner. That's why section 13.3 allows the author to refuse to allow publication of an article even if copyright is owned by the purchaser. (And you thought coders liked unstructured code!). And I now have a headache .... ?:| Glen P.S. BTW the only reason this matters to me is that I traditionally work on equipment where "Open Source" -- in the real meaning of the phrase and with major restrictions -- is the traditional format. This is because virtually all clients have their own internal IT people.


> my understanding of Canadian copyright law, as it would apply to a computer program, is that by default, where the work is commissioned and paid for by another entity, that entity is the "first owner" of the copyright and therefore the legal "author" per the statute, UNLESS there is an agreement to the contrary. Since Section 14 gives moral rights to the "author," it follows that the employer has the moral rights as well as the usual legal rights incident to ownership. I have to say the issue is not entirely clear, however, and there does seem to be a fair amount of confusion and disagreement up there on the issue, no doubt in part because there are different rules applicable to different kinds of works of authorship. From an employer perspective I would likely insist upon an assignment and waiver of moral rights just to make clear what the understanding of the parties is. From a programmer's perspective, assuming I was concerned about my own or my client's future use of the code, I would take the time to draft an appropriate agreement making clear that the actual author would retain certain rights to use the work, whatever those might be. I cannot disagree that certain employers or clients might find all of this a tedious, burdensome and difficult exercise .. which leaves the developer to decide how important the concessions on each side really are and the extent to which they are willing to risk loss of the engagement. As a practical matter, in the case of unsophisticated client I don't think I would worry a great deal about later use of common library code. In all events, in the case of code authored prior to the present engagement, the client should have no copyright ownership interest in it unless the developer assigns it away. They would of course have an implied license to use it .. and I don't think I would fuss about them modifying it.


You are, of course, correct. That is the work around. Unfortunately, it requires the client to understand copyright law. ("Why can't I license moral rights? What do you mean you waive your rights? No, my lawyer says I have to have a work-for-hire clause." etc.). And the sad truth is that most internal IT people don't know enough about running a service company. And copyright, you must admit, is approaching the esoteric limits for even a consulting company. It also requires more words than a simple, "this license includes the right to change the code", since you need to "waive the moral rights" only for this client and work done on the client's behalf. And then only certain of the moral rights etc. etc. etc.. A paragraph where a sentence will do. All for code that the contractor may or may not retain. (My coding was on big machines and I don't normally keep a copy if only because of the difficulty and cost of copying and storing it). I should also point out that the only reason I'm familiar with this is that I typically act as a consultant even if I am hired as a contractor. That means I share documents and articles that will not become the property of the client. So I have a need for two clauses - one for software (or other product) and one for documents. Glen Ford, PMP


> To be more precise, in Canada moral rights may not be assigned, they may, however, be waived, which effectively solves the problem you assert. See Canadian Copyright Act, Section 14.1 (2) in particular and the entirety of Section 14 generally.


The big problem with copyright is that what the customer normally needs can't be licensed. Generally speaking, most clients need: 1. the ability to change the software 2. the ability to make copies for internal use (backup etc.) 3. the ability to run the software on multiple processors/machines in their organization 4. the right to transfer their rights on sale of a unit. Very few companies ever consider the possibility of selling their software as a package unless that's the business they're in. The first one is the only one that really sticks out as an issue to most clients. The problem is that the last three can be licensed. The first is called a moral right and (at least in Canada) cannot be licensed. That's why a lot of companies try to get a "work for hire" copyright... the employer owns the copyright with an employee. And it's the only way they can see to get the moral rights. The problem of course is that most clients don't realize that the legislation sets out the rights and limitations. In Canada, for example, there is a provision preventing a software contractor from transferring moral rights. Effectively, the clause is null and void. Definitely a case of the need for copyright law to be adjusted to meet the world of the information age. Unfortunately, the drive for reform seems to be focused on protecting company rights from that great threat to the capitalist system. I'm speaking of piracy here. (sarcastically if you haven't guessed). Glen Ford,PMP

Editor's Picks