Attestation Rulebook for attestations of type Payment Terms

• Author(s):

  • [Florin Coptil, Robert Bosch GmbH]
  • [Dominic Hurni, SBB]

• Previous Authors

• Reviewer(s):

  • [Ricky Lamberty, Robert Bosch GmbH]

• Contact:

  • Florin Coptil*

• Feedback:

1 Introduction

This attestation addresses the following question:

What are the agreed financial conditions — including payment due date, currency, and delivery terms — between a buyer and a supplier?

The Payment Terms Attestation provides a standardized, verifiable representation of the financial conditions agreed between a buyer and a supplier, enabling structured exchange of payment term attributes for use in KYS, KYC, supplier onboarding, financial risk assessment, and regulatory compliance processes

1.1 Document Scope and Purpose

Payment terms define the financial conditions under which a buyer settles a transaction with a supplier. Key elements include:

• Due Date — Specifies when the payment must be made (e.g., on delivery, within 30 days of invoice, or at a future fixed date).
• Currency — Indicates the currency in which the payment will be made, aligning with international standards such as ISO 4217 numeric and alphabetic codes.
• Associated Incoterm — Connects the payment obligation to delivery and risk transfer terms defined by Incoterms 2020, clarifying which party is responsible for costs, shipping, and insurance.

Within the Know Your Supplier (KYS) process, payment terms are essential to:

• Mitigate financial risks through clearly defined payment conditions.
• Confirm supplier commitment to meet contractual and currency obligations.
• Ensure alignment with internal policies and regulatory standards.

Integrating payment terms into KYS strengthens financial control, transparency, and overall supplier due diligence.

Design Decisions

This Payment Terms Attestation Rulebook is based on:

• ISO 8601 for date and duration formatting
• ISO 4217 for currency codes
• Incoterms 2020 published by the International Chamber of Commerce (ICC)
• EU Company Certificate (EUCC) framework as the foundational legal identity layer for buyer and supplier identification

1.2 Document Structure

This Rulebook is structured as follows:

• Chapter 2 describes the Payment Terms attestation attributes and metadata in an encoding-independent manner, including the data model.
• Chapter 3 specifies how the attestation attributes and metadata are encoded: Section 3.2 covers SD-JWT VC-based encoding.
• Chapter 4 specifies attestation usage scenarios, Relying Party obligations, and integration with KYS workflows.
• Chapter 5 defines trust anchors and verification mechanisms for issuer authorization.
• Chapter 6 defines revocation mechanisms for the attestation.
• Chapter 7 provides compliance information regarding the EUDI framework and applicable data protection laws.

1.3 Keywords

This document uses the capitalised keywords SHALL, SHOULD and MAY as specified in [RFC 2119], i.e. to indicate requirements, recommendations and options specified in this document.

In addition, must (non-capitalised) is used to indicate an external constraint, i.e. a requirement that is not mandated by this document, but, for instance, by an external document. The word can indicates a capability, whereas other words, such as will, and is or are are intended as statements of fact.

1.4 Terminology

Additional terminology specific to this attestation:

2 Attestation Attributes and Metadata

The Payment Terms Attestation is designed to provide a standardized, verifiable representation of the financial conditions agreed between a buyer and a supplier. This attestation enables structured exchange of payment term attributes for use in KYS, KYC, supplier onboarding, financial risk assessment, and regulatory compliance processes.

2.1 Introduction

Payment terms define the financial conditions under which a buyer settles a transaction with a supplier. Key elements include:

• Due Date — Specifies when the payment must be made (e.g., on delivery, within 30 days of invoice, or at a future fixed date).
• Currency — Indicates the currency in which the payment will be made, aligning with international standards such as ISO 4217 numeric and alphabetic codes.
• Associated Incoterm — Connects the payment obligation to delivery and risk transfer terms defined by Incoterms 2020, clarifying which party is responsible for costs, shipping, and insurance.

The attestation structure is defined as a structured object:

Data Model:

PaymentTerms
├─ payment_due (M)                          // ISO 8601 duration (e.g., P30D)
├─ currency (M)                             // ISO 4217 alphabetic code
├─ incoterm (M)                             // Incoterms 2020 three-letter ICC code
├─ buyer_identifier (Object) (M            // At least one identifier required
│   ├─ euid (str) (O)                       // European Unique Identifier
│   ├─ lei (str) (O)                        // Legal Entity Identifier per ISO 17442
│   ├─ tax (str) (O)                        // National tax or registration number    
│   ├─ gln (str) (O)                        // Global Location Number for legal entities — GS1 identifier
│   ├─ duns (str) (O)                       // Data Universal Numbering System — Dun & Bradstreet identifier
│   ├─ eori (str) (O)                       // Economic Operators Registration and Identification number — EU customs identifier
│   ├─ bpnl (str) (O)                       // Business Partner Number Legal entity — Catena-X identifier per ICD 0243
│   ├─ siren (str) (O)                      // Système d'Identification du Répertoire des ENtreprises — French company identifier
├─ supplier_identifier (object) (M)           // At least one identifier required
│   ├─ euid (str) (O)                       // European Unique Identifier
│   ├─ lei (str) (O)                        // Legal Entity Identifier per ISO 17442
│   ├─ tax (str) (O)                        // National tax or registration number    
│   ├─ gln (str) (O)                        // Global Location Number for legal entities — GS1 identifier
│   ├─ duns (str) (O)                       // Data Universal Numbering System — Dun & Bradstreet identifier
│   ├─ eori (str) (O)                       // Economic Operators Registration and Identification number — EU customs identifier
│   ├─ bpnl (str) (O)                       // Business Partner Number Legal entity — Catena-X identifier per ICD 0243
│   ├─ siren (str) (O)                      // Système d'Identification du Répertoire des ENtreprises — French company identifier
├─ agreement_date (M)                       // ISO 8601 date (YYYY-MM-DD)
├─ payment_reference_event (O)              // Enum: invoice_date | delivery_date | order_date | ...
├─ contract_reference (O)                   // Reference to underlying contract or PO
├─ transaction_amount (O)                   // Monetary value of the transaction (Decimal)
└─ delivery_location (O)                    // Agreed delivery location (address or identifier)

Explanation:

• payment_due, currency, incoterm, buyer_identifier, supplier_identifier, and agreement_date are mandatory top-level attributes.
• payment_reference_event, contract_reference, transaction_amount, and delivery_location are optional attributes.
• The attestation is a flat object — no nested sub-objects are required for the mandatory attributes.

Attestation Classification:

This attestation type MAY be classified as:

• "EAA" when self-issued by the legal entity subject to the payment terms disclosure.

2.2 Mandatory attributes

2.2.1 PaymentTerms Attributes

2.3 Optional attributes

BuyerIdentifier Optional Attributes

SupplierIdentifier Optional Attributes

2.4 Conditional attributes

No conditional attributes are defined for this attestation type. All attributes are either mandatory or optional as specified above.

The following conditionality rules apply to identifier objects:

2.5 Mandatory Metadata

Note: Only the additional mandatory attributes are listed; the mandatory attributes defined by the protocol are not specified.

2.6 Optional Metadata

2.7 Conditional Metadata

No conditional metadata elements are defined for this attestation type.

2.8 Value Lists

2.8.1 Incoterm Codes

The incoterm attribute SHALL use one of the following standardized values as defined by Incoterms 2020 (International Chamber of Commerce):

2.8.2 Currency Codes

The currency attribute SHALL follow ISO 4217 alphabetic currency codes.

Note: Any valid ISO 4217 alphabetic currency code is permitted. The examples above are non-exhaustive.

2.8.3 Payment Reference Event Codes

The payment_reference_event attribute, when present, SHOULD use one of the following standardized values:

2.8.4 Identifier Type Reference

The following identifier types are supported within buyer_identifier and supplier_identifier objects:

2.9 Integrity Rules

The following integrity rules SHALL be enforced:

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 (also called mdoc) is out of scope for this Rulebook, as offline proximity presentation is not a current requirement for the Payment Terms attestation.

3.2 SD-JWT VC-based encoding

The Payment Terms attestation uses the SD-JWT VC format to allow for selective disclosure of payment term attributes.

Selective Disclosure: Top-level claims (payment_due, currency, incoterm, buyer_identifier, supplier_identifier, agreement_date, payment_reference_event, contract_reference, transaction_amount, delivery_location) SHALL be individually selectively disclosable, enabling a legal entity to disclose only the attributes requested by a Relying Party.

The . notation is used to indicate the nesting of attributes.

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

3.2.1 Attribute Encoding Table

Notes:

• MUST: The claim SHALL be selectively disclosable — the holder MAY choose to disclose or withhold this claim when presenting the credential to a Relying Party.
• MUST NOT: The claim SHALL NOT be selectively disclosable — it is always present in plain text in the JWT header/payload and cannot be withheld by the holder, as it is required for credential verification and trust establishment.
• iat, exp, and iss follow RFC 7519 standard JWT claim naming conventions.

3.2.2 Status Claim

For SD-JWT VC-compliant Ownership Attestations, the attestation MUST include a status claim if the technical validity period is greater than 24 hours. This claim enables Relying Parties to determine if a credential has been revoked via a status list mechanism.

The status claim SHALL be a JSON object with the following members:

Example:

{
  "status": {
 "type": "status-list",
 "status_list_credential": "https://issuer.example.com/status/paymentterms/2025",
 "status_list_index": 789,
 "status_purpose": "revocation"
  }
}

3.2.3 Example Payload

The following is a non-normative example of a Payment Terms SD-JWT VC payload:

{
  "vct": "eu.we-build.paymentterms.1",
  "iss": "https://issuer.example.com",
  "iat": 1736935200,
  "exp": 1768471200,
  "issuing_entity": "did:example:legal-entity-456",
  "issuing_country": "DE",
  "attestation_legal_category": "EAA",
  "schema_version": "1.0",
  "trust_anchor_url": "https://trust.webuildconsortium.eu/anchors/eidas-tl",

  "payment_due": "P30D",
  "currency": "EUR",
  "incoterm": "DAP",
  "buyer_identifier": {
      "euid": "CHE-102.909.703",
      "gln": "7601003000003",
  },
  "supplier_identifier": {
      "euid": "DEB8534.HRB14000",
      "lei": "529900F0LT5OP4SV6122",
      "gln": "4012345000016",
      "duns": "318280815",
      "eori": "DE811128135",
      "bpnl": "BPNL00000003CML1",
      "siren": "6710101601"
  },
  "agreement_date": "2025-01-10",
  "payment_reference_event": "invoice_date",
  "contract_reference": "PO-2025-00123",
  "transaction_amount": 250000.00,
  "delivery_location": "Hauptstraße 12, 10115 Berlin, Germany",

  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/paymentterms/2025",
    "status_list_index": 789,
    "status_purpose": "revocation"
  },

  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

Sample payloads are provided under ../data-schemas/sd-jwt/sample-data/payment-terms-sd-jwt-sample.json

3.3 W3C Verifiable Credentials Data Model-based encoding

4 Attestation usage

4.1. Issuance process

For EAA (Self-Issued / Standard Issuance):

• The issuer (i.e., the legal entity itself) issues the attestation based on the information and supporting documentation available at the time of issuance.

• The issuer is responsible for ensuring that the attested information remains accurate and must immediately revoke the attestation if any change occurs that affects the validity or accuracy of the underlying data.

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

4.2 Relying Party Obligations

When receiving and processing an attestation, the Relying Party SHALL perform the following verification obligations.

4.2.1 – 4.2.8 Base Verification Process

The Relying Party SHALL perform the base attestation verification process 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

4.2.9 Validate Integrity Rules

Validation of integrity and policy rules will be specified in a future version of this Rulebook.

5 Trust anchors

This chapter specifies the trust anchor mechanisms used by Relying Parties to establish trust in the issuer of an Electronic Attestation of Attributes (EAA) or a Qualified Electronic Attestation of Attributes (QEAA). The corresponding verification procedures are defined in Sections 4.2.2–4.2.4.

5.2 Electronic Attestations of Attributes (EAAs)

For EAAs, trust is established through a cryptographic chain anchored in the Electronic Business Wallet Owner Identity Document (EBWOID). The EBWOID SHALL be included in the header of every EAA. During EBWOID issuance, the EBWOID provider verifies that the public key contained in the EBWOID is owned by the Electronic Business Wallet (EBW) owner.

The Relying Party SHALL verify the EBWOID in accordance with the verification procedure defined in this Rulebook. Upon successful verification, the Relying Party obtains:

• assurance that the EBWOID was issued by an authorized provider and is not self-issued;
• the verified identity of the issuer, including its name and EUID (or another globally unique EBW owner identifier); and
• the public key authorized to verify the EAA signature.

Authorization of the issuer is subsequently determined in accordance with the Relying Party's internal policies. Such authorization MAY be based on locally maintained wallet configuration or on trusted jurisdiction- or domain-specific trust list services that identify issuers authorized for a particular type of EAA

6 Revocation

An attestation SHALL remain valid only while its underlying information is accurate, complete, and legally effective.

6.1 Revocation Mechanism

• Token Status List: The issuer must maintain an active IETF Token Status List (aligned with the Attestation Status List mechanism specified by the EU Commission).
• Credential Metadata: The metadata status_list must be populated in every issued CompanyInfo attestation, referencing the status list URI and the credential's specific index.

Authorized Authority: Only the authorized issuer (the self-issuing legal entity for EAA) may modify the status list entry.

6.2 Revocation Triggers & Business Rules

• EAA Trigger (Manual Obligation): The self-issuing legal entity is under strict obligation to immediately update or revoke its EAA if its available documents, financial thresholds, or ownership structures change.

Relying Party Action: A revoked or suspended attestation must be treated as invalid for credential-validity purposes by all RPs. The business interpretation is determined by the Relying Party's internal compliance policies.

7 References