Receipt and invoice emails: the fields customers look for

A receipt email gets opened for a specific reason: someone wants to confirm a charge, forward it to accounting, or check it against their bank statement. Design for that specific task, not for brand impression.

What people actually scan for

• The exact amount charged, in large, unambiguous text near the top
• The date and a transaction or invoice ID, since this is what gets referenced in a support request or expense report
• What was purchased, in plain language, not an internal SKU or product code that means nothing to the customer
• The payment method used (last 4 digits of a card, for example), so it's clear which account was charged
• A clear path to a full invoice or receipt PDF if your product needs one for expense reporting, not just the email body itself

Design for forwarding and screenshots

Receipts get forwarded to finance teams and screenshotted for expense reports constantly. A layout that holds up as a plain-text forward or a cropped screenshot, key information in a simple vertical list rather than a complex multi-column design, serves that real use case better than an elaborate branded template that only looks right rendered in full.

VAT and tax line items for B2B customers

For any EU B2B sale, the receipt or invoice needs the VAT amount broken out separately from the subtotal, the VAT rate applied, and your VAT ID, not just a single all-in total. If reverse charge applies (common for cross-border EU B2B transactions with a valid VAT ID on file), state that explicitly on the document rather than showing a VAT line of zero with no explanation, since an unexplained zero reads as a mistake to whoever's reconciling the invoice.

Attaching a PDF vs. inline HTML only

Many finance teams specifically need a PDF attachment for their own record-keeping systems, an HTML email alone isn't always sufficient even if it contains the same information. Generate the PDF server-side at the same time as the email (a headless rendering library, or a dedicated invoicing service if your billing platform already produces one) and attach it, rather than expecting the customer to print the email itself.

Idempotency for the same charge

Payment webhooks, like carrier webhooks, can redeliver. A retried webhook for the same successful charge shouldn't generate a second receipt email; key the send on the payment or invoice ID and check whether a receipt was already sent for that specific ID before triggering another one.

It's transactional, not a marketing opportunity

It's tempting to use a receipt as a cross-sell moment. Resist it, or keep it minimal and clearly separated from the receipt content itself. A receipt mixed with upsell messaging is harder to scan for the actual information the recipient opened it for, and it's the kind of email people already expect to be short and functional. Violating that expectation costs more trust than the cross-sell is likely worth.