How to Audit Your AI Agent Spending
Last updated: 2026-09-28
An agent spending audit needs two ledgers: a settlement record for what was charged and an execution record for what the tool call did. Reconcile them by stable references, time, amount, and scope. Do not treat a payment event as proof that a useful execution occurred.
Try the Zambo demo · Explore Zambo
Use the public receipt verifier to inspect a receipt when you have one. A receipt is evidence about a recorded execution, not a guarantee that an outside system accepted the result or that a human decision was correct.
Why spending needs two records
A payment record answers a financial question: was a charge authorized, accepted, settled, refunded, or rejected? An execution receipt answers an operational question: what tool call did the execution layer record and what result did it observe? These records may be related, but they are not interchangeable. A settled payment can precede a failed tool call. A successful tool call can be free or covered by an entitlement. A monthly audit should preserve both sides and document unmatched rows rather than forcing them into a convenient total.
Build a reconciliation key
Choose a stable reference that appears in the payment and execution systems, or maintain a controlled cross-reference table. Useful dimensions include receipt id, payment reference, agent identity, tool name, timestamp, currency, amount, and entitlement period. Do not use a rounded timestamp as the only key. Clock skew and retries can create collisions. If the payment system cannot carry the execution id, store the linkage at the application boundary and make its creation observable. An unmatched payment is a review item, not evidence of fraud or success.
Separate authorization from settlement
An authorization may be declined, expire, or be captured later. A settlement can be reversed or refunded. Record the lifecycle rather than counting every event as spend. The execution side has similar distinctions: requested, started, observed, failed, and completed are not synonyms. A finance operator should decide which financial state counts toward the report and which execution state supports cost attribution. Write that policy down before the first monthly close so the numbers do not change when an exception appears.
Per-call cost attribution
Attribute a cost to the smallest unit the finance team can explain. If a pass covers a time window, do not invent a per-call price unless the accounting policy defines an allocation method. You can report the payment total, the entitlement period, and the set of receipts observed during that period. For usage-priced calls, compare the charged amount with the execution reference and any provider fee. Keep tax, network, and conversion adjustments separate from the tool's operational result. A receipt proves the execution record, not the accounting treatment.
Monthly close workflow
At close, export the settlement events for the period, export execution receipt references, normalize time zones, and join on the controlled key. Classify rows as matched, payment-only, execution-only, duplicate, refunded, or pending. Investigate high-value and repeated exceptions first. For each matched row, verify that the tool and scope are plausible and that the receipt's observed result is available. Preserve the original exports and the reconciliation output. A later correction should append an adjustment rather than silently rewriting the prior close.
Handling a Day Pass payment
A Day Pass payment is a settlement event that grants an entitlement window. The payment record says that the charge reached the payment flow. Subsequent tool receipts show which calls were recorded while the entitlement was active. Do not claim that the payment proves every call in the window succeeded. Check the access key or entitlement reference according to the system's rules, then reconcile each material call separately. If the payment is rejected, the execution ledger may still contain free-tier calls before the challenge. Keep those categories distinct.
Exceptions and disputes
A customer dispute should start with a narrow claim. Was a payment settled? Was an entitlement issued? Was a particular execution recorded? Did the owning system observe the requested result? Gather the payment reference, receipt reference, timestamps, and relevant system response. If the receipt is missing, say so. If it verifies but the customer disputes correctness, route the issue to the tool or system owner. The public verifier at /verify can support the execution check, but it cannot adjudicate an account or financial dispute.
Privacy and retention
Finance exports often contain wallet addresses, account identifiers, invoices, and sensitive metadata. Keep the public receipt projection minimal and store restricted reconciliation data under the finance team's controls. Hashes are not a universal anonymization method. Define who can join a receipt to a payer and how long that linkage is retained. When sharing an audit sample, redact credentials and unnecessary personal data while keeping the fields needed to reproduce the conclusion. A clean audit trail is not a reason to publish a private ledger.
What a receipt can and cannot prove
A verified receipt can support a claim that a specific execution record has the stated integrity properties and observed fields. It cannot prove that the charge was fair, that a product was valuable, that a user authorized a wallet, or that an external side effect occurred after the observation. State the boundary in the reconciliation report. This prevents a payment receipt and an execution receipt from being combined into a broader claim neither record supports alone.
A compact control checklist
Before closing, confirm the canonical time zone, settlement state rules, refund treatment, join key, duplicate policy, exception owner, and retention location. Sample matched rows and all material unmatched rows. Verify representative execution receipts. Record assumptions and unresolved gaps. Then publish the financial summary with a link to the underlying restricted evidence, not with private payloads embedded in a public page. The strongest audit is explainable by another operator who was not present when the agent ran.
Review notes
Good evidence work starts with a bounded question. Name the action, the system that owns the result, the time window, and the person or service responsible for reviewing it. Then separate three states that are often collapsed into one: an action was requested, an execution layer recorded an action, and an outside system confirmed an outcome. The first state is intent. The second is execution evidence. The third is outcome evidence. A page that keeps these states separate is easier to use during an incident and harder to misuse in a status summary.
When evidence is incomplete, record the gap instead of filling it with confidence. A missing record may be a collection failure, a transport problem, a retention issue, or an action that never ran. Those possibilities have different owners and different remedies. Preserve the original record, the verification attempt, and the reviewer conclusion. If a later retry succeeds, keep the earlier attempt visible. This makes the evidence useful to someone who was not present when the work happened and gives the next operator a concrete place to start.
Reviewers should also write down assumptions. State which timestamp is authoritative, whether a result was observed directly, how a hash was computed, and which system owns the final state. If the answer depends on an external service, link the external evidence or mark it unavailable. If the action involved private data, describe the field class without copying the data into a public page. These habits turn a receipt from a decorative status badge into a durable review artifact. They also make disagreements productive: two reviewers can compare assumptions instead of arguing over a summary.
Finally, keep the evidence proportional to the decision. A low-risk read can use a light check, while a money movement, data mutation, deployment, or external communication deserves a stronger receipt and an independent state check. Do not use a larger word count or a more elaborate format to imply certainty. The relevant question is always what was recorded, what was verified, and what remains outside the record.
Frequently asked questions
Is a payment receipt the same as an execution receipt?
No. Payment evidence covers settlement. Execution evidence covers what the execution layer recorded.
How should a Day Pass be counted?
Count the settlement and entitlement according to finance policy, then reconcile subsequent tool executions separately.
What is an unmatched payment?
It is an exception requiring review. It is not automatically proof of a successful tool call or misuse.
Can the public verifier resolve a billing dispute?
No. It can help inspect execution evidence, while billing and authorization require their owning systems.
What should a monthly report preserve?
Original settlement and execution exports, join rules, exception classifications, adjustments, and reviewer notes.