Following up on the reconciliation thread in x402-foundation/x402#2833, one development that may be relevant to CAAP-1's roadmap:
With the EU's e-invoicing rollout (EN 16931, now updated for B2B and the ViDA reporting requirements), a growing share of booked agent payments will have a formal e-invoice sitting next to the x402 receipt. For a CAAP-1 ledger that raises two small questions:
-
Linking. The audit binding already retains content hashes per entry. An entry could reference its e-invoice the same way — hash of the invoice XML — so payment, delivery receipt and formal invoice reconcile over one key, with no new semantics in the spec. Same pattern we settled on for disclosure records.
-
Validation before booking. An e-invoice that fails the EN 16931 business rules (broken totals arithmetic is the classic) is a defect the buyer has to chase, which puts it in the same "who must act" taxonomy CAAP-1 already uses for receipt failures.
FYI on the producer side: the endpoint you reference for signing now also validates e-invoices against the complete official EN 16931 Schematron rule set (CEN validation artefacts 1.3.16, used unmodified, attribution in every response) for UBL, CII and ZUGFeRD/Factur-X — every finding with its official BR- code and severity, result signed and independently verifiable like everything else there. Details in the machine-readable catalogue: https://eucompliance.tools/llms.txt
No spec change requested — the linking in (1) works with what the binding already retains. Happy to provide test fixtures (valid + deliberately broken invoices) if useful.
Following up on the reconciliation thread in x402-foundation/x402#2833, one development that may be relevant to CAAP-1's roadmap:
With the EU's e-invoicing rollout (EN 16931, now updated for B2B and the ViDA reporting requirements), a growing share of booked agent payments will have a formal e-invoice sitting next to the x402 receipt. For a CAAP-1 ledger that raises two small questions:
Linking. The audit binding already retains content hashes per entry. An entry could reference its e-invoice the same way — hash of the invoice XML — so payment, delivery receipt and formal invoice reconcile over one key, with no new semantics in the spec. Same pattern we settled on for disclosure records.
Validation before booking. An e-invoice that fails the EN 16931 business rules (broken totals arithmetic is the classic) is a defect the buyer has to chase, which puts it in the same "who must act" taxonomy CAAP-1 already uses for receipt failures.
FYI on the producer side: the endpoint you reference for signing now also validates e-invoices against the complete official EN 16931 Schematron rule set (CEN validation artefacts 1.3.16, used unmodified, attribution in every response) for UBL, CII and ZUGFeRD/Factur-X — every finding with its official BR- code and severity, result signed and independently verifiable like everything else there. Details in the machine-readable catalogue: https://eucompliance.tools/llms.txt
No spec change requested — the linking in (1) works with what the binding already retains. Happy to provide test fixtures (valid + deliberately broken invoices) if useful.