Bizdivers

For ONE bank statement line (a bank_transaction id — the resource_id of a match_bank_transaction close blocker), list the book items already on the books it can be matched to: AP payments, customer receipts, expenses and journal entries of the SAME amount, best first. This is the reconciliation worksheet's own candidate list. A journal entry here can be the entry the OTHER side of a transfer between the company's own accounts already booked; matching to it is how the second side settles without booking the movement twice. The answer's route says how the line is settled, and next_step says which tool to use: match (propose_match_bank_transaction), payment_match_proposal (propose_confirm_payment_match), books_already_hold (a feed line whose money is already on the books — never categorize it), review_queue (propose_categorize_bank_review), link_expense (a booked feed line with no receipt attached: propose_link_expense_to_bank_line with one of expense_candidates), or no_action (relay message). Candidates are limited to records within 10 days of the line (or up to 90 days after an AP payment, a check clearing late); an empty list on route match means nothing of that amount is on the books near the line's date — say so rather than proposing a match to something else, such as next month's same-amount payment. The id here is a bank_transaction id, not the statement_line_id that list_statement_lines returns for an uploaded statement's control line.

list_bank_match_candidates

Get the bank reconciliation worksheet for ONE bank account and ONE calendar month, with the product's own numbers: the statement's beginning and ending balance and where they come from (uploaded statement, entered, or none yet), the book balance, the outstanding items on both sides with their ids (deposits in transit and outstanding checks as outstanding_items; unmatched bank lines as unmatched_lines), the opening difference the month inherited, the adjusted bank balance and the unexplained difference, whether the month is already prepared or reviewed (record), and prepare_blockers — exactly what stands between the month and Prepare. Call this INSTEAD OF rebuilding cash balances from get_trial_balance or list_transactions: it is the same computation the Reconciliation tab shows, and a figure derived by hand will not agree with it. door says which worksheet the month is on. connected_feed: feed lines are booked through the review queue (list_bank_reviews, propose_categorize_bank_review); statement: lines are matched to the books by hand (list_bank_match_candidates, propose_match_bank_transaction). Every id in unmatched_lines and open_statement_lines carries id_kind (bank_transaction or bank_statement_line) — pass it only to a tool that takes that kind. Lists are capped at 50; the counts beside them are complete. bank_account_id comes from list_bank_accounts. period_year and period_month name a calendar month; on the statement door the figures describe the statement period ending in that month (period_start/period_end say which).

get_bank_reconciliation

List the BANK REVIEW QUEUE — bank-feed transactions waiting to be coded to a GL account and posted. This is the work behind the close cockpit's bank_rec bucket, and the only place to get a review id for propose_categorize_bank_review. Each row carries the AI classifier's ranked GL account suggestions with a confidence and its reasoning, plus one line saying what the transaction was: explain and confirm a suggestion rather than inventing a coding from the description. Defaults to status pending_review, which is where the work is; pass another status, or "all", to look at the rest. Do not propose the account named by bank_gl_account_id — the entry would cancel itself out and the server refuses it.

list_bank_reviews

Return the cash-outflow forecast: total committed (approved/scheduled) payments due within each window of days from the as-of date. Defaults to 30/60/90-day windows as of today. Answers "how much cash do I need to cover upcoming payments".

get_cash_forecast

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage coding ONE bank review queue item to a GL account and approving it. Approving POSTS a journal entry, so this puts the transaction on the books — the user must explicitly confirm before anything is written. Get review_id and the candidate gl_account_id from list_bank_reviews, and prefer the classifier's top suggestion when its confidence is high: explain it, do not replace it. Never pass the row's bank_gl_account_id — the entry would cancel itself out. When a suggestion carries a bank_account_id the line is a transfer between the company's own accounts: pass entity_type "bank_account" and that id, and gl_account_id must be that account's own GL, or the movement gets recorded twice. This is one item at a time and there is deliberately no bulk version; do not stage forty of these to clear a queue.

propose_categorize_bank_review

