Firm workspace tool reference

This reference is for people configuring AI clients or building integrations. For day-to-day bookkeeping, start with the firm workspace guides. You can describe the job to your assistant without typing these tool names.

The hosted workspace exposes one tool surface over MCP at https://api.zenofirm.com/mcp — the same surface the console uses. Connect an AI client once, and everything below is available to it, scoped to your firm and to the companies your firm has connected. There are 125 of them, in the groups below.

The rules every tool follows

One shape for every answer. A tool returns its result, or it returns a refusal with a plain-language reason and a hint naming what to do instead. A tool never guesses its way past a problem.
Reads never pause. Reading your books, your context, your work log and your history stays available even when a subscription lapses. Only writes pause. Nobody loses sight of data their own ledger contains.

Planning writes nothing. qb_plan_batch, qb_plan_feed, qb_plan_cleanup, qb_import_iif and qb_import_table all resolve, check and render. None of them touches QuickBooks.
Only a person approves. No tool lets the AI approve a plan. A person approves with their own click, on the plan’s page in the Zeno console or on the plan page drawn inside the chat when they are signed in, and Zeno refuses to post a plan approved any other way. Saying “go ahead” in the chat is not an approval; the AI points you at the plan’s page. Your decision reaches the conversation through qb_await_verdict, so nobody has to go back and say “now post it”.
Apply refuses drift. If the plan or the exclusions changed after the verdict, applying is refused and a new plan is required.
The ledger stays authoritative. Read models are labeled copies for search and speed; every write goes through QuickBooks, never around it.
Single writes wait for you too. The few tools that change QuickBooks without a plan (voiding, deleting or editing one document, a recurring template that never posts on its own, tax setup, currencies, company settings, attachments, emailing a customer, reversing a run) write nothing on the AI’s first call. It hands you a link to an approval page, also listed on the console’s Plans page, that shows exactly what it will do, and only after you press Approve can that exact call run, once. The same goes for making a knowledge entry or playbook live, closing a period, and approving expense claims. A changed argument means a new approval.

Companies and connection

Tool	What it does
`qb_list_companies`	The firm’s client companies and the state of each connection, with the client answers, owners’ questions and inbox documents waiting across them.
`qb_status`	Connection health, read-model freshness, and the plans still waiting for a decision.
`qb_setup`	What is left to set up, for a new firm or one client: the first read of the books, the check-up, the business profile, bank feeds, card processors and drafts waiting to be confirmed, each with the tool or console page that does it. Once the books are read it also lists the questions only you can answer — cash or accrual, payroll, how the owner is paid, sales tax, loans, what to do with charges nobody recognises, how often the books close — each with what the books show. Your AI asks a few at a time and files each answer as client knowledge, as a draft for you to confirm. It changes nothing.
`qb_company_info`	Live company profile from QuickBooks — name, country, fiscal year start, address.
`qb_sync_mirror`	Refresh the read models: a full sync the first time, change-data-capture after. Pass `rebuild: true` when the copy is wrong rather than merely stale — after a company reset, a restored backup, or a bulk delete done outside Zeno. The transaction window reaches 24 months back by default; pass `historyFrom` (a date, such as the year the file was opened) or `historyMonths` to reach further. The window is per company, is kept by every later sync, and only ever widens. Every full pull also asks how many transactions the company holds dated before the window and the earliest of them, and says so — so a window that begins after the file’s first transaction is never silent about it.
`qb_get_entitlements`	The QuickBooks subscription tier and feature grants behind classes, locations, purchase orders, and budgets.

Reading the books

Most reads answer from the read models, which is why they are fast and why they carry a sync time. Reads marked live go to QuickBooks every call.

