> ## Documentation Index
> Fetch the complete documentation index at: https://zenofirm.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Expense claims

> Turn a company card into a claim queue: receipts, a cardholder's submission, a reviewer's approval, and only then a posting.

Most card charges are bookkeeping. Some are somebody's expenses, and those need
a person to say what the charge was for and another person to accept the
answer before it becomes a posting.

Zeno handles that as a second lifecycle on some of the lines in [the
queue](/docs/cloud/bank-feeds). A fed card account can be marked an **expense
account**, and from then on every charge arriving on it is a **claim**: born
draft, assigned to a cardholder, and barred from posting until it is submitted
and approved.

Ordinary bank lines never grow that second lifecycle. It is a switch someone
throws, not something inferred from the account's type.

## Setting it up

Under **Settings → Expense cards**, pick a fed account and turn claim handling
on. Then record who carries which card.

| What you record    | Why                                                                                                                                                                                  |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name**           | Who the cardholder is.                                                                                                                                                               |
| **Card last 4**    | For a corporate program with several physical cards on one feed, this is how an arriving charge finds its owner. With one card on the account, every line goes to its single holder. |
| **User reference** | The email or handle of the person who submits. It is what their own view filters on — two people can share a name, and an address cannot.                                            |

Charges already sitting in the queue when you turn this on are backfilled into
claims rather than left behind.

## Who acts next

A claim is only ever in one person's court, and the queue says whose: the
**Claims to review** tab holds what a reviewer owes a verdict on, and
**Awaiting cardholder** shows what is still with the person who carries the
card.

| State         | Whose move     | What happens next                                         |
| ------------- | -------------- | --------------------------------------------------------- |
| **Draft**     | The cardholder | Attach a receipt (or say why there is none), then submit. |
| **Submitted** | The reviewer   | Approve it, or send it back with a question.              |
| **Sent back** | The cardholder | Answer, fix, resubmit.                                    |
| **Approved**  | Nobody         | Cleared to be planned.                                    |

<Warning>
  Approving a **claim** approves the claim. It does not post anything. An
  approved claim becomes eligible for a plan, and that plan still needs its own
  human approval before a single entry reaches QuickBooks. The two approvals
  answer different questions: *was this a legitimate business expense?* and *do
  these postings look right?*
</Warning>

## What the cardholder sees

Somebody whose entire business here is the card in their pocket does not get
the console. Their page shows only their charges. They can attach a receipt,
submit a claim, or answer a reviewer's question there.

Every request on that page is filtered by the signed-in person's own address
rather than by anything the page asks for, so a cardholder cannot see another
person's charges. Approving their own claim is not on the list.

Invite them from **Settings → Team** with the **cardholder** role. Like
everyone else in the firm, a cardholder is never counted.

## Submitting

A claim cannot be submitted on nothing. Each line needs one of:

* a linked receipt,
* an explicit reason there is no receipt, or
* at least a coded account.

*Attach a receipt or have a category* — one or the other, and the rule is what
stops a month of unexplained charges arriving in a reviewer's queue. The
cardholder attaches or waives the receipt on their own page; the category
comes from the client's coding rules or the assistant, as it does for every
other line in the queue.

An operator can submit on a cardholder's behalf with `qb_submit_expenses`, and
it is recorded as such.

## Reviewing

Submitted claims sit on the queue's **Claims to review** tab, each with its
cardholder, its receipt, its coding and the conversation so far. A reviewer
approves, or sends back — singly or as a selection. The same two verdicts are
`qb_approve_expenses` and `qb_return_expenses` from a chat client.

Approving requires a coded account on every line. A claim without a category is
a question, not an approval — send it back, or ask the assistant to code it
first.

Sending back requires a reason. The reason lands twice: as the sent-back reason
on the line, and as a question in the claim's conversation, so the cardholder
sees what was asked rather than only that something was wrong.

Comments never change a claim's state. Answering a question does not resubmit
it — resubmitting does. The cardholder answers on their own page; a reviewer
asks through `qb_expense_comment`.

## Receipts

Receipts arrive in [the firm inbox](/docs/cloud/tools#the-firm-inbox), by email or
upload, usually without anyone knowing which charge they belong to. Zeno
works both directions:

**Charge first.** A charge is missing its receipt; the assistant finds the
document in the inbox and links it with `qb_link_receipt`.

**Receipt first.** A pile of receipts arrives; `qb_match_receipts` scores them
against the unlinked charges. Zeno needs to be told what each receipt *says* —
its total, date, merchant, and card last 4 — which is what an assistant that
can read the file is for — and then earns its keep on what a person is slow at
across hundreds of charges:

* the amount has to be within 10%, or it is not a candidate at all;
* dates tolerate the days between a swipe and its settlement;
* merchant matching sees through the processor prefixes card statements
  carry — `SQ *`, `TST*`, `PAYPAL *`.

One candidate is marked safe to link without a person only when it scores 90 or
better *and* is 10 clear of the runner-up. Two plausible charges means somebody
looks.

<Note>
  The first link holds. Re-linking means unlinking first — so a mistake is undone
  deliberately, and never silently replaced.
</Note>

A linked receipt is the claim's evidence. It shows as a chip on the queue line
that previews the document, it rides into submission, it stops the coverage
report counting the charge, and after the posting lands it is the document
Zeno attaches to the QuickBooks transaction.

## What the dashboard shows

`qb_expense_dashboard` answers the question a controller actually asks — ask
the assistant for it by client and date:

* month-to-date card spend against the same days last month, and year-to-date;
* charges missing receipts — the count, the dollars, and how many are more than
  30 days stale, because past a month a receipt is probably gone;
* the breakdown by cardholder and by account;
* the work queue: drafts, submissions waiting, claims sent back, and receipts
  still sitting in the inbox.

## Posting

Approved claims are ordinary coded feed lines again. They go into a plan with
everything else on the account, a person reads the table and approves it, and
`qb_apply_batch` posts it. See [plan, review, apply,
reverse](/docs/cloud/governed-work).

The exact tool names are listed under [expense
claims](/docs/cloud/tools#expense-claims) and [receipts](/docs/cloud/tools#receipts).