The line in the log
A log says, 'transfer complete.' It may be true, but the line alone may not identify the payer, recipient, amount, authorized request, ledger version, or whether the recipient's balance was read back. Without those links, a later reviewer cannot tell a completed transfer from an optimistic message printed before the write.
A receipt should describe a material operation with enough identity, time, inputs, authorization, output, and correlation to reconstruct what happened. It may also record an unconfirmed effect or a partial failure. Honesty is more valuable than a tidy success word.
A claim tied to an effect
The PHS enforcement standard treats receipt production, persistence, causation, failure, partial effects, reconciliation, and retention as distinct obligations. It explicitly rejects a component's own compliance claim as sufficient evidence. The claims discipline asks us to label what the receipt confirms and what remains inferred.
A receipt can itself be wrong if the service that writes it is defective. Independent readback, hashes, or downstream acknowledgement may be needed for the effect the user cares about. The receipt is a structured witness, not a magic seal.
Pause here: Which identifiers and independent checks would let someone verify the effect without trusting the operator's memory?
Design the receipt before the action
A good design decides in advance where the operation commits and how interrupted work will be classified. If a payment was sent but the confirmation failed, a truthful receipt must make a retry safe rather than invite a second debit. If a message was queued, the record should not pretend it was read.
The difference between a log and a receipt is the difference between hearing a door slam and knowing which door, whose key opened it, and whether it is now secure.
My answer: A receipt is structured, attributable evidence of a bounded operation and its outcome, including uncertainty. A vague log line is not enough for consequential work.