AI Agent Outcome Receipts: How to Reconcile Work, Retries and Payments

Research edition: 2 November 2026 · DN Outcome Receipt Draft v0.1 · Local synthetic evidence

An agent completes two attempts. The first response is rejected; the second is accepted. The upstream provider charges for both. The buyer pays only for the accepted outcome. Everybody can have a plausible receipt, yet the parties can still disagree about who owes what.

The missing record is often the one that joins the work to the commercial agreement. A transaction hash does not describe every acceptance condition. A successful tool call does not establish that the buyer received a useful result. A matching spreadsheet total cannot establish that the underlying evidence is genuine.

This article extends DN’s API-call economics analysis and the State of the Agentic World evidence map. The practical question is straightforward: can two parties reconstruct the same outcome from the same task record?

The Signal: The Receipt Exists, but the Acceptance Rule May Live Elsewhere

x402’s HTTP documentation distinguishes payment requirements, submitted payment payloads and settlement responses. It also notes that settlement timing depends on the payment scheme. A production adapter must preserve those native meanings rather than treat every payment-related response as the same event.

x402’s Signed Offers & Receipts extension already documents signed interaction artifacts, with EIP-712 and JWS formats. Its described receipt fields include the resource, payer, network and issuance time, with an optional transaction hash. The documentation also distinguishes signature verification from confirming that a signing key represents the service.

DN interpretation: a buyer-specific rule such as “a CSV with 100 eligible rows, no duplicates and the agreed freshness window” still needs an explicit application-level link. A native receipt should be retained and verified in its own format. DN’s draft illustrates reconciliation around it; it does not replace or verify that artifact.

OpenTelemetry’s GenAI evaluation-event documentation provides a way to describe evaluation results and associate them with an operation or response. It is marked as development work. W3C Trace Context provides correlation headers for distributed tracing. These are useful connections between records, with their own scope and privacy constraints.

DN Alpha Thesis: The Reconciliation Gap Is a Commercial Control Problem

DN calls the unresolved distance between what was authorized, what was attempted, what was accepted and what was charged the reconciliation gap. This is an editorial framework, not a numerical risk score.

Closing that gap can make procurement, support and billing decisions easier to inspect. It does not require a new universal protocol. It requires a disciplined mapping between existing evidence and the agreement the parties actually made.

The most dangerous shortcut is to let one claim stand in for all four. A receipt format can help expose that shortcut. Its presence alone cannot prevent it.

Who Pays for the Retry That Did Not Count?

There are two separate ledgers: the upstream cost of performing the work and the amount invoiced to the buyer. Accepted-only billing changes the second ledger. It does not make the first one disappear.

In DN’s synthetic example, two attempts each incur a declared upstream cost of $0.01. The first is rejected and the second accepted. The agreed buyer price is $0.05 per accepted outcome. The upstream total is $0.02 and the buyer invoice is $0.05. Their $0.03 difference is before infrastructure, human review, refunds, tax and other costs; it is not verified net profit.

The record declares the operator as the retry-cost bearer. That is a field to reconcile with the contract, not proof that the operator agreed to it or paid it. A different arrangement might put specific retry charges on the buyer or include them inside the provider’s fee.

The agreement should answer five questions before the workflow begins: which attempts can be charged, what counts as acceptance, who evaluates the result, how many retries are permitted and when further work requires new authorization. Ambiguous answers become especially expensive when repeated across many small transactions.

Try the DN Outcome Receipt Consistency Checker

The example below uses invented identifiers and amounts. Change the invoice from 5 cents to 2, switch the acceptance criterion or duplicate an attempt identifier to see the inconsistency. A consistent result still leaves authenticity and actual payment unverified.

Example receipt JSONDraft JSON Schema24 synthetic fixturesExecuted resultsCase directory CSVMethodology and limits

What the checker actually checks

It compares the supplied authorization and policy references across attempts, rejects duplicate attempt identifiers, links final acceptance to one accepted attempt and the same criterion, and checks declared invoice arithmetic. It also flags unresolved retry-cost allocation, disputed settlement and selected contradictions between settlement labels and amounts.