Tool	What it does
`qb_list_accounts`	The chart of accounts: name, type, balance, active.
`qb_find_customers`	Search customers by name fragment.
`qb_find_vendors`	Search vendors by name fragment.
`qb_list_items`	Products and services.
`qb_find_transactions`	Find transactions by kind, counterparty, document number, amount, or date range.
`qb_query`	Read-only SQL over the read models — the cross-cutting question no single endpoint answers. One `SELECT` at a time, always scoped to one company. `format: "csv"` answers with one spreadsheet string in place of rows, ready for a working paper.
`qb_list_employees`	Employees, live, inactive included, with the ids a `qb_plan_names` line takes. Deactivating an employee through a plan doubles as termination — a release date records when.
`qb_list_currencies`	Currencies enabled for the company, live.
`qb_list_tax_codes`	Tax codes with their rates, live. Rates are immutable in QuickBooks — what you see is what transactions get.
`qb_list_budgets`	Budgets, live. A budget is created, changed or deleted through a plan’s budgets section in `qb_plan_batch`, and `qb_report` BudgetVsActuals compares one with the live Profit and Loss.
`qb_list_custom_fields`	Custom fields, live: both kinds QuickBooks Online keeps (sales form fields and the custom fields made in its custom fields settings), each with its type, options and where it is. Values are set through plans: an entry’s `customFields`, a customer or vendor line’s `customFields`, or a cleanup Modify’s `patch.customFields`. Fields are defined or changed in a plan’s customFields section in `qb_plan_batch`. A company connected before Zeno asked for the custom fields permission is offered a reconnect on the Clients page. See Custom fields.
`qb_list_projects`	Projects, live: name, customer, status, dates and completion. Projects are created, changed or deleted through a plan’s projects section in `qb_plan_batch`, and a plan entry can carry a project. A company connected before Zeno asked for the Projects permission is offered a reconnect on the Clients page.
`qb_list_customer_types`	Customer types, live. Read-only for the same reason.
`qb_report`	Run a QuickBooks report live — Profit and Loss, Balance Sheet, Trial Balance, General Ledger, aged receivables and payables, cash flow, and the rest. Report parameters pass straight through. Each result also carries a link to Zeno’s PDF of the report, which runs the report again when it is opened and works for 24 hours.
`qb_check_vendor_statement`	Hold a vendor’s statement against the books. Your assistant reads the statement’s lines and passes them; Zeno lists what is on the statement and not in QuickBooks, what is in the books and not on the statement (and when one looks like a bill entered twice), and amounts that differ. An invoice paid by check or card with no bill entered counts as paid, not missing. Given the statement’s ending balance, it compares what QuickBooks shows owed on that date, read live, and says how much of any gap the items explain. It does not compare balances for a vendor billed in another currency. Changes nothing: a missing bill goes into a plan you approve.

The batch loop

Everything that changes the ledger goes through these, in this order. The loop is described in full under plan, review, apply, reverse.

Tool	What it does
`qb_plan_batch`	Preflight a batch into a reviewable plan: resolve names against the ledger, apply the client’s coding rules, validate shapes and dates, flag duplicates and already-posted entries. Besides postings, a plan can carry names, bulk corrections, budgets, projects, custom fields and recurring templates. Writes nothing.
`qb_review_batch`	Re-render a stored plan’s approval table and its verdict state.
`qb_await_verdict`	Wait for the person’s decision on a plan, so an approval they give on the plan’s page reaches the conversation with their words.
`qb_exclude_line`	Record a reviewer’s decision on one line — exclude it, or put it back.
`qb_reject_plan`	Record a human’s rejection, in their words. A refusal is a decision and leaves a trace. The latest verdict counts, so this is also how an approval that has not posted is withdrawn - a plan superseded by a re-plan, or one no longer wanted. Only an applied plan is refused; `qb_reverse_run` undoes that one.
`qb_apply_batch`	Post an approved plan. Refuses unless a person approved it on the plan’s page, on drift, or if it was already applied — except a plan whose run was interrupted by a server restart, which `resume: true` continues, skipping by name every line that run posted.
`qb_list_plans`	Plans for the firm, newest first, with each one’s latest verdict and stage; says how many there are, takes `limit`, and `open: true` keeps only the plans still waiting on someone.
`qb_list_runs`	Runs — applies and reversals — newest first.
`qb_run_detail`	One run’s journalled entries: what posted (with the amount QuickBooks Online posted beside what the plan said, where they differ), what was skipped and why, what failed, what has been reversed.
`qb_reverse_run`	Undo a run. Entries reverse in descending order, voided where QuickBooks voids and deleted where it cannot; names the run created are retired last.

The queue

The queue that turns arriving transactions into coded postings. Statements and live bank connections fill the same queue, and nothing downstream can tell the two apart — which is why a firm can start on downloaded files and add a connection later without re-learning anything. These tools are the only road for coding a line: the console’s Bank feeds page shows the result and takes the verdicts. Working the queue is described in full under the queue.

