Expense Policy Audit

skill

Pull card/expense transactions, test them against policy rules, and flag exceptions to managers.

Download .md

Expense Policy Audit

Pull card and expense transactions, test each one against your organization's expense policy rules, and flag exceptions to the responsible manager for review.

When to use

  • You need a recurring sweep of company card or reimbursement transactions checked against spending limits, category rules, or receipt requirements.
  • A manager wants a digest of policy exceptions (over-limit spend, missing receipts, disallowed categories, duplicate charges) instead of reviewing every line item manually.
  • Finance wants proposed corrections (flag for refund, reclassify, or reverse) staged for human sign-off rather than applied automatically.

Tools

  • http-get — read expense/card transactions and policy reference data from the finance or card-provider API.
  • shell-execute — run a local script to parse exported transaction data and apply policy rule checks (limits, categories, duplicate detection).
  • send-message — notify the relevant manager or finance teammate with a summary of flagged exceptions.
  • create-task — stage any proposed corrective action (refund, reversal, journal entry) as a human approval task; never execute it directly.

Playbook

  1. Call http-get against the expense platform's REST API (e.g. GET https://api.expenseprovider.com/v1/transactions?since=2026-07-01) to pull the latest card and reimbursement transactions.
  2. Call http-get again (e.g. GET https://api.expenseprovider.com/v1/policies) to fetch the current policy rule set: spending limits per category, required receipt thresholds, disallowed vendors, and approval tiers.
  3. Use shell-execute to run a local parsing script that normalizes the transaction export and evaluates each transaction against the fetched policy rules, producing a list of exceptions (over-limit, missing receipt, disallowed category, duplicate charge).
  4. For each transaction that appears twice or shows a suspicious near-duplicate amount/vendor/date, confirm it with a second http-get call to the provider's transaction detail endpoint before flagging it as a duplicate.
  5. Group exceptions by the employee's manager using org data already available to you, and draft a concise summary per manager: transaction ID, amount, vendor, rule violated, and recommended action (approve, request receipt, escalate, or reverse).
  6. If a transaction needs a proposed refund, reversal, or journal correction, do not execute it — call create-task with a title starting "APPROVAL: " (e.g. "APPROVAL: Reverse $412 duplicate charge, txn #8891") describing the transaction, the rule violated, and the proposed action, and route it to the finance approver.
  7. Call send-message to each manager (or the finance lead) with the exception summary and links to the corresponding approval tasks so they can act quickly.
  8. If the policy platform lacks an endpoint for a needed check (e.g. no vendor-blacklist API), stop and route the gap as a human handoff via send-message rather than guessing at the rule.
  9. Log a brief run summary (transactions reviewed, exceptions found, approval tasks created) so the next audit run has a clean starting point.

Failure modes

  • Policy rules fetched from http-get are stale or incomplete, causing false positives or missed violations — always confirm the policy source and timestamp before flagging.
  • Duplicate-detection logic in shell-execute misfires on legitimate recurring charges (e.g. monthly software subscriptions); verify vendor and cadence before flagging as a duplicate.
  • Proposing a financial correction without staging it through create-task as an approval item — this playbook never authorizes autonomous money movement.
  • Missing or misconfigured Integration credentials on the expense provider's host causes http-get calls to return 401/403; stop and message a human via send-message naming the service and required scopes rather than retrying blindly.

Done when

  • All transactions since the last audit have been pulled and evaluated against current policy rules.
  • Every exception has either a manager notification (send-message) or a staged approval task (create-task titled "APPROVAL: ...") — no corrective action was executed directly.
  • The relevant managers or finance lead have received a clear, actionable summary of flagged exceptions.