For attempt billing, the expected buyer invoice is unit price multiplied by the count of attempts marked buyerBillable. For accepted_outcome billing, it is one unit price when task acceptance is accepted, and zero otherwise. Upstream costs include every attempt regardless of the buyer-billable flag.

Supported scope: one task, one to 100 attempts, at most one accepted outcome and USD cents. Each monetary input must be a nonnegative integer no greater than 1,000,000,000,000 cents. The draft excludes token decimals, currency conversion, partial acceptance, refunds, tax and chargebacks. A pending settlement uses zero settled cents in this demonstration profile; that is not a rule imposed by any payment network.

Outside scope: checking signatures, fetching referenced evidence, establishing identity, enforcing a contract, confirming a blockchain transaction or verifying that the output is useful. Arbitrary native x402 receipts are not accepted as this draft format.

A Retry Identifier Is Not the Same as a New Purchase

x402’s payment-identifier documentation describes deduplication using a logical payment identifier and server-side response handling. It recommends retaining identifiers across retries and binding them to request fingerprints. The described behavior also depends on cache lifetime and configuration. A declared identifier alone is not evidence that a deployment enforced those rules.

The DN checker only detects duplicate attempt identifiers inside the supplied record. It does not test server-side idempotency. In a production investigation, distinguish a transport retry of one logical request from a new purchase, a changed quote or a newly authorized attempt. Preserve the native request and payment identifiers alongside the task mapping.

A timeout is especially important. Before retrying an action that can move money or create an external commitment, reconcile what the authoritative system reports. A missing client response cannot by itself tell you whether the action happened.

Local Test Results: 24 Cases, Including One Deliberately Untrustworthy Record

DN executed the published consistency function against 24 invented cases. All 24 matched their expected classifications. Five were internally consistent and nineteen produced issues. These are checks of this small function and its stated rules, not a measured fraud-detection rate or a provider security score.

The most useful control is fabricated-but-balanced. It deliberately supplies an invented task identifier while keeping the fields and arithmetic consistent. The checker accepts its internal consistency. That result demonstrates the limit: record consistency cannot authenticate the record.

The pending case is equally useful. It preserves $0.02 of upstream costs while accepted outcomes and the accepted-only buyer invoice remain zero. This stops “no accepted work” from silently becoming “no cost.”

To reproduce the classifications locally, download checker.mjs, fixtures.json and reproduce.mjs into one folder, then run node reproduce.mjs. No dependencies or external calls are required. The results artifact records the executed checker’s SHA-256; that identifies the source bytes, not a trusted publisher signature.

How to Use This in a Real Procurement or Billing Review

For a buyer: define acceptance before delivery

Choose a task-specific rule that can be checked against retained evidence. For a research export, that might include coverage, freshness, allowed sources and duplicate handling. Decide who can approve exceptions. A vendor’s completion label should not silently become the buyer’s acceptance decision.

Request a redacted record for one ordinary success, one rejected result and one interrupted request. Ask the supplier to explain which charges remain in each case. This gives the pilot a useful commercial test without requiring unrestricted access to production data.

For an operator: retain the binding, not every raw payload

Map the task to the applicable authority, policy version, attempts, evaluation and invoice. Production records may need durable content digests, authorized signatures, reliable timestamps and references to original artifacts. A mutable identifier is not an immutable commitment to a policy or rubric.

Use access-controlled evidence stores and purpose-specific retention. Public correlation identifiers should not contain customer names, secrets or sensitive payloads. Keep the mapping detailed enough for the authorized reviewer while minimizing what crosses organizational boundaries.

For a marketplace: reconcile before computing reputation

Do not turn every settled payment into a completed-task reputation event. Separate paid access, claimed delivery, buyer acceptance, dispute and reversal. Define how a correction affects downstream summaries. Otherwise, an impressive transaction count can conceal repeated rejected outputs or duplicate activity.

