--- name: freshbooks-client-payment-behaviour-review description: Assess one FreshBooks client's payment history and reliability, covering how long they take to pay, what they owe now, and whether credit is on file, so the user can decide whether to extend terms, request a deposit or tighten collection. Use when the user asks whether a specific client pays on time, is reliable, deserves more credit or terms, or needs a deposit before new work. --- # Review one client's payment behaviour The question is **how this client behaves as a payer**, judged from their own history. It is not a portfolio view of who owes money today (that is the receivables triage job), and it is not an account health check. Answer one client well: how fast they pay, how often they pay late, what they owe right now, and whether any credit sits on the account that could offset a new invoice. ## 1. Pin down the client and the business first Confirm the client by name and, if more than one matches, ask which one. Use `accounting__list_clients` to find the record and `accounting__get_client` to read it. Confirm the business scope too: `business-profile__list_businesses` shows the businesses the login can reach, and FreshBooks may hold several. A client record in one business is not the same as a client in another. If the user has not said which business, say which one you used. Read the client record for anything that changes how you judge the history: payment terms set on the client, currency, and whether the record is active or archived. An archived client with old invoices is a different conversation from an active one. ## 2. Build the payment history from invoices Use `accounting__list_invoices` filtered to this client, then `accounting__get_invoice` for any invoice whose status or dates you need to confirm. Page through the full list rather than stopping at the first page, because a reliability judgement drawn from the last three invoices alone is weak. Aim for the whole relevant window, and if the history is very long, state the window you used (for example, the last twelve months) rather than implying a complete record. For each paid invoice, measure the gap between the invoice date and the date it was paid. Use `accounting__get_payment` or `accounting__list_payments` to find the payment dates, because the invoice status alone does not tell you when the money arrived. Where an invoice was paid in part, record each part against its own date. Compute these, and show the working for the figures you quote: - **Median days to pay** across paid invoices. Prefer the median to the mean, since one invoice paid six months late skews a mean badly. - **Share paid on or before due date**, counted over invoices that have a due date. - **Worst gap**: the single largest lateness, with its invoice. Paid-on-time against paid-late is the core signal. Ask whether the late ones cluster (one bad quarter) or are spread across the whole history (a standing habit). ## 3. Read what is owed right now Separate the current position from the history: - Open balance: invoices still unpaid or partly paid, with their amounts and how far past due each is. - Anything in a disputed or unusual state. Report what the record shows and do not guess at the reason. A client who paid slowly two years ago and is fully paid today is a different risk from one with an invoice forty days overdue now. Keep those two findings apart in the write-up. ## 4. Check for credit on file Use `accounting__list_credits_for_client`. Credit on the account reduces what the client will actually pay on the next invoice and can explain a balance that looks lower than expected. Note the amount and whether it is applicable. Do not net the credit against open invoices in your own figures unless you state that you have done so, because the user may treat that as a real cash position when it is not. ## 5. Look at the client's commercial footprint Use `accounting__list_estimates` and `accounting__list_recurring_templates` to see whether the client has pending work or standing billing. A client with a large open estimate and a poor payment record is the case the user most needs flagged. Do not assume recurring billing is healthy; report it as set up, and leave the health judgement to the payment evidence. ## 6. Turn the evidence into a recommendation, with its limits Map the findings to a recommendation that matches the evidence. A client paying on time with no open balance and no credit issues supports extended terms. A client paying late as a habit, or with an overdue balance now, supports a deposit or shorter terms. A client with little history gives weak evidence either way, and the honest answer is "not enough invoices to judge". Say which conclusion the data supports and which it does not. ## Common patterns and traps - **Judging from invoice status alone.** A "paid" status does not say when the money arrived. Check payment dates before calling someone reliable. - **Counting only the recent few invoices.** Three clean recent payments can hide a long record of lateness, or a bad last month can hide a good year. State the window. - **Averages distorted by one outlier.** Use the median and report the worst gap separately so one stale invoice does not define the client. - **Mistaking a dispute for a late payer.** An invoice that was contested is not evidence of slow payment. Look at the record before counting it. - **Netting credit silently.** Show credit as its own line. Quietly reducing the balance by credit makes the position look better than the cash actually is. - **Confusing one business with another.** The same client name can exist in more than one business under the login. Confirm the scope before concluding anything. - **Treating a small sample as a verdict.** Two invoices are an anecdote. Say so and recommend collecting more history before changing terms. ## Output ``` Client: Window: Payment pattern: median days to pay; of paid on or before due date; worst gap days (invoice ) Pattern shape: Owed now: invoices, oldest days past due, or "nothing open"> Credit on file: Pending work: Recommendation: — Not established: ``` ## Rules - Do not change anything on the client, invoice, payment or credit records. Read only. If a change seems useful (adjust terms, apply credit, send a reminder), propose it and wait for the user's explicit yes before any tool that would make it. - Never state a payment, credit or balance figure that the tools did not return. If a number is missing, say it is not available. - Do not infer why a client paid late. Report the dates and let the user supply context. - Do not treat a client's history as a guarantee of future behaviour. Say that the recommendation is based on the record shown. - Do not switch the active business to look for the client without telling the user which business you are now reading. Switching scope is a change of context; wait for the user's explicit yes first if it is not already clear. ## Done when - The client is confirmed in a named business, and the window of history is stated. - The median days to pay, the on-time share and the worst gap are each computed from payment records, not inferred from status. - Current balance and credit are reported as separate lines. - The recommendation follows from the evidence, and the output says what the record does not establish.