Search for "AI expense management" and you will find a hundred products that use AI to help humans track their receipts and categorize their transactions. That is not what this post is about. This post is about the opposite problem: tracking what AI agents spend when they are the ones making purchases.

This distinction matters because the approaches are fundamentally different. Human expense management assumes a person made a purchasing decision and needs to report it. Agent expense management assumes software made a purchasing decision and you need to understand, attribute, and control it. The audit question changes from "why did you buy this?" to "what task authorized this spend, was it within the expected range, and can I trace it back to a specific agent run?"

I wrote an introduction to agent expense tracking in March. This post goes deeper: the architecture of agent expense management, the specific workflows that make it operational, and the patterns that emerge when you run agents with real spending authority at scale.

Why Agent Expense Management Is a Different Problem

Human expense management has decades of established tooling and process. Expensify, Brex, Ramp — the category is mature. But every tool in this category assumes the same basic model: a human made a purchase, the human has context about why, and the expense management system captures that context through receipts, categorization, and approval workflows.

AI agent spending breaks this model in five specific ways:

1. No human made the purchasing decision

When an agent buys a $7 dataset to complete a research task, no human selected that dataset or approved that specific purchase. The agent made an autonomous spending decision within its delegated authority. The expense record cannot include a human's explanation of "why" — it needs to capture the task context, the agent's decision parameters, and enough information to reconstruct the reasoning after the fact.

2. Transaction velocity is machine-speed

A human employee might submit 5-20 expense reports per month. An AI agent running autonomously can generate dozens of transactions per day. A fleet of agents across a team can produce hundreds. The expense management system needs to handle this volume without requiring per-transaction human review — the review has to be pattern-based and exception-based, not per-item.

3. Attribution goes to tasks, not people

Human expense systems attribute spend to employees and departments. Agent expense systems need to attribute spend to tasks, workflows, and agent identities. "Marketing spent $5,000 this month" becomes "the content research workflow spent $340 across 47 tasks, averaging $7.23 per task, with three tasks spending more than 2x the average." The granularity of attribution is fundamentally different.

4. Non-deterministic spending patterns

A human buying the same thing twice will spend roughly the same amount. An AI agent running the same task twice might spend different amounts depending on which data sources it accesses, which APIs it calls, and what prices those services charge at the time. Agent expense baselines are statistical, not deterministic — you need to track distributions, not fixed amounts.

5. Proactive controls, not reactive review

Human expense management is largely reactive: the purchase happens, the receipt is submitted, a manager approves or rejects it. Agent expense management must be proactive: spend limits are set before the task runs, the card balance enforces the ceiling in real time, and anomalies trigger alerts before the budget is exhausted. By the time you are "reviewing" agent expenses, the money is already spent. The controls have to be in place before the agent starts.

The Foundation: Per-Task Card Isolation

Everything in agent expense management flows from one architectural decision: issuing one card per task.

When every task gets its own card, you get automatic isolation. All transactions on card X belong to task Y. There is no ambiguity about attribution, no shared spending to untangle, and no risk of one task's spending affecting another task's budget. The card is the boundary, and the card's balance is the ceiling.

With AgentCard, this looks like:

agent-cards cards create --amount 10.00

The command returns a card ID. You record that card ID against the task ID in your system. Every subsequent transaction on that card is automatically attributed to that task. When the task completes, you close the card. The card's transaction history is a complete, isolated audit trail for that task's spending.

This is the same principle I discussed in Set Spending Limits for AI Agents, applied to expense management: the spending limit and the attribution boundary are the same thing. A card with a $10 limit that is mapped to task ID research-2026-02-25-001 simultaneously enforces the budget and creates the expense record.

Transaction Data: What Gets Captured

When an AI agent makes a purchase with an AgentCard virtual card, the following data is captured for each transaction:

  • Card ID: The unique identifier for the card, which maps to your task ID.
  • Merchant name: The name of the merchant as reported by the card network.
  • Transaction amount: The exact amount charged, in the transaction currency.
  • Currency: The currency of the transaction.
  • Timestamp: When the transaction was authorized.
  • Authorization status: Whether the transaction was approved or declined.
  • Merchant category code (MCC): The merchant's category classification in the card network.

This data is available through three channels: the check_balance and get_card_details MCP tools for real-time agent access, the agent-cards CLI for human review, and webhook events for automated ingestion into your logging and reporting systems.

Critically, the card-to-task mapping established at issuance time means every piece of transaction data inherits the task context. You do not need the agent to "report" its expenses. The expense record is created automatically by the act of spending.

Webhook-Based Transaction Logging

