EAASD-JWT VCmdoc

Attestation Rulebook for attestations of type eInvoice

Category: non-qualified EAA

This Rulebook is derived from the generic WE BUILD attestation rulebook template, version 1.0 with 11 chapters (itself derived from the EUDI attestation rulebook template) and keeps the template's chapter structure. It specifies the eInvoice attestation used in WE BUILD Use Case SC5 (eInvoicing), Scenario 4 (Direct eInvoicing between Business Wallets).

• Author(s):
  • Andreas Abraham, Validated ID
  • Maarten Boender, Sphereon

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues

1 Introduction

1.1 Document scope and purpose

This Rulebook defines the eInvoice attestation, an Electronic Attestation of Attributes (EAA) used within WE BUILD Use Case SC5 (eInvoicing).

In plain language, the eInvoice attestation is a verifiable representation of an invoice exchange event. It binds the content of a structured electronic invoice (via a payload hash) to a cryptographic signature associated with the Supplier's legal-person identity, so that a Buyer, receiving the attestation directly into its Business Wallet, can verify the integrity of the invoice, the validity of the Supplier's identity, and, where applicable, the authenticity and validity of any referenced supporting evidence. In Scenario 4 this exchange is wallet-to-wallet and machine-to-machine, without an intermediary access point: trust is established cryptographically at the point of exchange rather than delegated to a network operator.

• Real-world fact expressed: that a named Supplier has issued a specific electronic invoice (bound by payload hash) to a named Buyer, together with the core invoice header data (amounts, currency, VAT, parties) and optional supporting evidence needed to accept and process it.
• Issuers: the Supplier (the invoice seller), acting as a legal person through its European Business Wallet (EBW). The Supplier self-issues the eInvoice attestation for each invoice.
• Holders: in the direct wallet-to-wallet flow the attestation is issued by the Supplier's EBW and presented to, and then held by, the Buyer's EBW.
• Relying parties: the Buyer (the invoice recipient) verifying the attestation in its Business Wallet; and, where the Buyer delegates processing, a third-party software/service provider that verifies integrity rules on the Buyer's behalf.
• Use case / user journey: SC5 Scenario 4 (Direct eInvoicing between Business Wallets). The attestation is issued per invoice, delivered directly from Supplier EBW to Buyer EBW using the OID4VP/DCQL profile in a machine-to-machine context, and verified on receipt. This scenario is designated MVP.
• Source material: the eInvoice Attestation description (v0.5 final draft, Maarten Boender) and the SC5 Scenario 4 specification (v1.0). Attribute names use EN 16931 semantic term names in camelCase style; the invoice payload is bound to the EN 16931 semantic model with Peppol BIS Billing 3.0 syntax, with country-specific profiles permitted (see Section 2.8).

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], to indicate requirements, recommendations and options.

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF, supplemented by eInvoicing domain terminology (Supplier/Seller, Buyer, invoice payload, EN 16931, Peppol BIS Billing 3.0) and WE BUILD terminology (EBW, EBWOID, WE BUILD LoTL, WE BUILD Trusted List, List of Trusted Entities (LoTE)) as defined in the SC5 specification and the WP4 Blueprint.

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

This Rulebook follows the structure mandated by [Topic 12] of the ARF and the WE BUILD Attestation Rulebook Template v1.1. The eInvoice attestation is a non-qualified EAA in the sense of the [European Digital Identity Regulation], implemented within the WE BUILD pilot trust framework rather than the eIDAS production ecosystem (WP4 Blueprint D4.1 §1.2.1). It uses the SD-JWT VC format profiled by [HAIP], OpenID4VCI for issuance and OpenID4VP/DCQL for presentation per the WE BUILD Conformance Specifications (cs-01, cs-02), and the IETF Token Status List for revocation per the WE BUILD ADR on Attestation Revocation. The invoice payload is bound to the [EN 16931] semantic model with [Peppol BIS Billing 3.0] syntax (country-specific profiles permitted), consistent with ViDA-relevant guidance where applicable. Escalation to an eIDAS-qualified EAA (QEAA), and any associated QTSP involvement, is a post-pilot decision and out of scope for this version. Open dependencies (payload canonicalization and hash strategy; the LPID/signing-key trust anchor mechanism) are tracked with WP4 and noted inline in Sections 2.9 and 5.

