E-invoices for agentic commerce (UCP, ACP)

AI agents now buy from stores through two protocols: the Universal Commerce Protocol (UCP, Google and Shopify, ucp.dev) and the Agentic Commerce Protocol (ACP, OpenAI and Stripe, spec 2026-04-17). Neither protocol's order carries an invoice or a receipt, and neither carries a business buyer's tax identity anywhere a merchant reads it: UCP's buyer is a name, an email and a phone number; ACP's has a company.tax_id that no storefront implementation uses. Yet in Belgium, Germany, France, Oman, the UAE and a growing list of countries a compliant e-invoice (business buyer) or fiscal receipt (consumer) is the law for exactly these orders.

ai.goroute.einvoice closes that gap. It is a small extension to both protocols, version 1.0.0-draft, published by GoRoute. Anyone may implement it, on any e-invoicing provider; nothing in it requires GoRoute.


Name	`ai.goroute.einvoice`
Version	`2026-09-24` (UCP capability versions are dates); this document is 1.0.0-draft
Specification	this page
Capability entry	`https://goroute.ai/ucp/einvoice.json`
JSON Schema	`https://goroute.ai/ucp/einvoice.schema.json` (draft 2020-12)
Extends	`dev.ucp.shopping.checkout`, `dev.ucp.shopping.order`
Requires	UCP `2026-08-25` or later

Those last two addresses are the normative ones for this extension and will not change. Both were fetched on 24 September 2026 and answered 404; until they answer, this is a specification to read rather than one to declare — see the check under Declare it below.

What it says

At checkout, the agent may add buyer_business. Its principal is buying as a business; here is who the invoice is for.

