An agent's first purchase reaches finance as a card line carrying a merchant name, an amount, a date and a last four. Nothing on it says which team owns the cost, and nothing says a person agreed to the spend. Your controller will ask four questions about that line, usually in the week of the close, and the telemetry your engineers already have answers the first one partly and the rest not at all.
Here they are, in the order they get asked, with what has to be true before the close rather than after it.
Which cost centre owns this line, and who authorised it?
Neither answer comes off a card statement. A shared corporate card charges every agent purchase to whoever holds the card, and the party that placed the order is a service account rather than a person. For the line to arrive attributed, the purchasing instrument has to be scoped to one agent and tied to the human who set its limits.
Coding by merchant is the workaround teams reach for first. It holds until two agents buy from the same vendor, which for API providers is usually week one. After that, every line needs somebody to guess, and the guess goes into the books.
"Authorised" to a controller means a named person accepted the spend before it happened. An approval that lived in a chat thread and stayed there isn't attached to the transaction, so at the close there is nothing to point at. [Moving off a shared card to per-agent issuance](/blog/migrate-shared-cards-to-scoped-delegation) makes the attribution arrive with the line.
Can you tie this to a statement and close the month?
Only if the agent's record and the card statement describe the same purchases, with the same identifiers, over the same period. Finance closes against the statement. A record living in an application database with its own naming and its own clock creates a second set of books that somebody matches by hand every month.
Most agent deployments produce exactly that: a trace in an observability tool, keyed by run ID and kept only as long as the observability plan keeps traces.
The close is also the wrong moment to find a purchase you would have refused. The money has moved and the vendor has been paid, so the only conversation left is a recovery conversation. [Control at the authorization moment rather than at reconciliation](/blog/authorization-time-control-vs-reconciliation) is the difference between a policy that decides and one that reports.
Who could have altered this record, and does that make it evidence?
A record counts as evidence when the party being asked about couldn't have written it. Logs produced by the same service that made the purchase, into a store the agent's own credentials can write to, answer the question "what did our systems record". That is a weaker claim than "what happened", and the gap opens the first time an outsider asks.
| | Engineering telemetry | A finance-grade record |
|---|---|---|
| Written by | the service that made the purchase | the system that authorised it, outside the agent's write access |
| Answers | what our systems recorded | what happened, and who agreed to it |
| Keyed by | run ID and session ID | the agent, and the identifiers the statement carries |
| Approvals | absent, or sitting in a chat thread | attached to the transaction they approved |
| Retention | as long as the observability plan keeps traces | as long as audit and tax retention require |
| Changeable by | anyone with write access to the log store | no one after the fact |
A log store nobody can correct is an inconvenience to an engineer and the whole point to an auditor.
A card dispute, an insurance claim, a diligence request and a data-protection review asking what an agent held and for how long all land on that same record. [Retention and residency for agent payment data](/blog/agent-payments-data-residency-retention) covers the last of those.
What changes when it happens fifty times a day?
Manual review stops happening, and nobody ever decides to stop it. One agent purchase a week can be read by a person after the fact. Fifty a day can't, so the review has to move in front of the purchase: limits that hold on their own, and a person pulled in only where the amount or the merchant warrants it.
Finance wants two things at that volume: the purchases it would have refused stopped before they clear, and the rest arriving already coded. Approving each one by hand is nobody's goal, and a queue of fifty a day gets rubber-stamped by Thursday.
Volume also changes what one mistake costs. An agent that misreads a pricing page once produces a line item. The same agent on a schedule produces a subscription nobody ordered, and it renews until somebody reads the statement closely.
Shatale issues agent-scoped virtual cards with your policy enforced at the authorization moment, human approval workflows above the thresholds you set, and an immutable per-agent record of every decision and approval. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting. The line your controller opens carries the agent, the limit it ran under, and the person who set it.
What to ask
- Does a purchase arrive attributed to one agent and one cost centre, or is it coded afterwards?
- Can I export a per-agent record that lines up with the card statement inside my close window?
- Who can write to that record, and would an edit be visible?
- Are approvals stored with the transaction, or in whatever tool the approval happened in?
- If a purchase falls outside policy, is it blocked, escalated to a person, or logged for me to find at month-end?
FAQ
How do you account for AI agent purchases?
An agent purchase is coded the same way it would be if a person made it. Nothing about the expense category changes because software placed the order. What changes is the evidence around the line: it arrives without an owner and without anyone's sign-off, so both have to be attached when the card is issued.
What does finance need that an engineering log doesn't provide?
An engineering log answers what the system did. Finance needs the line tied to a cost centre, an approval attached to the transaction rather than sitting in a chat thread, identifiers that match the card statement, and retention as long as your audit obligations. A trace keyed by run ID covers none of those.
Is an audit trail written by the agent's own system enough?
Not for a question anybody outside the team asks. A log the purchasing service can write to answers what your systems recorded, which is a weaker claim than what happened. An auditor wants to know who could change the record and whether the change would show, and a record kept outside the agent's write access answers that.
When should approvals be required instead of after-the-fact review?
Above the amounts and merchant categories your finance team would want to see before the money moves. After-the-fact review works while one person can still read every line, and it stops working once agents run continuously. Past that point the threshold has to be enforced at the authorization moment, with purchases above it blocked or escalated for approval.
---
The audit half of this sits inside a wider split: [identity, authorization and audit are three different questions](/blog/agent-identity-vs-authorization-vs-audit), and finance only ever meets the third. Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).