How to Invoice for Web Development & Software Work (Milestones, Pass-Throughs & Code Ownership, 2026)

Every other trade in this cluster gets paid for something the client can't take back without you. A plumber leaves with the wrench. A caterer takes the money before the food is ordered. Development is the inversion: by the time you invoice, the site is already live on the client's host, the code is already sitting in the client's repository, and the app is already in their store account. You have delivered the entire value of the work, and then you have asked for money. That is a structurally weak position, and it is why developer invoicing is less about the invoice document than about the sequence of events the invoice sits inside — deposits taken before the first commit, milestones that get paid before the next phase starts, an acceptance definition that says when the work is finished, and a contract clause that keeps the copyright with you until the last dollar clears. Get that sequence right and the invoice is a formality. Get it wrong and you are an unsecured creditor of a company that already has everything it hired you for.

Choose the Billing Model Before You Write the First Invoice

Four models cover almost all development work, and each one shifts risk somewhere different. Hourly — you bill time at a rate, usually every two weeks or monthly. It is the fairest model when the scope genuinely can't be known (a rescue job on someone else's codebase, an open-ended integration, a discovery phase), and it protects you completely from scope creep because every extra request simply shows up as more hours. Its weakness is that it caps your upside, invites clients to scrutinize your speed, and makes your income depend on invoicing discipline you may not have. If you bill hourly, track as you go and describe what you did in plain terms — "12.5 hrs — checkout flow: Stripe webhook handling, failed-payment retry, order confirmation email" gets approved; "12.5 hrs — development" gets questioned. Fixed fee — one price for a defined deliverable. Clients love it because they can budget it, and it rewards you for being fast, but it puts the entire estimation risk on you and it only works if the scope is written down in enough detail to say what isn't in it. Milestone billing is fixed fee split into paid checkpoints, and for any project past roughly five thousand dollars it is the correct default — more on it in a moment. Retainer — a recurring monthly amount for ongoing availability, maintenance, or a block of hours. It is the most valuable model to end up in, because it converts a project business into a predictable one, and it deserves its own conversation once a build ships. Whichever you choose, write the payment terms on the invoice itself rather than assuming the contract speaks for it — the person in accounts payable paying your invoice has usually never seen your contract.

Deposits, Milestones, and the Kill Fee

The single most important structural decision is never being more than one unpaid phase deep. A deposit of 30% to 50% before any work begins is standard in development and you should treat a refusal as information about the client rather than a negotiation to win. It does three things: it covers the discovery and planning work you'd otherwise do for free, it filters out clients who were never going to pay, and it means a project that dies in week two costs you nothing you didn't already collect. Then split the balance into milestones tied to deliverables, not to dates — "design approved," "backend and API complete," "staging build accepted," "launched to production" — because a date-based schedule bills the client for a week in which they were the ones holding you up, and a deliverable-based one doesn't. Two or four milestones is usually right; more than five and you spend the project invoicing. The rule that makes the structure actually work is that each milestone invoice is paid before the next phase starts. If a client disappears after milestone two, only milestone three is unpaid — instead of the entire project. Hold the final payment against launch or handover, and make it meaningful: a final payment of 10% is not enough leverage to get anyone's attention, while 25% to 30% reliably is. Finally, put a kill fee in the contract — a cancellation charge, commonly 25% to 50% of the remaining uninvoiced fee, that applies if the client pulls the plug mid-build. Calculating it against what hasn't been invoiced yet is what makes it defensible: a cancellation on day one costs you very little and should cost them very little, and a cancellation at 80% complete has taken months of your calendar off the market. When you do invoice it, reference the clause by name and show the arithmetic, because a cancellation invoice with a bare number on it is the one clients contest.

Define "Done" — Because "Done" Is What Triggers the Invoice

