The two documents sit either side of the same event. An invoice is issued before the money moves and asks for it. A receipt is issued after and confirms it arrived.
Simple enough as a sentence. Invoice vs receipt goes wrong constantly in practice, though, because the same transaction produces both, they carry nearly identical information, and plenty of software calls one by the other’s name.
What each one is for
An invoice is a demand for payment. It creates a receivable in your books and, in most jurisdictions, a tax point. It is the document your client’s accounts payable works from, and the document you cite when payment is late.
A receipt is proof of payment. It creates no receivable, because the receivable it relates to has just been cleared. It is the document your client keeps for their expense records and their own tax deduction.
The practical test: if the money has not moved, it is an invoice.
Side by side
| Invoice | Receipt | |
|---|---|---|
| Issued | Before payment | After payment |
| Says | This is owed | This was paid |
| Creates a receivable | Yes | No |
| Creates a tax point | Usually yes | No, the invoice already did |
| Client uses it to | Approve and pay | Claim the expense |
| You use it to | Chase the debt | Close the debt |
| Numbering | Sequential, unbroken | Own sequential series |
Both need their own unbroken number series, kept separate from each other. Why that matters, and what a gap in a sequence costs you at audit, is in how invoice numbering works.
Why sending the wrong one is expensive
Three failures, in rough order of how often they happen.
A receipt read as an invoice, and paid twice. The most costly. You send a receipt confirming payment, it looks like every other document you send, and it lands in an accounts payable queue that processes documents rather than reading them. Now you owe a refund and the relationship has a small hole in it.
An invoice read as a receipt, and never paid. The mirror image. The client files it as confirmation of something already settled, and the debt ages quietly until you chase it. By then the conversation starts with confusion rather than with the due date, which is a much worse place to begin. The sequence that recovers this without damaging the relationship is in what to do when an invoice is not paid.
A receipt issued without an invoice ever existing. Money arrived, you confirmed it, and there is no tax document underneath. This is the one that surfaces at filing rather than at the time, and it is common when payment comes in against a proforma invoice that nobody converted.
The label at the top of the page is doing real work. It should be unmistakable and it should be the largest thing on the document.
What has to be on each
An invoice needs enough for the client to pay it and for both tax authorities to accept it. That means your legal name and registration details, theirs, a unique sequential number, and the issue and due dates. Then an itemised description, the amounts before tax, the tax rate and amount, the total, and how to pay. The full list, and the fields people leave off, is in how to write an invoice.
A receipt needs less, but the two fields that matter most are the ones most often missing: which invoice it settles, and how much of it. A receipt for a partial payment that does not say it was partial will be read as settling the whole thing.
Include the payment date, the method, the amount received, and the invoice reference. Everything else is convenience.
Partial payments, deposits, and the messy middle
Real transactions rarely produce one invoice and one receipt.
A deposit is usually a payment against a proforma or against the first invoice in a plan. It produces a receipt for the amount received, and the balance stays open. What it must not do is close the invoice.
A partial payment produces a receipt for what arrived and leaves the invoice open for the remainder. If your system only understands paid and unpaid, this is the case that breaks it, and it is one of the reasons matching payments to invoices is harder than it looks.
One transfer settling several invoices produces one incoming payment and several receipts, or one receipt referencing several invoices. Either is defensible. Deciding once and being consistent is what makes the reports mean anything later.
A refund is not a receipt in reverse. If the invoice itself was wrong, the instrument is a credit note, which corrects the document rather than recording a movement of cash.
Where the receipt actually comes from
For most service businesses the receipt should not be typed at all. It should be produced by the payment landing.
That means the bank feed has to reach the invoice, so that a transfer arriving on Tuesday can settle a specific document rather than a category. When bank transactions link to the invoice or receipt they belong to, the receipt stops being a document you remember to send and becomes a consequence of the money moving.
It also means the client should be able to find both without asking. Most “can you resend that” email exists because the documents live in an inbox rather than somewhere the client can reach, which is what a customer portal is for.
Where this sits in the wider chain
Invoice and receipt are the last two documents in a longer path: an agreement, a scope, a price, a document that asks, a payment, a document that proves. That path and the four places money leaks out of it is the contract-to-cash workflow.
For recurring work both documents are produced twelve times a year, which is exactly when doing it by hand stops being viable. A billing schedule issues the invoice on a cadence, and scheduling the invoice itself removes the last manual step.
Enlivy keeps the invoice, the receipt and the bank line as one record, sold as separate packs. You can start free.
If you are comparing this against a bookkeeping-first tool, the write-ups on QuickBooks, Wave and Xero cover where each of them stops.