2.2 Regulatory basis

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

3.1 Introduction

The eInvoice attestation is modelled as one object representing a single invoice exchange event. It binds to an external structured invoice payload (EN 16931 / Peppol BIS) via invoicePayloadHash, and carries the core invoice header data needed for verification and acceptance (parties, amounts, currency, VAT). It may include one or more optional evidenceReferences that integrity-bind supporting business documents (e.g., purchase order, delivery note, contract or acceptance evidence), and optional grouped paymentInstructions and taxSubtotal containers. In this version, evidenceReferences deliberately retains this broad supporting-document scope, including evidence used for invoice acceptance or dispute resolution. It is not used for correction-chain linking; precedingInvoiceReference serves that separate purpose.

Per ARB_12 of [Topic 12], this document defines the attribute attestation_legal_category. Because this Rulebook profiles a non-qualified EAA for the WE BUILD pilot, the attribute SHALL have the exact value non-qualified-EAA.

Seller and buyer are each modelled as an object carrying name, identifier, vat and country. identifier is itself an object supporting multiple identification schemes, because implementers legitimately hold different registry identifiers for the same legal entity: euid, lei (Legal Entity Identifier, ISO 17442), vat, gln (GS1 Global Location Number), duns, eori (EU customs identifier), bpnl and siren (French national company identifier). Of these, only identifier.euid is mandatory. The other identifiers are OPTIONAL.

Logical model (informative):

eInvoiceAttestation
├── attestation_legal_category : "non-qualified-EAA"
├── invoicePayloadHash                 (integrity anchor to the canonicalized invoice payload)
├── invoiceFormat                      (optional; EN 16931 default, may be country-specific)
├── invoiceNumber
├── issueDate
├── seller                             (Supplier, the issuer; mandatory)
│   ├── name                                (EN 16931 BT-27)
│   ├── identifier                          (M; at least euid required)
│   │   ├── euid    (M)                     (European Unique Identifier, verified, IR-EI-06)
│   │   ├── lei     (O)                     (Legal Entity Identifier, ISO 17442, unverified)
│   │   ├── tax     (O)                     (national tax/registration number, unverified)
│   │   ├── gln     (O)                     (GS1 Global Location Number, unverified)
│   │   ├── duns    (O)                     (Dun & Bradstreet DUNS, unverified)
│   │   ├── eori    (O)                     (EU customs identifier, unverified)
│   │   ├── bpnl    (O)                     (Catena-X Business Partner Number Legal, ICD 0243, unverified)
│   │   └── siren   (O)                     (French national company identifier, unverified)
│   ├── vat                                 (EN 16931 BT-31)
│   └── country                             (EN 16931 BT-40)
├── buyer                              (Buyer, the relying party; optional as a whole)
│   ├── name                                (required within group, EN 16931 BT-44)
│   ├── identifier                          (required within group; at least euid required)
│   │   └── (same sub-schema as seller.identifier)
│   ├── vat                                 (required within group, EN 16931 BT-48)
│   └── country                             (required within group, EN 16931 BT-55)
├── BuyerElectronicAddress             (optional)
├── amountDueForPayment
├── invoiceTotalVatAmount
├── InvoiceCurrencyCode
├── taxSubtotal[]                      (optional container; VAT breakdown, one entry per tax code)
│   ├── taxCategoryCode
│   ├── taxableAmount
│   ├── taxPercent
│   ├── taxAmount
│   └── taxExemptionReasonCode         (optional)
├── paymentInstructions                (optional container)
│   ├── paymentMeansCode
│   ├── paymentMeansText               (optional)
│   ├── paymentAccountIdentifier
│   └── paymentCardPAN                 (optional)
├── evidenceReferences[]               (optional array; supporting business documents; URI + hash only)
│   ├── evidenceReferencesType
│   ├── evidenceUri
│   └── evidenceHash
├── precedingInvoiceReference          (conditional; required for non-active lifecycle states)
└── invoiceLifecycleStatus             (optional; defaults to active when omitted)