Tool	What it does
`qb_preview_statement`	Read a statement without staging any of it: the header as written, which column each role ended up reading, the first rows as the importer would produce them, and what it would skip. CSV column detection is a guess about somebody else’s spreadsheet, and this is where a wrong guess gets corrected.
`qb_import_statement`	Stage a CSV or OFX/QFX/QBO statement onto the feed. Rows are parsed, deduplicated, and run through the company’s coding rules — auto rules fill, suggest rules propose. Writes nothing to QuickBooks.
`qb_bank_feed`	The staged queue with its coding, rule provenance, and suggestions. `view` narrows it to the question actually being asked — needs coding, suggested, ready, matched.
`qb_name_cards`	Name the cards on a card account (Amex, Chase with a second card: one account, several cards) and give each a default account. A card’s charges are suggested to its default when no coding rule says otherwise, and post only through an approved plan. No expense claims involved.
`qb_code_feed_lines`	Code, exclude, restore, or match staged lines. A manual edit clears the line’s rule provenance, because the badge means “a rule did this”. Posted lines refuse edits — reverse the run instead. The batch lands whole or not at all: after a failure nothing changed and the same updates can be sent again; a line that was already matched says so, with the transaction it went to.
`qb_match_feed`	Find what the feed does not need to post: ledger candidates already in QuickBooks within $0.02 and ±5 business days, and mirrored pairs across two fed accounts that are one transfer rather than a check plus a deposit.
`qb_match_options`	Everything that could stand in for one line: the automatic candidates, groups of ledger rows that together sum to it (four cheques entered by hand, one lodgement on the statement), the transfer partner, and a free search of the register for the cheque that cleared three weeks late.
`qb_plan_feed`	Build a reviewable plan from pending lines. Money out becomes Checks or card charges, money in becomes Deposits or card credits, and mirrored pairs fold into one Transfer. Each entry carries `bankfeed:<id>`, so the posting stays linked to the raw bank line.

qb_plan_feed produces an ordinary plan. A person approves it on its page and qb_apply_batch applies it like every other batch — a feed that posted its own entries would be a second path to the ledger, and a second path is a path where the gates are not.

Live bank connections

Optional, and with Stripe and Square below, the only parts of the workspace that reach a third party for transaction data. Setting one up is a settings job, not a daily one.

Tool	What it does
`qb_connect_bank`	Start connecting a bank login. Returns a URL for a person to open in any browser — the credentials go to the bank, never through Zeno. `syncFromDate` is where the feed starts: it sets how much history the bank is asked for, up to two years, and skips anything before it. The bank settles that reach once, when the login is connected, so ask for everything the books will ever need. Without a date the bank shares its last ninety days. Pass a `connectionId` instead to re-authenticate a lapsed login, which keeps the cursor and the history.
`qb_complete_bank_connection`	Finish a hosted-link session and list the accounts it discovered. Each one stays disabled until it is mapped: discovery is not a decision.
`qb_map_feed_account`	Say which QuickBooks bank or credit-card account a discovered account’s lines land in, and enable it. Until an account is mapped, its transactions are not staged and the login is not read at all; mapping it brings in its history from the feed’s start.
`qb_set_feed_account`	Turn a mapped account’s staging on or off. Disabling pauses a feed without forgetting where it posts or discarding what it already staged; enabling again fills the pause in. A pause is “not now” — `qb_set_feed_start` is how to skip a stretch for good.
`qb_set_feed_start`	Move where a connection’s feed starts. Earlier re-reads the login’s history on the next sync — lines already on the feed are recognised by their bank id, not doubled — and reaches back at most to what the bank shared at connect time. Later only narrows what future syncs keep.
`qb_bank_connections`	The company’s connections and their health. `needsReconnect` is a feed that has stopped — a lapsed login fails silently, so treat the flag as work.
`qb_bank_balance`	The bank’s own balance beside the QuickBooks balance for each fed account, with the difference decomposed: feed lines not yet posted (and how many sit in a plan awaiting approval), lines excluded on purpose, and what remains that the feed cannot see. The bank figure is the current balance the bank reported on the last sync, labelled with its as-of; the QuickBooks figure is read live. A gap is a to-do list, not a fault.
`qb_sync_bank_feed`	Pull new transactions onto the feed, and with no connection named, read the client’s new Stripe and Square payouts too. The server also does both on a schedule.
`qb_disconnect_bank`	Disconnect a login. Staged and posted lines keep their history: disconnecting stops the future, never rewrites the past.

Stripe, Square and Helcim payouts

