Skip to content
Back to skills

Ar Aging

ASecurity

Produce an accounts-receivable aging report and surface overdue invoices for a Well workspace. Use when the user asks who owes them money, an AR aging report, overdue invoices, days sales outstanding (DSO), or which customers to chase.

  • 342 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 1, 2026
toolsrust

Security analysis

A100/100

Scanned September 1, 2026

npx -y skills add WellApp-ai/Well --skill ar-aging --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ar Aging?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ar Aging
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/wellapp-ai-ar-aging/badge)](https://www.skillsdirectory.com/skills/wellapp-ai-ar-aging)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ar-aging
description: Produce an accounts-receivable aging report and surface overdue invoices for a Well workspace. Use when the user asks who owes them money, an AR aging report, overdue invoices, days sales outstanding (DSO), or which customers to chase.
---

# Accounts-receivable aging from Well

Collections is **judgment, not nagging**. The point of an aging report is to chase the right customers — firmly where their payment history warrants it, gently where it doesn't — and to **never chase an invoice that was already paid, disputed, or credited**. Verify status before recommending any chase.

## Build it

1. **Discover the schema first** (see `well:querying-well-data`).
2. **Open receivables** — issued `invoices` filtered on the payment-status / outstanding field the schema exposes (don't infer "unpaid" by subtracting sums if a status field exists). Pull due date, outstanding amount, and the customer (`companies`).
3. **Confirm what's actually settled** — cross-check against `transactions` / `invoice_transactions` so a payment already received but not yet reflected in status isn't counted as overdue. This is the `well:reconciliation` sibling skill — reuse it.
4. **Bucket by age** from the due date: Current (not yet due), 1–30, 31–60, 61–90, 90+ days overdue. Total per bucket and per customer.
5. **Per-customer behavior** — where history exists, note each customer's typical days-to-pay so the user can prioritise (a chronic late-payer ≠ a first-time slip).

## Rules

- **Verify status before chasing.** Exclude paid / disputed / credited invoices from "to chase" — chasing a settled invoice is the fastest way to lose trust.
- Sort the chase list by amount × overdue age, but annotate each with the customer's payment tier.
- Don't sum across currencies without converting (`exchange_rates`).
- Report **DSO** (days sales outstanding) only with the window it's computed over.

## Present it

An aging table (buckets × totals), a top "to chase" list (verified-open only, with each customer's payment behavior), DSO with its window, and the total outstanding — in the workspace currency.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.