Receipt content must not be rewritten after issue

What it is

Once an order confirmation, purchase receipt, or issued invoice is out, amount, tax id, and line items cannot be rewritten on the original file. Address change, returning a line, issuing a credit, must be a new record (correction, partial-refund receipt, credit note) that cross-references the original. Someone holding an old screenshot must still match that capture. This is not multi-channel lists, and not whether mail and app use the same words—that is channel consistency. This is no tampering in time.

Why it happens

A receipt exists to compare later. If the original mutates, the bank statement, the expense file, and a support promise lose their anchor. If a merchant rewrites display names back onto issued lines, people read substitution. Finance and tax treat “void + new issue” as the legal change; an in-place edit teaches that history can be erased. New records also make responsibility recoverable: who changed what, when, why. Silent overwrite leaves only the latest state; a dispute cannot reconstruct.

Studying it

After issue, change a goods display name, refund a line, change an invoice header. Compare rewriting the PDF in place with a correction that keeps the original. Have people check against the first screenshot.

Independent variables: original still downloadable, correction links the original, display rename written back onto the receipt. Dependent variables: screenshot vs current download, whether expense still accepts the original, whether a dispute can show the change chain.

“The number is correct now” is not immutability—that may be the overwritten number. Ask whether the first issued copy still exists.

Where it stops holding

Unissued drafts (unpaid, uninvoiced) may change. Logistics state and ETA are in-flight fields, not issued money and tax lines. A translated display name may appear on order detail as current name; the receipt PDF should keep the name at issue and note it. Statutory e-invoice credits follow local process; the UI must credit, not edit the original PDF.

Applying it

• Payment success and invoice success each mint an immutable snapshot; download is always that version.
• Refunds, header changes, and line changes mint new records, listed in time on detail, linked to the original.
• Goods renames affect browse, not issued snapshots.
• Verify by renaming an SKU after issue and refunding a line, then downloading original and new record. Original amount and lines are as-then; the new record states the delta. A rewritten original PDF fails.

Related

• Within the group: H7.12.1 E-invoices and purchase receipts serve different legal uses · H7.12.2 Multi-channel orders need one order history · H7.12.4 Confirmations across channels must stay consistent
• Adjacent: H8.06 Version history · H7.07 Refunds and after-sales · H7.05 Order confirmation
• Search terms: immutable receipt · credit note · invoice void