{"id":14813,"plugin_id":"plugin_asdk_app_6aa7b09b97808191b0ced38534cd8782","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:10:14.282Z","digest":"9cdf84a4fb0ad7fffa38782e992379c8df40828e7ab2e6e1ff3635fba503420f","against":null,"payload":{"name":"checking-payments","description":"Look up what a company owes its contractors through Wingspan and what has happened to a particular payment. Use for \"what do we owe\", \"what did we pay last month\", \"how much is outstanding\", \"what is awaiting approval\", \"show me [name]'s payments\", \"what happened to this payment\", \"why has this not been paid yet\", \"has this been paid\", \"is this payment disputed\".","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":365}],"skill_md_contents":"---\nname: checking-payments\ndescription: Look up what a company owes its contractors through Wingspan and what has happened to a particular payment. Use for \"what do we owe\", \"what did we pay last month\", \"how much is outstanding\", \"what is awaiting approval\", \"show me [name]'s payments\", \"what happened to this payment\", \"why has this not been paid yet\", \"has this been paid\", \"is this payment disputed\".\n---\n\n# Checking payments\n\nThe shared rules for every call — ids, paging, previewing a write, what the\ntools cannot do — are in the `using-wingspan-tools` skill. Apply them here.\n\nA **payable** is one payment owed to one contractor — the row on the Payables\nscreen in the Wingspan app. A **contractor** is a person or business the company\npays. An **engagement** is the named working arrangement a payment is filed\nunder.\n\nTwo tools cover most of this: `search_payables` lists and filters, `get_payable`\nreads one payment in full. Every row a search returns carries a `payableId`, and\nthat is the id `get_payable` takes. A third, `get_payroll_preview`, reads what\nthe next payroll run would pay as things stand today.\n\n## Listing and searching\n\n`search_payables` with no arguments lists every payment except cancelled ones,\n25 to a page.\n\n| Argument | What it does |\n| --- | --- |\n| `query` | Free-text search over the contractor's name, email and company, plus the invoice number. At least two characters; a full email address matches exactly. |\n| `status` | Which screen view to read: `all`, `draft`, `toApprove`, `scheduled`, `paid`, `cancelled`. |\n| `contractor` | One contractor's payments only — their `contractorId`, your external id for them, or their email. |\n| `referenceId` | The one payment carrying your own id for it, set when it was created. No two payables share one. |\n| `dueDateFrom`, `dueDateTo` | Bound the due date, as `YYYY-MM-DD`, inclusive. |\n| `paidDateFrom`, `paidDateTo` | Bound the date paid, as `YYYY-MM-DD`, inclusive. |\n| `sortBy` | `dueDate`, `createdAt`, `updatedAt`, `openedAt`, `paidAt`, `amount` or `scheduledPaymentDate`. One field per call. |\n| `sortDirection` | `asc` or `desc`. Defaults to `desc`. Refused without `sortBy`. |\n| `limit` | Rows per page, 1 to 100. Defaults to 25. |\n| `pageToken` | Continue a previous page. Pass the previous result's `pagination.nextPageArgs` back unchanged. |\n| `accountId` | Read one child account of an organization instead of the signed-in account. Only when the user names one; `who_am_i` lists them. |\n\nThere are no other filters. Do not invent one.\n\nWhat each `status` view holds:\n\n- `all` — every payment except cancelled ones.\n- `draft` — created but not yet opened, so the contractor cannot see it.\n- `toApprove` — open and waiting for someone at the company to approve it.\n- `scheduled` — approved and waiting for a payroll run.\n- `paid` — paid or in transit only. Payments recorded off-platform, partially\n  paid or refunded are not in this view; use `all` for a complete history.\n- `cancelled` — cancelled. Hidden everywhere else, which is why totals stay\n  honest.\n\nEvery view, `all` included, also leaves out two kinds of row: the batch-level\ntotal a payroll run creates, which would double-count against the individual\npayments, and personal payment-link invoices. Neither can be read by id either.\n\n## Totals\n\nA list normally carries a `summary` with a count and an amount total, covering\n**every** payment matching the filters, not only this page. Use it for \"how\nmuch do we owe\" instead of adding up a page, and say which filters it covers.\nWhen `summary` is null the totals were unavailable — say so rather than summing\nthe page and presenting it as the total.\n\nA correct total over the wrong set of payments is still the wrong answer, so\npick the view before reading the summary:\n\n- **\"What do we owe?\"** means approved-and-unpaid plus open-and-unapproved.\n  Read `scheduled` (approved, waiting for a payroll run) and `toApprove` (open,\n  waiting for approval) separately and report both figures with their names.\n  Do not read `all`: it includes paid, in-transit, off-platform and refunded\n  payments.\n- **Drafts are not owed yet.** `draft` payments are invisible to the contractor\n  and not scheduled. Report them as a separate line if the user asks what is\n  in the pipeline, never inside the owed figure.\n- **Partial payments are not separable here.** A partially paid payable shows\n  its full amount in whichever view holds it; the summary has no\n  remaining-balance figure. If the roster has partially paid payables, say the\n  owed figure may overstate what remains, and point to the Wingspan app for\n  the exact balance.\n- **`paid` is history, not liability.** It answers \"what have we paid\", and\n  only for payments paid or in transit; off-platform and refunded records sit\n  under `all`.\n\n## The words on a row\n\nEach row's status is the wording the Wingspan app shows, not a raw code, so it\ncan be read to the user as-is.\n\n| Row says | Means |\n| --- | --- |\n| Draft | Created and not yet opened. |\n| Action required | Waiting on someone at the company: approval, a dispute the contractor raised, or something the contractor resubmitted. |\n| Awaiting contractor | Open, but the contractor was not eligible for payment when it came up. |\n| Scheduled | Approved and queued for a future payroll. |\n| Paid | Paid, or the payment is in route. |\n| Refunded | Refunded, in whole or in part. |\n| Off-platform | A historical record of a payment made outside Wingspan. |\n| Cancelled | Cancelled. |\n\nOne more value can appear on a row: `Unknown`, when the payment is in a state\nthe row wording has no pill for — a returned deposit is the common case. Read\n`get_payable` for it; the detail headline names it, Returned. The money did not\nland, the payment stays on the payroll run it was part of, and it is final for\nthat payment: a replacement is a new payment, created in the Wingspan app.\n\n**Approval is a separate field from status.** A payment can be open and\nunapproved, or open and approved; the status wording above folds that in, but\nthey are two different things underneath. Approving happens in the app.\n\n## One payment in full\n\n`get_payable` returns what the Payables detail panel shows:\n\n- The panel headline and the row's status wording.\n- Any alert on it. Two exist: the contractor has not finished setting up\n  digital payments, and the contractor disputed the invoice — their reason is\n  in the activity timeline.\n- The amount, with the breakdown from gross to net and a named row per\n  deduction.\n- The line items, the due date, whether the due date was rescheduled, and the\n  original date if it was.\n- How it was paid, the attachments, any notes and purchase-order or project\n  labels.\n- `activity` — the full timeline of everything that has happened to it,\n  newest first.\n\nQuirks of the timeline are worth knowing before you conclude something did not\nhappen. At most two views of the invoice link are ever listed — the first, and\nthe first more than an hour after it — so a short timeline is not evidence the\ncontractor stopped looking. Views after the payment was paid are dropped. A\n\"due today\" reminder sent on the same day the payment was opened is suppressed.\n\n## What these tools cannot see\n\n**Where the money is in the banking system.** No payout or bank-transfer\nrecord is read, matching what the Payables screen itself shows. The furthest\neither tool goes is the date the deposit was confirmed. A confirmed deposit\nmeans the sending bank finished processing, not that the money is available or\nfinal — a payment can still come back afterwards, and that shows up on the\npayment itself, where `get_payable` names the state Returned. A question like\n\"has the bank transfer landed\" or \"why did the transfer fail\" belongs in the\nWingspan app, or with Wingspan support.\n\n**Past payroll runs and funding sources.** A payroll run is the batch that funds\nand pays a set of approved payments, and the funding source is the account\nWingspan debits to fund it. `get_payroll_preview` reads the *next* run before it\ngoes out — when it processes, how much moves, what is funded but held on\neligibility, and what gets left behind. Runs that have already happened, and the\naccount behind any of them, are not readable here. When a user asks why a\nscheduled batch has not gone out, or which account funded it, send them to the\nPayroll screens in the app.\n\n**What the preview is worth predicting with: nothing.** It is today's data, not\na forecast. It reports what the next run would pay if it went out against the\nrecords as they stand right now, and it models none of what happens between now\nand then — a contractor finishing a requirement and becoming eligible, someone\nopening or approving a draft, an amount edited, a payment cancelled, a new\npayable created. Any of those changes the answer. Report it as \"as things stand\ntoday\" and never as what the run will pay.\n\n## Why is this not paid yet\n\nWork down this list.\n\n1. `get_payable`. If the status is Draft, it was never opened. If it says\n   action required, the secondary line on the row says which of the three it\n   is — approval, a dispute or a resubmission. If it says awaiting contractor,\n   the contractor was not eligible when the payment came up.\n2. If the answer points at the contractor, `get_contractor` with the\n   `contractorId` on the payment. Its `alert` gives the single reason —\n   invited and not signed up, tax information not shared, archived, payments\n   eligibility pending, an outstanding requirement, or one expired or\n   expiring. The `finding-contractors` skill lists all eight outcomes.\n3. If the payment is paid but the contractor says the money has not arrived,\n   that is the banking question above: Wingspan app, or Wingspan support.\n\n**\"Awaiting contractor\" is not a reason to cancel anything.** It means the\ncontractor was not eligible at the moment payment came up. Fix the contractor\nand the payment carries on. Cancelling and recreating loses the record and,\nbecause a payment's engagement is fixed when it is created, is sometimes\nunrecoverable.\n\n## Finish these in the Wingspan app\n\n- Approving or unapproving a payment, rescheduling it, cancelling it, and\n  paying it. Releasing a draft is not app work — that is `open_payables`.\n- Starting a payroll run, funding sources, invoices, payment splits and\n  accounting integrations.\n- Resolving a dispute with a contractor.\n- Anything about a bank transfer after Wingspan has sent the payment.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}