Most late developer payments are not payment disputes. They are acceptance disputes wearing a payment dispute's clothes: you believe the milestone is complete, the client believes there are still three things outstanding, and the invoice sits in limbo while you argue about whether a bug is a bug or a feature request. The fix is to write, in the contract or the statement of work, what specifically constitutes acceptance of each milestone — the feature list, the browsers and devices supported, the performance or test-coverage bar if there is one, and, critically, a review window: the client has, say, five business days from delivery to submit written revisions, after which the milestone is deemed accepted and invoiced. That clause matters more than any other sentence in the document, because without it a client can defer acceptance indefinitely by simply not responding, and your invoice never becomes due. Pair it with a revision cap — two rounds of revisions included, additional rounds billed hourly at a stated rate — so "can we just try one more version of the homepage" has a price. Distinguish a defect (it doesn't do what was specified — you fix it free) from a change (it does what was specified but they now want something else — that's a change order), and say so plainly in writing, because the ambiguity between those two is where unpaid weeks live. Then, when you invoice, reference the acceptance: "Milestone 3 — staging build, accepted 14 Aug per email." Referencing the contract and the approval on the invoice turns a request for money into a record of an agreement already made.

Change Orders: Bill Scope Creep Before You Build It

Scope creep is the second-largest drain on freelance development profit after late payment, and it almost never arrives as a big request. It arrives as "quick" ones — a field added to a form, a second language, an admin export, a redesign of one section, an integration with a tool the client adopted mid-project. Each is small enough that saying no feels petty, and together they are a month. The discipline that solves it is unglamorous and absolute: when a request falls outside the written scope, you send a change order before you write the code, not an invoice after. A change order is three lines — what's being added, what it costs, and what it does to the timeline — and it needs a written yes (an email reply is fine) before work starts. This is not bureaucracy for its own sake. It is the only mechanism that lets you say yes to everything a client wants while still being paid for it, and clients almost always approve them, because the request genuinely is worth the money to them. The failure mode is doing the work first and invoicing after, at which point you are asking for money for something already delivered, and the client's honest reaction is that they thought it was included. On the invoice, put change-order work on its own clearly labeled lines referencing the approval — "CO-2: multi-currency pricing (approved 21 Aug) — $1,400" — rather than absorbing it into a milestone total, because visible change orders teach a client that requests have prices, and buried ones teach them the opposite.

Hosting, Domains, APIs, and Licenses: The Pass-Throughs Devs Forget to Bill

Developers leak more money through third-party costs paid on their own card than through any other single habit. It starts innocently — you register the domain during the build because it's faster than waiting for the client's IT department, you spin up the hosting on your account, you buy a $79 theme license and a couple of plugins, you put the client's traffic through a mapping or email or AI API keyed to your account — and then the project ends and you are still paying for all of it, sometimes for years, for a client you no longer work with. Decide the ownership model before the build, and there are only three honest ones. Client-owned is the cleanest: the client creates and pays for the domain, host, and third-party accounts in their own name and adds you as a collaborator. Nothing appears on your invoice, nothing lingers on your card, and there is no ownership question when the relationship ends. Pass-through means the accounts are in the client's name but you administer them and bill the cost through — invoice it as its own clearly labeled line at cost ("Hosting — Aug 2026, billed at cost — $24.00"), attach or reference the receipt, and keep it separate from your labor lines. Vendor-owned means the accounts are yours and you resell the service as part of a package; this is legitimate and often the basis of a good maintenance business, but understand what it changes: you are now reselling a service rather than being reimbursed for one, which affects both your income reporting and, in some states, whether that line is taxable. It also creates a real risk at the end of the relationship, when a client who believes they own their domain discovers the registrar account is in your name. Whatever the model, itemize these separately from your work — bundling a hosting charge into a development line makes both look arbitrary — and if you mark anything up for administration, say so rather than hiding it. Our guide to invoicing for expenses and reimbursements covers the receipt-and-markup mechanics in more detail.

Who Owns the Code Until You're Paid

This is the clause that replaces the leverage every other trade has and you don't. Standard practice in development contracts is that copyright in the delivered work transfers to the client upon receipt of full payment — not on delivery, not on launch, but on payment. Until then, the client has, at most, a limited license to use the work for review and testing. Clients generally accept this without argument, because they need the eventual transfer to be clean and unambiguous themselves: a company that later raises money or gets acquired will be asked to prove it owns its own codebase, and a vague ownership trail is a genuine problem in that process. So the clause protects both sides, and it is worth stating on the invoice as well as in the contract — a single line such as "Full ownership of all delivered work transfers to the client upon payment of this invoice in full" is polite, factual, and does more to move an invoice through accounts payable than any number of reminder emails. A few adjacent points are worth fixing in the same paragraph of your contract. Say what happens to third-party and open-source components — you can't transfer copyright in a library you didn't write, so the client receives it under its own license, and your contract should acknowledge that rather than promise something impossible. Decide whether you retain a portfolio right to show the work and describe your role. If you reuse your own internal tooling, frameworks, or boilerplate across clients, carve those out explicitly as retained property licensed to the client, or you may find you've signed away the thing you use on every project. And keep credential handover as a payment-triggered event too: transferring the repository, the deployment access, and the environment secrets is the practical moment of delivery, and it should happen when the final invoice clears, not two weeks before it.

Sales Tax: Custom Work, Prewritten Software, and SaaS Are Three Different Things

Most freelance developers assume their services aren't taxable, and in many states they're right — but the assumption is doing more work than they realize, and the details are state-specific enough that this is a map of what to check rather than advice for your state. The distinction that drives everything is between custom software written for one client and prewritten ("canned") software sold to anyone. Prewritten software is treated as a taxable product in most states with a sales tax, including when it's delivered purely by download and nothing physical changes hands. Custom software developed for a single customer is frequently exempt, because states tend to view it as the sale of a service rather than a product — though this genuinely varies, and a handful of states do tax custom development. SaaS is a third category again: roughly half of US jurisdictions now tax it in some form, some by treating it as a software sale, some as a data-processing or information service, and some not at all. Why this matters on your invoice rather than only on your tax return: the same project can contain lines from more than one category. Your custom development labor may be exempt while the prewritten theme license, plugin, or stock component you resold to the client on the next line is taxable — and separately-stated items are often treated differently from the same items bundled into one price, which means how you itemize can change what you owe. Related services sit on their own footing too: installation, configuration, data migration, training, and ongoing maintenance or support contracts each have their own treatment in different states, and support that includes future software updates is treated differently in some places than pure labor. Add to that the fact that for remote services the relevant jurisdiction is usually where the client is, not where you are, and that economic-nexus thresholds can pull you into a state you've never visited if you do enough business there. None of this is a reason for alarm — most solo developers doing custom work for a handful of clients have a simple answer — but it is a reason to get the answer once, from a CPA in your state, and then set your invoices up so they're right by default. Our general guide to sales tax on invoices covers the mechanics of showing it correctly once you know your treatment.

Getting Paid by a Corporate Client

Invoicing a startup founder and invoicing a 4,000-person company are different activities, and developers routinely lose weeks by treating them the same. A larger client will typically require some or all of the following before your invoice can be paid at all: a completed W-9, enrollment in a vendor onboarding or supplier portal, banking details submitted through their process rather than typed in your invoice footer, and — the big one — a purchase order raised before the work starts. In most AP systems an invoice without a valid PO number simply cannot be matched, and it will sit unpaid regardless of how correct it is or how well the project went. So ask, at contracting: do you need a PO, and who raises it? Then put the PO number in a prominent position on every invoice against that project. The rest is unglamorous alignment: your invoice's legal entity name must match the name on their vendor record; your line-item descriptions should mirror the language on the PO or statement of work so the match is mechanical; the billing contact is accounts payable, not your project sponsor — sending it to the person you talk to daily is one of the most common ways to add two weeks to a payment; and if they use a portal, the invoice usually has to be submitted there rather than emailed. Our guide to getting an invoice approved by accounts payable walks the whole path. Two other things pay for themselves here: submit before their cutoff (many AP departments run payment batches on a fixed weekly or monthly cycle, and missing the cutoff by a day costs a full cycle), and state late fees in the contract if you want them enforceable — our late-fee calculation guide covers what's reasonable. If the client is overseas, currency, payment rails, and withholding all come into play; invoicing international clients covers those.

Turn the Build Into a Retainer Before You Send the Final Invoice

The most valuable invoice a developer sends is not the last one on a project — it's the first one on the maintenance agreement that follows it. A finished site or app is not a finished relationship: it needs security patches, dependency and framework updates, uptime monitoring, backups, small content and feature changes, and someone to call when something breaks at an inconvenient hour. If you don't sell that, one of two things happens — the client neglects it until something fails and then blames the build, or they hire someone else and that person becomes their developer. The moment to propose it is while the final milestone is still in flight, when the work is fresh and goodwill is at its peak, not three months later in a cold email. Price it as a flat monthly fee for a defined set of inclusions rather than a vague "support" line: what's covered, how many hours or requests are included, what response time you commit to, what falls outside and gets billed separately, and — worth stating — that emergency work outside business hours carries a different rate. Then invoice it on a fixed day each month, in advance rather than in arrears, which is both standard for retainers and materially better for your cash flow. Retainer revenue is what makes a freelance development business survive a slow quarter, and it is the difference between hunting for the next project every eight weeks and choosing the next project. We've written the transition up in detail in converting a project client to a retainer, and the mechanics of billing it repeatedly in recurring invoices for freelancers.

How InvoiceQuick Helps

Development invoicing rewards exactly what InvoiceQuick is built for: an itemized bill where the milestone, the change orders, and the pass-through costs are all visible as separate lines with their own math, so nothing looks like a number the client has to take on faith. Save your business details once — name, contact, remit-to, payment terms, and your EIN if corporate clients ask for it — and each invoice is a few taps: the milestone with its acceptance reference, change orders on their own labeled lines with the approval date, hosting and licenses itemized at cost, and the deposit or prior payments subtracted so the balance due is obviously correct. Put the PO number and the ownership-transfers-on-payment line right in the notes where accounts payable will read them. A consistent invoice number sequence means you can pull any project's paperwork in seconds a year later, which is what settles a question about what was in scope. It produces a clean PDF you can attach to a portal submission or an email, it's free with no sign-up required, and it works from a laptop or a phone. Create your first invoice in about a minute, then reuse it for every milestone after that. (Billing in stages, taking money up front, or working by the hour? Our guides to progress and milestone billing, deposit and upfront-payment invoices, and invoicing for hourly work cover the rest — and if you're subcontracting to an agency rather than billing the end client, the subcontractor invoicing guide covers pay-when-paid and lien-waiver territory.)