Estimate, Invoice, or Receipt? Which Document to Send and When

Three documents, three different jobs. Most small businesses use two of them and improvise the third — usually by sending an invoice when a receipt was needed, or a receipt when nothing had been paid yet.

The difference matters more than it sounds. Each document does something different to your books, and sending the wrong one either leaves money uncounted or counts it twice.

Here's what each one is, when to send it, and how to tell which you need.

The short version

An estimate is a price you're offering. Nothing is owed yet.

An invoice is a request for payment. Money is owed and not yet received.

A receipt is proof of payment. Money has already changed hands.

They map to the three stages of a sale — before, during, after. If you can say which stage you're at, you know which document to send.

The estimate: a price, not a promise

An estimate goes out before any work starts. Some businesses call it a quote or a proposal. The name doesn't matter to your books — what matters is that it carries no obligation on either side.

The customer hasn't agreed to pay. You haven't agreed to be paid. Nothing has moved.

That's why an estimate should never appear in your revenue. If a quote for $4,000 shows up in your profit figure before the customer accepts it, your books are telling you about money that may never exist. A tradie quoting five jobs a week would be looking at a wildly inflated set of numbers by month end.

Send an estimate when:

• The customer asked "how much?"
• The scope is agreed but the work hasn't started
• The price needs approval from someone else before you begin

An estimate should carry an expiry date. Materials prices move, your availability moves, and an accepted quote from four months ago is a problem you don't need. Thirty days is standard.

The other thing worth doing: get the acceptance in writing. Not because you're expecting a dispute — because "you said two grand" and "I quoted two grand plus materials" is the most common small-job argument there is, and a dated acceptance ends it in one line.

The invoice: money owed

An invoice is the document that creates a debt. Once you send it, the customer owes you, and that amount sits in your accounts receivable until it's paid.

This is the point where the sale enters your books. Not when the estimate went out. Not when the money arrives. When the invoice is issued.

That trips people up, and it's worth sitting with for a second: your profit and your bank balance are not the same number, and the invoice is where they part ways. You invoice $6,000 in March, get paid in April. March's profit shows $6,000. March's bank account doesn't. Both are correct — they're answering different questions.

Send an invoice when:

• The work is done, or the agreed milestone is reached
• You've delivered goods and payment is on terms
• A deposit is due before you start

An invoice needs a due date, and the due date needs to be a date, not a duration. "Net 30" printed alone is an invitation to interpret. "Due September 15" is not. If you're not sure what terms to set, we've written about picking between Net 7, 15, and 30 — the short version is that most small businesses inherit Net 30 without ever deciding on it.

If you're sending an invoice for the first time, there's a full breakdown of what belongs on it — and, just as usefully, what to leave off.

The receipt: proof it's settled

A receipt confirms money has been received. It's issued after payment, and it's the only one of the three that looks backwards.

Here's where the confusion usually starts, because there are two different documents that both get called a receipt.

A payment receipt acknowledges payment against an invoice you already sent. Invoice first, payment second, receipt third. It's the paper trail that closes the loop, and it's what a customer asks for when they need proof for their own books.

In Papertools every payment receipt carries the invoice number it settles, so the link between the two is never guesswork.

A sales receipt covers a sale where payment happened immediately and no invoice ever existed. Someone walks in, buys something, pays on the spot. There was never a moment where money was owed, so there was never anything to invoice.

The distinction matters because of what each one does to your accounts. A payment receipt clears an existing debt — the sale was already counted when you invoiced. A sales receipt records the sale and the payment at once, because nothing had been recorded yet.

Send a sales receipt when the customer pays on the spot. Send a payment receipt when they're settling an invoice.

Get this backwards and you'll double-count. Issue an invoice, then issue a sales receipt when they pay, and you've now recorded the same sale twice — once as a receivable, once as a fresh sale. Your revenue looks better than it is, your receivables never clear, and at tax time you're paying on income you never earned.

The one that catches people: deposits

A customer pays half up front. What do you send?

Not a sales receipt — there's an invoice coming for the balance, and recording a standalone sale now would mean counting the job twice.

The clean approach is an invoice for the deposit, then a payment receipt when it's paid, then a second invoice for the balance at completion. Two invoices, two receipts, one job. Every stage has its own document and nothing gets counted twice.

It feels like more paperwork than it is. Each document takes under a minute if your customer and items are already saved.

What this won't fix

None of this helps if the underlying agreement is vague. A perfectly structured estimate for badly defined work still ends in an argument about what "supply and install" included.

It also won't make anyone pay faster. A correct receipt doesn't collect a debt — that's what payment terms and a reminder sequence are for. Documents record what happened; they don't change it.

And it won't rescue books that were never kept. If sales have been going in as one lump each month with no document trail, getting the document types right from here is good, but it doesn't reconstruct what came before.

Quick reference

How Papertools handles it

Papertools keeps these as four separate document types, each with its own numbering sequence — EST-, INV-, SR-, and PR- — so you can tell at a glance what any document is.

An accepted estimate converts to an invoice in one click, carrying the line items across, so there's no retyping and no chance of the quoted price drifting on the way through. The estimate guide covers the whole flow.

When a payment lands, recording it against the invoice generates the payment receipt and clears the balance from your receivables automatically — including partial payments, which handles the deposit case without any of the manual tracking.

The double-counting problem mostly solves itself, because sales receipts and invoices are different objects rather than the same document with a different label on it.

Where to go next

• How to Write an Invoice (What to Include and What to Leave Off) — the anchor piece for this cluster
• Invoice Payment Terms: Should You Use Net 7, 15, or 30? — picking a due date that suits your cash cycle
• How to Number Invoices — why each document type gets its own sequence
• Send your first invoice — the step-by-step in Papertools