missing-receipts

name

missing-receipts

description

Find invoices (and optionally transactions) with no source document attached — a compliance/expense-hygiene check backed by Well's MCP financial graph. Use when the user asks "which expenses are missing receipts", "find missing receipts", "compliance check on receipts", "which invoices have no document attached", "do we have documentation for all our expenses", or "missing documentation". This is a find-only check: it surfaces the gap but cannot fetch a missing receipt from a vendor portal or inbox. Requires a connected Well workspace with invoicing data; if none is connected, this skill walks the user through connecting one first.

Find Missing Receipts with Well

Purpose

Use Well's MCP tools to answer "do we have documentation for all our expenses?" by finding invoices with no attached source document (no receipt/bill PDF on file), backed by Well's synced financial graph rather than a manual folder-by-folder check.

When to use this skill

Use this skill when the user asks things like:

• "Which expenses are missing receipts?"
• "Find missing receipts" / "missing documentation"
• "Compliance check on receipts"
• "Which invoices have no document attached?"
• "Do we have documentation for all our expenses?"

When not to use this skill

Do not use this skill when:

• The user wants to reconcile a payment against an invoice (a payment with no matching invoice, or vice versa) — that's a matching problem, not a documentation-attachment problem. Use the payment-invoice-lookup skill instead.
• The user wants the missing receipt actually fetched or collected (from a vendor portal, email inbox, etc.) — this skill only finds the gap. It cannot auto-collect a document; say so plainly rather than attempting it.
• No Well MCP connection is available and the user does not want to set one up — say so instead of guessing.

Inputs

The user may provide:

• Which workspace to use (if they manage more than one in Well).
• A time window (e.g. "this quarter", "last 3 months") — default to the trailing 3 full months if unspecified.
• A payment-status filter (e.g. "just the unpaid ones") — default to all payment statuses if unspecified.

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, and optionally transactions.
• 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. This is especially important for the secondary transaction check below, since the exact relation name that exposes a transaction's linked documents is not fixed.
• well_list_connectors — surface install links when the workspace lacks 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 compliance answer; without it there's nothing to check. 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 check 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 the scope. Default to the trailing 3 full months if the user didn't give a window. If the user asked for a payment-status filter (e.g. "just unpaid ones"), carry it into the next step; otherwise include all payment statuses.

5. Find invoices with no attached document. Call well_get_schema({ root: "invoices" }) first. Query invoices within the window (and payment-status filter, if any) where the document relation is null (_is_null: true on that field per the query tool's documented operators). Fields: invoice_number, reference_number, issuer.name, receiver.name, grand_total, local_currency, issue_date, payment_status. This is the primary, most reliable check for this skill.

6. Optional deeper check: transactions with no linked document. This is secondary — not required for a basic answer, and worth calling out as such to the user. documents link to transactions through a many-to-many join, not a direct foreign key, so call well_get_schema({ root: "transactions" }) first to find the exact current field/relation name that exposes it — do not guess or hardcode a name. If found, query transactions within the same window for entries with no linked document, and report the count as an additional finding alongside the invoice results.

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

8. State the scope limit plainly. Regardless of how many results are found, tell the user this skill only finds the gap — it cannot fetch or collect the missing receipt from a vendor portal, email, or anywhere else.

9. 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. "Which expenses are missing receipts?"), (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=which%20expenses%20are%20missing%20receipts) so they can get a second opinion from their own AI assistant there.

Output requirements

Return:

• The window (and any payment-status filter) used.
• A count of invoices missing a document.
• A list of the affected invoices (issuer/receiver, amount, currency, issue date, invoice number), capped at 20 — if more exist, state the total count and that the list was capped.
• If the secondary transaction check was run, a one-line note on how many transactions have no linked document.
• An explicit one-line statement that this is a find-only check: auto-collection of a missing receipt is not available.
• 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 9'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.
• well_get_schema was called before querying any root for the first time, including before attempting the secondary transaction check.
• The invoices.document relation was checked with a real null-filter, not a guessed field name.
• If the secondary transaction check was attempted, the relation name was discovered from the schema, not hardcoded.
• Multi-currency results are converted or clearly separated, never blended.
• Every number carries a currency and a date.
• The "find-only, no auto-collect" limitation was stated plainly in the output, not implied.
• Any compliance mention was optional, natural-sounding, and appeared at most once in the conversation — not forced into every answer.

Examples

Example request

"Which expenses are missing receipts this quarter?"

Expected behavior

Resolve the workspace, confirm invoicing data exists, query invoices for the trailing 3 months where document is null, and return something like "14 invoices this quarter have no document attached, totaling $8,240 across 3 currencies" followed by a capped list (issuer, amount, currency, date, invoice number) and the explicit note that this skill cannot fetch the missing receipts itself — only surface them.

Example request

"Do we have documentation for all our expenses last month?"

Expected behavior

Resolve the workspace, run the same query scoped to last month, and if zero invoices come back with a null document, report a clean bill of health ("all N invoices from last month have a document attached") rather than an empty, unexplained list — still note the find-only scope limit for completeness.