This model preserves the information content of the eInvoice Attestation description v0.5 while grouping the seller and buyer fields, and their identifiers, into nested objects for readability and for consistency with the identifier convention used across other WE BUILD financial-sector attestations. The grouping is informative; the normative encoding (Chapter 3) follows the JSON object/camelCase identifiers used in the attribute tables below.

Subsections 2.2–2.7 define the attributes and metadata. Section 2.8 documents the code lists and Section 2.9 the integrity rules.

Chapter overview and requirements

This chapter defines all attributes and metadata that an eInvoice attestation may contain, in an encoding-independent manner (ARB_06 in [Topic 12]). Each attribute is marked mandatory, optional, or conditional in its section (ARB_09). Attribute names follow the EN 16931 semantic term names in camelCase style. The NOTE from [RFC 8610]-style descriptions applies: an attribute marked mandatory means the Issuer SHALL ensure the element is present in the attestation; it does not imply that a Relying Party must request it, nor that a User cannot refuse to release it.

Applicable legal category. Per the SC5 working assumptions, the eInvoice attestation is implemented as a non-qualified EAA for the WE BUILD pilot; QEAA escalation (which would require QTSP involvement) is a post-pilot decision. Where the SC5 specification refers to a "WE BUILD QEAA", this denotes a technically interoperable, ITB-tested attestation within the pilot trust framework, not an eIDAS-qualified EAA. The requirements for non-qualified EAA in [Topic 12] therefore apply:

• An attribute indicating that the attestation is an EAA SHOULD be included (ARB_12). See Section 2.1.
• One or more attributes or metadata representing identification data of the issuer (the Supplier) SHALL be included (ARB_15).
• One or more attributes representing the subject SHOULD be included (ARB_17).
• Attributes or metadata representing the validity period SHOULD be defined (ARB_19).
• Attributes or metadata representing the location of the trust anchor SHOULD be defined (ARB_21); see Chapter 5.

3.2 Mandatory attributes

3.3 Optional attributes

3.4 Conditional attributes

This section defines both standalone conditional attributes and members of optional containers/arrays. For container members, presence and obligation are conditional on the presence of their parent group: if the parent group is present, members marked "M (within group)" SHALL be present and members marked "O (within group)" MAY be present.

Standalone lifecycle attribute (conditional on invoiceLifecycleStatus):

seller group members (seller is mandatory; all members below are M within group):

buyer group members (conditional on buyer being present; all members below are M within group once buyer is present):

identifier group members (used identically as seller.identifier and buyer.identifier; conditional on the parent seller/buyer group being present):

taxSubtotal container members (conditional on taxSubtotal being present):

paymentInstructions container members (conditional on paymentInstructions being present):

evidenceReferences array members (conditional on evidenceReferences being present):

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

4.4 Code lists

4.5 Integrity rules

NOTE Two naming inconsistencies in the source description v0.5 have been reconciled here to match the attribute tables in Sections 2.2–2.4: buyerRegistrationIdentifier → buyerLegalRegistrationIdentifier, and totalTaxAmount → invoiceTotalVatAmount and buyerLegalRegistrationIdentifier were themselves superseded by seller.identifier.euid and buyer.identifier.euid respectively; IR-EI-01 and IR-EI-06 below use the v0.8 paths.

5 Formats

5.1 SD-JWT VC-based encoding

This attestation type SHALL be issued in the [SD-JWT VC]-compliant format and SHALL comply with the 'SD-JWT VCs' profile specified in [HAIP] (ARB_01b).

Verifiable Credential Type (vct): eu.we-build:einvoice:1

(Proposed value; subject to registration in the WE BUILD Attestation Rulebooks catalog by the WP4 semantics group, ARB_05.)

For all claims, the tables below specify whether an Attestation Provider MUST, MAY, or MUST NOT make the claim selectively disclosable (ARB_30). A Type Metadata Document SHOULD be defined for this vct per Chapter 6 of [SD-JWT VC] (ARB_31).

Encoding conventions: tstr attributes are encoded as JSON strings; monetary and percentage values are carried as strings (as in the source description) to preserve exact decimal representation; dates use RFC 3339 full-date strings; taxSubtotal and evidenceReferences are JSON arrays of objects; and paymentInstructions, seller, buyer and identifier are JSON objects.

