Expense claims

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. 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. 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.

​

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, 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. 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. The exact tool names are listed under expense claims and receipts.