What makes a receipt valid
A receipt is a document acknowledging that payment has been received. To be valid for accounting, tax, or expense reimbursement purposes, it should include: the name and contact info of the seller, the name of the buyer (or "cash" for anonymous retail), the date of the transaction, an itemised list of what was sold, the total amount, the payment method, and a unique receipt number for the seller's records.
In most jurisdictions, the seller is legally required to issue a receipt on request. In the EU and UK, retail receipts must include VAT registration number and the VAT amount. In Japan, all business receipts above ¥30,000 require detailed counterparty information. In the US, no federal requirement exists for receipt formatting — state laws and IRS substantiation rules govern what auditors expect.
- Required: seller name + address, date, itemised description, total, payment method, receipt number.
- EU/UK retail: must include seller VAT number and the VAT amount on each line.
- US business: IRS Pub 463 requires substantiation — date, place, business purpose, names of attendees for meals/entertainment.
- Japan: receipts above ¥30,000 must include counterparty details for tax purposes.
- Universal: a unique number for the seller's records helps audit trail. The generator above auto-numbers REC-XXXX.
Receipt vs. invoice — which one to use
An invoice asks for payment; a receipt confirms payment was received. The same transaction can have both — you issue an invoice when work is delivered, and a receipt when payment lands. Many small businesses skip the receipt step entirely and just mark the invoice "paid" on their copy — that's legally fine in most jurisdictions, but the buyer often wants a receipt for their own records.
When the buyer is a corporate expense reimbursement scheme (employee buying lunch with a company card), they almost always require a separate receipt — the invoice doesn't suffice because corporate AP wants to see the payment confirmation, not the request for payment.
Use this generator when: a buyer asks for a receipt; you took cash payment that needs documentation; you sell physical goods; you operate a service business and want to provide closure to each transaction.
- Invoice: sent before payment. Specifies amount due, due date, payment terms.
- Receipt: sent after payment. Specifies amount received, date received, payment method.
- Both: corporate reimbursement schemes often want both; small B2C transactions only need a receipt.
- Cash transactions: always issue a receipt — it's the only audit trail for cash payments.
Receipt formatting that gets accepted
Most expense reimbursement systems are extremely picky about receipt format. The most common reasons receipts get rejected: missing the seller's full name (just "Joe's" isn't enough — they want "Joe's Cafe LLC, 123 Main St, San Francisco, CA"); missing date; total doesn't match payment confirmation; or it's clearly altered (handwritten edits, missing line items).
For B2B receipts to corporate buyers, the safest format is: company letterhead at top, "RECEIPT" in clear bold text, both parties' full legal names + addresses, itemised line items with quantities and unit prices, subtotal + tax (if applicable) + total, payment method ("Card ending 4242", "Wire transfer", "Check #1029"), date of payment, and the seller's signature or a printed receipt number.
The generator above produces all of this automatically when you enter the details. The PDF output looks professional enough to pass any corporate AP audit. For physical retail receipts (CVS-style), the formatting is different — but those are typically POS-printed, not generated by tools like this one.
- Always include: full legal names of both parties, full addresses, ISO date.
- Payment method specifics: "Card ending 4242" beats "Card"; "Check #1029" beats "Check".
- Avoid handwriting: corporate AP rejects handwritten edits. Generate a fresh receipt instead.
- Match payment confirmation: total on receipt must exactly match the bank/card statement amount.
Multi-currency receipts and FX
When you receive payment in a currency different from your accounting base currency, the receipt should show the *transaction* currency (what the buyer actually paid in), not your base currency. This is what corporate AP and tax authorities expect to see. Your accounting system handles the FX conversion separately for reporting purposes.
If you accept multiple currencies (USD primary, EUR for European clients), generate the receipt in the currency the client actually paid. The exchange rate at time of payment is what your bank used; record it in your accounting books, not on the receipt itself. Don't issue a receipt that says "€1,000 = $1,080" — that creates ambiguity and is non-standard.
- Receipt currency: always the transaction currency, not your base currency.
- FX gain/loss: recorded in your accounting system, not on the receipt.
- Multi-currency operations: use a separate receipt template per currency to avoid confusion.
- Refunds: always in the original transaction currency, regardless of FX moves since.
Anti-fraud — what auditors flag
This receipt generator is for legitimate businesses documenting real transactions. We log every generation server-side and the receipts include a small footer attributing the source. The information here is for awareness — the same red flags that make our generated receipts look credible also let auditors detect fakes.
Auditors flag receipts that: (1) have no consistent numbering pattern across a buyer's submissions, (2) use round-number amounts (always $50.00 instead of $47.32), (3) lack itemisation, (4) have inconsistent fonts/formatting within a single receipt, (5) match each other in template too closely (clearly the same generator across multiple "vendors"), (6) lack VAT/tax line items where they should appear, or (7) come from sellers without verifiable web presence.
If you're generating legitimate receipts for legitimate transactions, none of this matters — your receipts will look exactly like every other small business's receipts, because they are. The points above are useful only as a sanity check that your output looks credible.
- Round numbers raise flags: real transactions are messy. $47.32 reads as legitimate; $50.00 reads as suspicious.
- Itemise everything: "Consulting" is suspicious; "8 hours of consulting at $120/hr = $960" is credible.
- Verifiable seller: a real business has a domain, a phone, a real address. Receipt should show all three.
- Consistent numbering: all your receipts to the same buyer should have sequential or pattern-matching numbers.