A payout reaches the bank as one number. Zeno reads what each one settled from Stripe or Square, once a person has connected the client’s account on Connections. The AI sets where each kind of money goes and plans each payout as one deposit split into its parts, on the bank line it caused. Helcim is recorded through a clearing account instead (why). A charge that pays an invoice, or a payment already recorded, settles it instead of counting as a sale again. Nothing posts until a person approves.

Tool	What it does
`qb_stripe_payouts`	The client’s Stripe connection and recent payouts as Zeno read them: each payout’s sales, refunds, disputes, fees and adjustments, whether it is ready to plan, planned or posted, and how many of its charges Zeno would settle against an invoice or payment and how many it could not decide. With `payoutId` (or `payoutIds`), everything Zeno read of those payouts: every charge, refund, dispute, fee and adjustment with its id, dates and amounts, what each charge carries (description, invoice number, customer, billing name and email, metadata), and what Zeno proposes it settles and why. Read-only.
`qb_plan_stripe_payouts`	Plans Stripe payouts as deposits split into sales, refunds, disputes, fees and adjustments, each on the bank feed line it caused. Each charge first settles a payment already recorded and still undeposited, then an open invoice (a new payment applied to it), and is a sale only when neither fits. `settle` lets the AI say what a charge settles, `[{ charge, invoice \| payment \| sale }]`; Zeno checks each against the books and plans nothing if one does not hold, saying why. A withdrawal (Stripe debiting the bank) becomes a check. A payout already in a plan, or whose parts do not add up, is refused with the reason. Nothing posts until a person approves.
`qb_square_payouts`	The client’s Square connection and recent payouts, every location: each payout’s sales, sales tax, tips, refunds, disputes, loan repayments, fees and adjustments, whether it is ready, planned, posted, still being read or failed, and the same charge counts. With `payoutId` (or `payoutIds`), every entry with its ids, amounts and what each sale carries (note, reference ids, order lines, customer), and what Zeno proposes it settles. Read-only.
`qb_plan_square_payouts`	Plans Square payouts as deposits split the same way, each posted against the bank line it caused, with charges settled and `settle` honoured as for Stripe. A payout already in a plan, or whose parts do not add up, is refused with the reason. Nothing posts until a person approves.
`qb_helcim_payouts`	The client’s Helcim connection and card batches: each batch’s sales and refunds, whether it is ready, planned, posted, still being read or open, and whether a Helcim deposit has carried it out of clearing; and the Helcim deposits and fee debits on the bank waiting to be recorded. With `batchId`, every transaction in the batch and what each sale would settle. Read-only.
`qb_plan_helcim_payouts`	Plans a client’s Helcim activity in one plan: each closed batch as a deposit into the clearing account (sales less refunds, with charges settled as for Stripe), each Helcim deposit on the bank as a transfer out of clearing matched to the batches it carried, and each Helcim debit on the bank to the fees account. A deposit whose batches are not in clearing yet, or that no run of batches adds up to, is held with the reason. Nothing posts until a person approves.
`qb_set_payout_connection`	Sets up a client’s Stripe, Square or Helcim connection from the chat: the bank account payouts land in, the account each kind of money goes to (sales, refunds, fees, disputes, adjustments; for Square also sales tax, tips and a Square Capital loan, which must be a liability; for Helcim the clearing account its batches wait in, which must be an asset and not the bank), and whether charges first match invoices and payments already in the books or are all booked as sales. Names come from the client’s chart; a wrong one is refused and nothing changes. Connecting the account itself stays a person’s step in the console.

Expense claims

Turn a fed card account into a claim account and every charge on it grows a second lifecycle: draft, submitted by the cardholder, approved or sent back by a reviewer. Only an approved claim can reach a plan. See expense claims.

Tool	What it does
`qb_setup_expense_account`	Turn claim handling on for a fed account (or off), and record the cardholders who carry its cards. Existing pending lines are backfilled. Turning claims on needs the firm’s Expense claims setting, in Bank connections.
`qb_cardholders`	Who carries which company card, and each card’s default account. Read-only.
`qb_expense_claims`	The claim queue with each line’s claim state, receipt, cardholder, and conversation. `submitted` is the reviewer’s court; `draft` and `sent_back` are the cardholder’s.
`qb_submit_expenses`	The cardholder’s act: submit draft or sent-back claims. Each line needs a linked receipt, an explicit no-receipt reason, or at least a coded account first.
`qb_approve_expenses`	The reviewer’s act, recorded with who and when. Requires a coded account on every line — a claim without a category is a question, not an approval.
`qb_return_expenses`	The reviewer’s other act: send claims back with a required reason, which lands both as the sent-back reason and as a question in the conversation.
`qb_expense_comment`	Add to a claim’s conversation. Comments never change a claim’s state — answering a question does not resubmit it.
`qb_expense_dashboard`	Receipt coverage and card spend: month to date against the same days last month, charges missing receipts and how many are over 30 days stale, the breakdown by cardholder and by account, and the work queue.

