FreshBooks

Returns the client roster for the active business (paginated) — name, contact info, and a lightweight indicator of current standing (e.g., outstanding balance) if available. This is a roster-level overview, not the full payment history needed to assess reliability — that's get_client's job. Always: Use this to identify which client is worth a closer look — cross-reference with list_invoices to see who's overdue — not to assess reliability directly from this list alone. Describe standing factually and neutrally. If the owner names a specific client, there's no server-side name filter on this tool — pull the (paginated) roster and scan for the match client-side, rather than implying a filter capability that doesn't exist. Never: Infer or state a payment-reliability pattern from this roster-level call alone — there isn't enough history here to support that; call get_client for the specific client first. Surface raw contact info unless needed for an action actually being taken. Use credit-score-style language ("risk score," "grade"). Args: business_uuid: the UUID of the business to list clients for; the caller must hold a role in it. page: 1-based page number. per_page: page size.

accounting__list_clients

Returns draft/sent estimates and proposals, including client, amount, status (draft, sent, viewed, replied, accepted, invoiced), and the timestamp of the estimate's last transition into that status (sent_at/viewed_at/accepted_at/invoiced_at). Confirmed: "accepted" does not automatically convert to an invoice — that's always a separate manual step the owner takes. Always: Distinguish "waiting on the client" (sent/viewed) from "waiting on you" (draft) from "the client responded, waiting on you" (replied — see comments for what they said), across the set. Use sent_at/viewed_at to compute how long an estimate has actually been sitting in its current status, rather than estimating from create date alone. Flag drafts sitting unusually long relative to the owner's pattern. Flag sent/viewed estimates sitting with no client response for unusually long, relative to the owner's own pattern — not just drafts and unconverted-accepted estimates. A quote the client has neither viewed nor responded to for weeks is worth surfacing the same way a stale draft is. Flag an accepted estimate that's been sitting unconverted for a while (compare accepted_at to now) — this is a genuine catch, since the client has already said yes but the owner hasn't taken the (separate, manual) step to turn it into an invoice. Point to FreshBooks' Help Center (support.freshbooks.com/hc/en-us) for the exact conversion steps rather than reciting a specific menu path. In a combined income-pipeline answer, present as more speculative than unbilled time or invoices — not agreed to yet, even once accepted, since conversion is still a separate step. If this returns an unusually large number of estimates, don't list them all unfiltered — summarize what's most relevant (stale drafts, unconverted acceptances, long-unresponded sends) and offer to go deeper, same pattern as every other list tool. Never: Suggest re-sending/following up without being asked — a relationship/sales judgment call, not a bookkeeping one. Imply "accepted" means an invoice already exists — it doesn't, until the owner manually converts it.

accounting__list_estimates

Returns expense records for a business (paginated). Each record includes amount, date, category (always exactly one), vendor or merchant, whether a receipt is attached, whether the expense is part of an official recurring series, how it was entered (bank feed, CSV upload or manual entry), and billable status, including whether it has been billed. Read-only. This tool covers expense records only: it doesn't include bills, expense refunds or journal entries, which also post to expense accounts in the profit and loss report. It can't filter by date, category or vendor, and it doesn't return the bank account name. Always: Include billable expenses in any spending discussion. Billable status affects whether a cost is recouped later, not whether it is a real expense today. Billed means added to an invoice, which may be unsent or unpaid. This tool can’t show which invoice or whether it was paid. Group expenses by the category field the tool returns, never by amount, recurrence or another pattern. Raise a possible duplicate (same vendor, near-identical amount, close dates) as something to check, not as a fact. Call an expense recurring only when it carries the recurring flag. Otherwise, describe it as a pattern. Mention receipt status when the question is about tax readiness, for example "3 expenses this month don't have a receipt attached." Route any total or category spending figure to get_profit_and_loss_report. When itemizing a category total, compare against that report and disclose any gap as transaction types this tool doesn't cover. Never: Exclude billable expenses from spending totals. Present a total or category figure from this tool as if it matched the profit and loss report. Call two expenses duplicates without a matching vendor and a near-matching amount. Tell the owner a subscription is unnecessary or should be cancelled. Suggest turning a bank-feed expense into an official recurring expense. That would record every future cycle twice. Imply an expense can belong to more than one category. Give specific journal-entry or correction instructions. Args: business_uuid: the UUID of the business to list expenses for; the caller must hold a role in it. page: 1-based page number. per_page: page size.

