> ## Documentation Index > Fetch the complete documentation index at: https://developers.haia.finance/llms.txt > Use this file to discover all available pages before exploring further. # receipt > Read the receipts build has assembled โ€” list the store, or show one verdict in full. ```sh theme={null} haia-trace receipt list haia-trace receipt show [operation] ``` [`build`](/cli/build) assembles receipts and writes them under the Trace root; these two read them back. `list` answers *what is in the store?* with one line per receipt, and `show` answers *what happened in this operation?* by rendering the stored verdict in full. Both are read-only. A receipt is **derived** from a run's events, so `build` is the only thing that creates one โ€” there is no `receipt new`, unlike [`template new`](/cli/template). To change a verdict, change the template or the events and build again. ## `receipt list` Every receipt in the store, grouped by the run it came from, oldest run first. ```sh theme={null} haia-trace receipt list ``` ```text theme={null} ๐Ÿงพ Receipts run 1721709600000 โœ” op-1 FULL x402-buyer โœ– op-2 PARTIAL x402-buyer run 1721712000000 โœ” op-1 FULL x402-buyer 3 receipts across 2 runs. ``` Each line carries the operation, its verdict, and the template the verdict was assembled against โ€” two receipts in one run can be judged against different shapes, and a verdict means nothing without knowing which. The stages behind the verdict are what `show` is for. Narrow it with either filter: ```sh theme={null} haia-trace receipt list --run 1721709600000 # one run haia-trace receipt list --status partial # only the unresolved operations ``` A `--run` that matches nothing is refused and names the runs the store does hold: it means you asked for something absent, and silence would read as "that run went fine". A `--status` that matches nothing is a real answer about the store, so it prints one and exits 0. An empty store is the state every project starts in, so `list` points at `build` rather than failing. ## `receipt show` With no operation named, the whole of the **most recent** run โ€” the "how did the run I just built go?" question, which needs no ids to hand. ```sh theme={null} haia-trace receipt show ``` ```text theme={null} run: 1721712000000 ๐Ÿงพ x402-buyer ยท op-1 ยท FULL โœ” challenge confirmed โœ” payment confirmed โœ” settlement confirmed operation completed ``` Name an operation for one receipt, and add `--run` to reach an older one: ```sh theme={null} haia-trace receipt show op-2 haia-trace receipt show op-2 --run 1721709600000 ``` The run is printed either way, because it is implicit unless you gave `--run` โ€” and two runs of one program yield receipts with identical operation ids and different verdicts. Unlike `list`, having nothing to show is a **failure**: the caller asked for a verdict and there is none, so an empty store or an unknown operation exits non-zero rather than printing nothing. An unknown operation names what the run does hold. `show` is more than `cat`. An operation id that isn't a bare slug โ€” a URL-ish `context_id` โ€” is escaped into the receipt's file name, so the file is not nameable by hand. Looking a receipt up by the ids it was written under is the only reliable way to it, and it is what both commands do โ€” by reading the directory, so that every lookup can also report any damage it passed over. ## Options | Argument / option | Applies to | Meaning | | -------------------------- | -------------- | ------------------------------------------------------------------------ | | `[operation]` | `show` | Operation to show. Default: every operation in the run. | | `--run ` | `list`, `show` | Which run. Default: every run for `list`, the most recent for `show`. | | `--status ` | `list` | Show only receipts with this verdict. | | `--dir ` | `list`, `show` | Root holding `events/`, `receipts/` and `templates/`. Default: `.trace`. | | `--json` | `list`, `show` | Machine-readable output instead of a terminal rendering. | ## JSON output `list` emits an **index**, not whole receipts โ€” it says what is in the store, so it carries the fields a reader scans or filters on: ```json theme={null} { "receipts": [ { "run": "1721709600000", "operation": "op-1", "path": ".trace/receipts/1721709600000~op-1.json", "completeness": "full", "template": "x402-buyer" } ], "unreadable": [] } ``` An entry in `unreadable` carries the `run` and `operation` its file name records alongside the `path` and the `reason`, so a consumer can tell whether the damage is in the run it just built or in an old one kept as evidence. That index carries the `completeness` an agent decides on, so a spend policy can read the store through one command rather than globbing the directory and re-deriving how receipts are named. `show --json` emits the full [Receipt](/concepts/operation-receipt) objects as `{ run, receipts, unreadable }` โ€” the same shape whether or not you named an operation, so a script consuming it never has to branch on the argument count. A file in `receipts/` that cannot be parsed โ€” truncated mid-write, hand-edited, written by an older CLI โ€” is **reported**, not skipped: on stderr in every case, and in the `unreadable` array of both commands' JSON. A store that is partly damaged must never present as intact, so this holds even when a query is refused, and a run whose receipts are *all* unreadable is still counted as the most recent run rather than passed over for an older one. Files the CLI didn't write are passed over in silence. The warning goes to **stderr**, never stdout. It is a diagnostic about the store rather than part of the answer, so `receipt list --json | jq .` stays valid with a damaged file present, and `receipt show --json > out.json` still shows the damage on your terminal.