BILL

Purpose: Provides details of a particular AP payment, found by its confirmation number rather than a payment ID, for a payment sent to a vendor. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - Use when the user has a P-prefixed confirmation number from a payment they sent. Accepts confirmation numbers of the form "P12345678 - 1234567" (P prefix, 8 digits, dash, 7 digits). Not for incoming/customer-side payments (C or R prefix). - The result already carries the same full payment detail as payables_get_payment, including billPayments[] (one entry per bill paid). A follow-up question about the bill this payment covers goes straight to payables_get_bill with a billPayments[].billId; do not re-fetch via payables_get_payment first.

payables_find_payment_by_confirmation

Purpose: Fetch one AR (accounts receivable) invoice by id, which represents money owed by a customer to the AR organization. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - To resolve an invoice NUMBER (e.g. "invoice 002", not an invoice id) to an invoiceId first, use receivables_list_invoices. - To check whether a financed invoice's loan was disbursed, and how much was funded, use receivables_get_invoice_financing_details.

receivables_get_invoice

Purpose: Provides details of a particular AP payment, including its status, how it was disbursed, such as check or ACH, and whether it can still be cancelled. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - This tool is the one payment-detail call: status, delivery pipeline, disbursement method and details, and cancel/void state are all on its response. Example: "where is my payment in the delivery pipeline" or "the tracker shows delivered but it's not arrived" -- its tracker and singleStatus fields answer both directly. - "Why is my payment on hold (at this/some stage)?" and other "on hold"/"stuck"/"stage" phrasings are this tool's tracker/singleStatus/disbursementStatus question. - A follow-up on one specific row from an earlier payables_list_payments result that needs detail the list row doesn't carry (disbursement, tracker, cancel state, or which bills a payment with a null row billId covered) means call this tool with that payment's id -- never payables_list_bills (bills don't reference payments) and never payables_list_payments again (the row is already in hand). A row with a non-null billId already names its one bill. - This tool's response does not include the bill's own fields (due date, amount owed, description, line items) -- when the question asks about the bill itself, not just which bill a payment covers (e.g. "what bill does this cover" followed by any detail about that bill), read billPayments[].billId from this response and call payables_get_bill with it; do not treat this tool's own payment-detail answer as a substitute for the bill's detail. - Takes a sent-payment id (begins with stp). A received-payment id (begins with 0rp) is a customer payment: use receivables_retrieve_payments with filters: { id: { eq: "<that id>" } }.

payables_get_payment

Purpose: Fetch one AP (accounts payable) bill by id, which represents money this organization owes a vendor. Its amount is in the bill's own currency (the currency field), not the organization's base currency. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - The response includes payments[]: the payments applied to the bill (id, amount, processDate). Those entries carry no status. For the full status/detail of those payments (status, singleStatus, disbursementType, confirmationNumber), take their ids (begin with "stp"). For one payment ("the first payment"), call payables_get_payment with its id. For two or more ("those payments"), call payables_list_payments once with filters: { id: { in: ["stp1", "stp2"] } }, not payables_get_payment per id. Note: the total actually paid is the bill's paidAmount, not the sum of payments[].amount (a cancelled or uncleared payment appears in payments[] but does not count toward paidAmount).

payables_get_bill

