Аудит подписок
Неиспользуемые и дублирующие подписки, рекомендация cancel/keep.
Обзор
Keep SaaS spend honest without turning into weekly noise. A cron re-prompts a persistent session that pulls recurring charges from Plaid, reads the subscription register in {{subscription_sheet}}, and reconciles the two: duplicate or overlapping tools, seats that look unused, price hikes since the last check, renewals coming up soon, and shadow IT — recurring charges with no matching row in the register. Only new or changed findings get reported; an unresolved item from last week doesn't repeat as if it were new.
Proactive and schedule-driven; read-only against Plaid and the register, with a single Slack digest as the only output. The agent recommends; it never cancels, pauses, downgrades, or otherwise modifies a subscription.
Когда подключать
- The weekly cron fires the spend-audit run.
- A human asks for a manual check of SaaS spend or a specific vendor.
- The subscription register is updated and needs a fresh reconciliation pass.
Workflow
Step 0 — Orient and resume
cat .kortix/memory/saas-spend-audit-log.md 2>/dev/null || echo "(no ledger yet — first run)"Read the last recorded state for every tracked subscription: its last known price, when it was last flagged, what was recommended, and whether it's still open. This run diffs against that history — a subscription flagged last week with nothing new to say gets skipped, not repeated.
Step 1 — Pull recurring charges from Plaid
Fetch card and bank transactions for a trailing window (60–90 days) wide enough to catch both monthly and annual cadences. Group by merchant/payee and amount to identify which charges are actually recurring — a one-off purchase is not a subscription.
Step 2 — Read the subscription register
Read every row in {{subscription_sheet}}: vendor, plan, seat count, price, renewal date, and owning team, where present. This is the source of truth for what the business believes it's paying for.
Step 3 — Reconcile charges against the register
Match each recurring charge to a register row by vendor and amount (allow small tolerance for currency conversion or a prorated period). A recurring charge with no matching row, after checking obvious name variants (Acme Inc. vs Acme, Inc vs ACME*SUBSCRIPTION), is shadow IT.
Step 4 — Detect the five waste signals
| Signal | How to detect |
|---|---|
| Duplicate / overlapping tools | Two or more register rows serving the same category (e.g. two project-management tools, two e-signature tools) with active charges on both. |
| Unused seats | A register row's seat count against any usage/active-user data available (register notes, admin exports mentioned in the sheet); flag a gap wide enough to matter, not a single idle seat. |
| Price hikes | This charge's amount vs. the last price recorded in the ledger or register for that vendor — flag anything above the skill's threshold (default: >5% or any absolute jump worth a person's attention). |
| Upcoming renewals | A register renewal date within the next 30 days, especially on an annual plan, so there's time to act before it auto-renews. |
| Shadow IT | A recurring charge from Step 3 with no matching register row at all. |
Step 5 — Filter against the ledger
Drop anything unchanged from a prior week's report. Keep: brand-new findings, findings where something material changed (price moved again, renewal is now closer, a previously-unused seat is still unused N weeks later), and anything a human marked in the ledger as "recheck." Never drop shadow IT until it's either added to the register or explicitly dismissed by a human.
Step 6 — Compose and post the digest
One message to {{alert_channel}} per run:
- Group by signal type (duplicates, unused seats, price hikes, renewals, shadow IT).
- Each line: the vendor, the evidence (charge amount, register row or its absence, the specific numbers involved), and a suggested action — cancel, downgrade, consolidate onto one tool, renegotiate before renewal, or "add to register and confirm owner" for shadow IT.
- A quiet week (nothing new or changed) gets a single brief line, not a re-post of every still-open item in full.
Every recommendation is phrased as a suggestion for a person to execute — the agent never implies it has taken or will take the action itself.
Step 7 — Update the ledger
Update .kortix/memory/saas-spend-audit-log.md with the current state of every tracked subscription (see <ledger-format>) and a dated log line of what was reported this week.
<ledger-format> Lives at .kortix/memory/saas-spend-audit-log.md. Maintains, per vendor: the last known price, the last charge date and amount, the register match status (matched / shadow IT), the most recent recommendation and its status (open / dismissed by a human / register updated). Below that, dated Run log entries with what was newly reported, what stayed silent because it was unchanged, and any reconciliation the agent couldn't resolve (e.g. ambiguous vendor name match) for a human to confirm next run. </ledger-format>
Ограничения
- Recommend-only. The agent suggests cancellations, downgrades, and consolidations. It never cancels, pauses, downgrades, or otherwise modifies a subscription or a payment method — no billing API write access exists.
- Read-only connectors. Plaid and the subscription register are read-only. The agent never writes a row, a price, or a status into either system.
- No repeat noise. The ledger is checked before every post — an unresolved finding from a prior week is not re-reported as new.
- Shadow IT is flagged, not judged. A charge with no register match is reported with its evidence; the agent doesn't assume it's unauthorized or recommend blocking the card, only that a human confirm and register it.
- Secrets scoped. The Plaid access token and Sheets credentials are injected at runtime, scoped to this agent's grant.
- Audit rules are code. Waste thresholds (e.g. the price-hike percentage) live in this skill and change through a reviewed change request, not an ad hoc instruction mid-run.
