By profession

How to Invoice as a Software Developer

Software invoicing is complicated by two things nobody encounters in most other trades. The work is invisible until it is deployed, and the thing you built can be used whether or not you get paid, because it is already running on the client's infrastructure. Both problems have the same answer, and it belongs on the invoice: bill in short cycles, and make ownership conditional on payment.

By Arshad Hossain · Published 16 August 2026

The short version

Bill sprints in advance or at sprint close — never let three sprints accumulate unpaid.
Code IP should transfer on payment, and the invoice should say so.
Bug fixes inside warranty are free; changes of mind are billable. Define the line.
Third-party costs are pass-throughs, and belong in the client's name where possible.

Billing models and their failure modes

Development engagements use a small number of billing structures, and each fails in a specific way that you can design around.

Time and materials bills actual hours or days. It is honest and flexible, and clients dislike it because there is no ceiling. It works when the work is genuinely exploratory. Invoice fortnightly or monthly and never let more than one cycle go unpaid.

Fixed price bills an agreed sum for an agreed scope. Clients prefer it, and it transfers all estimation risk to you — which is severe in software, where estimates are notoriously optimistic. It only works with genuinely locked scope and a written change process.

Sprint-based billing bills per iteration at an agreed rate. It is the best fit for most agile work: the client can stop after any sprint, and you are never more than one sprint out of pocket. This is the model most worth defaulting to.

Retainer billing buys ongoing capacity, typically for maintenance and support after launch, and is covered in retainer and recurring invoices.

Model	Estimation risk	Client can exit	Invoice cadence
Time and materials	Client	Any time	Fortnightly or monthly
Fixed price	You	At milestones	On milestone
Sprint-based	Shared	End of any sprint	Per sprint
Retainer	Shared	Notice period	Monthly in advance

Code ownership should be conditional on payment

This is the leverage that software work uniquely needs, because unlike a physical deliverable you cannot repossess a deployed application.

State on the invoice that intellectual property in the delivered code transfers to the client on receipt of payment in full. Until then, the client is using code they do not own. That is a materially stronger position than being an unsecured creditor, and it turns a chase into a straightforward conversation about completing a transfer.

The corollary is that you must actually be able to make the claim. If you push directly to the client's repository from day one and hold nothing, the term is rhetorical. Approaches vary — staged handover, working in your own repository until milestone payment, or holding deployment credentials — and the right one depends on how much trust the relationship has earned.

Be careful with open-source components. Code you incorporate under a permissive or copyleft license is not yours to assign, and the invoice term should cover the work you authored rather than claiming ownership of the whole dependency tree.

Warranty bugs versus billable changes

This distinction causes more developer-client friction than pricing does, and it is entirely definable in advance.

A bug is the software failing to do what was agreed. Fixing it inside a stated warranty period — 30 to 90 days after delivery is typical — is not billable. You are completing work already paid for.

A change is the client wanting something different from what was agreed, including things they now realize they wanted all along. That is billable, at your normal rate, regardless of how small it seems.

Write the definition into the invoice terms in one sentence: "Defects in delivered functionality are corrected free of charge for 60 days from delivery. Changes to agreed functionality are chargeable at the standard rate." Then apply it consistently, including on the small things — the precedent set by absorbing three "tiny" changes is what makes the fourth one an argument.

Third-party costs and infrastructure

Hosting, domains, API subscriptions, app store fees, SSL certificates, paid libraries — modern software carries a tail of third-party costs, and how you handle them matters more than the amounts suggest.

Wherever possible, have the client hold these accounts in their own name and pay them directly. It avoids you funding their infrastructure, avoids the awkwardness of a service lapsing because an invoice is late, and means the client keeps access if the relationship ends.

Where you do pay on their behalf, bill at cost as clearly labeled pass-through lines and attach the evidence. Do not mark them up quietly. If handling them is real work, charge a stated management fee for that work rather than inflating the underlying cost — the first is a service, the second reads as a hidden margin when discovered.

Recurring costs need an explicit answer to what happens at renewal. An annual API subscription you paid for in month two is a real liability if the engagement ends in month five.

Developer invoicing questions, answered

How do I invoice for software development?

State the engagement, the sprint or milestone covered, the basis of the charge, and what was delivered in that period. Add pass-through costs separately, then the total, payment terms and your IP transfer condition.

Should I bill fixed price or hourly for development?

Sprint-based billing suits most work: the client can stop after any iteration and you are never more than one sprint out of pocket. Fixed price only works with genuinely locked scope, because software estimates are systematically optimistic and the risk lands on you.

When should I invoice for a sprint?

At the start of the sprint, or immediately at its close. Never let two sprints accumulate unpaid — that is the point at which a payment problem becomes a significant loss rather than a manageable one, and where stopping work gets emotionally harder.

Who owns the code, the developer or the client?

Whatever the contract says, and in the absence of an assignment the author generally retains copyright. Standard practice is transfer on payment in full, stated on the invoice. Note that incorporated open-source components are not yours to assign.

Should I fix bugs for free?

Inside an agreed warranty period, yes — a bug is the software failing to do what was agreed, so fixing it completes work already paid for. Thirty to ninety days is typical. Changes to agreed functionality are billable however small they seem.

What is the difference between a bug and a change request?

A bug is the software not doing what was agreed. A change is the client wanting something different from what was agreed, including things they now realize they always wanted. Define this in your terms and apply it consistently, especially on small items.

How do I bill for hosting and third-party services?

Ideally have the client hold and pay those accounts directly. Where you pay on their behalf, bill at cost as clearly labeled pass-through lines with evidence attached, and charge a stated management fee if handling them is real work.

How do I invoice for maintenance after launch?

As a monthly retainer billed in advance, stating what it covers — security updates, dependency upgrades, uptime response, a bank of hours — and what falls outside. Open-ended "support" with no definition is how maintenance retainers become unprofitable.

Should I charge for meetings and calls?

On time and materials, yes, and say so up front. On sprint or fixed pricing, a reasonable amount is built into the price. If a client's meeting load is genuinely disproportionate, that is a scope conversation rather than something to absorb silently.

How do I invoice for a discovery or technical spec phase?

As its own paid engagement with a concrete deliverable — an architecture document, a scoped backlog, an estimate. Paid discovery is what makes a credible fixed-price quote possible, and it filters out clients who were never going to proceed.

What if the client stops paying mid-project?

Stop work immediately and say so plainly. Continuing while unpaid increases your exposure with every commit and weakens your position. Because IP transfers on payment, the client cannot legitimately use unpaid work, which is what you point to.

How do I invoice as a subcontractor to an agency?

Invoice the agency, not the end client, matching their PO or job reference exactly. Confirm their payment terms, which are often longer than the end client's, and clarify who owns the delivered IP — usually the agency, who assigns it onward.

Frequently Asked Questions

Should I put my hourly rate on a fixed-price development invoice?

No. It invites the client to recalculate the fee based on how long the work took, which punishes you for being efficient. Reference the milestone and what was delivered instead, since that is what the fixed price was actually for.

Can I take an application offline if I am not paid?

Legally risky and situation-specific, particularly if the client's business depends on it. Withholding future work and undelivered code is the safer lever; disabling a running production system can expose you to a damages claim. Take advice before acting on live infrastructure.

How do I handle scope creep on a fixed-price project?

With a written change process agreed at the start: changes are specified, priced and approved before implementation. The process matters more than the pricing, because it makes the cost of a change visible at the moment it is requested rather than at the end.

Build your developer invoice

Free, no sign-up, no watermarks. Your data stays in your browser.

Create an Invoice Free