the artifact
legacy
An invoice generated later from usage rows you hope are accurate.
a2a
A signed execution receipt linked to a separate per-call economics row.
execution evidence for each invoice line
AI agent invoicing: signed run, separate amount.
An invoice should explain both what ran and what was charged. a2a keeps those concerns explicit: the runtime signs execution fields in an Ed25519 receipt, then the control plane stores price, compute, fee, and payout beside the verified receipt ID. An invoice can reference both records without falsely claiming the economic amount was signed.
signed execution · linked ledger · explicit provenance
0
receipt-to-ledger join keys
0
receipts per billable call
0%
signed economic fields
the problem
An invoice nobody can verify is just a number to argue about.
Traditional invoicing assembles a bill from usage rows after the fact and asks the buyer to trust it. When a charge is questioned, both sides dig through logs to reconstruct what happened, and the answer is only as good as records the buyer can't independently check. For high-volume, machine-to-machine agent calls, that model breaks: too many charges, too little proof, and no way for the buyer to confirm a line item without going through you.
An invoice built from usage rows is only as trustworthy as records the buyer can't check.
Disputes turn into log archaeology on both sides to reconstruct a single charge.
A price change can silently rewrite invoices that were already issued.
Monthly batch invoicing lags the work and hides per-call detail.
the a2a way
Build invoice lines from signed runs and linked economics.
Use the verified receipt for execution evidence and the control-plane row for price and fee data. receipt_id connects them, while formal invoice issuance and accounting remain separate.
The receipt supports the invoiceCryptographically checkableEvery field a buyer needsPer-call economics stored at ingestionCost broken down, not bundledOne join key per run
The receipt supports the invoice
Authenticated Agent API paid calls receive Ed25519-signed receipts. After verification, the control plane stores price, compute, markup, fee, and payout beside the receipt ID; public `/invoke` and standard MCP gateway receipts record zero platform economics.
Cryptographically checkable
The buyer can verify execution fields such as caller, input hash and preview, grant IDs, tool calls, result preview, artifacts, handoffs, and timing. That verification does not cryptographically validate the separate invoice amount.
Every field a buyer needs
The receipt identifies the caller and records input and result evidence; the linked ledger row states the charge and fee split. Present both in a billing UI so a dispute can distinguish execution evidence from platform economics.
Per-call economics stored at ingestion
When the control plane ingests a verified receipt, it calculates and stores the current card price and split on that database row. Later card-price changes do not rewrite the stored row, but that durability comes from the ledger, not the Ed25519 signature.
Cost broken down, not bundled
The ledger row decomposes buyer gross into compute and seller markup, then records platform fee and seller payout. Those fields can make an invoice legible without mislabeling them as signed receipt data.
One join key per run
receipt_id links the signed execution artifact to the control-plane economics row. That creates strong per-call source material for invoicing, while invoice issuance, tax, payment terms, and formal accounting remain separate concerns.
side-by-side
A trust-me invoice vs. a verifiable receipt.
verification
legacy
The buyer trusts your line items because they have no way to check them.
a2a
An Ed25519 signature verifies execution fields; ledger controls support the amount.
disputes
legacy
"What did I pay for?" turns into a support thread and a reconciliation.
a2a
Caller and run evidence are signed; cost and fee fields come from the linked ledger.
price changes
legacy
A rate change risks rewriting invoices already issued.
a2a
Per-call economics are stored at receipt ingestion and remain separate from the signature.
cadence
legacy
Batch a monthly invoice by exporting and aggregating usage.
a2a
A receipt ID joins execution evidence and ledger economics per call.
dimension
legacy
a2a
the artifact
An invoice generated later from usage rows you hope are accurate.
A signed execution receipt linked to a separate per-call economics row.
verification
The buyer trusts your line items because they have no way to check them.
An Ed25519 signature verifies execution fields; ledger controls support the amount.
disputes
"What did I pay for?" turns into a support thread and a reconciliation.
Caller and run evidence are signed; cost and fee fields come from the linked ledger.
price changes
A rate change risks rewriting invoices already issued.
Per-call economics are stored at receipt ingestion and remain separate from the signature.
cadence
Batch a monthly invoice by exporting and aggregating usage.
A receipt ID joins execution evidence and ledger economics per call.
questions
Frequently asked.
How does invoicing work for an AI agent?
An authenticated Agent API paid call receives an Ed25519-signed receipt plus separate per-call price and fee fields. Public `/invoke` and standard MCP `tools/call` receive evidence receipts but no platform economics. A receipt is not an invoice, and its signature does not cover an amount.
What makes a signed receipt better than a normal invoice?
A signed receipt gives the buyer independently verifiable execution evidence. A normal invoice also needs price, tax, terms, and accounting controls. Linking the invoice line to a receipt ID improves traceability, but the Ed25519 signature verifies only the receipt payload, not the linked charge.
What's on the invoice for a single call?
Use the signed receipt for identity/caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. For authenticated Agent API paid calls, use the linked control-plane row for gross, compute, markup, fee, and payout. An invoice can present both with provenance explicit.
If I change my price, do old invoices change?
The cost is not on the signed receipt. When the verified receipt is ingested, the control plane stores the calculated price and split on its row. Later card-price changes do not rewrite that stored row. Formal invoice corrections or credits still follow your billing system's accounting rules.
Can a buyer verify an invoice without contacting me?
The buyer can verify the signed execution fields without contacting you. Verifying the invoice amount requires trusting or auditing the separate control-plane ledger and any external billing system. The receipt ID gives both sides a precise join key for that review.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent, trust the receipt
Invoice with proof, not claims.
a2a cloud deploys any agent as a live service with managed Postgres, MCP, and an API. Link authenticated Agent API paid-call receipts to separately stored economics when constructing invoice lines. Public `/invoke` and standard MCP receipts are evidence-only; keep tax, terms, and accounting in the billing system built for them.