E-invoices and purchase receipts serve different legal uses

What it is

The confirmation on the success page proves “you bought, money moved.” An e-invoice is the statutory document for tax and expense: buyer name, tax id, invoice codes—not the same object as a purchase receipt. One “download receipt” action makes finance reject the file, or people treat a legally empty success screenshot as an invoice. This is the split between two documents, not how channels collapse into history, and not whether the live confirmation has a cancel control.

Why it happens

A purchase receipt serves check and after-sales: order id, SKU, amount captured. An invoice serves compliance: buyer legal name, tax id, rates, issuer seal. People often do not know the expense header at order time, or they buy personally and need a company invoice, so invoicing is often later. If the UI has one “download receipt” act, the two needs collide: finance wants an invoice PDF, support wants an order id. States differ too: paid is not invoiced; invoiced is not void-and-reissue. Unsplit, people mash download before issue, or mail a printed order detail as an invoice.

Studying it

Have someone who must expense complete an order. Compare success page only, success plus order PDF, a separate invoice entry and state. Watch what they hand “finance.”

Independent variables: invoice entry separate from confirmation, header collected, invoice state visible. Dependent variables: file type submitted for expense, rejection for wrong document, duplicate requests before issue.

Labs have no real finance; use role-play or a real expense-rule checklist. Invoice regimes differ widely; the measure is “did the UI make them take the right document,” not one country’s tax code.

Where it stops holding

Markets that do not issue invoices (card statement only) should not grow an invoice flow—that is a false promise. Digital goods and small cross-border amounts may be unable to issue a local invoice; say so before buy. One order into many invoices, or many orders into one, is an invoicing rule; the UI must follow it, not default to one-to-one and fail after submit.

Applying it

• Order detail lists two objects, “purchase receipt” and “invoice,” each with state (not issued / issuing / issued).
• Collect legal name and tax id, preview the face, then submit; the downloaded filename matches the document type.
• Do not label an order PDF as an invoice before issue.
• Verify by completing an order and “handing it to finance”: invoice or success screenshot. Then ask where the order id lives for after-sales. One button serving both needs fails the split.

Related

• Within the group: H7.12.2 Multi-channel orders need one order history · H7.12.3 Receipt content must not be rewritten after issue · H7.12.4 Confirmations across channels must stay consistent
• Adjacent: H7.05 Order confirmation · H7.07 Refunds and after-sales · S3.06 Regional legal requirements on the interface
• Search terms: e-invoice · purchase receipt · fapiao