Approving a claim clears it for planning. It does not post anything. The plan qb_plan_feed builds from those lines still needs its own human approval before qb_apply_batch touches QuickBooks.

Receipts

Tool	What it does
`qb_match_receipts`	Score inbox receipts against unlinked charges. Amount is required and a receipt more than 10% off is no candidate; dates tolerate settlement lag; merchant matching sees through processor prefixes (`SQ `, `TST`, `PAYPAL *`). Proposes only.
`qb_link_receipt`	Link a receipt to its charge, record that a charge needs none, or undo a link. First link holds — re-linking means unlinking first, so a mistake is undone deliberately rather than silently replaced.

The linked document is the claim’s evidence: it rides into submission, it stops the coverage report counting the charge, and after posting it is what qb_attach_document puts on the QuickBooks transaction.

Importing a file

The division of labour that makes a large import cheap and safe: the agent works out the shape from fifteen rows, and the engine applies it to every row deterministically. Reading fifty thousand rows through a model burns the customer’s tokens to produce a plausible-but-wrong ledger. See importing and migrating.

Tool	What it does
`qb_inspect_import`	Look at a file before reading it: what format it is, and for a spreadsheet or CSV its headers, a small sample of rows, and which columns parse as dates and amounts.
`qb_import_table`	Read a spreadsheet or CSV into a reviewable plan using a column map worked out from that sample. Pass `groupBy` when several rows make one document — a bill register keyed by bill number. The map itself is shown to the reviewer, so a wrong column is caught before anything posts.
`qb_import_iif`	Read a QuickBooks IIF file into a reviewable plan. Name lists become the plan’s lists section and transactions become its entries, so one approval covers a whole migration.

qb_import_iif returns warnings that matter: every block that did not reconcile against its own total, every transaction kind QuickBooks Online has no equivalent for, and every payment that will post unapplied. Read them before approving, not after.

Correcting what is already posted

Tool	What it does
`qb_plan_cleanup`	Preflight a bulk cleanup into a reviewable plan: void, delete or correct many documents already in QuickBooks as one approval table and one reversible run — any number of targets, in as many plans as a reviewer can read. Name them by `select` (kinds, a date range, a name, a line account: everything matching becomes a line, already in dependency order, capped per plan) or by explicit `targets`. A selection carries one action for every match: `Delete` pages, and the same selection again after the plan applies takes the next batch; `Modify` carries one header `patch` (dates, numbers, memos, and the header’s location, class, customer or vendor by name) and/or one `recode` rule (lines on account, class, item or customer A move to B, by name, turned into each document’s lines at apply; `paidFrom` moves the bank or card account a purchase was paid from, or the account a deposit went into); `Void` is allowed when everything matching fits in one plan, because a voided document would match the selection again. See Bulk operations. A target the read models have not seen is read live from QuickBooks rather than refused, so any id `qb_delete_transaction` would accept is accepted here. Each target is pinned to the revision it carries now, so a document somebody edited between approval and apply is refused rather than acted on. Lines act in order, and the plan warns by name when a document is numbered ahead of a payment applied to it.
`qb_modify_transaction`	Change one transaction in place. The update is sparse, with one exception: passing `lines` replaces every line, because QuickBooks has no partial line patch. Waits for your approval.
`qb_void_transaction`	Void one transaction: it stays in the ledger at zero, keeping its number and its place in the audit trail. Waits for your approval.
`qb_delete_transaction`	Permanently delete one transaction. No stub, no undo. Waits for your approval.