This connects directly to DN’s transaction-permission research: authority, execution and economic acceptance belong in different fields because they fail in different ways.

Methodology, Falsification and Limitations

Sources: current official documentation was reviewed on 2 November 2026. Protocol descriptions are documentation findings. DN’s reconciliation-gap framework and draft record are editorial proposals. The 24 cases are locally executed synthetic observations.

Test design: the fixtures cover selected reference mismatches, duplicate attempts, missing evidence, changed criteria, conflicting states, unsupported currency, invalid monetary types, invoice disagreement and settlement disagreement. Expected labels were defined for the draft’s own rules. They do not represent a random sample of production failures.

Falsification: reproduce the fixtures, then supply a counterexample inside the supported scope where the function silently miscalculates or fails to flag a stated invariant. A fabricated but balanced record is an expected limitation, not a detected forgery. A genuinely signed artifact still needs its native verification and a separate acceptance assessment.

Independence: no payment processor, provider platform or security vendor was tested or ranked. There were no model calls, paid requests, blockchain requests or signature checks in the fixture execution. No independent replication is claimed.

Commercial disclosure: the Research Desk is DN’s own paid service. Its placement does not affect fixture labels. This draft provides operational research, not a legal determination, accounting certification or payment authorization.

Reuse and corrections: DN’s files are released under CC BY 4.0; retain attribution and limits. Third-party source material keeps its own terms. Send corrections with a case identifier and reproducible evidence. Material changes should receive a new version.

Primary Sources

1. x402 HTTP 402 and payment headers.
2. x402 Signed Offers & Receipts.
3. x402 Payment-Identifier and idempotency.
4. OpenTelemetry GenAI evaluation events, development status.
5. W3C Trace Context, Recommendation dated 23 November 2021.
6. DN local synthetic execution results and draft methodology.

Frequently Asked Questions

What is an AI-agent outcome receipt?

In this article, it is an application-level record linking a task, authority references, attempts, acceptance evidence, billing terms and settlement references. DN v0.1 is a small editorial draft, not an industry standard.

Does DN replace x402 signed receipts?

No. Native signed artifacts should retain their original format and verification process. DN’s draft illustrates application-level reconciliation questions and does not parse or verify x402 receipts.

Does an internally consistent result prove payment or delivery?

No. It means the supplied fields and arithmetic satisfy the supported checks. Invented records can be internally consistent. Authority, evidence, signatures and payment still require external verification.

Who pays for retries when customers pay only for accepted work?

The agreement determines the allocation. An operator may absorb upstream charges, a provider may include retries in its fee, or a buyer may accept specific retry charges. Outcome-based buyer billing does not make failed work costless.

Why are upstream costs separate from the buyer invoice?

They describe different obligations. A provider may charge the operator for multiple attempts while the operator invoices the buyer once for accepted work. Subtracting those two amounts still does not establish net profit.

Does this checker support stablecoins or token decimals?

No. The demonstration supports USD cents only. Production integrations need explicit asset, network, decimal and conversion handling. Relabeling USDC as USD is not a valid conversion.

Can I paste a live receipt into the checker?

Use synthetic or redacted examples in the published draft format. Never paste credentials, personal data or live transaction payloads. The checker itself sends no requests and stores no input; ordinary site analytics are separate.

What exactly did DN test?

DN executed 24 synthetic record cases against its own consistency function. All matched their expected classifications: five internally consistent and nineteen with issues. No provider API, payment network, model or signature verification was tested.

Are the receipt schema and checker equivalent?

No. The JSON Schema describes the allowed structure and value types. The checker adds reference, state and arithmetic checks. Passing either does not authenticate the record.

Can I reuse the files?

The DN draft and synthetic fixture dataset are available under CC BY 4.0. Attribute Decentralised News and retain the limitations. Third-party standards and source artifacts retain their own licenses.

Edition and evidence cut-off: 2 November 2026. DN Outcome Receipt Draft v0.1. A consistent record remains externally unverified.