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.
• A vendor paid by card and bill or through multiple funds: read multiple-payment-methods.
• Unused or dormant funds: read unused-funds.
• Limits that are likely oversized: read high-limits.
• Recurring charges needing a dedicated control: read recurring-spend-controls.

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

Finding X: <decision-oriented title>
<Short plain-language body with the evidence and likely impact needed for the decision.>
Next step: <review, owner confirmation, or exact proposed control change>

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.