List the individual blockers inside ONE close-cockpit bucket, with each blocker's title, severity, underlying record, current assignee and — crucially — its action_type, which names what would resolve it. Call get_close_cockpit first to learn which buckets hold work and what their keys are, then drill into a bucket here before recommending or proposing anything. Use action_type to choose the matching propose_* tool; if no tool fits that action_type, or that tool is not among the tools you have (it needs permission to propose changes), say so plainly and point the user at the blocker's deep_link instead of inventing a workaround. Omit period_year/period_month for the latest open period; supply both for the fiscal period covering that calendar month.

list_close_blockers

List the CLOSE CHECKLIST for a fiscal period — the per-period reminders (close_tasks) an operator writes and ticks off while closing the books. These are NOT general tasks: for those use list_tasks, which reads a different table. Unchecked items block the close and are counted in get_close_cockpit's close_checklist bucket, so use this to say which reminders are still outstanding. To tick one off, use propose_complete_close_task (never propose_complete_task, which completes an unrelated general task). Omit period_year/period_month for the latest open period; supply both for the fiscal period covering that calendar month.

list_close_checklist

Get the close cockpit for a fiscal period: every close-blocker bucket with its count and worst severity, the period being reported on, and whether that period is read-only. This is the FIRST tool to call for anything about closing a period — it tells you which buckets still hold work. A bucket with count 0 is clear; any count above 0 means the period is not safe to close. A bucket with not_evaluated true was NOT checked at all (an evergreen bucket on a closed or locked period) — do not report it as clear. To see the individual blockers inside a bucket (their titles, ids, severities and what action would resolve each one), call list_close_blockers with that bucket's key. Omit period_year/period_month to report on the company's latest OPEN period; supply both to report on the fiscal period covering that calendar month.