Registered / standard claims:

Private claims specific to this attestation type:

Illustrative JWT claim set (informative, synthetic data):

{
  "vct": "eu.we-build:einvoice:1",
  "iss": "https://wallet.greenflowers.example/issuer",
  "iat": 1768435200,
  "exp": 1800057600,
  "attestation_legal_category": "non-qualified-EAA",
  "status": { "status_list": { "idx": 128, "uri": "https://status.webuild.example/sc5/einvoice" } },
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } },
  "cryptographically_bound_to": "uri:eu.ebw.oid.1",
  "invoicePayloadHash": "sha256:9f2c8b1e7d43a0c5f6e9b2d1a4c7e0f3b6d9a2c5e8f1b4d7a0c3e6f9b2d5a8c1",
  "invoiceFormat": "EN16931",
  "invoiceNumber": "INV-2026-000123",
  "issueDate": "2026-07-15",
  "seller": {
    "name": "Green Flowers B.V.",
    "identifier": {
      "euid": "NL853746281B01",
      "gln": "5410000000004"
    },
    "vat": "NL853746281B01",
    "country": "NL"
  },
  "buyer": {
    "name": "Fleurs de Paris S.A.S.",
    "identifier": {
      "euid": "FR59120680088",
      "siren": "512068008"
    },
    "vat": "FR59120680088",
    "country": "FR"
  },
  "BuyerElectronicAddress": "0009:FR59120680088",
  "amountDueForPayment": "1210.00",
  "invoiceTotalVatAmount": "210.00",
  "InvoiceCurrencyCode": "EUR",
  "taxSubtotal": [
    {
      "taxCategoryCode": "S",
      "taxableAmount": "1000.00",
      "taxPercent": "21",
      "taxAmount": "210.00"
    }
  ],
  "paymentInstructions": {
    "paymentMeansCode": "58",
    "paymentMeansText": "SEPA Credit Transfer",
    "paymentAccountIdentifier": "NL91ABNA0417164300"
  },
  "evidenceReferences": [
    {
      "evidenceReferencesType": "purchase_order",
      "evidenceUri": "https://erp.greenflowers.example/documents/po-2026-000045",
      "evidenceHash": "sha256:3a7c9e1b5d8f2a4c6e0b3d7f9a1c5e8b2d4f6a0c3e7b9d1f5a8c2e6b0d4f7a3c"
    }
  ],
  "invoiceLifecycleStatus": "active"
}

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE ISSUED SD-JWT IN base64 ENCODING ONCE A REFERENCE ISSUER IS AVAILABLE]

[RULEBOOK AUTHOR TO PROVIDE A HUMAN-READABLE VERSION OF THE SD-JWT PAYLOAD WITH THE DISCLOSURES, ONCE THE SELECTIVE-DISCLOSURE STRUCTURE IS FINALISED WITH WP4]

5.2 ISO/IEC 18013-5-compliant encoding

The eInvoice attestation is presented in automated, online, system-to-system (wallet-to-wallet) flows between European Business Wallets (see Chapter 4 and SC5 Scenario 4). There is no proximity / offline presentation use case (ARB_02). An ISO/IEC 18013-5 (mdoc) encoding is therefore not specified in this version. If a future use case requires proximity presentation, a document type and mdoc encoding would be added here.

5.3 W3C Verifiable Credentials Data Model-based encoding

A W3C VCDM encoding is not specified for this attestation type. SD-JWT VC (Section 3.2) is the single normative encoding for SC5, consistent with the WE BUILD Conformance Specifications. (Note that only a non-qualified EAA may use the VCDM format, ARB_01a; this attestation is a non-qualified EAA, so a VCDM encoding could be added in future if an interoperability need arises.)

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

Primary use case. SC5 Scenario 4 (Direct eInvoicing between Business Wallets). The Supplier's EBW issues and signs the eInvoice attestation and presents it directly to the Buyer's EBW endpoint using the OID4VP/DCQL profile in a machine-to-machine context, having resolved the Buyer's wallet endpoint via the List of Trusted Entities (LoTE), as specified in [ETSI TS 119 602]. The Buyer's EBW verifies the attestation, recomputes the payload hash, and accepts, rejects, or quarantines the invoice.

