Receipt and Invoice Email Templates You Can Copy Today
A receipt email template confirms a payment that has already cleared, gives the buyer a durable record they can file or forward, and makes the next step obvious — usually "here is your download" or "here is how to get help." An invoice email template does the opposite job: it asks for money that has not arrived yet, so it leads with the amount due, the due date, and a payment link. Because they are system emails, they must render reliably and carry no promotional content.
What a receipt email has to do (and what it must not)
The job is narrow. Confirm the charge, state the amount and the payment method, provide a reference number support can trace, and attach or link a document the buyer can keep. Leave out upsells, newsletter signup prompts, and social follow requests — they belong in campaigns, not in a payment record.
Three constraints follow from this being a system email:
- It must render with images off. Some email clients block images by default. If your line-item table is a screenshot, readers with images blocked will see nothing.
- It must be readable without the PDF. The attachment is a record, not the message. Someone reading on a phone at a checkout counter should get the total from the email body alone.
- It is transactional. Genuine receipts and invoices generally do not carry unsubscribe links or promotional footers the way a campaign does. That does not exempt you from consent and record-keeping rules where you operate — check the requirements that apply to your jurisdiction and your payment processor's terms.
A receipt is sent after the charge settles. An invoice is sent before payment is due. Mixing them — sending an invoice that looks like a receipt, or a receipt that asks for money — is the most common structural mistake, and it is worth keeping them as separate templates from day one.
Template 1: Payment receipt with line items and tax breakdown
Subject: Your receipt for order {{order_number}} — {{total_amount}}
Preview text: {{item_count}} item(s), paid with {{card_brand}} ending {{card_last4}}.
Hi {{first_name | "there"}},
Thanks — your payment went through. Here is your receipt.
Order {{order_number}}
Date: {{payment_date}}
Payment method: {{card_brand}} ending {{card_last4}}
Transaction ID: {{transaction_id}}
--------------------------------------------------
Description Qty Unit Amount
--------------------------------------------------
{{item_name}} {{qty}} {{unit_price}} {{line_total}}
{{item_name}} {{qty}} {{unit_price}} {{line_total}}
--------------------------------------------------
Subtotal {{subtotal}}
Discount ({{discount_code}}) -{{discount_amount}}
{{tax_label}} ({{tax_rate}}) {{tax_amount}}
Total {{total_amount}} {{currency}}
--------------------------------------------------
Your invoice PDF is attached, and you can also download it here:
{{invoice_pdf_url}}
Questions about this charge? Reply to this email or contact
{{support_email}} and quote {{transaction_id}}.
{{company_name}}
{{company_address}}
{{company_registration_number}}
Adapt this when:
- Multi-currency orders. Put the ISO currency code next to every amount, not just the total. "49.00" is ambiguous; "49.00 EUR" is not.
- Tax-inclusive regions. For EU B2C sales, state that prices include VAT and show the rate. For US sales, show the jurisdiction — "Sales tax (CA)" reads very differently from "Tax."
- Marketplaces. Name the seller of record explicitly, because the buyer's card statement may show a different entity than the storefront they bought from.
Build the itemized table with real <table> markup or a block editor's column blocks. Table-based markup is the safest choice for email clients that handle CSS layout inconsistently, and a collapsed receipt table is worse than no table.
Template 2: Invoice email with due date and payment link
Subject: Invoice {{invoice_number}} — {{amount_due}} due {{due_date}}
Preview text: Billing period {{period_start}}–{{period_end}}. Pay online in one click.
Hi {{first_name | "there"}},
Invoice {{invoice_number}} is ready. The amount due is
{{amount_due}} {{currency}}, payable by {{due_date}}.
Invoice number: {{invoice_number}}
Issue date: {{issue_date}}
Due date: {{due_date}}
Billing period: {{period_start}} – {{period_end}}
[ Pay {{amount_due}} now ]
{{payment_link}}
--------------------------------------------------
Description Qty Unit Amount
--------------------------------------------------
{{item_name}} {{qty}} {{unit_price}} {{line_total}}
--------------------------------------------------
Subtotal {{subtotal}}
{{tax_label}} ({{tax_rate}}) {{tax_amount}}
Total due {{amount_due}} {{currency}}
--------------------------------------------------
Prefer bank transfer?
Account name: {{bank_account_name}}
IBAN: {{iban}}
Reference: {{invoice_number}}
Buyer tax ID: {{buyer_tax_id}}
Seller registration: {{company_registration_number}}
Questions? Contact {{billing_email}}.
{{company_name}}
{{company_address}}
Adapt this when:
- B2B cross-border. Show the buyer's VAT or tax ID and the seller's registration number. If the reverse charge applies, say so on the tax line rather than leaving it blank.
- Recurring billing. State the billing period in the body, not only in the PDF. Subscription customers ask "what am I paying for this month?" and the email should answer it.
- Late payment. Do not fold a reminder into the first send. A separate reminder template, sent after the due date, keeps the original invoice clean as a record.
Put a text URL under the pay button. Some clients strip or fail to render buttons, and an invoice with no visible payment path is a support ticket waiting to happen.
Template 3: Refund and credit note confirmation
Subject: Refund of {{refund_amount}} for order {{order_number}}
Preview text: Reference {{transaction_id}}. Credit note {{credit_note_number}} attached.
Hi {{first_name | "there"}},
We have issued a refund for order {{order_number}}.
Original transaction: {{transaction_id}}
Refund amount: {{refund_amount}} {{currency}}
Refunded to: {{card_brand}} ending {{card_last4}}
Reference: {{refund_reference}}
Remaining balance on this order: {{remaining_balance}} {{currency}}
{{#if credit_note_number}}
A credit note ({{credit_note_number}}) is attached for your records.
{{/if}}
Refunds are processed by your bank or card issuer, and the time it
takes to appear on your statement is set by them. If you have not
seen it after {{processor_window}}, contact {{support_email}}.
{{company_name}}
Adapt this when:
- Partial refunds. Always show the remaining balance. A refund email that omits it invites a follow-up question.
- Tax adjustments. If the refund reverses a taxed charge, include the corrected tax line and the credit note number.
- Timing language. Do not promise a specific number of days unless your payment processor's own documentation states it. Point to the processor's window instead.
Line items, tax details and the PDF attachment
These three details are a common source of support questions, so treat them as a unit.
Line items. Four or five columns maximum: description, quantity, unit price, amount. Right-align every numeric column and use tabular figures so the decimal points line up. If a table can run long, repeat the header row on each page or section.
Tax. Show the rate and the jurisdiction, not just a total. Never compute tax inside the email template — pull the final numbers from your billing system so the email and the PDF cannot disagree. That single rule prevents the most embarrassing failure mode in this whole category: a receipt that says one total and an attached invoice that says another.
The PDF. Attach it and link to a hosted copy. Attachment size limits and spam filtering vary by provider, and a link survives forwarding better than a file. Name files predictably — invoice-2026-0417.pdf, not document1.pdf — because accountants and finance teams search by filename. Generate the PDF server-side from the same data object that renders the email.
This is where you would wire up a transactional send. Mailerflow's transactional email API sends on a high-priority lane with templates and variables, and the REST API supports idempotency keys — which matters here specifically, because payment webhooks retry. Without an idempotency key, a retried payment.succeeded event produces a second receipt for the same charge. The developer docs cover scoped keys, the OpenAPI spec, code samples and the JS SDK.
Subject lines and preview text that pair with these templates
| Template | Subject line | Preview text |
|---|---|---|
| Receipt | Your receipt for order 48213 — 128.40 EUR | 3 items, paid with Visa ending 4242 |
| Receipt | Payment received: 49.00 USD for Pro plan | Transaction ID 9f2c…a71. Invoice attached. |
| Receipt | Order 48213 confirmed — download ready | Your files are available now. |
| Invoice | Invoice INV-2026-0417 — 2,400.00 USD due 30 Nov | Billing period 1–31 Oct. Pay online in one click. |
| Invoice | INV-2026-0417 is ready | Amount due 2,400.00 USD, payable by 30 Nov. |
| Refund | Refund of 49.00 USD for order 48213 | Reference 7b31…c02. Credit note attached. |
| Refund | We have refunded order 48213 | 49.00 USD back to Visa ending 4242. |
Receipts get opened because the reader is looking for a number, so put the number in the subject. Invoices get opened because the reader owes something, so put the due date there. Preview text should extend the subject rather than repeat it — if the subject carries the amount, the preview carries the payment method or the period. Avoid promotional phrasing in both; a genuinely transactional message should not read like a discount blast.
Personalizing system emails without breaking them
Every placeholder needs a fallback. A receipt that opens with "Hi ," looks broken, and a broken-looking receipt makes the reader doubt the payment record itself. Guest checkouts are the usual culprit, because there is no first name to merge.
Variables worth having: first name (with fallback), order or invoice number, amount, currency, due date, payment method, transaction reference, support email, and the hosted PDF URL. Variables to avoid: anything that can legitimately be empty — company name for consumer orders, tax ID for non-business buyers, discount code when no discount applied. Wrap those in conditional blocks instead of printing blanks. For example, use {{first_name | "there"}} so a missing name falls back to a neutral greeting, and wrap the discount line in {{#if discount_code}}…{{/if}} so it disappears entirely when no code was used.
If you are building the layout from scratch, Mailerflow's visual block editor and reusable templates let you define one receipt structure and swap content per event, and the AI email builder can draft a responsive design, subject lines and preview text from a description. If you are also handling account emails, the fallback patterns in these password reset templates transfer directly.
Mistakes that make receipts and invoices fail
- Sending the receipt before settlement. An authorization is not a payment. Send on the settled event, not the authorized one.
- Mismatched totals. Email and PDF must render from one data source. If they can drift, they will.
- Missing tax lines. A total with no rate and no jurisdiction is not a usable record for a business buyer.
- Oversized attachments. Large PDFs get stripped or filtered. Keep the file lean and always provide the hosted link.
- No plain-text alternative. Some recipients and some corporate gateways read text only.
- Essential information inside images. A logo is fine; a total is not.
- No transaction reference. Support cannot trace a charge without one.
- Duplicate sends. Retried webhooks are the usual cause. Use idempotency keys.
- Campaign tooling for transactional mail. An unsubscribe footer on a receipt confuses recipients and can suppress the message entirely.
- Assuming the recipient is the buyer. Receipts get forwarded to accountants and expense systems, so the email should stand alone without the surrounding app context.
FAQ
Should a receipt be a PDF attachment or an inline HTML email? Both, for different reasons. The HTML body is what the buyer reads immediately, including on a phone with images blocked. The PDF is what gets filed, forwarded and reimbursed.
Can I send receipts and invoices from the same domain as my marketing email? Technically yes, but separate subdomains are often recommended for transactional and marketing traffic because it isolates reputation. Check your provider's setup guidance for the exact DNS records.
Do receipts need an unsubscribe link? For genuine transactional messages, generally no. Confirm against the rules that apply to you and your recipients' jurisdictions before deciding.
How do I stop duplicate receipts when a payment webhook retries? Use idempotency keys on the send request, keyed to the payment or event ID. A retried event then resolves to the same send instead of a new one.
How long should I keep the hosted copy of an invoice? It depends on your jurisdiction's retention rules and, for tax documents, often several years. Confirm with your accountant rather than guessing.
Send your first transactional email with the Mailerflow REST API — scoped keys, idempotency and an OpenAPI spec. Start free.


