Update to Nella Finance AI

{
  "name": "nella-receivables-and-collections",
  "description": "Show who owes the business money, how overdue it is, which balances are largest and oldest, and when each customer is likely to pay based on how they have paid before. Use when the user asks who owes them, what is overdue, how bad their debtors are, who to chase, when someone is likely to pay, or about a specific customer's outstanding balance. Do not use for cash forecasting, runway or affordability; for what the business owes suppliers; for performance; for whether the books are reliable or ready to close, which is month end; for tax returns or filing deadlines, which is compliance even when the user says \"overdue\"; or for a broad \"what needs my attention\" request, which goes to the finance director briefing. \"Overdue\" and \"outstanding\" here always mean money a CUSTOMER owes, never a filing and never an unreconciled item.",
  "included_files": [],
  "skill_md_contents": "---\nname: nella-receivables-and-collections\ndescription: Show who owes the business money, how overdue it is, which balances are largest and oldest, and when each customer is likely to pay based on how they have paid before. Use when the user asks who owes them, what is overdue, how bad their debtors are, who to chase, when someone is likely to pay, or about a specific customer's outstanding balance. Do not use for cash forecasting, runway or affordability; for what the business owes suppliers; for performance; for whether the books are reliable or ready to close, which is month end; for tax returns or filing deadlines, which is compliance even when the user says \"overdue\"; or for a broad \"what needs my attention\" request, which goes to the finance director briefing. \"Overdue\" and \"outstanding\" here always mean money a CUSTOMER owes, never a filing and never an unreconciled item.\n---\n\n# Receivables and collections review\n\nThe user wants to know who owes them money, how overdue it is, and when it is\nlikely to arrive.\n\n## Gather\n\nStart with `get_ar_ap_ledger` — the open sales ledger, as at today. It is the\nprimary source and does not depend on any other tool.\n\n| Tool | Add it when |\n|---|---|\n| `get_ar_chase_drafts` | Candidates ranked by overdue amount, with a tone from payment history and, on some plans, prepared draft wording |\n| `list_invoices_and_bills` | The specific unpaid invoices are wanted |\n| `get_invoice_or_bill_link` | The user wants to open or download a document |\n| `get_top_customers_and_suppliers` | Concentration matters — one customer owing most of it |\n| `get_cash_forecast` | The user asks what the collections mean for cash |\n| `search_transactions` | Checking whether something was actually paid |\n\n**If `get_ar_chase_drafts` returns `has_data: false` or is otherwise\nunavailable, do not stop.** Continue from `get_ar_ap_ledger` and\n`list_invoices_and_bills`: rank the outstanding balances by overdue amount and\nby age of the oldest open item, and say that chase candidates were not available\nso the ranking is by amount and age alone, without payment-history context.\n\n## What is due, versus when it will arrive\n\n`receivables.forward` gives what is DUE in the next 7 and 30 days, by due\ndate, over every open invoice — plus `overdue`, `undated` and the largest\nitems. That is timing on paper. When it will actually ARRIVE is behaviour, and\nthat is the section below. Keep the two apart: a customer with £10k due next\nweek and a 60-day payment history is not £10k next week.\n\n## Answering \"when are they likely to pay\"\n\n`get_ar_ap_ledger` returns `avg_days_to_pay` per counterparty where there is\nenough settled history, plus a `trend`.\n\n**`avg_days_to_pay` is measured from the INVOICE DATE, not the due date.** It is\nthe mean of (date paid − date issued) over settled invoices. Adding it to a due\ndate double-counts the payment terms and pushes every expectation out by roughly\nthe length of those terms. Apply it to the invoice date.\n\nWhere `avg_days_to_pay` is null there is too little settled history to judge —\nsay the customer's payment behaviour is unknown rather than assuming they pay on\ntime. The due date is then the only basis, and it is a weaker one.\n\nSay plainly that this is behaviour, not a commitment. A customer who has paid in\n45 days four times may still pay in 90.\n\n## Structure the answer\n\n1. **The conclusion** — total outstanding, how much is overdue, and how serious\n   that is, in a line or two\n2. **Ageing** — how old the overdue portion is\n3. **Who to look at first** — ranked by overdue amount and age, with how each\n   customer usually pays and when payment is likely, where that is known\n4. **Concentration** — where one customer dominates the balance\n5. **What could not be assessed** — undated invoices, customers with no payment\n   history, anything skipped\n6. **Safe checks**, and what belongs with the user's accountant\n\n## Rules you must follow\n\n**These are amounts OUTSTANDING NOW, not sales for a period.** Do not present\nreceivables as revenue or compare them to a P&L figure. For who the biggest\ncustomers were by invoiced value, that is `get_top_customers_and_suppliers` —\nthe two answer different questions and will not match.\n\n**`assessable: false` means the platform could not read that side.** It is never\na statement that nothing is outstanding.\n\n**`has_data: false` means NOT ASSESSED.** Unread receivables are not \"nobody\nowes you money\". Say which it is.\n\n**The chase list is a subset, and nothing in it says by how much.**\n`get_ar_chase_drafts` returns `counts` by draft status — draft, approved, sent,\ncancelled — not a tally of who was left out. Customers below the chase threshold\nor too recently due simply do not appear, and no field reports them.\n\nSo check it yourself: compare the number of debtors in `drafts` against\n`open_count` and the overdue total on the ledger's receivables side. Where the\nchase list is shorter, say it covers part of what is outstanding and give the\nledger total alongside it. Never present the chase list as everyone who owes.\n\n**Overdue is derived, not read.** No accounting platform has an \"overdue\" status\nof its own. A document with no due date CANNOT be judged either way — it is\nneither overdue nor current, and the count of those is given. Report it.\n\n**`coverage_note` is on `list_invoices_and_bills`, not on the ledger.** Read it\nwhenever you quote a count from a document listing: some platforms cannot filter\nat source, so a short result means \"none on this page\", NOT \"none in the\nledger\". The ledger itself reports `open_count` for the whole side — use that\nfor totals, and never present a page of documents as the full picture.\n\n**Tone is a suggestion derived from payment history** — how that customer\nusually pays. It is not a judgement about them, and the rationale is given.\nRelay the rationale rather than asserting someone is a bad payer.\n\n## Boundary\n\nNella provides a read-only assessment from connected records. It has not\nposted, filed, approved, paid or sent anything. Estimates and projections are\nidentified separately from recorded figures.\n\n**Drafts may be returned, but NOTHING IS SENT.** `get_ar_chase_drafts` returns\nwho is overdue, by how much, for how long, and a suggested tone. Depending on\nthe plan it may also return prepared reminder drafts. Where wording is returned,\npresent it as a draft for the user to review. Where it is not, give the\ncandidates and their tone without inventing wording.\n\nEither way no reminder is dispatched and Nella cannot send one. Approval and\nsending happen in the Nella portal. A status of \"sent\" describes what was done\nthere, never something this connector did. Never imply a chase has gone out\nbecause a draft exists.\n\n`get_invoice_or_bill_link` returns a time-limited link to **open or download** a\ndocument. It does not email, share or send it to anyone.\n\nWhether to chase, when, and how firmly is the user's decision. Do not write a\nreminder for them unless they ask, and if they do, be clear it is theirs to\nreview and send.\n\nAnything about writing off a debt, provisioning for it, or the VAT treatment of\nbad debt goes to a qualified accountant.\n\n**Say \"your accountant\", and name no firm.** Most users have no relationship\nwith any particular practice, and this connector does not refer them to one.\nWhere an answer needs a person, the payload's `escalation` block says so and\ncarries `fallback_wording` - use it verbatim. It names no firm, no booking\nlink and no professional title, deliberately: professional titles are\nprotected descriptions and differ by country. The envelope's `advice_note`\nsays the same thing. Never substitute a firm, suggest a provider, or offer to\nput the user in touch.\n\n## When to stop or ask\n\n- If the sales ledger cannot be read, say so and stop. Do not infer debtors from\n  invoices listed elsewhere.\n- If the user asks about one customer, use their name to filter rather than\n  reporting the whole ledger.\n- If nothing is overdue, say so plainly — but only when the ledger was readable.\n"
}