For production expense management, real-time MCP queries are not sufficient. You need a persistent transaction log that captures every event and stores it with full task context. This is where webhooks come in.

AgentCard sends webhook events for card lifecycle and transaction events. The pattern for building an expense management system on top of webhooks is:

  1. Receive the webhook event. Each event includes the card ID, event type, and event-specific data (transaction amount, merchant name, etc.).
  2. Verify the signature. The webhook includes an HMAC-SHA256 signature in the X-Agent-Cards-Signature header. Verify it before processing. Do not skip this step — unverified webhooks are an injection vector.
  3. Enrich with task context. Look up the card ID in your card-to-task mapping and attach the task ID, agent ID, workflow label, and any other context you recorded at issuance time.
  4. Store in your logging system. Write the enriched event to your expense logging datastore — a database table, a log aggregator, or whatever your team uses for operational data.
  5. Evaluate alert conditions. Check whether the transaction triggers any alert conditions: spend exceeding a threshold, declined transaction, unexpected merchant category, velocity anomaly.

The result is a persistent, enriched transaction log where every entry includes both the financial details (what was spent, where, when) and the operational context (which task, which agent, what workflow). This log is the foundation for every downstream expense management activity: reports, audits, anomaly detection, and budget planning.

Attribution Reports: Understanding Where Money Goes

Once you have a transaction log with task context, you can build attribution reports that answer the questions agent expense management actually needs to answer.

Per-task spend reports

