List Autopost Decisions

The expense claim a receipt hold has already become (Lane B, F2778; C2b).

Read-time join expense_claim_line.receipt_item_id → expense_claim - the decision itself carries no claim. Present only on a held expense:receipt: row whose document is on a claim line; the sentence "became expense claim N - approve it in Payroll → Expenses" needs exactly these three facts.

Typed projection of a HELD coding proposal (ZET-75).

Lifted by the router only while outcome=held and the payload is a coding kind — code (invoice coder) or bankcode (bank coder) — what a reviewer needs to judge the booking (lines, dates, currency), not the raw replay payload (which stays internal and also survives on accepted rows). document_no and has_recognition are invoice-coder facts: a bank coding carries neither, so they read None/False.

The account a HELD document should most likely be coded to (ZET-386).

Only a suggestion for the person coding it by hand — never what Accept & post books (that is coding_proposal). source: human_history = this supplier's latest coding a person decided; ai_history = its latest coding at all; accountant = the AI accountant's proposal for a receipt from a supplier with no history.

Typed projection of a HELD fixed-asset capitalization proposal (J2).

Lifted by the router only while outcome=held and kind=='capitalize' — what a reviewer needs to judge "should this purchase go into the asset register?", not the raw replay payload (which stays internal and also survives on accepted rows).

needs_category is the one field the UI must act on: when true the accept body has to carry a fixed_asset_category_id, because no category claims the extracted asset_kind (or several do — then ambiguous_category too, which is a settings problem rather than a document one).

needs_split_source is its mixed-invoice sibling: the capital amount fits none (or several) of the coded lines, so the accept has to carry a reclassify_from_account_code chosen from split_source_options — the coded candidate account codes, deliberately not the whole chart (the accept completes a fact, it does not re-code the invoice).

What a held "duplicate of already-coded document" decision matched (ZET-410).

matched_on names the detector's arm — document_no: the invoice number ALONE (the arm compares nothing else), described by the booking that holds it (entry, date, the holder's counterparty and gross, so a reviewer can see at a glance whether it is the same invoice); payment_reference: the QR/SCOR reference, with the already-booked document (item_id, item_label) that carries it. Every holder field is optional: a named document that no longer exists still says what the arm matched on.