AI Finance Agent Cost Audit: A Reproducible Example

Start with the actual billing evidence

A finance-agent cost audit reconciles usage events with the final credits ledger. Inputs are a seven-day usage export, tool/provider identifiers, timestamps, request IDs, final billed units and task outcomes. Output is a reconciled spend table, duplicate candidates, failed-call evidence and a bounded optimization plan.

The numbers below are an illustrative dataset, not a real customer bill or a savings guarantee. Rates are assumed credits per call, not published provider prices. Credits are not RMB. Discover and Inspect are free and must not be counted as paid calls.

Define a comparable audit window

Choose a fixed UTC interval and list the included agents, environments and accounts. Keep production, scheduled research and development tests separate. Record tasks attempted and tasks completed; a smaller bill caused by fewer completed tasks is not an efficiency improvement.

Keep capability credits, external model tokens and infrastructure costs in separate ledgers. Join them by task or trace ID only when those identifiers are available. Preserve each original billing unit and currency; do not infer a money exchange rate from a credits balance.

Reconcile executions and financial entries

A usage event describes what happened; a ledger entry describes a balance movement. One execution can have adjustments, pending settlement or a later refund. Match stable identifiers and inspect unmatched records before reporting a total. Do not multiply every usage row by a catalogue estimate and call that an actual bill.

Build a ledger that can explain each charge

The following names are a proposed local audit schema, not a claim about the exact export columns of any provider. Map the official usage and ledger exports into these fields and retain the untouched originals. Exclude credentials and unnecessary personal data from the audit dataset.

Keep secrets out of request fingerprints. A fingerprint is useful for finding candidates, but it does not establish permission to store or reuse the response. Retention and redistribution depend on the source contract.

Reconcile the example: 314 credits

Every row satisfies calls × assumed unit price = total. The eight row totals sum to 314 credits. Actual audits must use final ledger charges, including applicable adjustments; an HTTP status alone does not establish the charge.

What the example does and does not show

The eight rows represent 50 hypothetical calls. Earnings accounts for 120 of 314 assumed credits, but being the largest category does not make it waste. Investigate whether the requested coverage, report periods and accepted outputs justify those calls before changing them.

Before comparing two runs, reconcile the opening balance, purchases, grants, charges, refunds and closing balance using the account’s own sign conventions. Exclude unrelated top-ups from the task-spend measure. Mark provisional entries and rerun the audit when settlement is complete.

Find avoidable work without labelling every charge waste

Model one explicit optimization: 314 → 267

Assume the 14 quote calls share an identical symbol, requested time, entitlement and freshness tolerance, so 13 can be removed by application-level reuse. Savings are 13 × 3 = 39 credits. Assume four of six FX calls are also redundant: 4 × 2 = 8 credits. Total modeled reduction is 47 credits; remaining spend is 314 − 47 = 267 credits, a 14.97% reduction.

These assumptions must be tested. Do not reuse old market results when the user asks for current/latest data. Do not assume all failed calls are free, providers are interchangeable, automatic caching is included, or any particular percentage will be saved.

Write down the exact requests removed and which retained response replaces each one. If quotes occur at different market times, or clients have different entitlements, the assumed 13-call reduction may be invalid. Recalculate from the eligible subset instead of preserving the headline percentage.

Separate valid controls from unsupported promises

• Deduplicate only equivalent requests within an explicit freshness window; implement and document the cache in your application.
• Inspect source coverage, schema, entitlement, licensing and billing before selecting an alternative provider; a cheaper call is not proof of equivalent data.
• Validate required parameters before calling; reconcile timeout and failure charges against the ledger rather than assuming a refund.
• Record free discovery separately from paid execution. Measure its latency independently.

Prove output quality before accepting a cheaper run

Replay the same task set with fixed expected evidence. Compare successful completion, source coverage, required fields, timestamps, numeric accuracy and handling of missing data. Review material discrepancies manually. A lower spend accompanied by stale quotes, missing filings or silent fallback is a failed optimization.

Report net settled credits per accepted task alongside total spend. Keep failed-task charges visible. For model or infrastructure costs, provide separate measures in their own units rather than adding tokens, credits and currency into a single number.

Reproduce the calculation, then audit your own log

This Python example computes the illustrative scenario locally. It makes no network calls and uses no fabricated tool identifiers. Export actual usage and credits using the current official usage/ledger documentation; do not rely on unverified CLI flags.

rows = [(14, 3), (8, 15), (5, 8), (3, 12),
        (6, 2), (2, 5), (9, 4), (3, 6)]
baseline = sum(count * unit for count, unit in rows)
removed = 13 * 3 + 4 * 2
after = baseline - removed
assert baseline == 314 and after == 267
print(round(100 * removed / baseline, 2))  # 14.97