get_close_cockpit

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage closing the fiscal period covering a calendar month, which stops further posting into it. The user must explicitly confirm before anything is committed. Call this only after verifying with get_close_cockpit that there are no blockers (get_close_plan's last step also says whether the period is closable right now); if blockers exist, drill into them with list_close_blockers and surface them to the user instead of staging a proposal. Identifies the period by calendar month: the fiscal period covering that month. Pass the same period_year/period_month you passed to get_close_cockpit.

propose_close_period

Get the server-computed, ordered roadmap for closing a fiscal period. Each step is one group of open blockers (grouped by bucket and what would resolve them), in the order they should be worked, naming the propose_* tool that resolves it — or, when no tool exists, saying so plainly and pointing at example_deep_link for the human to resolve it on its own screen. The LAST step is always the close itself: its closable field says plainly whether the period can be closed right now, and its reason explains why not when it can't. Call this INSTEAD OF inventing your own close sequence — the ordering encodes real dependencies that are not obvious from the cockpit alone: for example, bank transactions must be categorized before the journal entries that reclassify them are posted, and every journal entry must be posted before the financial statements are signed off, because the statements are read at status=posted. Re-call it after every confirmed proposal — it recomputes from live state, so it is also how you check what is left rather than tracking it yourself. A step whose tool is empty, or names a propose_* tool you do not have (it needs permission to propose changes), is NOT optional: resolve it by hand and do not silently skip it — doing so reports a shorter close than the real one. sample_blocker_ids are resource ids of the kind named in resource_type, which is usually — but not always — the exact id the resolving tool wants: propose_categorize_bank_review, for example, needs a review_id from list_bank_reviews, not the bank_transaction id shown here. Confirm the tool's own id via list_close_blockers or the matching list_* tool before calling it, rather than assuming a sample id is directly usable. period_year and period_month are REQUIRED and name the fiscal period covering that calendar month, the same convention get_close_cockpit and propose_close_period use.

get_close_plan

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage the GL coding of one or more line items on an AP invoice — the fix for a close blocker whose action_type is assign_invoice_gl. The user must explicitly confirm before anything is written. This changes ONLY which GL account each named line is coded to: it cannot change an amount, a date, payment terms or the invoice status, and there is no tool here that can. Get line_item_id values from get_invoice (each line carries its id). Identify each account by its ACCOUNT CODE, which list_gl_accounts lists (get_trial_balance shows only accounts that already carry a balance) and which the user will normally say out loud ("code it to 6110"); do not guess a code, and ask the user when you are not sure which account a line belongs to. Only ACTIVE expense and asset accounts can be used, and an invoice that has already been posted to the GL cannot be recoded.

propose_assign_invoice_gl

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage coding ONE receipt-based expense to a GL account and approving its support, together. Both halves are needed to clear the close cockpit's expenses bucket — an expense blocks while it is flagged needs_review OR has no GL account — and they are applied as one unit, so the record can never end up coded but unreviewed. This does NOT post a journal entry: it records the coding a later posting will use. The user must explicitly confirm. Get expense_id from list_expenses or list_close_blockers, and read the record with get_expense before choosing an account.

propose_categorize_expense

List the people who are active members of the company: user_id, name, email and role (owner, admin, manager, approver, clerk or viewer). Use it to turn a teammate's name into the user_id that propose_assign_task, propose_assign_blocker and the assigned_to arguments take, or that list_tasks filters on. If two people match a name, ask the user which one rather than choosing.

list_company_users

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage ticking off one CLOSE CHECKLIST reminder — a row in close_tasks, the per-period checklist shown on the close cockpit. This does NOT touch general tasks: to complete one of those use propose_complete_task, which acts on a different table. The user must explicitly confirm before the reminder is marked done. Get the id from list_close_checklist; do not guess it.

propose_complete_close_task

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage marking a general TASK as completed — a row in the tasks table, the ordinary to-do list. This is NOT the close checklist: to tick off a per-period close reminder (close_tasks) use propose_complete_close_task, which acts on a different table. The user must confirm before it is applied. An optional completion note is recorded as a task comment.

propose_complete_task

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage confirming a proposed bank-to-payment reconciliation match. The user must explicitly confirm before the match is applied and the payment is marked cleared. Get match_id from list_bank_match_candidates for that bank line: when its route is payment_match_proposal, payment_match.match_id is the id. Use propose_reject_match instead if the proposed payment is wrong.

propose_confirm_payment_match

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage raising a DRAFT close adjustment — an accrual, prepaid, depreciation or other period-end entry. A draft books nothing; posting it is a separate step the user confirms separately (propose_post_close_adjustment). Give it EITHER debit_account_id + credit_account_id + amount (the usual shape, and the only one that can later be trued up against the actual invoice), OR a lines array of at least two balanced lines. Never both. The fiscal period follows from entry_date — you do not choose it. The user must explicitly confirm; the confirmation shows them both sides and the amount.

propose_create_close_adjustment

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage creating a DRAFT journal entry with its lines. This does NOT post it to the General Ledger — a draft changes no balance. Posting is a separate step the user confirms separately (propose_post_journal_entry). Give at least two lines; each line carries EITHER a debit or a credit, never both, and the debit total must equal the credit total to the cent. Get account_id values from list_gl_accounts, using only accounts whose is_postable is true — never invent one. The user must explicitly confirm before the draft is created; the confirmation shows them every line.

propose_create_journal_entry

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage the creation of a new task. The user must explicitly confirm before the task is created. Use it when the user asks to create a task, follow-up or reminder on the general to-do list (list_tasks). Not for the per-period close checklist, which has no create tool here.

propose_create_task

Create a short-lived link for adding documents (invoices, bills, receipts, contracts, bank statement PDFs or OFX/CSV downloads) to this company's Bizdivers inbox. If you can run shell commands, upload each file yourself with the returned curl command (one file per request, the token in the X-Upload-Token header). Otherwise give the user upload_page_url to open and drop the files on. The link works for 30 minutes and up to 25 files. Each file is classified and extracted like an emailed document; nothing is approved, paid or posted — the user reviews the resulting drafts in Bizdivers. Afterwards call get_submitted_document with each returned document_id to see what it became.

create_upload_link

Add a new vendor (a supplier, contractor or other payee) to this company in Bizdivers. The vendor is saved as a draft: it cannot be paid, and invoices from it cannot be approved or posted, until a person reviews and activates it in Bizdivers. You cannot activate it; give the user the returned vendor_url so they can. If a vendor with the same name or legal name already exists, nothing is created and that vendor's id, number and status are returned with already_existed = true — use that vendor_id rather than trying again under a different spelling. Only name and vendor_type are required. Include address and contact details when you have them from a reliable source such as an invoice, and pass the page you read them from as source_url. Payment method, GL coding and 1099 settings are set by the person who activates the vendor in Bizdivers, never through this tool.

create_vendor

Return the status (open / closed / locked), name, and date range of the fiscal period that contains today's date, plus period_key, today's calendar month as YYYY-MM: pass its year and month as period_year and period_month to the other period tools. Use get_fiscal_period_status when the user names an explicit month instead.

get_current_period_status

Return the status (open / closed / locked) and date range of the fiscal period covering a specific year+month. Use to answer "is May closed yet?" for an explicit period; use get_current_period_status for today's period. Identifies the period by calendar month: the fiscal period covering that month.

get_fiscal_period_status

Stages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage flagging a vendor as a 1099 candidate (1099-eligible) with a reason, or clearing the flag with eligible false. The user must explicitly confirm. Get vendor_id from list_vendors or get_vendor.

propose_flag_1099_candidate

Get the full detail of one bank transaction by id, including amount, direction, counterparty, category, and reconciliation/match status (posted review, matched payment, linked expense). Use to answer 'what's this $X charge'. Get ids from list_transactions.

get_transaction

Get full detail for a single AP invoice (a bill from a vendor) by ID: header fields, line items, approval history, open/resolved exceptions, and vendor match status. Use after list_invoices to drill into one invoice.

get_invoice

Get full detail for a single close adjustment by ID: header fields, the journal lines with their GL accounts and vendor/customer counterparties, the source record the adjustment was raised from, the linked posted/reversal/true-up journal entries, and the matched-actual and variance trail. Use after list_close_adjustments to drill into one adjustment.

get_close_adjustment

Get one contract's full detail by id: status, counterparty, dates, value, payment and renewal terms, signature state, and the close action its current state can take. Get the id from list_contracts or from a close blocker's resource_id; do not guess it. Read close_resolution before proposing anything: it names the ONE action this contract's state can take.

get_contract

Fetch one customer by id, scoped to the current company. Returns identity, contact, and credit posture. Use list_customers first to find the id.

get_customer

Get one AR (customer) invoice in full: header, lines, the approval trail and every exception raised against it, resolved or not. This is NOT get_invoice, which reads an AP invoice from a vendor. Use it before proposing an approval: an invoice with unresolved BLOCKER exceptions cannot be approved until they are cleared, and clearing them is a different action done on the invoice's own screen.

get_customer_invoice

Get one receipt-based expense record in full, including its amounts, notes, exception state and any journal entries referencing it. Get the id from list_expenses or from a list_close_blockers row in the expenses bucket; do not guess it.

get_expense

Get one journal entry in full: the header, EVERY line with its GL account code and name and its debit/credit amount, what the lines add up to (line_debits, line_credits), whether the entry balances (is_balanced, balance_delta, header_matches_lines), and the fiscal period it sits in with that period's status. Use this after list_journal_entries or list_close_blockers to see WHY an entry is unbalanced, or to read an entry before proposing to post or reverse it. Read is_balanced, never total_debit against total_credit: those two header columns are held equal by a database constraint and always agree, so an entry the close cockpit flags as unbalanced looks fine from them. The disagreement is between the LINES, or between the lines and the header. Read is_reversed and is_reversing_entry, not status: a reversed entry keeps status 'posted' and is answered by a separate contra entry, and the pair nets to zero — do not describe either half as a live movement.

get_journal_entry

Check what happened to a document added through an upload link, by the document_id the upload returned: whether it is still being read, what kind of document it was classified as, what it became, what a person has to do next (next, record_url) — and, for an invoice, charge_match: whether a bank line already on the books pays it, so the bill is paid from that charge rather than the charge being booked a second time. Only documents this company received through a connector can be read.

get_submitted_document

Get full detail for one task by id: fields, the linked business entity (invoice/vendor/contract/etc.), and the comment thread, 50 comments at a time starting from the newest (comments_total and comments_truncated say whether older ones exist; pass comments_offset to page back). Use after list_tasks when the user asks for the details of a specific task.

get_task

Get detail for a single vendor by ID: identity, 1099/W-9 tax state, contact, address, and payment defaults. Use after list_vendors to drill into one vendor.

get_vendor

Render the Income Statement for a period: revenue, cost of revenue, operating expenses and other income/expense by account, plus net income. An Income Statement covers a RANGE, so it takes both ends. Name the period with period_year/period_month (the fiscal period covering that month is used, start to end) — that is the form to use when working on a close. Use period_start + as_of_date instead only for a free-form range; supplying both forms is an error, and omitting everything reports the calendar year to date. READ THIS BEFORE PROPOSING A STATEMENT SIGN-OFF: finalizing a period whose numbers you have not looked at is not a review.

get_income_statement

List the company's chart of accounts: id, account_code, account_name, account_type, account_subtype, is_active, and is_postable. is_postable is the ONLY flag that says whether a journal entry line may name this account directly — NEVER derive postability from is_control_account, is_bank_account or is_system_account; those three describe the account's role, not whether it accepts a posting (a bank GL account IS postable; the company's AR/AP default account is NOT, and carries none of the three role flags). Only propose accounts where is_postable is true. Use this to resolve an account's id before calling a tool that takes gl_account_id, or to discover an account with no activity in the current period (get_trial_balance only lists accounts that have a balance). Filter by account_type (a single type; omit to see every type — the underlying chart also supports several types per call but this tool only exposes one at a time), active_only (default true, set false to include inactive/archived accounts), or search over account_code and account_name. A user still names an account by its CODE in conversation ("code it to 6110") — that is the natural interface, and this tool exists to resolve a code (or discover one) to an id, not to replace it.

list_gl_accounts

List the company's connected bank accounts with their type, institution, status, and balances. Use to identify which account a transaction belongs to or to answer 'list my bank accounts'. BALANCES: account_type 'depository' is a checking or savings account and its balance is money the company HAS. account_type 'credit' is a credit card and its balance is money the company OWES (positive means owed; negative means the card is overpaid). account_type 'loan' is a mortgage, term loan or line of credit and its balance is also money the company OWES. NEVER add a credit or loan balance to a depository balance — they are opposite sides of the balance sheet, so the sum is not a total of anything. Report cash, cards and loans as three separate figures; a card balance is spending and a loan balance is borrowing, so do not add those two together either. ledger_balance is the posted balance on either type. available_balance is the posted balance minus pending holds on a depository account, but on a credit card or a loan it is the REMAINING CREDIT LINE or undrawn facility, never the amount owed — so never quote a card's available_balance as its balance, and if a card has no ledger_balance, say its balance is not synced rather than reporting zero or the credit line. COVERAGE: a connected account's feed reaches back only to feed_history_start; older dates come only from uploaded statements or an earlier connection. history_gaps are dates no source covers: activity there is MISSING, not absent, and a likely reason book cash differs from the bank. Say so and ask for the statement for those dates (Banking > Reconciliation); never invent an opening balance. history_coverage_unknown means gaps could not be checked, so an empty result is not evidence of no activity.

list_bank_accounts

List bank transactions for the company, newest first. Optional filters: bank account, date range (from_date/to_date as YYYY-MM-DD), direction (credit=inflow, debit=outflow), and reconciled status. Use to answer questions like 'show unreconciled transactions in May' or 'list debits on the checking account'. When the requested range overlaps dates the books do not hold for an account, the result carries history_gaps naming them. COVERAGE: a connected account's feed reaches back only to feed_history_start; older dates come only from uploaded statements or an earlier connection. history_gaps are dates no source covers: activity there is MISSING, not absent, and a likely reason book cash differs from the bank. Say so and ask for the statement for those dates (Banking > Reconciliation); never invent an opening balance. history_coverage_unknown means gaps could not be checked, so an empty result is not evidence of no activity.

list_transactions

List AP (accounts payable) invoices — the bills the company received from its vendors — newest first. Not invoices the company issued to its customers: those are list_customer_invoices. Filter by status, vendor, invoice-date range, and total-amount range. Use this to answer questions like 'what invoices are pending approval' or 'show invoices over $5,000 from last month'. For full detail on one invoice (line items, approvals, exceptions) use get_invoice.

list_invoices