PID verification (ARB_27). A Relying Party (the Buyer) does not request or verify a PID. Both Supplier and Buyer are legal persons; identity assurance is provided by the EBWOID / legal-entity binding (see Chapter 5), not by a natural-person PID.

Presentation requirements. Presentation is online and system-to-system via OpenID4VP, using DCQL queries as profiled by the WE BUILD Conformance Specification cs-02, in a machine-to-machine context. In the supplier-initiated flow, the Supplier's wallet first fetches a fresh Presentation Request (OID4VP Request Object, DCQL constraints, nonce, audience, expiry, correlation identifier, submission endpoint) from the Buyer's endpoint, then submits the eInvoice attestation (and invoice payload / optional evidence) as the OID4VP response. No offline / proximity presentation is supported. The upcoming Implementing Acts may additionally require a (Q)ERDS-based delivery track for stronger delivery evidence; this is out of scope for the MVP but noted as a possible additional pilot track.

Device binding (ARB_34). An attestation of this type SHOULD be device-bound to the issuing/holding Wallet Unit, evidenced by the cnf claim and verified through key binding at presentation (base verification step 4.2.8).

Binding to another attestation (ARB_28). An attestation of this type SHOULD be cryptographically bound to the Supplier's organisational identity attestation (EBWOID) on the same Wallet Unit. Where present, the binding metadata identifier SHALL be cryptographically_bound_to, its value SHALL be a string containing the bound attestation's vct, and that value SHALL be uri:eu.ebw.oid.1 (the EBWOID vct defined in [rb-ebwoid]).

Transactional data ([Topic 20]). No payment-authentication transactional data is defined for this attestation type. Although the invoice carries payment information (paymentInstructions), the eInvoice attestation records an invoice exchange event; it does not authorise an individual electronic payment, so the strong-user-authentication transactional-data mechanism of [Topic 20] does not apply.

The issuer is the Supplier, a legal person self-issuing this EAA through its EBW for each invoice, on the basis of an invoice payload prepared by its ERP (canonicalized, with invoicePayloadHash computed per the agreed rulebook). Issuance uses OpenID4VCI as profiled by the WE BUILD Conformance Specification cs-01.

The Issuer SHALL implement the base issuer obligations defined in the Base Verification specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#41-issuer-obligations

In particular, the issuer SHALL include the holder-generated public key (cnf) in the payload, SHALL include its own EBWOID-anchored certificate material in the attestation header (see Chapter 5), SHALL populate the status metadata (see Chapter 6) in every issued attestation, and SHALL ensure invoicePayloadHash is computed over the canonicalized payload per IR-EI-03.

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

An eInvoice attestation records an invoice exchange event, and SHALL support revocation so that an issued attestation can be invalidated where necessary (e.g., an invoice issued in error). The attestation is revocable; it is not a short-lived (≤24h) attestation.

8.1 Revocation mechanism

• Token Status List: the issuer SHALL maintain an active IETF Token Status List ([Token Status List]), aligned with the Attestation Status List mechanism specified by the EU Commission and mandated by the WE BUILD ADR on Attestation Revocation.
• Credential metadata: the status metadata SHALL be populated in every issued attestation with:
• status_list_credential (string, URI), the URI of the Status List Credential containing the status bitstring;
• status_list_index (integer, ≥ 0), the zero-based index into the status list bitstring for this attestation.
• Authorized authority: only the issuing Supplier (the self-issuing legal entity) may modify the status list entry.

8.2 Relationship between revocation and invoiceLifecycleStatus

Cryptographic revocation (via the registered Token Status List status metadata, Section 8.1) is distinct from the business-level invoiceLifecycleStatus attribute (active/corrected/cancelled/credited, Section 2.3). invoiceLifecycleStatus and the correction/credit-note lifecycle (IR-EI-09) express the accounting state of the invoice, while Token Status List revocation expresses the cryptographic validity of the attestation. An issuer correcting or cancelling an invoice SHOULD issue a new attestation with the appropriate invoiceLifecycleStatus value and a precedingInvoiceReference identifying the original or preceding invoice. The issuer SHALL revoke the superseded attestation via the Token Status List where it should no longer be relied upon.

