# Should your AI agent auto-pay invoices? How signed usage statements make it safer

_By Nakul Kelkar, September 16, 2026_

**Your AI agent should auto-pay an invoice only when the vendor, payee, usage and amount fit a policy you approved in advance.** A signed usage statement helps by making changes to the signed bill detectable and letting your software verify its signing key. It does not prove that the work happened, that the price is right or that you authorized payment. Use the signature alongside usage reconciliation, spending limits and duplicate-payment protection; send exceptions to a person.

![A small mechanical assistant inspects a usage statement at a verification desk, with a spending gate beyond it.](/blog/assets/signed-usage-statements/editorial.webp)

*Original generated illustration. Verifying a statement is one step before a payment decision, not a payment receipt.*

## What is a signed usage statement?

A usage statement describes what a service says you consumed: which account, which billing period, which units, which rates and which total. A digital signature binds a specific sequence of bytes to a signing key. If someone changes the signed amount while keeping the old signature, verification fails.

Our example uses a compact JSON Web Signature, or JWS, with Ed25519. Its three encoded parts contain a protected header, the statement and the signature. The verifier checks the original encoded bytes; it does not reformat the JSON and hope it means the same thing. The [JWS specification](https://www.rfc-editor.org/rfc/rfc7515) defines that envelope, and [RFC 8037](https://www.rfc-editor.org/rfc/rfc8037) defines Ed25519 support for it.

**The key must already be trusted.** An invoice that supplies its own public key can prove consistency with that key, but cannot establish that it came from your approved vendor. Bind a vendor to a trusted key through a separate setup process. A key ID printed in the statement is a lookup label, not proof of identity.

## A signed example you can verify

We created a fictional usage statement, signed it with a real Ed25519 key and ran an offline verifier against it. The statement totals **16¢: ten search units at 1¢ each, plus two scrape units at 3¢ each**. The example policy allows up to 20¢ for that statement from the approved fictional vendor and payee.

**The data and prices are invented; the signature and verification results are real.** This is a reference design for an invoice workflow, not Vaaya's production statement format, a customer invoice or a payment. No money moved.

The downloadable evidence includes:

- [The signed statement](/blog/assets/signed-usage-statements/usage-statement.jws) and [readable JSON](/blog/assets/signed-usage-statements/usage-statement.json).
- [The public verification key](/blog/assets/signed-usage-statements/public-key.pem) and [standalone verifier](/blog/assets/signed-usage-statements/verify-usage-statement.mjs).
- [A deliberately altered statement](/blog/assets/signed-usage-statements/tampered-statement.jws), [recorded verification results](/blog/assets/signed-usage-statements/verification-results.json) and [provenance](/blog/assets/signed-usage-statements/provenance.json).
- [Download and run instructions](/blog/assets/signed-usage-statements/README.md).

The private signing key is not published. Verification needs only the public key. A signed statement is also **not encrypted**: anyone with the artifact can decode its contents. Keep private prompts and customer content out of billing artifacts unless they are necessary and properly protected.

## What happens when the amount changes?

The demo separates two questions: “Does the signature verify?” and “Does the bill satisfy this payment policy?” They produce different answers.

| Scenario | Signature | Payment-policy decision |
| --- | --- | --- |
| Original 16¢ statement, 20¢ cap | Valid | Eligible under the example policy; no payment is sent. |
| Amount edited without a new signature | Invalid | Reject before trusting the statement's claims. |
| Original statement, cap below 16¢ | Valid | Deny: the approved amount is too low. |
| Original statement's invoice ID already recorded | Valid | Deny: the invoice was previously seen. |
| Original statement checked after expiry | Valid | Deny: the statement is outside its allowed time. |

The last three rows are why “the signature passed” is an incomplete payment rule. An authentic bill can still be unauthorized, stale or already paid.

The verifier uses a fixed example clock so these cases remain reproducible. Its duplicate record is a test fixture, not a production database. The demo does not establish delivery of the fictional work, handle concurrent payment workers or implement key rotation. Those are separate responsibilities in a real system.

## What else must an invoice pass before auto-pay?

Start with an owner-approved policy that names the vendor and destination account, permitted services, currency, maximum amount and billing period. Apply an aggregate budget as well as a per-invoice ceiling: ten individually acceptable invoices can still exceed the month's allowance.

Then make the checks deterministic:

1. **Verify the signer and bytes.** Allow only approved algorithms and keys. Reject invalid signatures before using the statement's claims in a payment decision.
2. **Match the bill to your account and records.** Check the issuer, customer, payee, currency and period. Reconcile billed usage against your own request or job IDs and agreed rates. Recalculate line totals and any applicable fees or taxes.
3. **Enforce the remaining budget.** A valid statement cannot raise its own limit or approve a new destination. Reserve the authorized amount so another worker cannot spend the same allowance simultaneously.
4. **Check the invoice identity and payment state.** Reject an already-paid invoice. Investigate an in-progress or uncertain payment before starting another one.

The small demo implements signature verification and selected policy checks. A production service also needs the independent usage records, durable budget reservations and payment-state handling described here. An LLM can help extract or explain an invoice; the payment service should enforce these gates in code.

![Invoice workflow: verify a trusted signature, reconcile usage, enforce the approved policy and duplicate checks, then submit and track an authorized payment.](/blog/assets/signed-usage-statements/payment-checks.svg)

*Recommended invoice workflow. The downloadable demo exercises verification and selected policy decisions; it does not connect to a payment rail.*

## How do you prevent paying the same invoice twice?

**Persist the invoice identity and reuse the same payment-operation key when retrying.** A signed statement can be copied perfectly. Replaying it does not break the signature.

Use a durable unique record for the vendor and invoice ID, with an atomic transition into payment-in-progress. Derive or store a stable idempotency key for that approved payment operation. If the network times out, check the original payment's status and follow the payment provider's retry rules before attempting anything new.

[Stripe's idempotency documentation](https://docs.stripe.com/api/idempotent_requests) explains how repeated requests with the same key return the saved result. It also allows keys to be removed after at least 24 hours, so a provider's retry protection does not replace your own long-lived invoice records. A fresh key after every timeout defeats the purpose.

Store the final payment reference and reconcile it back to the invoice. “Submitted,” “succeeded” and “unknown” must remain distinct states.

## What does Vaaya support today?

Vaaya gives an agent controlled access to paid tools, with [spending controls](https://vaaya.ai/spending-controls) and an [account history](https://vaaya.ai/agent-history) for reviewing what it bought. That history helps you compare activity with charges. It is not currently a portable, cryptographically signed usage statement.

Vaaya can also automatically collect repayment of drawn credit, as described in its [credit-account documentation](https://vaaya.ai/credit-account). That collection is based on the account's ledger. It is a different operation from letting an agent receive an arbitrary vendor invoice and decide to pay it.

The signed-statement files above are an independent working example of a possible verification layer. They are not an announcement of a Vaaya invoice auto-pay API. For an actual Vaaya tool purchase, the first article includes a [real paid search response and a separate spending-limit refusal](/blog/how-to-give-your-ai-agent-a-credit-card).

## Where does Instinct × Vaaya fit?

With [Instinct](https://instinct.com) on WhatsApp or iMessage, a useful instruction would be: “Review this month's tool charges, match them to the work I asked for and flag anything outside my budget.” Instinct can provide the conversational interface; Vaaya's spending records can inform the review where the integration has access to them. This is a suggested workflow, not a captured chat or a claim of a shipped invoice auto-pay integration. Any payment still needs its own authorized policy and supported payment flow. A message inside an invoice cannot grant that permission.

## When should the agent ask you instead?

Ask for review when a vendor changes its payment destination, the bill cannot be matched to usage, the amount exceeds the budget, a signature fails or the previous payment's outcome is unclear. Routine, reconciled charges within a policy you already approved are the useful candidates for automation.

If the bill passes verification but the account cannot fund it, stop at the funding decision. Do not silently raise the budget or switch payment methods. The previous article explains [what happens when an AI agent runs out of money mid-task](/blog/what-happens-when-your-ai-agent-runs-out-of-money).

## Questions

**Should an AI agent automatically pay invoices?**

Only for approved vendors and payees, within explicit amount and time limits, after matching the bill to authorized usage and checking for duplicates. New payees, mismatches and uncertain payment outcomes should go to a person for review.

**What does a signed usage statement prove?**

With a trusted signing key and a correctly implemented verifier, it shows that the signed bytes have not changed and were signed by the holder of that key. It does not prove delivery, correct pricing, authorization to pay or payment completion.

**Does Vaaya currently issue signed usage statements for invoice auto-pay?**

No. The signature example in this article is an offline reference design, not a current Vaaya invoice format or auto-pay feature. Vaaya provides spending controls and transaction history, and can automatically collect repayment of drawn credit under its account terms.

**Can a signed invoice be paid twice?**

Yes. A signature alone does not stop replay. Track invoice identities in durable storage, reserve each payment atomically and reuse the same payment idempotency key when retrying the same operation.

**Can I run the signature demo without an account?**

Yes. Download the demo files into one folder and run the included verifier with Node.js. It verifies a real signature over fictional usage data and exercises policy checks offline. It makes no payment and requires no account or API key.