Proforma Invoice vs Invoice vs Quote vs Estimate

Four documents, four jobs. An estimate is a non-committal range you give before you know the scope. A quote is a specific price you are offering to be held to, usually with an expiry date. A proforma invoice is a payment request that deliberately is not an accounting document yet: it lets a client raise a purchase order or wire a deposit before you have anything to book as revenue. An invoice is the real accounting record, the one with a sequential number that lands in your books and your tax return. Only the last one is mandatory. Most solo developers need two of the four, and the confusion costs them a week of back-and-forth per project.

Rather than define them in the abstract, this post follows one project through all four documents. A client emails on a Tuesday: "roughly what would a customer-facing analytics dashboard cost us?" By the time the work is paid for, that question has produced an estimate, a quote, a proforma invoice for the deposit, and a final invoice. Every number below is an illustration of the shape, not a market rate.

What does each document actually commit you to?

Here is the whole vocabulary in one table. The "commits you to" column is the one worth reading twice, because it is the column that gets people into trouble.

Document	Sent when	Carries a number?	Commits you to	Hits your books?
Estimate	Before scope is defined	Optional, your own reference	Nothing, beyond good faith	No
Quote	After scope is defined	Optional, your own reference	The stated price, if accepted while valid	No
Proforma invoice	After the quote is accepted, before delivery	No invoice number, marked "not a tax invoice"	Nothing extra; it restates the quote as a payment request	No
Invoice	On delivery, on milestone, or on schedule	Yes, sequential and unique	Nothing further; it records what is now owed	Yes

The pattern: commitment rises from estimate to quote, then stops. A proforma invoice adds no new promise. It is a formatting change, a quote wearing invoice clothes so the client's accounts payable system can process it. The invoice adds no promise either. It records a debt that already exists because you did the work.

The other axis is accounting. The first three are all pre-transaction paperwork and none of them belong in your revenue. The invoice is the only one that does. That is why it is the only one that gets a real number, and why your invoice numbering system should never issue a number for any of the other three.

When does a dev need an estimate vs a quote?

Back to the Tuesday email. The client wants "roughly what a dashboard would cost". You do not know how many metrics, whether the data warehouse exists, whether they want role-based access, or whether "real time" means websockets or a five-minute cron. Quoting a fixed number here is not confidence, it is a guess you will be held to.

So you send an estimate:

Based on what you have described, a dashboard of this shape typically lands between $9,000 and $14,000. The range is wide because three things are still open: whether the metrics come from your existing Postgres or need a warehouse, whether access is per-user or per-org, and how fresh the numbers have to be. A paid discovery session would close all three and turn this into a fixed price.

That is the entire job of an estimate. It tells the client whether they are in the right shop, names the variables that move the number, and proposes the step that removes the uncertainty. It does not pretend to precision it does not have. Write the range honestly and name the drivers, and clients rarely anchor on the bottom of it.

Two weeks later, after a scoping call, you know the answers. Now you can quote:

Customer analytics dashboard, fixed price $11,400. Includes: seven metric cards, two time-series charts, per-organization access control, CSV export, and a five-minute refresh cadence from your existing Postgres. Excludes: new data sources, mobile-native apps, and anything not listed. Valid until 18 October 2026. Payment: 40% on acceptance, 60% on delivery.

The difference is not tone, it is the exclusions list and the expiry date. A quote is only safe to give when you can say what is not in it. If you cannot write the exclusions, you are not ready to quote, and the honest move is another estimate or a paid discovery phase.

The practical rule for developers: estimate before scope, quote after scope, and never let a client convert one into the other in conversation. "So call it ten grand?" on a phone call is how an estimate becomes a quote without anyone writing anything down. If the pricing model itself is still open, hourly versus fixed-price billing is the decision to settle before either document goes out, because a quote for time-and-materials work is a different animal from a quote for a deliverable.

What is a proforma invoice even for?

The client accepts the quote and replies: "Great, send us an invoice for the deposit so I can get it through AP."

You have done no work yet. Nothing is owed. Issuing a real invoice for $4,560 would put revenue in your books for a project that has not started, and consume a number in your sequence for a document that might be cancelled. That is exactly the gap a proforma invoice fills.

A proforma invoice looks like an invoice: your details, their details, line items, the amount, payment instructions. It differs in three ways. It is labelled "Proforma Invoice". It carries a reference like PF-2026-014 rather than a number from your invoice sequence. And it says, plainly on the face of the document, that it is not a tax invoice.

That last part is not a stylistic choice. UK HMRC guidance in VAT Notice 700, section 17.3 says pro-forma invoices "are often used to offer goods or services to potential customers", that they cannot be used as evidence to reclaim input tax "even if they show all the details required for a VAT invoice", and that you should make sure they are "clearly marked 'this is not a VAT invoice'". It goes on to say that once you actually supply the goods or services, or receive payment, you must issue a proper VAT invoice. Different jurisdictions word it differently, but the logic travels: a document that is not a tax invoice must not be mistakable for one, and the moment money or delivery happens, a real invoice follows.