QuickBooks voids invoices, sales receipts, payments, bill payments and check-type purchases only. Everything else is refused by name with delete as the named alternative, rather than letting QuickBooks answer Unsupported Operation. Prefer voiding wherever it is allowed. For a single document those three are the right tools; a batch of one makes an approval table lie about what it is. For duplicate bills, a bad import, a wrong-month batch, a mass recode (a select with a recode rule) or emptying a file, qb_plan_cleanup journals every document’s pre-image before anything happens, so qb_reverse_run puts it back — restoring a void or an edit onto the same document, and re-creating a deleted one under a new id, saying which it did. Emptying an old file is the largest case, and it is still this loop: widen the window with qb_sync_mirror (historyFrom the year the file was opened), then qb_plan_cleanup with a select — every kind, or one at a time — which plans the batch in dependency order (deposits, then the payments they hold, then the invoices and bills those pay, then the rest), five hundred documents a plan. Approve, apply, run the same selection again for the next batch. Keep customers and vendors active until their documents are gone. There is no bulk-delete app to add; the plan is the bulk tool, with an approval table and one reversible run per batch.

Names and lists

QuickBooks Online has no delete for list names. Deactivation is the only undo, and it is not destructive: the row leaves every picker, every posted transaction keeps it, and it can be brought back. Names are created, changed and retired through a plan a person approves, like everything else that touches the ledger.

Tool	What it does
`qb_plan_names`	Create, change or retire accounts, customers, vendors, employees, products and services, classes, locations, terms, payment methods, tax agencies and currencies — as a plan. A tax agency is created once and never changed or retired (QuickBooks Online has no way to); a currency is checked against a live read of the company’s list and a switched-off one is turned back on rather than doubled. One approval table, one run, and every change keeps the row’s previous state so `qb_reverse_run` puts it back. There is no direct tool for these lists: a name write is a ledger write. Reserved accounts and QuickBooks’ shipped terms map to the existing row instead of being duplicated. A vendor’s tax id and an employee’s SSN and date of birth are refused; enter them in QuickBooks Online (what a plan carries but does not keep).
`qb_create_names`	Fix a plan’s missing names in one reviewed step: collect every name the batch needs, preview what would be created, then re-plan with those names in the plan’s lists section — one approval for the names and the postings that need them.
`qb_create_currency`	Enable a foreign currency. Refused when multi-currency is off.
`qb_set_exchange_rate`	Pin an exchange rate for a date. Setting it again overwrites that day rather than duplicating it.
`qb_create_tax_agency`	Add the tax agency a rate must reference.
`qb_create_tax_code`	Add a tax code and its rates in one call. Rates are immutable afterwards. Refused on US automated sales tax, which computes tax itself.
`qb_retire_duplicate`	Retire a duplicate name behind an alias: record the alias so every future plan resolves the old spelling to the survivor, and stage a one-line plan that retires the loser once a person approves it. Posted history stays where it is; a true merge is a QuickBooks interface operation.
`qb_map_name`	Record that alias directly — “the spelling on these documents means this ledger row.”

QuickBooks refuses some of these itself: a vendor with open transactions cannot be deactivated, a bundle cannot be created through the API, and one name index is shared across customers, vendors, and employees, so a display name can only be used once. Each tool says so rather than failing obscurely.

Company settings

Tool	What it does
`qb_preferences`	Live preferences: sales tax posture, class and location tracking, multi-currency, custom fields — the gates that decide what this company’s API accepts.
`qb_set_preferences`	Change those company-wide settings. Waits for your approval: two of these flags quietly discard data.
`qb_update_company_info`	Update the company’s outward-facing identity — the name, addresses, phone, and email customers see on every invoice. Waits for your approval.

Recurring templates

Tool	What it does
`qb_list_recurring`	Recurring transaction templates defined in QuickBooks.
`qb_create_recurring`	Create a template that reminds someone on a schedule or is held for manual use. It never posts by itself: a template that does is set up through a plan’s recurring section in `qb_plan_batch`. Any transaction QuickBooks Online can repeat; a payment cannot be a template. Waits for your approval.
`qb_delete_recurring`	Delete a template permanently. Waits for your approval. To change or delete one as a reversible run, use a plan’s recurring section in `qb_plan_batch`.

A plan’s recurring section creates, replaces or deletes templates of every type QuickBooks Online supports, scheduled ones that post on their own included. QuickBooks Online cannot edit a template, so a change is a replace: the old template is deleted first and a new one created under a new id. QuickBooks Online’s API makes every template it creates active, so a template is paused in QuickBooks Online itself. The client’s check-up page in the console lists every template, for reading. See Recurring templates.

Sending and attachments