The most basic report: for each task, show the total spend, the number of transactions, and the list of merchants. Compare actual spend to the authorized budget (the card's load amount). This report tells you whether tasks are spending within their budgets and identifies outliers.

Example output:

Task: research-2026-02-25-001
  Budget: $10.00
  Spent:  $7.42 (74.2%)
  Transactions: 3
    - DataProvider.io: $3.00
    - CloudStore API: $2.42
    - RefData.com: $2.00

Task: research-2026-02-25-002
  Budget: $10.00
  Spent:  $9.87 (98.7%)  [!] Near budget ceiling
  Transactions: 5
    - DataProvider.io: $3.00
    - DataProvider.io: $3.00
    - RefData.com: $2.00
    - CloudStore API: $1.87
    - PremiumData.io: DECLINED

The second task spent 98.7% of its budget and had a declined transaction, which means it tried to spend more than authorized. This is useful signal: it might mean the budget was too conservative for the task, or it might mean the agent made an unnecessary purchase. Either way, it warrants review.

Per-workflow aggregate reports

Group tasks by workflow type and compute aggregate statistics: average spend per task, median spend, standard deviation, total spend for the period. This tells you whether workflow budgets are calibrated correctly and reveals trends over time.

If the "content research" workflow averages $7.23 per task with a standard deviation of $1.80, you know a $10 budget covers most runs comfortably. If a new run comes in at $15, that is a 4+ sigma outlier worth investigating. If the average creeps from $7 to $9 over a month, data source prices might be increasing and budgets need adjustment.

Per-merchant spend analysis

Group transactions by merchant to understand where agent money goes. This reveals patterns that are not visible at the task level: "60% of all agent spend goes to DataProvider.io — should we negotiate a volume discount or prepay for credits?" or "agents are spending $200/month at a merchant I don't recognize — what is that?"

Anomaly Detection Patterns

Automated anomaly detection is essential for agent expense management at scale. Here are the patterns that matter:

Budget ceiling proximity

Alert when a task spends more than 90% of its budget. This is not necessarily a problem — some tasks legitimately need their full budget — but it warrants attention because it might indicate that budgets are too tight or that the agent is making unnecessary purchases.

Declined transaction alerts

Every declined transaction means the agent tried to spend more than it was authorized to. This is the spending control working as intended, but it also means the task could not complete its intended purchase. Track declined transactions to calibrate budgets and identify tasks that consistently hit their ceiling.

Spend velocity anomalies

Monitor the rate of spending across all agent cards. A sudden spike — say, 10 transactions in 60 seconds across multiple cards — might indicate a bug in an agent loop, a misconfigured workflow, or (in the worst case) a compromised agent. Set velocity thresholds based on your historical patterns and alert when they are exceeded.

New merchant detection

Flag transactions at merchants that agents have not previously used. New merchants are not inherently suspicious, but they represent a change in agent behavior that is worth reviewing. If your agents have been using the same three data providers for weeks and suddenly start buying from an unknown merchant, that deserves a look.

Per-task transaction count outliers

If a typical task makes 2-3 transactions and a new task makes 15, something is different. It might be a more complex task, or it might be a retry loop. Flag tasks with transaction counts more than 2 standard deviations above the workflow average.

Dashboard Review Patterns

During initial deployment, establish a weekly review cadence. The review should take 15-20 minutes and cover:

  1. Total agent spend for the week. Is it within your expected range? Trending up or down?
  2. Budget utilization distribution. What percentage of tasks spent less than 50% of their budget? Less than 90%? More than 90%? This tells you whether budgets are calibrated correctly.
  3. Declined transactions. How many, and for which tasks? Are the same workflows consistently hitting their ceiling?
  4. Top merchants by spend. Any surprises? Any merchants you do not recognize?
  5. Anomaly alerts fired. Review any velocity, new merchant, or transaction count alerts. Were they real issues or false positives? Tune thresholds accordingly.

After the first month of production agent spending, shift to exception-based review: only review when alerts fire or when periodic reports show anomalies. The goal is to reach a steady state where agent spending is boring — predictable, well-attributed, and within expected ranges.

Building Reports for Finance Teams

At some point, someone from finance will ask for a report on agent spending. They will not be familiar with task IDs, MCP tools, or card-per-task architecture. They will want numbers they can reconcile with standard accounting categories.

The bridge between agent expense management and traditional finance reporting is the card-to-task mapping enriched with business context. When you create a card for a task, attach metadata that finance can understand:

  • Cost center or department: Which budget does this task draw from?
  • Project code: Which project is the task part of?
  • Expense category: Data acquisition, software licenses, API usage, cloud compute, etc.
  • Approver: Which human authorized this workflow to spend money?

With this metadata attached to each card, you can generate reports that group agent spend by cost center, project, or category — the same dimensions finance uses for human expense reporting. The underlying mechanism is different (per-task cards instead of per-employee expense reports), but the output is compatible with standard financial reporting.

The Per-Task Isolation Advantage

The recurring theme in everything above is per-task isolation. One card per task gives you:

  • Automatic attribution: No need to parse transactions and figure out which task they belong to. The card is the boundary.
  • Enforceable budgets: The card balance is the ceiling. No software bug, no prompt injection, no agent misbehavior can spend more than the loaded amount.
  • Clean audit trails: Each card's history is a self-contained record of one task's spending. No shared-card ambiguity to resolve.
  • Easy anomaly detection: Compare each task's spending to the workflow average. Outliers are immediately visible.
  • Simple cleanup: When a task completes, close the card. There is no residual balance to track, no shared card to reallocate, no cleanup logic beyond one API call.

This is the same architecture I described in the original expense tracking post, extended with the reporting, anomaly detection, and finance integration layers that production deployments require. The foundation has not changed: per-task cards are the right primitive for agent expense management.

Scaling Agent Expense Management

As agent spending scales from a few tasks per day to hundreds, the expense management approach needs to evolve:

10 tasks per day

Manual review works. Look at each task's spending, check for anything unexpected. The CLI is sufficient: agent-cards cards list gives you the full picture.

50 tasks per day

Webhook-based logging becomes necessary. You cannot manually review 50 tasks daily. Set up automated attribution reports and exception-based alerting. Review weekly, not daily.

200+ tasks per day

You need a proper expense management pipeline: webhook ingestion, enrichment with task metadata, storage in a queryable datastore, automated anomaly detection, and dashboard reporting. Finance integration becomes important because the dollar amounts are large enough to matter for budgeting and forecasting.

The good news is that the underlying architecture — per-task cards with webhook events — scales linearly. The same primitives work at every scale; what changes is the sophistication of the analysis and reporting layer on top.

Frequently Asked Questions

How do I audit what my AI agent spent money on?

Issue one card per task so each card maps to one task. Every transaction is automatically attributed. Use the list_cards and check_balance MCP tools or the CLI to review activity. For comprehensive auditing, consume transaction webhooks and store events with task context attached.

Is AI agent expense management different from regular expense tracking?

Yes. Agent expense management handles autonomous spending decisions where no human chose the specific purchase, machine-speed transaction velocity, attribution to tasks rather than people, non-deterministic spending patterns, and proactive spend controls rather than reactive review.

How do I track AI agent spending across multiple tasks?

Issue one card per task, label each with a task identifier, and aggregate by querying all cards by time range or label. The MCP tools and CLI provide real-time queries. Webhook events enable historical reporting. Include agent ID in card labels for multi-agent attribution.

What transaction details are captured when an AI agent makes a purchase?

Merchant name, transaction amount, currency, timestamp, card ID, authorization status, and merchant category code. Combined with the card-to-task mapping from issuance, this provides a complete audit trail from task authorization through transaction execution.