> ## Documentation Index > Fetch the complete documentation index at: https://zenorent.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # The bookkeeping inbox > A shared workspace over the pending bank-feed queue, where you and Zeno work the same list together The bookkeeping inbox is one person and Zeno processing pending bank-feed items side by side. You open a session, pull in a batch, and work through it together — Zeno proposing in groups, you approving, correcting, or setting aside. Open it from **Zeno → Inbox**. > [!NOTE] > > This is badged **Experimental** in the app, and the badge is honest — the surface is still moving. The rules, knowledge, and log layers underneath it are not experimental; they run the everyday bank-feed review whether or not you use this workspace. ![Staging Pipeline](https://mintcdn.com/zenoservices/oXHN6W4EbbFuxgiw/images/illustrations/intake-pipeline.svg?fit=max\&auto=format\&n=oXHN6W4EbbFuxgiw\&q=85\&s=a9d56fc53dbef1b492b3018d2f1e45a7) ## Why a session A queue two people are working at once is a queue two people double-enter. A session is Zeno's answer: it's a real record with a start, a finish, and a hold on the items inside it. While you have items pulled into a session, they're yours. Someone else — a colleague, or Zeno in another conversation — can't pull the same rows out from under you. Abandon a session and the hold lapses on its own after half an hour, so a closed browser tab never strands work. Sessions are also the audit unit. Everything that happened inside one stays attached to it: what was pulled, what was applied, what was skipped and why. ## Working a batch **Pull items** into the session — filter by status, account, date range, or search, or name specific rows. Zeno groups what you pulled by payee before you look at it, so a hundred charges arrive as a handful of clusters. The grouping splits by cardholder as well as merchant, because on a shared card *who* spent decides which cost center it belongs to. It also normalizes the noise banks add — the `TST*` and `SQ *` prefixes, store numbers, trailing city and state — so one merchant reads as one merchant. Each cluster carries a suggested account when every item in it already agrees, a suggested vendor when the name matches one of yours, the item count, and the total. ## Applying Two shapes. Know which one you're in. **One category across many items.** The ordinary case: a cluster of twelve charges that are all Repairs. Approve the group and they post together. **Many categories across one item.** A single payment covering several jobs — a check whose memo reads *2300 — Ashbury Residences, 250 — Parkview Court*. Split it into legs, each with its own account or cost center. A split has to add up. The legs must sum to the item's amount, and Zeno checks that before anything posts, so a mistake comes back naming the actual discrepancy instead of surfacing later as an unbalanced ledger. Splits are also atomic here. The whole split posts as one operation, so a failure can't leave a half-categorized transaction behind. > [!TIP] > > On a batch of more than a few items, apply one first and look at it in the register before releasing the rest. Zeno will suggest this itself; it's worth taking. ## Matching what's already there Not every feed item is new spend. Plenty are echoes of something already in your register — a payment imported from another system, a check you entered by hand, a payout that posted ahead of the bank. Those need **matching**, not categorizing. Categorize an echo and you've counted it twice. Zeno surfaces candidates by amount and date within the same account, in two shapes: * **One to one** — link the item to the existing register row. * **Many to one** — a deposit that covers several payments. Zeno moves the individual payments through Undeposited Funds and posts the single bank-side deposit that sums them, which is how a bank's one-line deposit reconciles against your several invoices. ## Skipping and noting **Skip** takes an item out of your session without touching it — it goes back to the queue for someone else or a later pass. Skipping is recorded with a reason, so the next person knows why it's still there. **Notes** are session-scoped commentary: what you decided partway through, what you want to check. They live with the session. For anything worth remembering past today, use the **work log** instead. It's dated, it survives the session, and it's where you'd look in three months to answer "why is this categorized this way." See [How the AI works](https://zenorent.com/docs/how-the-ai-works.md#staying-in-control). ## Closing out Close the session with a summary of what you did. Items still held are released; everything the session touched stays linked for the audit trail. The session page keeps the story: the timeline of what was pulled, applied, skipped, and noted, in order, with the totals for each action. ## What Zeno won't do on its own Working the queue with Zeno is a conversation, not a hand-off. It's instructed to state a cluster's pattern, count, and proposed account, then wait for you. It also won't guess at a split it can't determine. Handed a check for several jobs with no readable breakdown, it leaves the item pending and asks rather than approximating. ## Where to go next * [Rules](https://zenorent.com/docs/rules.md) — turning a cluster you keep approving into a rule that fires at ingest. * [Knowledge & rules](https://zenorent.com/docs/knowledge-and-rules.md) — recording the judgment calls a rule can't hold. * [Books](https://zenorent.com/docs/books.md) — the review queue this workspace sits over. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.