Field		Meaning
`legal_name`	required	The buyer's registered name, as the invoice must show it
`tax_id`	one of these two	The buyer's tax identifier: VAT number (EU, with country prefix), ABN, NZBN, VATIN, or the equivalent. Spaces are ignored
`peppol_id`		The buyer's Peppol participant identifier as `scheme:identifier` (for example `0208:0000007720`), when the buyer knows it. Wins over `tax_id` for delivery
`scheme`	optional	What kind of identifier `tax_id` is: an ISO 3166-1 country code (the country's standard business identifier), or a four-digit Peppol / ISO 6523 ICD code
`order_reference`	optional	The buyer's own reference (a purchase-order number). Goes on the invoice as the buyer reference
`delivery`	optional	`peppol` (default): to the buyer's e-invoicing system over the network. `email`: a PDF with the e-invoice embedded. `none`: the buyer wants nothing sent. The merchant still issues and keeps the document — fiscal law is not optional — and may substitute what its country allows
`email`	optional	Where to send the document when `delivery` is `email`, if not the checkout buyer's email

After the order completes, the merchant exposes einvoice on the order. A merchant that declares the capability commits to issuing the document the buyer's country requires for every completed order, and to reporting it here.

Field		Meaning
`status`	required	`pending`, `issued`, `delivered`, `failed`, `held` (the merchant must act; see `error`), `skipped` (no fiscal document is required for this order)
`document_type`	required	`invoice` (a full tax invoice to a business), `receipt` (a fiscal receipt or simplified tax invoice to a consumer), `credit_note`
`delivered_via`	required	`peppol`, `email`, `authority` (filed with the tax authority only, buyer not reachable on the network), `none` (issued and stored, not sent)
`number`		The document number as issued
`pdf_url`, `xml_url`		Where the agent can fetch the PDF and the e-invoice XML. May be time-limited
`network_message_id`		The Peppol AS4 message identifier once the document is on the network
`transaction_id`, `document_uuid`, `verify_url`, `issued_at`, `error`		Optional; see the schema

A refund raises a credit note and the order's einvoice moves with it. An order no agent placed, or one with no buyer_business, is a consumer sale: the merchant issues whatever a consumer sale needs in its country (document_type: receipt), or reports skipped where nothing is.

UCP

UCP has no registry: a capability is owned by whoever owns its domain, and its schema must be served from that domain — ai.goroute.* from goroute.ai. Extension data rides as plain keys on the checkout and the order, composed with allOf in the schema, as UCP's own fulfillment and discount extensions do.

Declare it in your business profile at /.well-known/ucp, inside ucp.capabilities:

"ai.goroute.einvoice": [
  {
    "version": "2026-09-24",
    "spec": "https://docs.goroute.ai/docs/connectors/agentic-e-invoice",
    "schema": "https://goroute.ai/ucp/einvoice.schema.json",
    "extends": ["dev.ucp.shopping.checkout", "dev.ucp.shopping.order"],
    "requires": { "protocol": { "min": "2026-08-25" } },
    "config": { "documents": ["invoice", "receipt"], "delivery": ["peppol", "email", "none"] }
  }
]

Before you publish that declaration, fetch the schema address and confirm it returns the schema document. UCP has no registry, so a capability's authority rests on the host serving its schema and nowhere else: a declaration that names an address which does not answer cannot be checked by an agent or a validator, and an agent that cannot check a capability may ignore it. Fetched on 24 September 2026, https://goroute.ai/ucp/einvoice.schema.json answered 404, so a profile declaring it today is not yet usable; publish the declaration once the address serves the schema.

The agent sends buyer_business on checkout create or update:

{
  "line_items": [{ "item": { "id": "sku-espresso-1kg" }, "quantity": 2 }],
  "buyer": { "first_name": "Ana", "last_name": "Berg", "email": "ana@fjord.example" },
  "buyer_business": {
    "legal_name": "Fjord Supplies AS",
    "tax_id": "NO999999999MVA",
    "scheme": "NO",
    "peppol_id": "0192:999999999",
    "order_reference": "PO-77",
    "delivery": "peppol"
  }
}

The merchant answers on the order (and in the order webhook):

{
  "id": "ord_9f2",
  "checkout_id": "chk_41a",
  "buyer_business": { "legal_name": "Fjord Supplies AS", "tax_id": "NO999999999MVA", "peppol_id": "0192:999999999" },
  "einvoice": {
    "extension": "ai.goroute.einvoice",
    "version": "1.0.0-draft",
    "status": "delivered",
    "document_type": "invoice",
    "number": "INV-2403",
    "delivered_via": "peppol",
    "pdf_url": "https://store.example/einvoice/INV-2403.pdf",
    "xml_url": "https://store.example/einvoice/INV-2403.xml",
    "network_message_id": "9d3c1f2e-…@goroute.ai"
  }
}

The response's ucp.capabilities lists ai.goroute.einvoice among the active capabilities, as UCP requires; nothing of the extension goes inside ucp.

ACP

ACP has no extension registry, and its extensions RFC is a draft, so this is a documented merchant extension rather than a registered one. Field names and meaning are the same as above.

Request. ACP's checkout session already has buyer.company.name and buyer.company.tax_id (no scheme, no Peppol ID, no delivery choice). A merchant implementing this extension reads them when nothing better is offered, and reads the full object from metadata.buyer_business on POST /checkout_sessions and its update — metadata is the one place ACP's additionalProperties: false schemas leave for it.
Response. ACP's order has room for confirmation.invoice_number and confirmation.receipt_url; put the document number and the PDF there, so any ACP client sees them. Where a client implements the extensions RFC, declare { "name": "ai.goroute.einvoice", "extends": ["$.Order.einvoice", …] } in capabilities.extensions and expose the full einvoice object on the order; the declaration is spelled out in einvoice.json.

Implementations

WooCommerce — GoRoute E-Invoicing for WooCommerce 2.7.0 is the merchant side. It recognises an agent order by the markers the WooCommerce implementations write — the Stripe gateway's agentic checkout (created_via stripe-agentic-commerce), WooCommerce's experimental Agentic Checkout of 10.4 to 11.1 (order meta _agentic_checkout_session_id; removed in 11.2), the UCP/ACP Agent plugin (_ucpwc_order_id) — or by the goroute_wc_agentic_order filter. It takes buyer_business from order meta _goroute_buyer_business or the goroute_wc_agentic_order_identity filter, writes the legal name and tax id onto the fields the checkout would have filled, and issues the same business invoice a typed VAT number gets. The einvoice object is kept in order meta _goroute_einvoice and added to the order in the store's REST API (wc/v3), which is what a UCP or ACP layer on the same site reads. pdf_url and xml_url are empty there unless that layer supplies them through goroute_wc_einvoice_links, because WooCommerce keeps the documents behind the store login. Nothing changes for an order no agent placed.

Claude and other MCP clients — the GoRoute connector has the agent side: issue_einvoice_for_agent_order takes the order reference, buyer_business, the order's lines and currency, issues the invoice as the signed-in organisation through the same path as send_invoice, and returns the einvoice object with fifteen-minute pdf_url and xml_url links.

Any storefront or provider — with the GoRoute API directly: map buyer_business onto the buyer party of POST /api/v1/invoices (legal_name → name, tax_id → vat_number, peppol_id as is, order_reference → buyer_reference, delivery → delivery_channel), then fill einvoice from the response and GET /api/v1/transactions/{id}; the PDF is GET /api/v1/transactions/{id}/pdf and the XML GET /api/v1/transactions/{id}/document/content. Or with any other provider that can issue a compliant document: the extension names fields, not a vendor.

Versions

This is 1.0.0-draft, dated 2026-09-24. Field additions will keep the version's date moving and the draft label until a second independent implementation has shipped; a change that removes or renames a field gets a new date and a note here. Questions and implementations: admin@goroute.ai.

What it says​

UCP​

ACP​

Implementations​

Versions​

What it says

UCP

ACP

Implementations

Versions