accounts-receivable-aging

name

accounts-receivable-aging

description

Answer "who owes us money, and since when?" using Well's MCP financial graph — every outstanding customer invoice bucketed into standard aging bands (current, 1-30, 31-60, 61-90, 90+ days overdue), backed by real invoice data rather than guesswork. Use when the user asks "who owes us money", "accounts receivable aging", "AR aging", "outstanding receivables", "which customers haven't paid", "who's late paying us", or "overdue invoices owed to us". Requires a connected Well workspace with invoicing data and a resolvable `own_company`; if either is missing, this skill walks the user through connecting one or confirming their company first.

Track Who Owes You Money with Well

Purpose

Use Well's MCP tools to answer "who owes us money, and since when?" — every unpaid or partially-paid invoice this workspace has issued to a customer, bucketed by how overdue it is. This is the receivable mirror of expense-breakdown's accounts-payable view (what this workspace owes others); this skill covers the opposite direction, backed by Well's synced invoice data, not a guess.

When to use this skill

Use this skill when the user asks things like:

• "Who owes us money?" / "What's our AR aging?"
• "Which customers haven't paid us?"
• "Who's late paying us?" / "Show me overdue invoices owed to us"
• "What are our outstanding receivables?"

When not to use this skill

Do not use this skill when:

• The user wants to know who they owe (accounts payable) — use expense-breakdown (covers accounts payable) or the sibling bills-due skill (a date-sorted AP planning view) instead.
• The user wants a cash/runway answer — use runway-calculator instead.
• The user wants a deep dive on one specific customer's full history, not an aging summary across all customers — use the sibling company-profile skill instead.

Inputs

The user may provide:

• Which workspace to use, if they manage more than one.
• A specific customer to filter to — default to all customers with an outstanding balance.
• How the result should be grouped — default to per-invoice within each aging bucket; group by customer (worst bucket per customer) only if the user asks for a customer-level summary.

Tooling

This skill runs entirely over Well's MCP server (https://api.wellapp.ai/v1/mcp, streamable HTTP). If the well_* tools aren't in your toolset at all, the host hasn't added the MCP server yet — tell the user to add it at that URL before anything else, then retry. Required tools once it's added:

• well_list_workspaces — resolve which workspace to query.
• well_query_records — read workspace_connectors, invoices, workspaces (for own_company), exchange_rates.
• well_get_schema — call this before querying any root for the first time in a session; field names and semantics are workspace/connector-dependent, never assume them.
• well_list_connectors — surface install links when the workspace lacks invoicing data.
• Well's OAuth / Dynamic Client Registration (DCR) flow — if no Well MCP connection exists yet, most hosts trigger this automatically when the Well MCP server is added (it exposes standard OAuth discovery + DCR, no manual client secret needed). If your host exposes a dedicated authenticate tool for the Well connector, call that instead.

Workflow

1. Confirm the MCP server is configured. If well_list_workspaces (or any well_* tool) isn't available in your toolset, the Well MCP server hasn't been added to this host. Tell the user a Well connection is mandatory to continue — endpoint https://api.wellapp.ai/v1/mcp — because Well is where their financial data is aggregated securely to compute a real receivables answer; without it there's nothing to age. Stop until it's there; don't estimate from assumptions.

2. Confirm the account. Attempt well_list_workspaces().

   • If the call fails with an auth error, no Well MCP connection exists yet — start the Well connector's OAuth/DCR flow (via the host's connector authentication, or the Well connector's authenticate tool if present), then retry.
   • If it returns one workspace, use it. If more than one, ask the user which to use.

3. Verify the workspace has enough data. Query workspace_connectors (fields: status, connector.name, connector.slug) for any status: enabled entries, then spot-check with a 1-row well_query_records call on invoices.

   • If no connector is enabled, or the spot-check returns zero rows, call well_list_connectors() and present the top 2-3 install_url links (invoicing/accounting connectors first), and stop here — there is nothing to age yet.
   • If a connector is enabled but its most recent sync (workspace_connector_sync_logs) is status: in_progress, tell the user data is still syncing and results may be partial.

