Proforma Invoice vs Quotation vs Estimate vs Invoice

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. If you want a repeatable way to build that range, how to estimate a software project walks through it, and paid discovery covers charging for the session that closes the open questions.

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 the terms, and how much deposit to charge covers the percentage.

Proforma invoice vs quotation: what is the difference?

Vocabulary first. A quote and a quotation are the same document. "Quotation" is the formal word, and it is the one printed on British, Indian and export paperwork. "Quote" is what most US clients and most invoicing software say. Nothing below changes depending on which word sits at the top of the page.

The difference between a quotation and a proforma invoice is what you are asking the client to do. A quotation asks for a decision: here is the scope and the price, accept it or do not. A proforma invoice asks for a payment or an approval: the price is already agreed, and here is an invoice-shaped document your finance team can act on. The contents overlap almost completely. The timing and the request are what change.

	Quotation	Proforma invoice
Sent	While the client is still deciding	After the client has said yes
Asks for	Acceptance	A deposit, a purchase order, or internal sign-off
Laid out like	An offer or proposal	An invoice
Price still open to negotiation	Yes, that is the point of it	No, it restates what was agreed
Carries exclusions and assumptions	Yes, and it should	Rarely, there is no room for them
Shows bank and payment details	Optional	Yes
Reference style	Its own series, such as Q-2026-031	Its own series, such as PF-2026-014
Goes in your books	No	No

In the dashboard project, the $11,400 document with the exclusions list was the quotation. The $4,560 document the client's AP department asked for was the proforma invoice. Same project, same price, same line items. One went out before the yes, and one went out after it.

The two documents are close relatives, which is why they get mixed up. The US International Trade Administration describes a pro forma invoice as "a quote in an invoice format" that a buyer may need in order to apply for an import license, open a letter of credit or arrange a transfer of hard currency. The same guidance says pro forma invoices contain much of the same information as a formal quotation "and in many cases can be used in place of one". That is the export-trade origin of the proforma: when a buyer's bank or customs authority needs something that looks like an invoice before any goods move, the seller issues the quotation in invoice layout.

Can one document do both jobs?

In export sales, often yes. That is exactly what the trade guidance describes.

For development work, keep them separate, for one practical reason. A quotation needs room for things an invoice layout has no place for. The exclusions list, the assumptions, the expiry date and the line about how changes get priced are what protect you, and they get squeezed out when the document is shaped like a bill. A proforma that silently drops the exclusions is how scope creep starts with paperwork that looks official.

So send the quotation first. Once it is accepted, the proforma takes two minutes, because every figure on it is copied from the quote.

If a client asks for a "proforma quote", they nearly always mean one of two things: a quotation they can show their finance team before deciding, or a proforma invoice so they can pay a deposit. Ask which. The first is a decision document and the second is a payment request, and sending the wrong one costs a round trip.

What goes wrong when you send the wrong one?

• A proforma before the client has agreed. It reads as a bill for something nobody ordered, and it arrives without the exclusions that make the price safe to accept.
• A quotation when AP needs an invoice-shaped document. Accounts payable systems match on invoice fields: supplier details, a document reference, an amount due, payment instructions. A two-page proposal PDF sits in a queue until someone asks you to resend it in the right shape.
• A real invoice where a proforma belonged. You have used a number from your sequence and booked revenue for work that has not started. If the project is cancelled, you now have to void or correct an invoice you already sent, which is more paperwork than the proforma would have been.

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. The cross-border case comes up more than developers expect, and invoicing international clients covers the rest of that paperwork.

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

Is a proforma invoice the same as a quotation?

No, though they carry nearly the same information. A quotation is an offer the client can still accept, negotiate or decline. A proforma invoice is issued after the offer is accepted, in invoice layout, so the client can pay a deposit or get the spend approved. In export trade the two are sometimes merged into one document, because the buyer's bank needs an invoice-shaped quotation. For service work, the quotation comes first and the proforma follows it.

Is a quote the same as a quotation?

Yes. They are two names for one document: a specific price for a defined scope, offered for a limited time. "Quotation" is the more formal term and the usual one outside the US. An estimate is the different animal, because it gives a range and commits you to nothing.

Should I send a quotation or a proforma invoice first?

The quotation, every time. A proforma invoice restates a price that has already been agreed, so there has to be an agreed price to restate. The order for a project that uses all of them is estimate, quotation, proforma invoice, invoice, and most projects skip the first and the third.

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.