Purpose: Provide a list of AR (accounts receivable) invoices, which represent money customers owe the organization. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - Never send a filter or sort field this tool does not declare, even when the user's phrasing implies one. If no declared field covers the request, call with the closest supported default instead and tell the user that constraint could not be applied, or ask the user how to proceed. Never fabricate a field name to satisfy the request. - When a term the user uses (e.g. "reversed", "bounced", "e-payment") maps to multiple concrete values, filter on the broader set (in: [...]) rather than guessing one; the user sees every match and can narrow down themselves in a follow-up. - No customer name filter; only customerId. - Invoices with a due-date constraint ("due before July 2026", "overdue invoices"): filter on dueDate. Calling Conventions: - State Persistence: If a follow-up message asks for a different sort or filter than the last call (e.g. "sort by createdTime instead" or "now show only X" after an earlier call), call this tool AGAIN with the updated sort/filters args. Never re-order or re-filter the rows already in the conversation; that set may not contain the true top/matching results across the full dataset. - Cursor Reset: sort and filters are dropped when page is provided (the backend rejects combining a page cursor with sort/filters). If the user wants a page 2+ WITH a new sort/filter, start over from page 1 with the new sort/filters, not the old cursor. - Undocumented Fields: A field not in the documented filter list is rejected by this tool before any backend call (it is not tried server-side). If the field exists on this tool's output, fetch all pages and filter on the returned rows client-side instead; this is the expensive path (the full result set, not a narrowed one), so prefer the documented fields when they cover the request. - Negation Handling: When the user's request contains exclusions or negations ("not", "excluding", "without", "except"), read the ENTIRE sentence and, if needed, the previous sentence to understand the full context before selecting filter values. The negation may apply to the complete context, not just the immediately adjacent word. - Temporal Operators: Map "after" to gt and "before" to lt (exclusive); "since" and "from" to gte and "until" and "through" to lte (inclusive). A bounded period is two clauses, one gte and one lte. Filters: A range is two clauses, one gte one lte. Money fields are USD only. Status meanings: OPEN = no payment received yet; PARTIAL_PAYMENT = partly paid, the rest still owed; PAID_IN_FULL = fully paid, nothing owed. When the user asks how much customers owe or the outstanding balance, filter { status: { in: ["OPEN", "PARTIAL_PAYMENT"] } }: both still carry a balance, and totalDueAmount adds up that balance. For a plain list or count of open invoices, filter { status: { eq: "OPEN" } }. Sort: Append ":asc" or ":desc" to a field name. Omit unless the user asks for a specific order. Pagination: Omit max unless the user names a count; disclose the 100-item cap if they ask for more than that. page is an opaque cursor from the previous response's nextPage, never guessed. Aggregation / count questions: Read totalCount, totalDueAmount for the true total (not row count, not count/totalAmount; those reflect only the fetched batch). Example: "How many X do I have?" → answer with totalCount from the response, not row count. Count questions must STILL show the results card (never hide it; _display="hidden" is wrong here); the user verifies the count on the card. Correction & Degradation: - An unrecognized sort field does not fail the call; the sort is dropped, the rows come back in the default order, and the result's summary says so. Tell the user their requested order wasn't applied, don't present the result as if it were sorted the way they asked.

receivables_list_invoices

