Making every agent charge explainable

Take a hypothetical mid-sized SaaS company. It deployed a procurement agent to watch software license usage and buy seats before teams hit capacity. The agent got card access through a token delegation provider with a reassuring pitch: a 500 dollar per-transaction policy limit, merchant category restrictions, a monthly cap. Finance reviewed the setup and signed off. The controls looked solid on paper.

On Thursday at 2:47 PM, the agent tried to buy 10 seats of a project management tool and the vendor's checkout API returned a temporary 503 error. The agent did what agents do: it retried. On the sixth attempt the API accepted the request but returned a malformed success response, which the agent's validation logic read as a failure. So it retried again. The purchase went through cleanly this time, but the agent's internal state still said incomplete, so it kept going. Between 2:47 and 2:50 PM it submitted 12 purchase requests at 399 dollars each. Every one was under the per-transaction limit. Every one was evaluated independently. Every one was approved.

The policy engine did exactly what it was built to do: evaluate each authorization in isolation against static rules. Under 500 dollars? Yes. Allowed category? Yes. Approved vendor? Yes. What it could not see was the pattern, because it kept no memory of what it had just approved, and authorization latency meant that by the time request eight arrived, request five had been approved but had not yet landed in the transaction history the engine referenced. The agent, for its part, had no circuit breaker: no concept of I have been failing for a while, something is wrong.

Remediation failed on every path. The chargeback was declined because each transaction was technically authorized. The vendor sympathized but had provisioned 12 valid orders. The policy provider pointed to terms of service that called limits best-effort controls, with a liability cap of 100 dollars. And because the agent's charges sat on a shared corporate card between team lunches and travel, the accounting team spent two weeks manually separating agent spend from human spend across six months of history. The analyst who finally caught the incident found it the old-fashioned way: 12 identical charges in a three-minute window during weekly reconciliation. Her first guess was card fraud. It was automation.

The postmortem points at two infrastructure lessons. The first is about containment: a dedicated credential with a 500 dollar balance would have declined the second charge at the network with insufficient funds. No policy logic to fail, no latency window to race, no aggregate calculation required. The money is either there or it is not.

The second lesson is the one this post is about: the five-day detection gap and the two-week cleanup were reconciliation failures. When agent transactions mix with human spend, receipts are inconsistent, and disputes reduce to did we mean to buy this, no dashboard will save you. The fix is evidence that starts before the purchase happens, not forensics that starts after the statement arrives.

Every completed agent purchase should produce one durable record that links the whole chain: which agent, under which intent, approved by which policy, with which credential, producing which transaction. A minimum viable shape:

{
  "agentId": "agent_procurement",
  "intentId": "int_abc123",
  "purpose": "Add 10 seats, project management tool",
  "policyDecision": "approved",
  "expectedMerchant": "vendor.example",
  "expectedAmount": 39900,
  "credentialId": "cred_xyz",
  "transactionId": "txn_123",
  "postedAmount": 39900,
  "descriptor": "VENDOR EXAMPLE INC",
  "receiptUrl": "https://vendor.example/receipt/...",
  "createdAt": "2026-08-16T18:22:10Z",
  "verifiedAt": "2026-08-16T18:29:44Z"
}

If your system cannot produce this record for any charge, it is not audit-ready, and every dispute becomes an archaeology project. Note what the record makes trivially visible: 12 records with the same intent purpose and merchant in a three-minute window is an anomaly you can alert on in real time, not discover five days later.

Receipts are messy; accept that and set a hierarchy. A receipt URL captured at checkout is best. An invoice number with a PDF link is good. A confirmation email thread identifier is a workable fallback, and a screenshot of the order confirmation is the last resort. Many checkout flows let the agent extract the receipt reference at purchase time, which is when it is cheapest to capture.

Then build the one-page output finance actually needs, answering four questions for any charge: What was this for (the intent purpose)? Who or what approved it (the policy decision and approver)? Did it match the intent (merchant, amount, time window)? And where is the receipt? A team that can produce that page for every transaction stops fearing autonomy.

Four anomaly flags catch the most common incidents: descriptor does not match the expected merchant, amount exceeds the expected amount plus tolerance, multiple authorizations in a short window (the retry loop), and a purchase outside its intent window. None of them require machine learning; all of them require the evidence record to exist.

Reconciliation is where agent payments become a real product instead of a demo. Require intent before credentials, generate the evidence record on every purchase, capture receipts at checkout time, and render the explain-this-charge summary on demand. That is how autonomous spend becomes operationally sane, and it is the difference between a three-minute incident and a three-week cleanup.

Signets produces this chain by construction: credentials are issued against a logged intent, controls are enforced before money moves on every rail, and each transaction carries its evidence record, so the explain-this-charge answer exists the moment the charge does. If your finance team is the blocker between your agents and production, tell us what you are building and we will get you sandbox access.

What is AI agent spend reconciliation?

The practice of linking every agent transaction back to its intent, policy decision, credential, and receipt, so any charge can be explained in minutes. It turns a statement line into an evidence-backed record instead of a guess, and it is what makes agent spend auditable for finance teams.

How do AI agent overspend incidents actually happen?

Rarely as one big charge. The common pattern is a retry loop: an ambiguous merchant response, an agent without a circuit breaker, and a policy engine that evaluates each transaction in isolation. Twelve compliant 399 dollar charges in three minutes pass a 500 dollar per-transaction limit while the aggregate does the damage.

Can you charge back purchases an AI agent made by mistake?

Usually not. If the agent was authorized and each transaction cleared policy, networks treat the charges as legitimate, and vendors have valid orders on their side. That is why containment has to happen before the charge: scoped credentials with hard balances, velocity caps, and intent-linked evidence for the disputes that remain.

What should an agent payment evidence record contain?

The linked chain for each purchase: agent ID, intent ID and purpose, policy decision, credential reference, transaction ID, merchant and descriptor, expected and posted amounts, timestamps for each step, and a receipt reference. If any link is missing, disputes and audits fall back to reconstruction.