May 28, 2019

Question to freelancers: do you ever have a dispute over hours you bill?

Sergey Shvets @sergey_shvets


Want to ask everyone who works as a freelancer, especially in dev/design, how often clients complain about hours you bill? Do you need to send them a detailed invoice? How do you typically solve these situations?

I'm asking because I've suddenly realized that my product,, might be useful for this scenario and want to validate if it is even relevant.

Thank you!


  1. 3

    Been freelancing for 9 months. Never had a dispute of any kind. I credit this to two main things:

    1. Like @ulrichgero, I've moved most clients and projects to a per-project or per-day basis, so hourly reporting isn't necessary.
    2. Most importantly, though, no matter how the project's cost is set up I communicate a lot with clients to set up their expectations. I give them an estimated cost up front and communicate ASAP if it's looking like the final cost will be more than 5% higher than that original estimate. I also talk with them about what deadlines and specs are reasonable for their projects, so they don't ever feel like they were cheated or like I dragged my feet. I suspect that the underlying reason for hours disputes is usually that the client either were cheated or, more likely, felt like they were cheated because their expectations and reality were misaligned.
    1. 1

      Thanks for the response! What do you do to level their expectations? Also, how do you formalize the scope?

      1. 2

        No worries, Sergey! For leveling expectations, I treat it much like I did when I worked on a team at a "normal 9-5":

        First off, I need to understand what is being asked of me and when it will be needed by. For this, I usually ask what their timeline is and if I can see any designs they have already (since having them just describe features in words can lead to confusion, especially since designers or business people can have incorrect beliefs of what "should be really easy to tack on" to a coding project). This is the best time for me to find things like (actually story from a recent project) asking "where will this button go to?" and getting a response like "oh that'll go to the AR camera experience..." Finding things like that allows me to stop them and ask for details about this AR Experience (what does it look like), who they expect will build it (is it me?), and how critical it is.

        Once I understand the scope and deadlines, then, I can level their expectations by explaining things in terms of the "on-time/to-spec/under-budget" triangle (choose one to not care about). This usually looks like, "Ok, great, most of this seems totally doable. I am worried about that AR Experience, though. I think we'll either have to cut that, add a month or two to the project for it, or pay for a second contractor to tackle that while I tackle everything else." Once they understand the trade-offs, they can pick one, and we can move on.

        Finally, for formalizing the scope, contracts are the best and I will never do more than an hour of work without one. I usually make it clear what the deliverable is (an app? a particular website? etc), what the features of it will be ("The three pages, A B and C, as discussed in the designs named "X.psd" on <Today's Date>. This does not include the AR Experience."), and when they are due by ("To be delivered live on the internet and via code by 5/1/2019").

        1. 1

          Thanks for the detailed response, Zack! I assume your projects are usually at least a month of length? How often are you doing check-ins with your clients?

  2. 3

    Years ago, they asked for hourly bill. Now I get paid based on the project. Because what I'm giving them is more than hours. It's also passion and hard work.

    1. 1

      Thanks for the response! Do you build some document reflecting the scope of a project? Also, what do you do if customers ask for too many changes during the project?

      1. 2

        Yes! I build price table for my services and also make clear to clients that, for example the first change is for free but I rise the price when they asked for another revisions.
        This way, they send me exactly what they wanted me to do, and it also help me to not waste time.

        1. 1

          Do you formalize the scope in some kind of contract?

          1. 1

            Hi! sorry for late reply. Yes, I do.

      2. 1

        This comment was deleted 10 months ago.

  3. 3

    Never had a complaint.

    For EXISTING/REPEAT clients, they've never question my bill. At end of month, I just send them the bill, work I did categorized by project/website and general tasks. No, I don't list detail tasks of each and every little thing I did for the month (task listed may be: design and develop yyyyyyyyy functionality, fix bug in xxxxxxxxx section, or just a simple customer support, or website updates).

    For NEW clients, I give them my hourly rate, an estimate of whole project cost, and a not to exceed dollar figure. If scope changes and we may exceed the max. amount, I tell them beforehand. But I try not to get to that point, and if the additional work was simple, I'll just eat that cost. Overall I try to bill them under our agreed estimated cost. But I let them know that X feature they requested was provided at no charge, so they know they got a discounted total. This brings goodwill, and repeat business.

    1. 3

      Same here. I like billing by project with some safeguards built in for scope creep - we both know what to expect from the beginning.

      1. 1

        Thanks for the detailed response! @Lauren_IH mentioned "scope creep" — is this typical with customers and how big is this problem?

        1. 2

          You know, sometimes customers don't know exactly what they want. And in the course of the project as you communicate with them -- asking pointed questions, asking for clarifications -- they begin to think of new ideas, or finally becomes clearer for them what exactly they want. So yeah, it creeps up. Now, it's up to the dev to say Yeah I can do that, or No, that's too much will take a lot of time, and will be over-budget, and it's your responsibility to let the client know as early as possible. If the client really wants it, you all could agree on a new budget and there you go, you have the go signal.

          1. 1

            Makes a lot of sense! Thanks for insights! Also, do you work alone? Meaning you do all the designs, planning, development or there are some dependencies on clients themselves or other contractors?

            1. 2

              Yes, full stack, starting from planning, web/graphics design prototype, coding frontend and backend, database, server setup to customer support/training and upkeep/maintenance... heck even data entry. Doesn't matter to me, I'm paid the same hourly developer rate. :)

              Some clients though will have an in-house graphics designer and they may give me logos, artwork, photos to use, or even a rough prototype/photoshop mockup of the website they want and then I take it from there.

              Of course, clients supply the marketing/web copy and content. I can't do that for them.

  4. 2

    First, an anti-recommendation for project-based billing. Source: I did a bunch of it early in my career.

    Project-based billing often blows up (in a bad way) for freelancers. Specifically because typically neither the consultant nor the customer know exactly what they want. If you didn't think to ask whether the client had e.g. building an internal-facing dashboard as part of the project, you're likely to find yourself in the position of building e.g. an internal-facing dashboard for free for that client.

    That's all before scope creep, to which you are exposed unless you are in charge of making decisions about the scope of the delivery (which is exceedingly rare for a consultant).

    Hourly billing sucks, but it exposes you to far less risk as a consultant than project-based billing. (Daily billing is basically the same, but is more prevalent in Europe in my experience.)

    All that said, some clients will push back on the bill. You can mitigate that to some extent by over communicating expectations & progress. Some clients will be comfortable essentially participating in your Scrum/Agile process so they are kept current with project state.

    And beyond pushing back, if you freelance long enough you will have clients just refuse to pay (or can't pay, which has the same impact on your bank account). Keep this in mind and push your rates up now for all your clients to compensate, because you can't know in advance who your nonpaying clients will be. (They may not know yet that they won't be able to pay!)

    The biggest things I would advise around getting bills paid:

    • Get the customer to sign a contract before doing any work. No exceptions. The contract should have provisions for you retaining IP ownership until they pay in full (see for contracts). Do not start working until the client signs the contract.

    • Get a significant deposit from any company smaller than Fortune 500. If you think the project is $30k, $5k is a good floor for deposit. If the client won't pay a deposit up front, you will likely have trouble getting paid later.

    • Bill in smaller increments if possible (bi-weekly is better than monthly).

    • Send invoices on time & collect on time.

    1. 1

      Wow! Thanks! You say: "hourly billing sucks". What makes you say that?

      1. 1

        Hourly billing sucks because it misaligns incentives between consultant and customer. The consultant does better financially (in the short term) by billing lots of hours, while the client has an incentive to minimize hours billed by the consultant. So out of the gate, there is an alignment problem when the goal should be partnering to deliver results for the client.

        Hourly billing sucks because it's hard to not leave money on the table. If you're off the clock and the client Slacks you a quick question, how do you bill for the 2 minutes it takes to respond? What if you end up doing several 2-minute responses spread out over an hour? Add it up, and it's a recipe for underbilling/doing free work by default.

        Hourly billing also sucks for the freelancer because you are in one of two states: 1) fully engaged with a single client or 2) multi-tasking between clients. In case #1, billing hourly frequently leads consultants to "soften the blow" by not sending invoices that include e.g. 60-hour weeks. I have personally watched freelancers leave tens of thousands of dollars (each) on the table because of a perception the client would reject an invoice with a 55-hour week on it (think: prep for a major release).

        Freelancers in state #2 are often servicing smaller clients, which implies smaller hourly rates (e.g. Coke has a comfort level with high-dollar consultants that a smaller business may not). A focus on hourly billing allows you to service the smaller clients, but that may not be a smart decision in the larger context.

        Finally, at some point many clients will ask for a granular breakdown of the hours billed and what they were used for. This is a totally legitimate request from a customer. However, it also means you must prepare by recording not only time but specific details for everything you do, down to the smallest 15-minute (or smaller) block. That makes the entire enterprise much less fun.

  5. 2

    Nope. I charge per project or day/week/month.

    1. 1

      What do you do if you worked on a project half a day instead of a full day? And how do you agree on the length of the day? I've never seen daily charging, so curious on how that works.

      1. 1

        Let's say it equals to what you'd normally invoice as 5 billable hours. Half a day projects are still charged at daily rates, or per project. Daily rates are how contractors charge in the UK, some Mainland European countries and some Commonwealth countries.

        1. 1

          Thanks, never knew about that.

          1. 1

            Look up British, Swiss, Dutch, Swedish, etc. contracting offers. Most list offered daily rates.

  6. 2

    That happened to me once back in 2012 when I was first starting out. Since then, I try to maintain all "working hours" online via Slack so that my client can reach me literally any time during a shift. Under that system, hours billed has not been issue.

    1. 1

      By maintaining "working hours" you mean you just online during those hours and being as responsive as possible to clients?

      1. 2

        Exactly. In my experience however, it typically is not the client whom I directly interact with, it is other devs on the team. Either way, someone on the project can vouch for my hours/work time if necessary. It really has not come up since 2012 though. At this point, my clients have 6-figure budgets for development expenses across multiple dev teams. A couple hours here and there is really a drop in the bucket so ironically, i probably could "embellish" the invoice entries. Needless to say, I don't.

        1. 1

          Got it, thanks!

          1. 1

            Sure thing. I'm a full time contract developer so if you have any other questions about it, feel free to connect!