Tool	What it does
`qb_send_invoice`	Email an invoice or estimate to the customer through QuickBooks. A real email leaves, so it waits for your approval.
`qb_get_pdf`	Fetch QuickBooks’ own PDF of an invoice, estimate, sales receipt, credit memo, refund receipt, payment or purchase order, with a link the person opens or saves. The link needs no sign-in and works for 24 hours.
`qb_attach_document`	Upload an inbox document (by its id, exactly as received) or a file as a QuickBooks attachment, optionally linked to a transaction — the source document riding with the posting.
`qb_attach_documents`	Upload many files as attachments in one run — a folder of receipts, each riding with its transaction. Every upload is a line on the run, and `qb_reverse_run` deletes the attachments the run made. Up to 100 per call.
`qb_list_attachments`	List attachments, optionally those linked to one transaction.
`qb_delete_attachment`	Permanently delete an attachment and every link it has. Deleting a transaction does not delete its attachment, which is why this exists. Waits for your approval.

The firm inbox

Tool	What it does
`qb_inbox`	Documents waiting in the firm’s inbox, newest first, each with what Zeno read off it and the step it is on.
`qb_get_document`	Read one document — images and PDF pages come back to look at, text files as text.
`qb_update_document`	Say whose books a document belongs to and what kind of evidence it is.
`qb_resolve_document`	Close a document out of the inbox, either against the plan that carries its work — the audit path from a posting back to its evidence — or as needing none.

Today

Today is a short brief for the team: decisions a person needs to make and material changes worth knowing. Assistants revise their own subjects as work moves and remove what is resolved; earlier versions stay in history.

Tool	What it does
`qb_today`	Read the current Today page and its revision history, for one client or all you can see, or a saved version.
`qb_revise_today`	Publish one revision: add or replace subjects, remove resolved ones, reorder what remains. Each subject is an action (with a next step and a console link) or an update, with a one-sentence summary; the evidence goes in its body. A stale revision is refused without saving. Changes no books, approvals or client messages.

qb_guide with topic today has what belongs on the page and the format. Bodies take Markdown, or HTML fragments with inline CSS and SVG; scripts, forms and remote resources are not drawn.

Firm memory

A rule the AI saves is a suggestion until you make it automatic on the Rules page. Knowledge and playbooks wait for a person to confirm them, and editing one returns it to draft.

Tool	What it does
`qb_suggest_coding`	Triage descriptors before building a batch: for each one, the saved rule that matches it, or — when none does — what the ledger’s own history says this counterparty gets coded to, with the supporting line count and most recent date. The ones that come back unresolved are the lines that actually need a decision.
`qb_test_rule`	Dry-run a rule against the pending feed before learning it. “This catches these 14 lines” beats “trust me”. Nothing is saved.
`qb_learn_rule`	Save a coding rule: this descriptor means that account. It is saved as a suggestion; you make it automatic on the Rules page. Rules only ever fill fields that were left empty.
`qb_list_rules`	The company’s rules in priority order, with usage counts.
`qb_forget_rule`	Retire a rule. Its history of use stays on the record.
`qb_write_knowledge`	Save something a bookkeeper knows and would otherwise lose between sessions. Anchored to the names it is about, so it surfaces when those names appear.
`qb_confirm_knowledge`	Make an entry live, once you approve it.
`qb_list_knowledge`	The company’s knowledge, with anchors and confirmation state.
`qb_forget_knowledge`	Retire an entry.
`qb_write_playbook`	Save a procedure — a month-end close order, a reconciliation sequence. Firm-wide unless a company is named.
`qb_confirm_playbook`	Make a playbook live, once you approve it.
`qb_list_playbooks`	Firm-wide and per-company playbooks, and Zeno’s built-in checks with what each one reads.
`qb_run_playbook`	Fetch a confirmed playbook to work through, with its `{placeholders}` filled in and the client knowledge it needs already in view. It hands back a procedure and posts nothing: every write inside it still goes through a plan and an approval. A built-in check is not a playbook: run it with `qb_run_check`.
`qb_run_check`	Run one of Zeno’s built-in checks over a client’s books, or `check-up` for all of them: balances on the wrong side of their account, Undeposited Funds or a merchant clearing account that never washed to zero, invoices and bills open past 90 days, lines parked in Uncategorized or Ask My Accountant, large purchases expensed outright, the same vendor under two spellings, and how the client codes and closes. It returns a report of what to raise and changes nothing in QuickBooks Online. On a full-access connection it saves the result beside the client’s check-up in the console. A vendor coded the same way often enough comes back as a proposed rule.
`qb_business_profile`	A client’s business profile: twelve sections from the business itself to the open questions, each with its state, and until every section is confirmed, the figures from the books to write them from — services seen on the books, how vendors are coded, what genuinely recurs, where the money comes from and goes. Changes nothing; a view-only connection can read it.
`qb_write_profile`	Write sections of the business profile in the assistant’s own words, each with the evidence it stands on and whether it came from the books, from you, or both. Each lands as a draft; a section rewritten with different words needs confirming again.
`qb_confirm_profile`	Confirm profile sections you have read and agreed with: the ones named, or every draft. The first call returns a link and nothing changes until you approve it; it is recorded under your name.
`qb_log_work`	Append a dated work-log entry: what was done, why, and what remains open.
`qb_work_log`	Read the work log, newest first.