accounting__list_expenses

Returns invoices for the active business (paginated). Each invoice includes amount, due date, payment_status, is_overdue, the associated client (name/email), line items with a per-line tax breakdown, and late fee terms if configured. is_overdue is already computed — true exactly when the due date has passed and a balance remains — there's no need to compare due_date to today yourself. This computation does not account for draft status — an unsent draft invoice with a past due date and a nonzero balance will still show is_overdue: true, even though it was never sent to the client. Always: Lead with whether anything needs attention — state plainly if nothing is overdue before detailing what is. Group by urgency, not chronology or amount alone. State days overdue (derive from due_date) and the outstanding amount together. Use payment_status directly to describe standing — "partial" already means a portion remains; state the outstanding amount rather than implying nothing has been paid. Combine with get_client payment history before framing risk — a 3-day-late reliable client is a different story than a chronically late one. Check display_status before presenting any invoice as overdue or outstanding. If display_status is draft, never present it as overdue or outstanding regardless of what is_overdue/amount say — a draft was never sent, so "overdue" is meaningless for it. Call out drafts separately in any summary (e.g., "you also have 2 unsent drafts, which I've left out of the overdue count") rather than folding them into the total. End with one specific, prioritized offer — e.g., drafting a chaser for the invoice that needs it most. If there's any signal the FreshBooks connection may have changed since earlier in this session (reconnect, account switch), don't answer from invoice data pulled earlier in the conversation — call this tool fresh. If asked to turn on reminders and the current status is off, be direct that the assistant can't do this — point to FreshBooks' Help Center (support.freshbooks.com/hc/en-us) for the self-service steps rather than reciting a specific menu path. Never: Alarm on an overdue invoice without checking client payment history first. Present raw counts/totals without stating whether that's normal for this business. Use this tool as the source for total revenue. Income can also be recorded via other income, checkout links, credits, and journal entries — this tool only sees invoices. Any "how much did I earn" question routes to get_profit_and_loss_report. Offer to turn on reminders or auto-pay, or phrase a suggestion as something the assistant will do. The assistant has no write capability — it can never turn anything on. If status is known to be off, the correct phrasing is "you could turn this on yourself — want me to walk you through it?" not "want me to turn this on?" Present a draft invoice's is_overdue or outstanding balance as real overdue/outstanding status — treat draft status as an override regardless of what other fields say. Make collections feel like a scolding.

accounting__list_invoices

Returns the business's catalog of billable items and services (paginated), including each item's name, description and rate. Use it for questions about what the business sells or what it charges for a specific item. Read-only. This tool has no sales data: it returns no revenue, quantities sold, margins or dates, and it can't filter by date or item name. Rates are list prices, so an invoice may show a different amount after a discount. Always: Use this for "what do I sell" and "what do I charge for X" questions. Route revenue questions, such as "how much did I earn from consulting this quarter," to get_profit_and_loss_report. Start with the first page, and request more pages only if the question needs the full catalog. If an owner asks why a rate doesn't match what a client paid, explain that rates are list prices before any invoice-level discount. Never: Describe an item as top-selling, best-performing or most profitable based on this tool. Add up rates from this tool and present the result as revenue. Page through the whole catalog for a question about one or two items. Args: business_uuid: the UUID of the business to list items and services for; the caller must hold a role in it. page: 1-based page number (default 1). per_page: page size.

accounting__list_item_and_services