8.3 Revocation triggers and business rules

• Issuer trigger (obligation): the Supplier SHALL revoke the attestation without undue delay when the invoice is cancelled or replaced, or when the attestation was issued in error or contains inaccurate identity data.
• Relying Party action: a revoked or suspended attestation SHALL be treated as invalid; the Buyer SHALL reject or quarantine an invoice relying on it. The business interpretation of a revocation (e.g. handling of invoices already accepted) is determined by the Relying Party's internal policies.

9 Presentation

Base Verification Process

The Relying Party SHALL perform the base attestation verification process for EAAs as defined in the Base Verification specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#42-relying-party-obligations

This covers verification of attestation authenticity and issuer identity via the EBWOID chain (4.2.2–4.2.4), validity periods (4.2.5), revocation status (4.2.6), including checking the Supplier's authorization status against the Status Service, wallet integrity via the WUA (4.2.7), and holder key binding (4.2.8).

Validate attestation-specific integrity rules

In addition to the base verification, the Relying Party SHALL apply the integrity rules IR-EI-01 to IR-EI-09 defined in Section 2.9. In particular, the Relying Party SHALL: recompute invoicePayloadHash over the received invoice payload and confirm it matches (IR-EI-03); confirm that the invoice's buyer field matches the receiving Wallet's own identity (IR-EI-01); confirm seller.identifier.euid (and, when present, buyer.identifier.euid) matches the corresponding payload identities (IR-EI-06), the other identifier members are informational only and are not cross-checked; verify VAT arithmetic consistency (IR-EI-07); and, where evidenceReferences are present, retrieve the referenced artefacts via their URI and verify their hash and, where applicable, validity (IR-EI-08); and validate invoiceLifecycleStatus together with precedingInvoiceReference for corrections, cancellations and credit notes (IR-EI-09). If all checks pass, the Buyer's Wallet accepts the invoice and stores the attestation for audit; if any check fails, it rejects or quarantines the invoice with an error code. In both cases an optional status message MAY be returned to the Supplier's Wallet.

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

When receiving and processing an eInvoice attestation, the Relying Party (the Buyer, or a delegated third-party processor) SHALL perform the following verification obligations.

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

This chapter specifies how a Relying Party establishes trust in the issuer of an eInvoice attestation. The corresponding verification procedures are steps 4.2.2–4.2.4 of the Base Verification specification.

The eInvoice attestation is an EAA self-issued by a legal entity (the Supplier). Suppliers are not, and cannot practically be, individually registered on a Trusted List. Trust is therefore established through a cryptographic chain anchored in the issuer's EBWOID, following the common WE BUILD EAA trust model:

• The issuer's EBWOID SHALL be included in the header of every issued eInvoice attestation. During EBWOID issuance, the EBWOID provider verifies that the public key contained in the EBWOID is owned by the EBW owner.
• The Relying Party SHALL verify the EBWOID in accordance with [rb-ebwoid] and the Base Verification specification. The EBWOID provider's trust anchor is obtained via the WE BUILD trust list infrastructure (TLOL) operated under WP4.
• Upon successful verification, the Relying Party obtains: assurance that the EBWOID was issued by an authorised provider (and is not self-issued); the verified identity of the issuer, including its legal name and EUID; and the public key authorised to verify the attestation signature.
• The Relying Party SHALL then confirm that the verified issuer identity (EUID) matches sellerLegalRegistrationIdentifier in the attestation payload (IR-EI-06).

For endpoint discovery and issuer-metadata resolution, the WE BUILD List of Trusted Entities (LoTE) per [ETSI TS 119 602] is used (the EC's proposed European Digital Directory (EDD) may serve this role). [OPEN, the trust anchor mechanism for LPID and signing keys (registry vs federation vs QTSP signals) is not in scope of SC5 but is a dependency; it will be based on [ETSI TS 119 602]. WP4 Trust Registry Infrastructure WG to confirm.]

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References