Purpose: Provides a list of outgoing AP payments sent to vendors, most recent first (newest process date first by default), with totals across all matching payments. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - Never send a filter or sort field this tool does not declare, even when the user's phrasing implies one. If no declared field covers the request, call with the closest supported default instead and tell the user that constraint could not be applied, or ask the user how to proceed. Never fabricate a field name to satisfy the request. - When a term the user uses (e.g. "reversed", "bounced", "e-payment") maps to multiple concrete values, filter on the broader set (in: [...]) rather than guessing one; the user sees every match and can narrow down themselves in a follow-up. - To answer what customers PAID US, meaning money received from customers (the opposite direction from this tool), use receivables_retrieve_payments. - Not for looking up a specific payment by ID; use payables_get_payment. - referring to a list of payments made to vendor by an AP organization - for listing AP payments to vendor and filtering by criteria. - for finding a payment by its transaction number or payment reference (e.g. TXN-…), which is not a confirmation number: { transactionNumber: { eq: "<number>" } }. - Default direction: a payment ask is money out and belongs here unless it signals money received from customers ("customer payments", "payments received", "came in"), which is receivables_retrieve_payments. A follow-up that only narrows an earlier list keeps that list's direction. - To find which bill a payment covered, read the row's billId; for the bill's own details pass it to payables_get_bill. A null billId means the payment covered several bills: call payables_get_payment with the payment id and read billPayments[].billId. Never payables_list_bills (bills don't reference payments). - For the full status/detail of the payments applied to a bill: payables_get_bill returns that bill's payments[] (id, amount, processDate); take those payment ids (begin with "stp") and pass them here as filters: { id: { in: ["stp1", "stp2"] } } to get the full rows (status, singleStatus, disbursementType, confirmationNumber). This tool has no bill argument; the bill id is not a payment filter field. Calling Conventions: - State Persistence: If a follow-up message asks for a different sort or filter than the last call (e.g. "sort by description instead" or "now show only X" after an earlier call), call this tool AGAIN with the updated sort/filters args. Never re-order or re-filter the rows already in the conversation; that set may not contain the true top/matching results across the full dataset. - Cursor Reset: sort and filters are dropped when page is provided (the backend rejects combining a page cursor with sort/filters). If the user wants a page 2+ WITH a new sort/filter, start over from page 1 with the new sort/filters, not the old cursor. - Undocumented Fields: A field not in the documented filter list is rejected by this tool before any backend call (it is not tried server-side). If the field exists on this tool's output, fetch all pages and filter on the returned rows client-side instead; this is the expensive path (the full result set, not a narrowed one), so prefer the documented fields when they cover the request. - Negation Handling: When the user's request contains exclusions or negations ("not", "excluding", "without", "except"), read the ENTIRE sentence and, if needed, the previous sentence to understand the full context before selecting filter values. The negation may apply to the complete context, not just the immediately adjacent word. - Temporal Operators: Map "after" to gt and "before" to lt (exclusive); "since" and "from" to gte and "until" and "through" to lte (inclusive). A bounded period is two clauses, one gte and one lte. Filters: A range is two clauses, one gte one lte. Money fields are USD only. Vendor exclusion ("not X") isn't a vendor-argument option; resolve to id, then { vendorId: { ne: "<id>" } }. Sort: Append ":asc" or ":desc" to a field name. Comma-separate additional field:direction pairs for multiple keys, applied in the order given. Omit unless the user asks for a specific order. Pagination: Omit max unless the user names a count; disclose the 100-item cap if they ask for more than that. page is an opaque cursor from the previous response's nextPage, never guessed. Aggregation / count questions: Read totalCount, totalAmount for the true total (not row count, not count/totalAmount; those reflect only the fetched batch). Example: "How many X do I have?" → answer with totalCount from the response, not row count. Count questions must STILL show the results card (never hide it; _display="hidden" is wrong here); the user verifies the count on the card. Correction & Degradation: - An unrecognized sort field does not fail the call; the sort is dropped, the rows come back in the default order, and the result's summary says so. Tell the user their requested order wasn't applied, don't present the result as if it were sorted the way they asked.

payables_list_payments

Purpose: Provide a list of AP (accounts payable) recurring-bill templates, which represent reusable schedules that automatically generate bills for a vendor on a period, such as monthly. Distinct from a payment schedule or autopay: this only creates bills on a schedule and never pays them; each row's autoPayment says whether its bills pay automatically (autopay). Each row's billsCount is how many bills the template has generated so far. Answer "over $500" by comparing each row's per-occurrence amount. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Never send a filter or sort field this tool does not declare, even when the user's phrasing implies one. If no declared field covers the request, call with the closest supported default instead and tell the user that constraint could not be applied, or ask the user how to proceed. Never fabricate a field name to satisfy the request. - When a term the user uses (e.g. "reversed", "bounced", "e-payment") maps to multiple concrete values, filter on the broader set (in: [...]) rather than guessing one; the user sees every match and can narrow down themselves in a follow-up. - Not for one-off (non-recurring) bills, or the bills a template generated and their actual billed history (filter recurringBillId); use payables_list_bills. - Not for payment status or payment history on bills a template has generated; use payables_list_payments. - For "all my recurring bills", pass max 100 (the cap) and tell the user when totalCount is larger. - Sort only by createdTime or updatedTime. For "sorted by next due date" or end date, omit sort and tell the user that order is not available; schedule.nextDueDate is filter-only. - Pass only the vendor's name as vendor: in "my Acme retainer" the vendor is "Acme"; retainer, subscription or rent describes the bill, not the vendor. - A row's amount is what one generated bill charges (per occurrence); totalAmount sums those per-occurrence amounts across the matched templates. Neither is a sum of bills already generated, so never report either as what a template has billed. Calling Conventions: - State Persistence: If a follow-up message asks for a different sort or filter than the last call (e.g. "sort by archived instead" or "now show only X" after an earlier call), call this tool AGAIN with the updated sort/filters args. Never re-order or re-filter the rows already in the conversation; that set may not contain the true top/matching results across the full dataset. - Cursor Reset: sort and filters are dropped when page is provided (the backend rejects combining a page cursor with sort/filters). If the user wants a page 2+ WITH a new sort/filter, start over from page 1 with the new sort/filters, not the old cursor. - Negation Handling: When the user's request contains exclusions or negations ("not", "excluding", "without", "except"), read the ENTIRE sentence and, if needed, the previous sentence to understand the full context before selecting filter values. The negation may apply to the complete context, not just the immediately adjacent word. - Temporal Operators: Map "after" to gt and "before" to lt (exclusive); "since" and "from" to gte and "until" and "through" to lte (inclusive). A bounded period is two clauses, one gte and one lte. Filters: A range is two clauses, one gte one lte. For "over $X" or "under $X" asks, call with max: 100 and no amount clause, follow nextPage until it is null (at most 5 pages), then list only the rows whose amount is strictly over or under $X ("$X or more" includes $X). The answer covers active templates (the default { archived: { eq: false } }) unless the user asks for archived ones; say so. Add a caveat only if pages were left unfetched. amount cannot be filtered here; the backend rejects such filters. Sort: Append ":asc" or ":desc" to a field name. Omit unless the user asks for a specific order. Pagination: Omit max unless the user names a count; disclose the 100-item cap if they ask for more than that. page is an opaque cursor from the previous response's nextPage, never guessed. Correction & Degradation: - An unrecognized sort field does not fail the call; the sort is dropped, the rows come back in the default order, and the result's summary says so. Tell the user their requested order wasn't applied, don't present the result as if it were sorted the way they asked. - That fallback is not a reason to try one: for "sorted by next due date" or end date, send no sort at all, since schedule.nextDueDate and schedule.endDate are filter-only.

payables_list_recurring_bill_templates

Purpose: Provide a list of AP (accounts payable) bills, which represent money this organization owes a vendor. One bill can have multiple payments applied to it; one payment can cover multiple bills for a vendor. A row's amount is in that bill's own currency (the currency field), not the organization's base currency. fundingAmount is the USD value for an international bill and null for a domestic one; the amount filter is USD. When to Use This Tool: - Identify context in order domain(AP/AR/spend) -> sub-domain(bills/payments/invoices/vendors/budgets/transactions) -> tool -> field/value pairs (one pair per constraint the request implies, not just one). - Prompt with "Invoice" keywords without "bill" -> AR tools ONLY, never an AP bills tool, even though a bill also carries an invoice number field. "Bill" keywords -> AP tools. - Prefer the get tool for one entity's details when it is applicable to the identifier given; only fall back to list and filter when get does not apply, e.g. a name rather than an id. - Never send a filter or sort field this tool does not declare, even when the user's phrasing implies one. If no declared field covers the request, call with the closest supported default instead and tell the user that constraint could not be applied, or ask the user how to proceed. Never fabricate a field name to satisfy the request. - When a term the user uses (e.g. "reversed", "bounced", "e-payment") maps to multiple concrete values, filter on the broader set (in: [...]) rather than guessing one; the user sees every match and can narrow down themselves in a follow-up. - The payments applied to a bill live in payables_get_bill (its payments[]); for a bill's payments, call payables_get_bill, not a payment list. - "Recurring bills" are the schedules in payables_list_recurring_bill_templates, including when they were created or set up; this tool lists bills, one-off or generated by a template (recurringBillId). Calling Conventions: - State Persistence: If a follow-up message asks for a different sort or filter than the last call (e.g. "sort by dueDate instead" or "now show only X" after an earlier call), call this tool AGAIN with the updated sort/filters args. Never re-order or re-filter the rows already in the conversation; that set may not contain the true top/matching results across the full dataset. - Cursor Reset: sort and filters are dropped when page is provided (the backend rejects combining a page cursor with sort/filters). If the user wants a page 2+ WITH a new sort/filter, start over from page 1 with the new sort/filters, not the old cursor. - Undocumented Fields: A field not in the documented filter list is rejected by this tool before any backend call (it is not tried server-side). If the field exists on this tool's output, fetch all pages and filter on the returned rows client-side instead; this is the expensive path (the full result set, not a narrowed one), so prefer the documented fields when they cover the request. - Negation Handling: When the user's request contains exclusions or negations ("not", "excluding", "without", "except"), read the ENTIRE sentence and, if needed, the previous sentence to understand the full context before selecting filter values. The negation may apply to the complete context, not just the immediately adjacent word. - Temporal Operators: Map "after" to gt and "before" to lt (exclusive); "since" and "from" to gte and "until" and "through" to lte (inclusive). A bounded period is two clauses, one gte and one lte. Filters: A range is two clauses, one gte one lte. Money fields are USD only. Sort: Append ":asc" or ":desc" to a field name. Comma-separate additional field:direction pairs for multiple keys, applied in the order given. Omit unless the user asks for a specific order. Pagination: Omit max unless the user names a count; disclose the 100-item cap if they ask for more than that. page is an opaque cursor from the previous response's nextPage, never guessed. Aggregation / count questions: Read totalCount, totalDueAmount for the true total (not row count, not count/totalAmount; those reflect only the fetched batch). Example: "How many X do I have?" → answer with totalCount from the response, not row count. Count questions must STILL show the results card (never hide it; _display="hidden" is wrong here); the user verifies the count on the card. Correction & Degradation: - An unrecognized sort field does not fail the call; the sort is dropped, the rows come back in the default order, and the result's summary says so. Tell the user their requested order wasn't applied, don't present the result as if it were sorted the way they asked. - A request implying multiple constraints (e.g. a status plus a date range) must include a clause for each; sending only one silently narrows the answer to just that constraint. Sample Mappings: - "Show me bills approved but not yet paid" → filters: { approvalStatus: { eq: "APPROVED" }, paymentStatus: { in: ["UNPAID", "PARTIALLY_PAID"] } }

payables_list_bills