create_upload_link
ChatGPTCreate 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_vendor
ChatGPTAdd 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.
get_ap_aging
ChatGPTReturn the accounts-payable aging report: open AP bucketed by days past due (current, 1-30, 31-60, 61-90, 90+), with company totals and a per-vendor breakdown. Defaults to as-of today. The company totals always cover every vendor; the per-vendor rows are paged (limit/offset), with vendors_total and truncated saying whether more remain. Answers "what's my AP aging".
get_balance_sheet
ChatGPTRender the Balance Sheet: every account with a placement, grouped by section, plus total assets, liabilities and equity. A Balance Sheet is a position at a single date, so it takes an as-of date and no start date. Name the period with period_year/period_month (the fiscal period covering that month is used, as of its END date) — that is the form to use when working on a close, because it is the same period the sign-off record is keyed on. Use as_of_date instead only for a free-form question about a specific date. Supplying both is an error. READ THIS BEFORE PROPOSING A STATEMENT SIGN-OFF: finalizing a period whose numbers you have not looked at is not a review. Accounts listed under unmapped carry a balance and appear on no statement, so the totals exclude them — say so rather than reporting the statement as complete.
get_bank_reconciliation
ChatGPTGet 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_cash_forecast
ChatGPTReturn 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_close_adjustment
ChatGPTGet 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_cockpit
ChatGPTGet 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_plan
ChatGPTGet 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_contract
ChatGPTGet 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_current_period_status
ChatGPTReturn 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_customer
ChatGPTFetch 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_invoice
ChatGPTGet 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_expense
ChatGPTGet 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_financial_statement_review
ChatGPTGet the financial-statement sign-off record for a fiscal period: whether a review exists, what state it is in, who prepared/reviewed/finalized it, and whether it still blocks the close. This is the tool for "are the statements signed off for August?" — the close cockpit's financial_statements bucket is cleared only when this answers status "finalized". The record is keyed on the period's EXACT start and end dates: a year-to-date review is not a sign-off on one month, so this always reports the dates it answered about. next_status names the one legal forward move; pass it to propose_transition_fs_review. Omit period_year/period_month for the company's latest OPEN period.
get_fiscal_period_status
ChatGPTReturn 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_income_statement
ChatGPTRender 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_invoice
ChatGPTGet 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_journal_entry
ChatGPTGet 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_proposal
ChatGPTRead one staged proposal by the proposal_id a propose_* tool returned: its status now (pending, confirmed, rejected, expired or superseded), the full summary of what confirming it does, the record it created or changed once confirmed (committed_entity_kind, committed_entity_id), and, when a confirm was refused, last_confirm_error with the exact message the person saw. Call it after the person says they confirmed, or that it did not work, instead of asking them for a screenshot.
get_submitted_document
ChatGPTCheck 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_task
ChatGPTGet 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_transaction
ChatGPTGet 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_trial_balance
ChatGPTReturn the full trial balance for a fiscal period: every account that has a balance, its debit/credit column, and the period totals. Accounts with no activity (zero balance) are omitted, matching the standard trial-balance report. As-of the last day of the period, on the company's accounting basis. Use this for "show the trial balance for May"; use get_trial_balance_imbalance when you only need the variance. Identifies the period by calendar month: the fiscal period covering that month.
get_trial_balance_imbalance
ChatGPTReturn the trial-balance debits, credits, and variance for the given fiscal period. A non-zero variance means the books are out of balance and must be reconciled before close. Identifies the period by calendar month: the fiscal period covering that month.
get_vendor
ChatGPTGet 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_concentration
ChatGPTReturn vendor concentration of open accounts payable: the top-N vendors by outstanding balance, each vendor's share of total open AP, plus the AP universe totals. Use to assess vendor-dependency risk. Defaults to top 10 as of today.
list_bank_accounts
ChatGPTList 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_match_candidates
ChatGPTFor 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_reviews
ChatGPTList 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_close_adjustments
ChatGPTList close adjustments (AP accruals, prepaid setup/amortization, depreciation, payroll accruals, manual entries, true-ups) for the company, newest first. Filter by the fiscal period covering a calendar month, and by status. Status means: 'draft' = proposed but NOT yet posted to the GL, which is what a pending close adjustment is; 'posted' = booked to the GL; 'reversed' = its posting journal entry was VOIDED, so it is no longer in the GL; 'cancelled' = the draft was dropped before posting. A scheduled auto-reversal does NOT change status: an accrual that has already auto-reversed stays 'posted' with reversal_je_id set, and one whose reversing entry is still owed stays 'posted' with reversal_pending true — so to find accruals still waiting to reverse, filter status 'posted' and look at reversal_pending, do NOT filter on 'reversed'. Adjustments never assigned to a fiscal period are excluded whenever you filter by period. Use this to answer "what close adjustments are pending for this period?". For the lines, source document, and matched-actual/variance detail of one adjustment, use get_close_adjustment.
list_close_blockers
ChatGPTList 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_checklist
ChatGPTList 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_company_users
ChatGPTList 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_contracts
ChatGPTList the company's contracts, newest first, with the close action each one's CURRENT state can take. Use this for the close cockpit's contracts bucket, for "which contracts are waiting for approval", and for "what has expired". Every row carries close_resolution: "review_contract" (the contract is awaiting approval), "terminate_contract" (it is active and past its expiry date), or absent (it is not blocking the close). Act on that field — review and terminate are answers to different states, and proposing the wrong one sends the user to a button that does not exist. Contracts are NOT tied to a fiscal period: this bucket is evergreen, so there is no period argument and no period filter. For one contract's full detail use get_contract.
list_customer_invoices
ChatGPTList AR (accounts receivable) CUSTOMER invoices — the ones this company issued to its customers — newest issue date first. This is NOT list_invoices, which lists AP invoices the company received from its vendors; they are different tables and answering an AR question from the AP list is wrong, not approximate. Filter by status, customer, and DUE-DATE range. Use the due-date range to answer close questions about the customers blocker bucket, which is the bucket that keys period membership on due_date. For one invoice's lines, approvals and unresolved exceptions use get_customer_invoice.
list_customers
ChatGPTList the company's customers (accounts receivable), alphabetically by name, with an optional status filter. Use to answer "who are my customers" or to find a customer_id for get_customer, list_customer_invoices or list_revenue_requests.
list_expenses
ChatGPTList receipt-based EXPENSE records — the work behind the close cockpit's expenses bucket. An expense blocks a close when its receipt date falls in the period AND it is either flagged needs_review or has no GL account; blocks_close on each row is that test already applied, so you do not have to re-derive it. Use propose_categorize_expense to clear one — it sets the GL coding and marks the support reviewed together, which is what the bucket needs. For the authoritative list of what is blocking ONE period, call list_close_blockers with bucket_key "expenses" instead; this tool has no period filter.
list_gl_accounts
ChatGPTList 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_invoices
ChatGPTList 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_journal_entries
ChatGPTList journal-entry headers dated inside the given fiscal period, newest first, with an optional status filter (e.g. posted, draft). Returns totals per entry; for an entry's lines, or to see why it is unbalanced, call get_journal_entry. Identifies the period by calendar month: the fiscal period covering that month.
list_missing_w9_vendors
ChatGPTList vendors flagged as 1099-eligible that do not yet have a W-9 on file. Required before year-end 1099 generation; surfaced as a year-end close blocker. To ask for one, propose_request_w9. Paged: total is the full count, and truncated is true when more vendors remain past this page.
list_open_invoices_for_period
ChatGPTList AP invoices (bills from vendors) dated inside the given fiscal period that are not yet fully approved and posted. Useful when investigating close blockers tied to AP. Identifies the period by calendar month: the fiscal period covering that month.
list_payments
ChatGPTList vendor payments for the company, most recent payment-date first. Filter by status, vendor, and payment-date range. Use to answer questions like 'which payments are scheduled' or 'show payments to vendor X last quarter'.
list_possible_duplicates
ChatGPTList the open possible duplicates in the General Ledger: journal entries that look like the same money booked twice (a pending bank line booked and then booked again from its posted copy, an own-account transfer booked from both feeds, or two entries with the same amount on the same accounts within a few days), plus one-entry findings for a bank line the bank withdrew. Each finding carries its reason, a plain-English explanation, a recommendation naming which entry to keep and which to reverse (recommended_reverse_entry_id), and both entries with their lines, source and bank lines. Use finding_id to read ONE finding (the id list_close_blockers names for a possible_duplicates blocker). Walk them with the user: an entry with undo_through is undone from its source document, never reversed. To act, stage propose_reverse_possible_duplicate (books a contra for one entry) or propose_dismiss_possible_duplicate (records that they are two real transactions, or a duplicate already corrected elsewhere). Nothing here is applied. These are advisory: they warn on the close cockpit but never block a close.
list_proposals
ChatGPTList the changes staged for the calling user with propose_* tools, newest first, and what became of each. That includes changes staged by the in-app assistant and by every client the user connected, not only by you. Status is pending (waiting for a person), confirmed (done — committed_entity_kind and committed_entity_id name the record it created or changed, such as a draft journal entry to post next), rejected, expired, or superseded. A pending proposal whose confirm was refused carries last_confirm_error with the exact message the person saw — read it before re-staging anything or asking the person what went wrong. Use it to check whether a confirm happened instead of inferring it from balances. Each row's next field says what the status means. Paged: total is the full count, and truncated is true when more rows remain past this page.
list_receipt_link_suggestions
ChatGPTList the company's receipt-based expenses that are not linked to any bank line, each paired with the ALREADY-BOOKED bank-feed line it most looks like (amount, date and merchant), best candidate only. This is the backfill for receipts that arrived after their charge was booked: walk it with the user and stage each link with propose_link_expense_to_bank_line; nothing here is applied. A receipt whose charge is not booked yet, or that has no candidate above the matcher's threshold, is not listed — list_expenses with match_status=unmatched shows every unlinked receipt regardless. Pages over the UNLINKED receipts, newest first: a page can hold fewer suggestions than limit, or none, while later pages still hold some, so page on has_more (receipts_scanned == limit), never on count.
list_revenue_requests
ChatGPTList revenue requests — requests to bill a customer that have not yet become a customer invoice — newest first. Optional filters by status or customer_id. For invoices already issued to customers use list_customer_invoices; for what customers owe, use list_customer_invoices with a status filter.
list_statement_lines
ChatGPTList the lines of bank statements uploaded for connected accounts, newest first, with how each compared to the bank feed (match_kind: exact, fuzzy or none) and what was decided about it (resolution: open, matched, gap_filled or dismissed — dismissed means set aside, with resolution_note). An OPEN line blocks its month's reconciliation unless frozen_period is set. Then that month is already reconciled, the line blocks nothing, and it cannot change until a person reopens that month. By default only open lines are returned. A line that should not count, such as a pending charge the bank later dropped, can be set aside with propose_set_aside_statement_line. A FUZZY line (match_kind fuzzy) names a feed transaction that is probably the same movement: tell the user to confirm that match in the Statement panel rather than set the line aside. Each row's id is a statement line id (bank_statement_lines), not a bank transaction id. Paged: total is the full count, and truncated is true when more rows remain past this page.
list_tasks
ChatGPTList general TASKS for the company — rows in the tasks table, the ordinary to-do list — newest/highest-priority first. Optional filters: status (pending|in_progress|completed|cancelled), task_type, priority (critical|high|medium|low), assigned_to (a user_id from list_company_users), overdue, escalated. Paginated. Use this for 'show my open tasks', 'what's overdue'. Do NOT use it to answer what is blocking a period close: that is get_close_cockpit and list_close_blockers, and the per-period close reminders are a different table again (list_close_checklist). Call get_task for full detail on any one task.
list_transactions
ChatGPTList 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_unreconciled_txns
ChatGPTList bank transactions in the given fiscal period that have not been matched to a payment, expense, or journal entry yet. Common close blocker — reconciliation must be complete before close. To clear one, call list_bank_match_candidates with its id: it says whether the line is matched to something already on the books or coded through the bank review queue (list_bank_reviews). Identifies the period by calendar month: the fiscal period covering that month. Paged: total is the full count, and truncated is true when more rows remain past this page.
list_vendors
ChatGPTList vendors for the company, newest first. Filter by status, 1099-eligibility, and W-9 state (received vs missing). Use to answer questions like 'show vendor Acme', 'which 1099 vendors are missing a W-9', or 'list active vendors'. For full vendor detail use get_vendor.
propose_activate_vendor
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage activating (approving) a vendor that is in draft or pending_approval status, moving it to active so it can receive payments. The user must explicitly confirm. Get vendor_id from list_vendors or get_vendor. To fill in a vendor's details instead, use propose_update_vendor_details.
propose_approve_customer_invoice
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage approval of an AR CUSTOMER invoice — one this company issued to a customer, awaiting approval. This is NOT propose_approve_invoice, which approves an AP invoice from a vendor; they are different tables with different approval rules. The user must explicitly confirm before anything happens. On confirm the invoice runs the same gates the Approve button runs: the AR policy's independent-approver rule and the exception engine, which refuses while any blocker exception is unresolved. Get the id from list_customer_invoices.
propose_approve_invoice
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage approval of an AP invoice. The user must explicitly confirm before anything happens. On confirm the invoice runs through the full approval engine (validation blockers, required approval level, segregation-of-duties, GL posting) — exactly like the manual Approve action. If there are hard blockers the approval fails and is NOT forced through. Optionally pass override_codes (manager+ only) to downgrade overridable blockers.
propose_approve_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage recording an approval signature on a vendor payment that is awaiting approval. The user must explicitly confirm before the signature is recorded. A payment may require more than one signature: if it does, confirming records this one and the payment stays 'pending_approval' until the last one is recorded. On confirm the payment also runs the gates the Approve button runs — the vendor must be active, the fiscal period open, the W-9 policy satisfied, and an approver cannot record two signatures on the same payment. Get the id from list_payments.
propose_assign_blocker
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage assigning one close-cockpit blocker to a teammate, so it shows as theirs on the close cockpit. This records WHO will deal with the blocker — it does not resolve it. The user must explicitly confirm before the assignment is applied. Get blocker_id from list_close_blockers (it is the composite "<bucket_key>:<resource_type>:<resource_id>" id, not the bare resource id), and pass the assignee as a user UUID. Take it from list_company_users (match the teammate by name); never guess one. Pass the SAME period_year/period_month you passed to list_close_blockers, or omit both if you omitted them there.
propose_assign_invoice_gl
ChatGPTStages 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_task
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage assigning a general task to a teammate. The user must confirm before it is applied. Take the assignee's user_id from list_company_users (match the teammate by name); never guess one.
propose_balance_journal_entry
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage correcting ONE unbalanced DRAFT journal entry — the balance_journal_entry close blocker, whose resource_id is the entry id — by replacing ALL of its lines with a corrected, balanced set, as editing the draft on its own screen does. Nothing changes until someone confirms it in Bizdivers. The entry stays a draft: no balance moves until it is posted with propose_post_journal_entry, a separate step. Its date and description are kept, and each corrected line keeps the dimension codes, counterparty and memo of the existing line on the same account; a correction that would drop them is refused. Call get_journal_entry first, show the user which lines disagree and by how much, and stage ONLY the correction the user agrees to — never guess which line is wrong. Give every line the entry should have afterwards, not just the changed ones; the debits must equal the credits to the cent. A posted entry cannot be edited (use propose_reverse_journal_entry), and an entry in pending, approved or rejected status cannot be edited here.
propose_categorize_bank_review
ChatGPTStages 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_expense
ChatGPTStages 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_close_period
ChatGPTStages 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_complete_close_task
ChatGPTStages 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_task
ChatGPTStages 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_confirm_payment_match
ChatGPTStages 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_create_close_adjustment
ChatGPTStages 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_customer
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage creating ONE customer (someone this company invoices), exactly as the Customers page's New customer form does. Nothing changes until someone confirms it in Bizdivers. The customer is created active, with net 30 terms and USD unless the user says otherwise. Use the name, contact and address details the user gives; never invent them. Before staging, check list_customers so the same customer is not created twice; a live customer with the same name is refused and named. A customer is needed before propose_create_customer_invoice or propose_record_customer_payment can use it.
propose_create_customer_invoice
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage creating ONE DRAFT customer invoice (AR: an invoice this company issues to a customer), as the invoice form does. Nothing changes until someone confirms it in Bizdivers. A draft is not approved, not sent to the customer and not posted to the ledger; approving it is a separate step (propose_approve_customer_invoice). Sales tax is computed when the draft is created, from the company's tax settings. Get customer_id from list_customers (or create one with propose_create_customer first). Use the lines, quantities and prices the user gives; never invent them. The due date defaults to the issue date plus the customer's payment terms. This is NOT for vendor bills (AP); those arrive as documents in the inbox.
propose_create_expense
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage creating ONE expense record (a receipt-based support record, the Expenses page's New expense form) for a purchase the user describes. Nothing changes until someone confirms it in Bizdivers. It records the support only: nothing is posted to the ledger and no bank line is matched. Once created it is an open item in the expenses close bucket until it is coded and reviewed with propose_categorize_expense; say so. Use the merchant, date and amounts the user or a receipt gives you, never invented ones. Before staging, check list_expenses for the same merchant, date and total so the same purchase is not recorded twice.
propose_create_journal_entry
ChatGPTStages 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_task
ChatGPTStages 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_deactivate_vendor
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage deactivating ONE vendor: its status moves to inactive, exactly as choosing Inactive in the vendor page's status menu does. Nothing changes until someone confirms it in Bizdivers. An inactive vendor is never paid: its payments cannot be created, approved, scheduled, processed, printed, sent or posted, and its invoices cannot be approved or posted. So it is REFUSED while the vendor has payments in progress (pending approval, approved, scheduled, processing, completed but not yet posted to the GL, or a check not yet printed); the refusal names them, and they have to be finished, or cancelled or voided, first. Nothing is cancelled automatically. BEFORE staging, look at the vendor's open invoices and payments (list_invoices and list_payments for this vendor) and tell the user about them; the answer and the confirm card name open invoices too. It is refused for a vendor that is already inactive or terminated. Resolve the vendor to its UUID (list_vendors) first. Re-activating an inactive vendor is done from the vendor's page in Bizdivers (propose_activate_vendor only approves draft or pending vendors).
propose_dismiss_possible_duplicate
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage recording that a possible-duplicate finding is NOT a duplicate — its entries are two real transactions (resolution not_duplicate) — or that it WAS a duplicate already corrected by a separate entry (corrected_elsewhere; name that entry in the reason). Confirming writes the dismissal with the reason on the audit trail and the pair is never flagged again; nothing is posted or reversed. Take entry_ids from list_possible_duplicates (one or two ids, the finding's own). The reason must be the USER's, at least 3 characters — never invent one, and never dismiss a finding the user has not looked at. If the user wants the duplicate removed from the books, use propose_reverse_possible_duplicate instead. The user must explicitly confirm.
propose_flag_1099_candidate
ChatGPTStages 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_link_expense_to_bank_line
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage attaching ONE receipt-based expense to ONE bank-feed line that is ALREADY BOOKED (its review posted a journal entry), as the support for that entry. This posts NOTHING and moves no balance: the charge is already on the books once, and the link only records which receipt supports it, moving the expense to linked. Use it when list_bank_match_candidates answers route link_expense (take expense_id from its expense_candidates), or when list_receipt_link_suggestions pairs a receipt with a booked line. For a feed line NOT yet booked, categorize its review with propose_categorize_bank_review instead; for a statement-only line use propose_match_bank_transaction. If the preview says gl_mismatch, tell the user the receipt is coded to a different account than the entry posts to; the link does not change either. The user must explicitly confirm.
propose_link_expense_to_journal_entry
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage tying ONE receipt-based expense to the POSTED journal entry that booked it, for a receipt paid OUTSIDE the company's accounts — an owner's personal card, PayPal or cash — so no company bank line exists for it. Typical case: the user paid a company cost personally and it was booked as Dr expense / Cr that owner's capital contribution with propose_create_journal_entry; this then records the receipt as that entry's support, codes it to the account the entry debits and marks it reviewed, which is what takes it out of the expenses close bucket. It posts NOTHING and moves no balance. It is refused for an entry that pays from a company bank or card account: that receipt was paid by the company, so link it to its bank line instead (propose_link_expense_to_bank_line, or categorize the line). gl_account_id must be an account the entry debits, and is only needed when the entry debits more than one. Untying the receipt later, or reversing the entry, sends it back to review. The user must explicitly confirm.
propose_match_bank_transaction
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage matching ONE bank statement line to ONE book item that is already on the books — an AP payment, a customer receipt, an expense, or a journal entry (including the entry a transfer's other side already booked). This reconciles the line without booking anything new; the user must explicitly confirm. Take reference_type and reference_id from list_bank_match_candidates for that line, never from memory: the amounts must be equal to the cent and the server refuses anything else. It refuses a line in a month that is already reconciled, a line or item that is already matched, and — when the company requires receipts for card charges — a card charge matched to anything but an expense. For a line on a connected bank feed use propose_categorize_bank_review instead. One line at a time; there is no bulk version. bank_transaction_id is a bank_transaction id, not the statement_line_id that list_statement_lines returns.
propose_match_invoice_vendor
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage attaching a vendor record to an AP invoice whose vendor was never matched — the fix for a close blocker whose action_type is match_invoice_vendor. The user must explicitly confirm before anything is written. This changes ONLY which vendor the invoice is linked to: it cannot change an amount, a date, payment terms or the invoice status. Resolve the vendor with list_vendors first and pass its UUID; the confirmation shows the vendor name beside the name printed on the document, so check they are the same supplier before proposing. If no vendor record fits, say so — do not attach the closest one.
propose_pay_invoice_from_charge
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage paying ONE posted, open AP invoice WITH a card or bank charge that is already on the books — the first thing to try for a record_card_payment close blocker (an invoice expected to be paid by card whose charge has not been matched; its resource_id is the invoice id). Nothing changes until someone confirms it in Bizdivers. Confirming records a completed payment for the charge's amount, posts Dr Accounts Payable / Cr that account, and ties the payment to the charge line. Pass only invoice_id and the server finds the charge: one match is staged; several are listed for the user to choose (call again with bank_transaction_id); none means nothing on the books pays it, and the answer says what to do next. If the charge was already booked as an expense, paying the invoice with it reverses that booking so the expense is booked once; the confirm card says so.
propose_post_close_adjustment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage POSTING a draft close adjustment: it books its journal entry to the General Ledger and flips the adjustment to 'posted'. This is ONE WAY — a draft can be cancelled, a posted adjustment cannot be un-posted. If the adjustment has auto_reverse set, posting also books a reversing entry on the first day of the next period (or flags it pending when that period is not open yet). The adjustment's own period must be open. Call get_close_adjustment first to read what you are about to post. The user must explicitly confirm; the confirmation shows them both sides and the amount.
propose_post_journal_entry
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage POSTING an existing draft journal entry to the General Ledger. This is the step that puts the numbers into the accounts; after it the entry can no longer be edited or deleted, only reversed. The entry is posted into the fiscal period covering its own entry date — you do not choose the period. A closed or locked period refuses the post. Only a draft (or approved) entry can be posted; call get_journal_entry first to read what you are about to post. The user must explicitly confirm; the confirmation shows them every line of the entry.
propose_prepare_bank_reconciliation
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage PREPARING the bank reconciliation of ONE bank account for ONE month: the Reconciliation tab's Prepare, which freezes the worksheet into a reconciliation record awaiting an independent review. It posts nothing. It works on either door (connected feed or statement worksheet) and freezes exactly the period get_bank_reconciliation reports for that month. Call get_bank_reconciliation first: this stages nothing unless its can_prepare is true, and otherwise names the prepare_blockers to clear (unmatched lines, no statement, an unexplained difference, out of sequence, already reconciled). The ending balance comes from the statement on file; a month with none must have its statement uploaded or its balances entered on the Reconciliation tab first. review_now: only for a company owner when owner self-review is on in Settings → Banking — confirming then prepares AND signs off in one step. Otherwise leave it false and a different user signs off with propose_review_bank_reconciliation. bank_account_id comes from list_bank_accounts. The user must explicitly confirm before it is applied.
propose_process_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage SENDING an approved or scheduled vendor payment. Confirming this sends the payment: it is marked completed, posted to the general ledger, and counted into the vendor's 1099 year-to-date. No tool can undo that — reversing a sent payment means voiding it, which is a separate action taken on the payment itself. Tell the user plainly what will be sent, to whom, from which account, before asking them to confirm. The user must explicitly confirm. On confirm the payment also runs the gates the Process button runs: the W-9 policy hold, the 1099 threshold hold, and the status rules that stop an unapproved payment being sent. Get the id from list_payments.
propose_record_card_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage recording that a card paid ONE posted, open AP invoice when NO charge for it is on the books — the fallback for a record_card_payment close blocker after propose_pay_invoice_from_charge found nothing. Nothing changes until someone confirms it in Bizdivers. Confirming records a COMPLETED payment for the invoice's balance and posts Dr Accounts Payable / Cr the card, with no approval chain, on the user's word; a statement uploaded later ties to it. Ask the user which card paid (a card account from list_bank_accounts) and on what date; never pick either. If the server says a matching charge is on the books, use propose_pay_invoice_from_charge with that bank_transaction_id instead. If the card has a live feed, wait for the charge. If the invoice was not paid by card at all, no tool resolves it: the expected payment method is changed on the invoice's screen.
propose_record_customer_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage recording ONE payment a customer has already made to this company (a receipt: a check, ACH, wire, card or cash deposit), as the New customer deposit dialog does. Nothing changes until someone confirms it in Bizdivers. It is recorded UNAPPLIED and UNPOSTED: applying it to the customer's invoices and posting it to the ledger are done on the payment's screen afterwards; say so. Once recorded it is a candidate to match the deposit on the company's bank statement: the next statement upload can tie a matching bank deposit to it automatically, so the amount, date and account must be the real ones. Use the customer, amount, date and method the user or a remittance gives you; never invent them. Get customer_id from list_customers and, when the user names the bank account it was deposited to, bank_account_id from list_bank_accounts. An identical deposit already recorded (same customer, amount, date and account) is refused; one for the same customer, amount and date into another account is named so the money is not recorded twice. This is NOT a vendor payment (AP).
propose_reject_invoice
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage rejection of an AP invoice. The user must explicitly confirm before it is applied. On confirm the invoice is moved to 'rejected' and the reason is recorded — the same path as the manual Reject action.
propose_reject_match
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage rejecting a proposed bank-to-payment reconciliation match. The user must explicitly confirm before the match is rejected; if it was already confirmed, the payment's cleared status is reversed. Get match_id from list_bank_match_candidates (payment_match.match_id) for that bank line.
propose_request_w9
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage kicking off a W-9 request for a vendor by creating a follow-up task to collect the W-9. The user must explicitly confirm. It does not email the vendor. Get vendor_id from list_missing_w9_vendors or list_vendors.
propose_resolve_customer_invoice_exception
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage resolving ONE open exception on a customer invoice — a flag the AR exception engine raised (a mismatch against the contract or SOW, a missing approval, a duplicate billing period, and so on). A resolve_customer_invoice close blocker is a customer invoice with one or more of these open; its resource_id is the invoice id. Nothing changes until someone confirms it in Bizdivers. Resolving records a judgement that the flag has been dealt with, with a note, exactly as the invoice screen's Resolve button does; it does not change, approve, send or post the invoice. Call get_customer_invoice first to read the open exceptions and their ids, explain each to the user, and stage one per exception, with the user's own reason as the note — never invent a reason, and never resolve a flag to get past it. If the flag points at a real problem (a wrong amount, a missing contract), the fix is on the invoice's screen, not here. The over-threshold extra-approval flag is an approval and is refused here: a person clears it in Bizdivers. Approving the invoice afterwards is propose_approve_customer_invoice.
propose_reverse_journal_entry
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage REVERSING a posted journal entry by booking a contra entry against it. This does NOT un-post, delete or edit the original entry. The original stays posted exactly as it is. A separate contra entry is booked beside it, mirroring every line (each debit becomes a credit of the same amount and each credit a debit), dated the reversal date you give — which may fall in a later period than the original, in which case the original's own period still carries it. This is the only way to correct a posted entry — a posted entry cannot be edited or deleted. To restate it, reverse it and then create and post a corrected entry. A reason of at least 10 characters is required and goes on the audit trail. The user must explicitly confirm; the confirmation shows them the entry being reversed, line by line.
propose_reverse_possible_duplicate
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage reversing ONE journal entry of a possible-duplicate finding, so the money is on the books once. Confirming books a dated contra entry on the reversed entry's own date (the original stays posted beside it — nothing is edited or deleted), sets aside the bank review it was booked from so the line is not booked again, and records why on the audit trail. Take entry_ids from list_possible_duplicates; reverse_entry_id defaults to the finding's recommended_reverse_entry_id and must be one of entry_ids. The reason must be the USER's, at least 10 characters. Refused for an entry with undo_through (an AP payment, customer receipt or customer invoice posted it; only that document's own void undoes it — point the user at its href), and at confirm time for an entry dated in a reconciled bank month or a closed fiscal period, with the way out. If both entries are real, use propose_dismiss_possible_duplicate instead. The user must explicitly confirm.
propose_review_bank_reconciliation
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage the independent REVIEW SIGN-OFF of a prepared bank reconciliation, the second signature the month-end close requires. It posts nothing; it marks the record reviewed with the confirming user as reviewer. reconciliation_id is record.id from get_bank_reconciliation, when record.status is prepared. The reviewer must be a different user than the one who prepared it (record.prepared_by_user_id): this is refused at staging when you prepared it, and again at confirm when the confirming user did. Owner self-review does not apply here — it only exists as preparing and signing off together (review_now on propose_prepare_bank_reconciliation). A reviewed or reopened record is refused. The user must explicitly confirm before it is applied.
propose_review_contract
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage a human review sign-off on a contract, which activates it. This is the resolution for a contract whose close_resolution is "review_contract" — one awaiting approval. It is NOT how an expired contract is dealt with: for those use propose_terminate_contract. Confirming records that the user personally confirmed all four review assertions (the contract is valid and not expired, it is signed by both parties, the vendor matches the invoice, and the work is within scope) against their name, so tell them that is what they are being asked, and do not confirm anything on their behalf. Only vendor contracts activate this way; a customer contract has to go through the signed-validation gate on its own screen. Get contract_id from list_contracts or get_contract; do not guess it.
propose_schedule_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage scheduling an already-approved payment for a given payment date. The user must explicitly confirm. On confirm the payment moves from 'approved' to 'scheduled' with the chosen date. The payment MUST already be approved — scheduling can never bypass the approval chain; if the payment is not approved the action fails.
propose_set_aside_statement_line
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage SETTING ASIDE one open line of an uploaded bank statement, with a note saying why, so it stops blocking that month's reconciliation. This is the Statement panel's "Set aside": it posts nothing and changes no balance, and the note goes on the reconciliation record. Use it only for a line that should not count — for example a pending charge the bank dropped, or a line the bank printed in error — never to hide a real movement that still needs booking. Not for a FUZZY line whose feed candidate is the same movement: the user confirms that match in the Statement panel instead. A line in a month that is already reconciled (frozen_period in list_statement_lines) is refused; that month must be reopened first. statement_line_id is a bank_statement_lines id from list_statement_lines only. It is not a bank_transaction_id and not a close blocker's resource_id, which name a different record. The user must explicitly confirm before it is applied.
propose_submit_payment
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage submitting a DRAFT vendor payment for approval. The user must explicitly confirm before anything happens. On confirm the payment moves from 'draft' to 'pending_approval' — and, if the company's AP policy allows automatic approval for this amount and vendor, straight to 'approved' in the same step. Get the id from list_payments.
propose_terminate_contract
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage terminating a contract, recording the reason. This is the resolution for a contract whose close_resolution is "terminate_contract" — one that is still active but past its expiry date. It is NOT how a contract awaiting approval is dealt with: for those use propose_review_contract. Terminating is a legally meaningful state change and it can strand invoices that were relying on the contract, so the user must explicitly confirm, and the reason is required. Get contract_id from list_contracts or get_contract; do not guess it.
propose_transition_fs_review
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage moving a period's financial-statement review to its next state: under_review, ready_for_close, finalized (the sign-off that clears the close cockpit's financial_statements bucket), draft, or reopened. READ THE STATEMENTS FIRST with get_balance_sheet and get_income_statement, and tell the user what they say. Staging a sign-off on figures nobody has looked at is not a review. Post every journal entry and adjustment for the period BEFORE proposing a sign-off — finalizing snapshots the figures, and anything posted afterwards reports as drift against them. A period cannot be finalized before its end date has passed. A finalized period can only be reopened, and reopening needs a written reason. Call get_financial_statement_review first and pass its next_status; the period is named by calendar month, and the exact dates signed off are the fiscal period's own. Omit period_year/period_month for the company's latest OPEN period.
propose_unassign_task
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage removing the assignment from a task (leaving it unassigned). The user must confirm before it is applied.
propose_update_task_status
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage moving a general task (list_tasks) to pending, in_progress or cancelled. The user must confirm before it is applied. To mark a task done use propose_complete_task; to tick off a close-checklist reminder use propose_complete_close_task.
propose_update_vendor_details
ChatGPTStages a change for a person to confirm in Bizdivers; nothing changes until they do. Returns a confirm_url to give the user. Stage filling in a vendor's master data — legal name, contact details, address, payment terms and 1099 payment category — the fix for a close blocker whose action_type is update_vendor_details. The user must explicitly confirm before anything is written. Only the fields you name are changed; everything else is left exactly as it is. It cannot change the vendor's name, its status, its tax ID, whether a W-9 was received, its 1099 eligibility, its remit-to address or its credit terms — each of those has its own route: use propose_activate_vendor to approve a vendor, propose_request_w9 for a missing W-9, and propose_flag_1099_candidate for 1099 eligibility. Ask the user for values you do not have; never invent an address or a contact.
retry_submitted_document
ChatGPTProcess again a document that was added through an upload link and failed, without uploading the file again. Use it after get_submitted_document reports status "failed" (or "unclassified") and the cause named in next or error_message has been fixed — for example after the user turns on manual reconciliation for a bank statement. It works only on documents this company received through a connector, and only once they have stopped processing; a document still being read, or already processed, is refused. The same document can be retried at most once every 2 minutes. Returns the same fields as get_submitted_document, showing where the new attempt ended. If it fails again for the same reason, tell the user rather than retrying in a loop. If this call times out, the retry keeps running; check it with get_submitted_document. Nothing is approved, paid or posted: a successful retry files a draft the user reviews in Bizdivers.
search_documentation
ChatGPTSearch the Bizdivers product documentation and tutorials for how-to guidance, feature explanations, and setup steps. Use this whenever the user asks how to do something in the product, what a feature does, or where to find a screen. Returns documentation excerpts written for users — it does NOT read the user's own data, so pair it with the other read tools when a question needs both.
