# Ramp Spend Audit > Review Ramp spend for possible duplicate software, fragmented vendor payments, unused funds, oversized limits, and recurring-spend controls. Use when a customer asks for a spend audit, savings opportunities, or safer recurring spending. This skill identifies opportunities; it does not cancel subscriptions or change vendor-side payment settings. - Skill: `ramp-public/ramp-spend-audit` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add ramp-public/ramp-spend-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/ramp-public/ramp-spend-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: ramp-public (https://skillmd.com/u/ramp-public) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ramp-public/ramp-spend-audit --- # Spend Audit Start by asking which review the customer wants unless their request already names one. 1. Check everything 2. Software we may be paying for twice 3. Vendors we pay in more than one way 4. Money set aside that no one uses 5. Spending limits that may be too high 6. Regular payments that need better controls If the customer names an outcome, skip the menu and route directly to its guide. For a full audit, begin with one shared account scan, then use the relevant guides for each shortlist. Do not fetch the same broad account data again for every section. ## Direct Routing - Possible duplicate software: read [software-sprawl](references/software-sprawl.md). - A vendor paid by card and bill or through multiple funds: read [multiple-payment-methods](references/multiple-payment-methods.md). - Unused or dormant funds: read [unused-funds](references/unused-funds.md). - Limits that are likely oversized: read [high-limits](references/high-limits.md). - Recurring charges needing a dedicated control: read [recurring-spend-controls](references/recurring-spend-controls.md). ## Shared Audit Rules - Start read-only. Do not create, update, lock, unlock, or otherwise change a fund until the customer approves the exact change. - Discover capabilities for the current connection and permission first. Possible Ramp actions include: create a vendor-restricted fund; update merchant/category restrictions; set a positive periodic limit; set a per-transaction limit; lock or unlock a fund. This list is not runtime evidence; every action claim requires current connection plus permission discovery. Do not claim an action is available until runtime discovery confirms it. Otherwise give the manual Ramp-app path. - Use cleared or completed activity, keep currencies separate, and subtract refunds. Failed, declined, draft, and deleted activity is not spend evidence. - Check at least six months when available. An incomplete query, timeout, truncated page set, or unexpectedly small population is **Reduced coverage**, not proof that there are no findings. - A `trip_id = 0` means nontravel; a positive trip ID means travel-linked. Travel, dining, group-event, and multiple-attendee exclusions apply only to duplicate or overlap candidates. January 1, 1970 or near-epoch last-used timestamps are a never-used signal, verified against cleared activity, not a blanket exclusion. Bill-versus-card pairs are payment-method reviews, not duplicate spend; do not filter them out of that focused audit. - A possible overlap is an investigation, not a cancellation instruction or guaranteed saving. Do not make vendor-side changes or claim that a subscription has been cancelled. - Unless the admin asks for technical details, do not show CLI commands. Do not show MCP operation names. Do not show table names. Do not show query details. ## Check Everything Use the one shared account scan to group cleared card activity and paid bill activity by normalized vendor, currency, route, month, user, fund, and category. Record the date range, row count, distinct vendors, and which routes were available. For fund reviews, obtain the complete active-fund catalog from the scalable fund/allocation population surface; this is the candidate population, including active funds with no cleared spend. Follow `next_cursor` through every page of the lightweight catalog, or use the scalable Analyst allocation population surface when it returns the complete set. Include funds after page one, but do not read live details per fund during this population sweep. Use spend facts only to measure activity, then rank the complete lightweight catalog using available summary and activity fields. Cap expensive live detail reads at the ten strongest candidates needed to produce the five-result output. Catalog pagination completion is required and is not subject to the detail-read cap. Return the five most important items first. Keep savings and control opportunities separate. Offer `show me more` to reveal lower-priority items, supporting transactions, exclusions, and calculations. ## Output Format ```text Finding X: Next step: ``` Use only `Finding X` and `Next step` as result labels. Add one coverage note after the findings with the date range, routes and populations checked, and any **Reduced coverage**. For a ready control change, use this sequence: user chooses an outcome; re-read the exact target; show current state, proposed state, and consequence; user approves the exact change; re-read immediately before acting; make only that change; re-read and report the resulting state. A vague "fix it" is not approval.