The run journal records what was posted in enough detail to reverse it. It cannot say which document a batch came from, what was decided, or what is still open — that is what the work log is for.

Asking the client

What the books cannot answer, asked of the client. See Questions for the client for the whole loop.

Tool	What it does
`qb_ask_client`	Draft a question for the client about a bank line, a transaction, a document or nothing in particular. Nothing is mailed: a person sends it from the console’s Client questions page, and the client answers on a page or by replying to the email.
`qb_client_answers`	The client’s questions and answers for one client: by default the answered ones not yet acted on plus those still waiting on the client.

Questions from a business owner

A business viewer - a client’s owner the firm has given view-only access (see People and roles) - can leave questions for the firm from their own AI or the console. Their AI connection lists only the reads of their own companies’ books and the first two tools below; the firm’s AI answers with the third.

Tool	What it does
`qb_conversations`	The questions between business owners and the team, and their answers: the list, or one conversation by id. An owner sees only published replies; the team also sees drafts. Reading marks nothing read.
`qb_ask_bookkeeper`	For a business viewer only: leave a question for the team, or follow up on one, optionally about one transaction. It is queued for a person, not answered or passed to anyone’s AI, and it changes nothing in the books.
`qb_draft_reply`	For the team: draft a reply to an owner’s question. The owner sees nothing until a person reads the draft in the console and publishes it. `qb_list_companies` counts the questions waiting.

Reaching us

One tool writes to Zeno rather than to a client’s books.

Tool	What it does
`qb_contact_support`	Write to Zeno support from inside the chat — something broken, a capability that is missing, a source Zeno cannot read yet (filed as a connector request, the same as Request on Connectors), a question the assistant could not answer, billing, or plain feedback. Called without `confirm` it shows you the mail and sends nothing; `confirm: true` sends it. The report carries your firm, the build and which AI client it came from, so nobody has to ask; it is filed under the account that authorized that client, a copy lands in their inbox, and replying to it reaches a person. It keeps working when a subscription has lapsed.
`qb_share_testimonial`	Leave Zeno a testimonial for zenofirm.com/testimonials from inside the chat, in your own words, with your name, your business and its website so its logo can be shown. Called without `confirm` it shows you exactly how it will appear and sends nothing; `confirm: true` sends it. Your name and business default to your account and your firm, and you can change either. It is marked on the site as sent from your AI while signed in to Zeno, and someone at Zeno reads it before it goes up. Your AI should never write one you did not ask for.
`qb_guide`	How to do one job with Zeno, read by your AI when it needs it rather than on every connection: planning and approving work, correcting what is posted, names, coding rules, connecting banks and working the feed, Stripe, Square and Helcim payouts, expenses and receipts, imports, firm memory, reading the books, company settings, and questions to and from clients. Each page says what every field means, the order things run in, and the edge cases. It changes nothing.

​The rules every tool follows

​Companies and connection

​Reading the books

​The batch loop

​The queue

​Live bank connections

​Stripe, Square and Helcim payouts

​Expense claims

​Receipts

​Importing a file

​Correcting what is already posted

​Names and lists

​Company settings

​Recurring templates

​Sending and attachments

​The firm inbox

​Today

​Firm memory

​Asking the client

​Questions from a business owner

​Reaching us

The rules every tool follows

Companies and connection

Reading the books

The batch loop

The queue

Live bank connections

Stripe, Square and Helcim payouts

Expense claims

Receipts

Importing a file

Correcting what is already posted

Names and lists

Company settings

Recurring templates

Sending and attachments

The firm inbox

Today

Firm memory

Asking the client

Questions from a business owner

Reaching us