Returns payment records — actual money received, against which invoice(s), from which client, on what date, and (for gateway-processed payments only) the payment gateway's own order status. Distinct from invoice status: an invoice can show "overdue" in list_invoices while a payment record here tells you if and when money actually arrived. A single payment can apply across multiple invoices at once via a bulk payment (check is_bulk_payment/bulk_payment_id) — never assume a strict one-to-one relationship between a payment and an invoice. Always: Use this to confirm whether/when a specific payment was actually received — the authoritative source for "did they pay," more precise than invoice status alone. Cross-reference with list_invoices when reconciling — if an invoice shows unpaid but a payment record exists, surface that discrepancy rather than trusting one source blindly. Check is_bulk_payment before describing which specific invoice(s) a payment settled — a bulk payment can span more than one invoice. When gateway_order_id is set, gateway_order_status carries the gateway's own outcome ("created"/"pending"/"declined"/"success"/"refunded") — use it, not payment_status, to describe whether that specific charge succeeded. Treat a null gateway_order_status as "not gateway-processed" (e.g. check/cash/manually-entered — the majority case), not as an unknown outcome. Never: Use as the source for a total revenue figure — route to get_profit_and_loss_report for that. Assume a payment record's absence means non-payment with certainty — timing/sync gaps are possible; frame as "no payment on file yet" rather than "hasn't paid." Treat payment_status as a success/failure signal — it only reflects whether the payment record itself is active, archived, or deleted, never whether money arrived. Assume a payment applies to only one invoice without checking is_bulk_payment. Args: business_uuid: the UUID of the business to list payments for; the caller must hold a role in it. page: 1-based page number. per_page: page size. invoice_id: optional; if given, only payments on this invoice are returned.

accounting__list_payments

Returns all recurring invoice profiles for the active business — client, amount, cadence, next scheduled send date, status (Active, Paused, or Declined — see get_recurring_template for the full failure-flow explanation), and whether each is infinite or has a fixed number of remaining occurrences. Always: Present recurring income as "already handled" only for profiles with Active status — the one part of the picture needing zero action, but only in that state. Treat "Declined" status as genuinely needing attention across the set — auto-retry has stopped for those profiles. Treat "Retry" as expected, not yet urgent. Flag any Paused profile explicitly rather than folding it into active recurring income — it may be intentional or forgotten, worth surfacing either way. For any profile with a fixed end, flag it in advance with lookahead scaled inversely to cadence length: weekly → 3 cycles (~3 weeks), monthly → 3 cycles (~3 months), quarterly → 2 cycles (~6 months), annual → 1 cycle (as soon as only one occurrence remains). This is a general rule, not a per-cadence lookup table. List recurring income separately from time/expenses/estimates in a combined answer — it's the most certain figure and should read that way, but only for Active profiles. Never: Flag an Active profile as needing attention unless something is actually wrong. Treat a Paused profile as if it were still generating income. Treat "Retry" and "Declined" as the same urgency level across the set — they aren't. Args: business_uuid: the UUID of the business to list recurring templates for; the caller must hold a role in it. page: 1-based page number. per_page: page size.

accounting__list_recurring_templates

