The sequence is what makes this concrete. You deliver work, you issue an invoice stating what is owed and when, the customer pays, and you issue or their system generates a receipt confirming the payment. Two documents describing the same transaction at two different moments, and a business customer frequently needs both because their accounts payable process requires the first to authorise payment and the second to close it.

An invoice needs specific elements to function. A unique number, the date issued, your business name and contact details, the customer name and their details, a clear description of what is being charged for, the amount, any tax stated separately, the total, the payment terms, and how to pay. Missing any of those gives a business customer's system a reason to reject it, and rejection usually means silence rather than a request for correction.

The unique number matters more than it appears. It is how both parties reference the transaction, it is what your accounting software uses to match a payment to a sale, and it is what an examiner expects to see running in sequence. Numbers that repeat, skip erratically, or restart are a genuine problem at tax time.

A receipt is simpler and needs to state that payment was received, when, how much, and for what. If you take card payments the processor generates one automatically, which is sufficient. For bank transfers and cash you should issue one yourself, because the customer needs it for their records and the absence looks careless.

Consumer businesses frequently need only receipts, and business to business work almost always needs invoices. If you sell to the public at the point of service, an invoice adds a step nobody wants. If you sell to companies, an invoice is how their process begins, and providing only a receipt means asking somebody to construct paperwork you should have supplied.

The related item worth knowing is a quote or estimate, which is neither. It describes what work would cost before anybody has committed, it creates no obligation to pay, and it should say clearly that it is a quote rather than an invoice. Businesses that send a quote formatted as an invoice cause confusion in both directions.

Keep both for the retention period your records require, which is generally at least three years and longer for anything you might need to substantiate. Your accounting software stores them if payments and invoices are matched properly, and the discipline that matters is issuing them at the time rather than reconstructing later.

Then ask a new business customer what their invoice needs to contain, because larger organisations frequently require a purchase order number or a specific reference, and an invoice missing it will not be processed. That question takes one message and prevents a month of wondering why nothing arrived.

Send the invoice as a PDF attachment rather than as text in the body, since business systems expect a document they can file and a message containing figures cannot be processed by anybody's accounts payable software. Most accounting tools generate one automatically, which also handles the numbering and the record.

Include the payment link in the invoice itself rather than in the covering message, because the document is what gets forwarded internally and the message is what gets deleted. Somebody approving payment three days later should be able to act from the attachment alone.