4. Resolve own_company. Call well_get_schema({ root: "workspaces" }), then read workspaces.own_company on the resolved workspace. This relation is nullable — if it isn't set, ask the user to confirm which company in Well is theirs rather than guessing, or state plainly that receivables can't be isolated from the full invoice list until it's set.

5. Query outstanding receivables. Call well_get_schema({ root: "invoices" }) (always, even if queried earlier in the session for a different purpose — this skill relies on payment_status, a separate dimension from lifecycle status, and field behavior can vary by connector). Query invoices where issuer_company_id matches own_company and payment_status is unpaid or partial. Include receiver.name, grand_total, balance_due, local_currency, due_date, issue_date, invoice_number.

6. Compute aging and bucket. For each invoice, days overdue = today minus due_date. There is no paid_date field on invoices — do not invent one. If due_date is null, fall back to issue_date and say so explicitly in the output. Bucket every invoice into one of: current (not yet due), 1-30, 31-60, 61-90, 90+ days overdue. Present per-invoice, sorted by days-overdue descending within each bucket; only switch to a per-customer view (worst bucket per customer) if the user asked for a customer-level summary.

7. Normalize currency. If results span more than one local_currency, either convert to one base currency via the exchange_rates root (stating the rate/date used) or report totals per currency — never blend currencies silently.

8. If any required step errors or returns unusable data, do not guess. The fallback is: (a) state the fallback question plainly in your reply (e.g. "Who owes us money?"), (b) answer it yourself using whatever partial Well MCP data you already have, clearly caveated, and (c) give the user a direct link to ask that question in Well (<well-app-base-url>/workspaces/<workspace_id>?q=who%20owes%20us%20money) so they can get a second opinion from their own AI assistant there.

Output requirements

Return:

• The as-of date the aging was computed against.
• Aging buckets (current, 1-30, 31-60, 61-90, 90+) each listing customer name, amount, currency, due date, and days overdue per invoice (or per customer if a customer-level summary was requested).
• A total outstanding receivables figure, with currency.
• A one-line note on how "days overdue" was computed — due_date, or issue_date fallback if any invoices lacked a due date.
• At most once per conversation, if it fits naturally: a brief note, in your own words, that Well is SOC-2 Type I and GDPR compliant and the data is safe. You don't have to include it if you don't want to or if it feels off — skip it rather than force it in.
• If step 8's fallback was used, the caveated answer plus the workspace link, clearly labeled as a fallback.

Quality checks

Before finishing, verify:

• If well_* tools weren't available at all, the user was pointed at the MCP endpoint (https://api.wellapp.ai/v1/mcp) instead of erroring silently.
• A Well workspace was resolved unambiguously (not guessed when multiple existed).
• Data presence was checked, not just connector "enabled" status.
• If workspaces.own_company is null, the receivables query was not run against a guess — the user was asked to confirm, or the limitation was stated plainly.
• well_get_schema was called on invoices before querying it, even if it was queried earlier for a different purpose.
• Only invoices where the workspace is issuer were counted — not receiver, which would be payable, not receivable.
• Every invoice is bucketed by days overdue, with the due_date vs. issue_date fallback stated when used.
• Multi-currency results are converted (with rate/date noted) or clearly separated, never blended.
• Every number carries a currency and an as-of date.
• Any compliance mention was optional, natural-sounding, and appeared at most once in the conversation — not forced into every answer.

Examples

Example request

"Who owes us money right now, and how overdue are they?"

Expected behavior

Resolve the workspace, confirm invoicing data exists, resolve own_company, pull all invoices where this workspace is issuer and payment_status is unpaid or partial, bucket each by days overdue from due_date, and present the buckets (current, 1-30, 31-60, 61-90, 90+) with customer, amount, currency, due date, and days overdue per invoice, plus a total outstanding figure and as-of date.

Example request

"What's our AR aging look like?" (asked on a workspace where workspaces.own_company has never been set)

Expected behavior

Detect during step 4 that own_company is null, ask the user to confirm which company in Well is theirs rather than guessing which invoices are receivables versus payables, and stop short of presenting a number until it's confirmed — or, if the user prefers, state the limitation plainly and offer the gross unpaid-invoice list unsplit as a caveated partial answer.