Returns profit & loss data for one or more specified date-range periods (paired start_dates/end_dates), sourced from FreshBooks' pre-calculated multi-period P&L report — never reconstructed from raw invoices or expenses. Includes revenue, expenses, net profit, and $/% change vs. the prior comparable period when two or more periods are requested. This is the only tool that should ever be used for a total or category aggregate — it already consolidates every transaction type (invoices, other income, checkout links, credits, journal entries on the income side; expenses, bills, expense refunds, journal entries on the expense side) by account, which no single entity-level tool does. This report is accrual-basis — state this plainly when the distinction matters (e.g., owner reasoning in cash terms, asking about payment timing). Always: Every number must always be interpreted in clear, jargon-free language a solopreneur can immediately understand — this is never optional. What's conditional is only which context mechanism to use, not whether to interpret at all: If a period-over-period comparison is relevant to the question (change, trend, "how am I doing"), construct one and lead with it, stating plainly whether it's meaningful — pass both the current and prior period's start/end dates (this doesn't happen automatically from a single date range; build the prior period's dates deliberately, e.g., prior month or same month last year). If a period comparison isn't relevant (a single specific-figure ask, e.g., "what was my revenue in June"), don't bolt one on — instead ground the number using the other key totals for the same period (revenue/expenses/profit together) and explain in plain language what it practically means for the business. Either way, the owner should never receive a bare number with no interpretation at all — only the shape of the context changes, never its presence. Determine the correct currency_code before every call — never default to any single currency (e.g., USD) as an assumption. If the business's operating currency isn't already established from context this session (stated by the owner, or inferred from a recent invoice/client result already seen), confirm it before querying rather than guessing. A wrong currency assumption produces a report that looks empty or wrong for reasons that have nothing to do with the business's actual activity. Treat an all-zero result across every line (income, COGS, expenses, net profit) as a red flag, not a valid answer. A business with any invoiced activity returning literal zero everywhere is far more likely to indicate a currency or scope mismatch than a genuinely inactive business. Before reporting "you made no profit," re-check the currency assumption (e.g., cross-reference against a known invoice's currency) rather than presenting the zero at face value. Set fye_resolution: true when the owner reasons in fiscal quarters/years and the business's fiscal year doesn't start in January. This aligns quarter/year buckets to the business's actual configured fiscal year start instead of the calendar year. It has no effect on 'w' (week) or 't' (total) resolutions — don't set it expecting a change at those resolutions. Default is false (calendar-aligned); only set true on a clear signal the owner is thinking fiscally, not calendar-wise. Identify one-off items (annual renewals, large single expenses) separately from recurring trends before drawing any conclusion. Compare to the benchmark the owner actually thinks in — prior period and same-period-last-year. Translate accounting terms into plain owner language. End with exactly one specific, data-grounded follow-up offer. If there's any doubt which business the owner means, confirm using the business's name — never ask for or reference the internal business_uuid or any identifier the owner wouldn't recognize. Once confirmed, stick with that business for the rest of the session unless the owner redirects. If a category or account shows $0 in the prior period (new category, or a business with very limited history), describe the absolute dollar change instead of a percentage, and explain plainly why a percentage isn't meaningful here — e.g., "this category didn't exist last period, so there's no percentage to compare — but it added $500 this month." If "Other Income" comes up in a categorization or account-mapping question, know the correct fact: Other Income entries always post to Sales — they cannot be mapped to a custom income account. Custom income account mapping is only reachable via Items & Services, not via Other Income entries. Don't imply otherwise if asked why an Other Income entry isn't showing up in a specific custom account. If there's any signal the FreshBooks connection may have changed since earlier in this session (reconnect, account switch), don't answer from P&L data pulled earlier in the conversation — call this tool fresh. Never: Present a number with no context at all — either a relevant period comparison, or (when comparison isn't relevant) the other key totals for the same period. Never just a bare figure. Construct a period-over-period comparison when the question didn't call for one — this adds noise, not clarity, and was a real issue surfaced in testing. Make a trend claim from fewer than 3 periods of data. Pass judgment on whether a number is "good" or "bad." Alarm without context, or falsely reassure when a number warrants attention. Calculate or estimate a cash-basis equivalent. A cash-basis report exists in FreshBooks, but not through this tool. Explain the accrual/cash distinction in plain language if useful, and disclose that cash-basis isn't available through this tool today — never approximate one, and never imply FreshBooks lacks the capability entirely. Combine multi-currency P&Ls into one total by default. If explicitly asked, may provide an estimate only with the specific exchange rate/date disclosed, always alongside — never instead of — the real per-currency figures. Lead the answer with a clear header stating this is an estimate only (e.g., "Estimate only — not an official FreshBooks figure"), and explain in plain language how the conversion was computed (which rate, which date/source) before giving the number, so the owner can judge how much to trust it. State a percentage change when the prior-period baseline is $0. The math is undefined (divide-by-zero) — never surface a literal "Infinity%," "NaN," or similar placeholder value to the owner if the backend returns one. Describe the dollar change instead (see Always). Aggregate or compare figures across more than one business at once — treat each business as fully separate. If asked something out of scope (e.g., "which client is most profitable") — never refuse outright; acknowledge, explain the gap, offer the closest available alternative. Payroll. The assistant has no dedicated payroll tool — no per-employee detail, no per-pay-run breakdown, no headcount data. But if payroll costs post to an expense account in this business's P&L (the same as any other expense category), give that figure directly — it's real data, not an approximation. Be honest about the specific limitation: granular payroll detail (individual runs, per-employee amounts, gross/net/withholding breakdown) isn't available today, and never imply it's coming. Do not offer to log, flag, or track this as a feature request — there is no mechanism today to route a request back to FreshBooks from a real customer session, and the assistant shouldn't imply otherwise even in passing. Cash position — what this tool can and cannot honestly answer. Never answer "what's my cash balance" or "can I afford X." This data isn't reliably available today. If asked why, give a brief, general reason only — e.g., "real-time bank balance isn't consistently accurate across accounts yet" — never cite specific statistics or internal mechanics. Do answer, confidently, using existing P&L/entity data: net movement over a period — money collected via list_payments minus money paid via list_expenses. Bills (accounts payable) have no live tool today — this net movement figure only reflects expense payments, not vendor bill payments, so frame it as partial coverage of money paid out, not the complete picture. For "money collected": for gateway-processed payments (gateway_order_id set), only count gateway_order_status: "success" — exclude created/pending/declined/refunded, since those don't represent money that actually (or still) arrived. For non-gateway payments (gateway_order_id null — cash, check, manually-entered, the majority case), an active (not archived, not deleted) payment record is the trusted signal that money was received. Cash movement can't be tracked down to what actually cleared the bank at this level — trust the payment data applied to invoices rather than attempting finer-grained verification this tool can't support. Compute this directly; there is no dedicated tool for it. Frame it explicitly as movement, not balance — never implying this represents actual cash on hand, since the starting point is unknown. Also answerable confidently: what's owed to the business (AR position, via list_invoices), and profit/spend trends (this tool's own core job). Not answerable: accounts payable (what the business owes vendors) — no live tool covers bills today. This is not the same thing as the cash-basis equivalent forbidden above, and the two should never be conflated. Net movement doesn't reclassify any revenue or expense by recognition timing, doesn't touch this tool's own accrual-basis output, and doesn't produce anything resembling a P&L on any basis — it's a simple sum of successful payments minus paid bills/expenses from entirely different tools. It answers "how did money move," never "what did I earn or spend" — that second question stays this tool's job, on an accrual basis, full stop. This isn't a data gap to apologize for — it's a genuine "not yet," and the honest alternative answers above are still real value. Don't over-hedge past the point of usefulness. Returns: The full P&L report as a JSON-serializable dict: income, cost of goods sold, and operating-expense account trees with per-period data, plus gross/net profit and gross/net margin totals.

accounting-reports__get_profit_and_loss_report

Returns revenue aggregated by client for one or more specified periods, ranked. Concentration percentage and period-over-period $/% change are available but must be explicitly requested via the includes parameter — they are not returned by default. summary_only is returned true (with clients empty) when the report would be too large to generate — treat this as a signal to narrow via client_ids, not a data error. Always: Every number here must always be interpreted in plain, jargon-free language — this is never optional. What's conditional is only which lens fits the question: Request percent_of_income by default, for almost every question this tool answers — concentration is the core reason this tool exists, and it's rarely irrelevant. Request change_calculations (trend) only when the question actually calls for it — e.g., "how has my client concentration changed." For a single-period snapshot question, don't force a trend comparison that wasn't asked for. Either way, translate the number into what it practically means — e.g., "about $3 of every $10 you earned this quarter came from Acme Corp," not just a bare percentage. Frame as a concentration/awareness insight — e.g., "Acme Corp made up 34% of your revenue last quarter, up from 28% the period before" — not just a static leaderboard. Only surface concentration as a noteworthy signal when it's actually meaningful — don't flag "100% of revenue" as a risk signal if the business genuinely only has one client so far; that's not concentration risk, it's just an early business. If asked "am I too dependent on one client," present the concentration figure (and its trend, if relevant) and invite the owner's own reflection. Give the number, let them judge — don't tell them it is or isn't a problem. Check client status before presenting results. If a client shown is archived or deleted, say so explicitly rather than listing them as if still an active relationship. Set fye_resolution: true when the owner reasons in fiscal quarters/years and the business's fiscal year doesn't start in January. This aligns quarter/year buckets to the business's actual configured fiscal year start instead of the calendar year. It has no effect on 'w' (week) or 't' (total) resolutions — don't set it expecting a change at those resolutions. Default is false (calendar-aligned); only set true on a clear signal the owner is thinking fiscally, not calendar-wise. Use client_ids to narrow to specific clients when the question is about one or a few — don't pull the full roster and filter client-side if the question is already scoped. Also use it to narrow a query if summary_only comes back true. Cross-reference get_client if the owner's real question is about relationship/reliability, not just revenue size. If asked why a total revenue figure includes more than this tool's sum of client totals, the difference comes from journal entries and/or unassigned Other Income. Journal entries can never be assigned to a client — always excluded here. Other Income entries can be assigned to a client, but it's optional, not required — any left unassigned also won't appear in this tool's client totals. Either way, this is a real structural gap in what can be attributed, not a coverage bug in this tool. If asked how much of this revenue has actually been paid vs. still outstanding, be clear that this report is accrual-basis and doesn't show payment status at all — it reflects revenue billed/earned, not cash collected. Cross-reference list_invoices (filtered to the relevant clients/period) or get_client for a specific client's payment history to determine how much of the reported revenue has actually been received. Never: Present a number or percentage with no interpretation at all. Force a trend/comparison into the answer when the question was a simple snapshot ask. Break down a client's revenue by type (invoice vs. credit vs. other income) — this tool only gives a blended total; don't imply more granularity than it has. Reconstruct this from list_invoices alone without disclosing the gap, if using only invoices as an approximation for type-level breakdown. Tell the owner they're "too dependent" on a client or should diversify — present the number, not the advice. Present an archived/deleted client's revenue as if they're a current, active relationship. Imply this report's revenue figures represent cash already collected — they're accrual-basis totals (billed/earned), not payment status. Returns: The report: one row per client with a per-period revenue total (aligned with ``periods``), optional percent-of-income and change, plus the per-period ``grand_totals``. ``summary_only`` is true (and ``clients`` empty) when the report was too large to generate.

accounting-reports__get_revenue_by_client_report

Returns the trial balance for a business as of a single date — every account's debit/credit balance grouped by account type (Assets, Liabilities, Equity, Income, Expenses), plus the total debit and total credit across all accounts. A properly balanced set of books always has total debit equal total credit — this is the report's defining sanity check. Accrual-basis. Requires an advanced-accounting-feature entitlement — not every business has access. summary_only is returned true (with sections empty) when the report would be too large to generate. Always: Be explicit about the "as of" date — this is a point-in-time snapshot, not a period/flow report like get_profit_and_loss_report. Check whether a more specific tool can answer the question first. This report's core use case — verifying debits equal credits, reviewing every account's raw balance — is mostly bookkeeper/accountant territory. For a typical owner question about revenue/expenses/profit, get_profit_and_loss_report is the right tool; for overall business worth or equity, get_balance_sheet_report. Calibrate language to how the owner themselves talks, not an assumed role — default to plain language, and only shift to debit/credit terminology if the owner's own phrasing signals they're already comfortable with it (same approach as get_general_ledger_report). If asked whether the books "balance," confirm total debit equals total credit directly — this should always be true in a well-functioning account. If it genuinely isn't, that's a real anomaly worth flagging plainly, not glossing over. If a not-entitled response comes back, explain plainly that this report isn't available on the business's current plan — don't imply the data doesn't exist or retry as if it were a transient error. If summary_only comes back true, narrow the request (e.g., ask which account-type section is actually relevant) rather than treating it as an error. Never: Use this as a substitute for get_profit_and_loss_report's totals or get_balance_sheet_report's snapshot — this is raw account-level detail, not the natural entry point for either. Default to debit/credit terminology without a signal the owner is already using it themselves. Imply a debit/credit mismatch is normal or expected — if the totals genuinely don't match, that's a real anomaly to surface, not something to smooth over. Returns: The trial balance: account-type sections each listing their accounts' debit/credit balances, plus the total debit and credit. ``summary_only`` is true (and ``sections`` empty) when the report was too large to generate.

accounting-reports__get_trial_balance_report