The other place proforma invoices are load-bearing is customs. US import rules define a pro forma invoice as the importer's own statement of value when no commercial seller's invoice is available, in a prescribed form set out in 19 CFR 141.85. If you ship physical goods you will meet it there. If you ship code, you will only ever meet the finance-department version.

So the document trail for our project now reads: estimate, quote, proforma for $4,560 (40% deposit), deposit received, real invoice issued for that $4,560, work starts. Note the ordering. The proforma is what gets the money moving; the invoice is what records that it moved. If your deposit structure is still undecided, net terms, deposits and late fees covers how much to ask for and when.

Which documents are legally binding?

This is general information, not tax or legal advice. Whether any of these documents binds you depends on your jurisdiction and, more than anything, on the words printed on the document itself. For anything with money at stake, ask a local accountant or your tax authority.

With that said, here is the shape most systems land on.

An estimate is typically not an offer. It is an indication of likely cost, and describing it as an approximation with named variables is what keeps it that way. Send an "estimate" that contains one exact figure and no ranges, and you have written a quote with the wrong word at the top.

A quote is typically an offer. If the client accepts it while it is still valid, in many systems that acceptance plus consideration forms a contract at the quoted price. That is precisely why quotes carry expiry dates and exclusions: the expiry limits how long the offer stands, and the exclusions define what the price covers. This is also why the flat claim that "quotes are legally binding and estimates are not" is too strong. A quote does not bind anyone until it is accepted, and what it binds you to is whatever the document says, no more.

A proforma invoice creates no payment obligation of its own. It restates an obligation that the accepted quote or contract already created. Paying it is voluntary in the sense that no debt is enforceable purely because a proforma exists.

An invoice does not create the obligation either, which surprises people. The obligation comes from the contract and the delivered work. The invoice is the demand and the evidence. Its legal weight is evidential and fiscal: it is the record you and your client both rely on. The IRS lists invoices among the supporting documents for gross receipts that a business is expected to keep, alongside cash register tapes, deposit information and receipt books.

The practical takeaway for a solo developer: your real protection is not the label on the PDF. It is a signed scope with an exclusions list. A statement of work does more for you than any of these four documents.

Which of these can a freelancer skip entirely?

Most of them, most of the time.

Keep the invoice. Non-negotiable. It is the accounting record, and it needs the full field set: sequential number, both legal entities, dates, line items, currency, payment instructions. What belongs on a software development invoice is the checklist.

Keep the quote, in writing, always. Not because the law demands it, but because it is the only document that says what is excluded. Scope disputes are the most expensive thing that happens to freelance developers, and they are almost always disputes about a sentence nobody wrote down.

Use the estimate when you genuinely do not know. It buys you the right to say a number without being trapped by it. Skip it when scope is already clear, because sending an estimate you could have quoted just adds a round trip.

Skip the proforma unless a client asks for one. Most small clients will pay a deposit against a quote, or against a line on an invoice, without needing an intermediate document. The proforma earns its place with three kinds of client: companies whose AP system will not raise a purchase order without an invoice-shaped document, clients paying in advance across a border where the bank wants paperwork for the wire, and anyone who needs internal approval before you start.

For our dashboard project, the minimum viable trail is: quote with exclusions, deposit invoice, final invoice. The estimate was useful because the first email was vague. The proforma was useful because that client's AP department needed it. Neither is a rule.

When it is time for the real one, generate it free at billable.dev in your browser. Nothing you type is sent anywhere, there is no account, and the numbering, totals and print layout are handled for you. If you want a document to start from rather than a blank form, the free invoice template for developers has the same structure laid out field by field. Pro is $4/month billed $24 per six months, or $79 once, if you want saved clients and recurring invoices.

FAQ

Can a proforma invoice be paid?

Yes, and that is often the whole point of sending one. A client can absolutely pay against a proforma invoice, and many deposits are collected exactly this way. What the proforma does not do is record the transaction. Once the payment arrives, issue a proper invoice for the same amount, with a real sequential number, and reference the proforma on it so the two documents reconcile. HMRC's guidance is explicit on this sequencing: once you receive payment or supply the service, a proper invoice must follow.

Does a quote expire?

Only if you say it does. A quote with no expiry date is an open offer, and clients do come back six months later expecting the old price while your rates and your availability have moved. Put a validity line on every quote, 14 or 30 days is normal for development work, and treat a late acceptance as a request for a fresh quote rather than an argument. The expiry also does quiet sales work: it gives a stalled thread a natural reason to be revisited without you inventing pressure.

Can I convert a quote into an invoice?

Yes, and it should be close to mechanical. A quote that was written properly already contains the line items, the amounts, the currency and the payment terms. Converting it means adding the things an invoice needs and a quote does not: a sequential invoice number, an issue date, a due date as an actual calendar date, and the removal of anything conditional. What should not change is the price. If the price moved, the correct document is a change order against the original scope, not a quietly larger invoice.

Do proforma invoices get invoice numbers?

No, and this is the single most common mistake. A proforma must not consume a number from your invoice sequence, because that sequence has to be unbroken and every number in it has to correspond to a real accounting document. Use a separate reference series with its own prefix, such as PF-2026-014, so the proforma is trackable without polluting the ledger. When the real invoice follows, it takes the next number in the actual sequence and references the proforma in its notes.