Current CLI documentation · Billing rules and pricing

Summarize your normalized ledger locally

Save the following standard-library Python utility as audit_usage.py. Its CSV format is defined here for analysis; it is not an official export schema. Use positive credits_delta for settled charges and negative values for refunds or reversals after explicitly mapping the source ledger. Keep adjustments as distinct entries with their own identifiers.

import csv
import sys
from collections import defaultdict
from decimal import Decimal, InvalidOperation


def audit(stream):
    reader = csv.DictReader(stream)
    required = {"entry_id", "task_id", "tool", "outcome", "credits_delta"}
    if not required.issubset(reader.fieldnames or []):
        raise ValueError("Missing normalized audit columns")
    seen = set()
    net = Decimal("0")
    by_tool = defaultdict(Decimal)
    by_outcome = defaultdict(Decimal)
    for line, row in enumerate(reader, start=2):
        if any(not (row.get(k) or "").strip() for k in required):
            raise ValueError(f"Blank required field on line {line}")
        entry = row["entry_id"].strip()
        if entry in seen:
            raise ValueError(f"Duplicate ledger entry: {entry}")
        seen.add(entry)
        try:
            amount = Decimal(row["credits_delta"])
        except InvalidOperation as exc:
            raise ValueError(f"Invalid credits on line {line}") from exc
        if not amount.is_finite():
            raise ValueError(f"Non-finite credits on line {line}")
        net += amount
        by_tool[row["tool"]] += amount
        by_outcome[row["outcome"]] += amount
    return {"entries": len(seen), "net_credits": str(net),
            "by_tool": {k: str(v) for k, v in by_tool.items()},
            "by_outcome": {k: str(v) for k, v in by_outcome.items()}}


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Usage: python audit_usage.py normalized_ledger.csv")
    with open(sys.argv[1], newline="", encoding="utf-8-sig") as source:
        print(audit(source))

The program rejects blank fields, repeated ledger identifiers and invalid amounts, then summarizes net credits by tool and outcome. It intentionally does not auto-delete repeated requests: multiple executions can be valid, while repeated billing-entry IDs can inflate totals. It also does not decide which tasks passed quality review.

Run it only on an approved local export: python audit_usage.py normalized_ledger.csv. A toy input containing charges of 7 and 7 plus a refund of −2 must return net credits of 12. This checks arithmetic and parsing, not the correctness of a production invoice.

Turn an audit finding into a controlled rollout

1. Freeze the baseline: save the task set, time interval, rules, source exports and code revision.
2. Form one hypothesis: identify specific equivalent calls, their ledger entries and the proposed replacement response.
3. Replay offline where possible: compare evidence and calculations before allowing new billable traffic.
4. Release to a bounded sample: set an attempt limit and a task budget, observe fresh ledger entries, and stop on quality regressions.
5. Reconcile after settlement: separate measured reductions from modeled estimates and record remaining unmatched entries.
6. Keep a rollback path: restore the prior routing or cache policy without erasing the audit trail.

An audit finding should name its owner, evidence, expected change and acceptance test. If billing rules or source rights remain unclear, record the uncertainty instead of turning it into a savings claim.

Questions to resolve before claiming savings

Can a credits balance be converted directly to RMB?

No fixed RMB conversion is assumed here. Use the actual purchase, currency and invoice terms; external model/client fees remain separate.

Are Discover and Inspect paid operations?

The official pricing page states they are free. Call charges follow the capability billing rule and final ledger. Purchased top-up credits do not expire; trial/promotion terms may differ.

What makes a savings result credible?

Matched workloads, the same required output quality, recorded billing periods, explicit failure treatment and a reconciled before/after ledger. A modeled example is not measured production evidence.

Does a timeout prove that a call was not charged?

No. A client can lose the response while execution or settlement continues. Preserve the original identifiers, use documented reconciliation support and check the final ledger before retrying or claiming a refund.

Can the cheapest provider replace the current one?

Only after checking coverage, timestamps, definitions, entitlement and reuse conditions against the task contract. Compare the cost of accepted results, including failures and fallback, rather than a displayed unit price alone.

How often should the audit run?

Choose a cadence that matches workload changes and settlement timing. Repeat after a routing, pricing-rule, model, prompt or caching change. Preserve comparable windows so normal market activity is not mistaken for an engineering improvement.

Check the current billing and audit contracts

Use the current official references to map exports and execution identifiers. Keep a dated copy of the rules used for your audit; examples on this page are an analysis method, not a replacement for the account’s final ledger.

• QVeris pricing and final-charge rules
• REST API: usage, credits ledger and execution reconciliation
• Current CLI reference