XML (Extensible Markup Language)

XML (Extensible Markup Language) is a W3C (World Wide Web Consortium) standard markup language used as the foundational data format for EU procurement notices, specifically through the eForms specification established by Implementing Regulation (EU) 2019/1780. XML provides a structured, machine-readable, and self-describing representation of procurement information that enables automated processing, validation, and exchange of procurement data across all EU Member States. Every above-threshold procurement notice published on TED (Tenders Electronic Daily) is encoded in eForms XML, making the format central to the entire European procurement transparency infrastructure.

How It Works

XML is a general-purpose markup language that uses a hierarchical (tree-like) structure of elements, attributes, and text to represent structured data. In the context of EU procurement, XML serves as the "language" in which procurement notices are written, transmitted, validated, and published.

Core XML concepts in procurement context:

Elements. XML data is organized into elements, each representing a discrete piece of information. In eForms, each business term (BT) corresponds to one or more XML elements. Elements are enclosed in opening and closing tags and can be nested hierarchically:

<cac:ProcurementProject>
  <cbc:Name>IT Infrastructure Modernization</cbc:Name>
  <cbc:Description>Procurement of servers, storage, and networking equipment</cbc:Description>
  <cac:MainCommodityClassification>
    <cbc:ItemClassificationCode listName="cpv">48800000</cbc:ItemClassificationCode>
  </cac:MainCommodityClassification>
</cac:ProcurementProject>

Attributes. Elements can have attributes providing additional metadata. In eForms, attributes are used for currency codes, language tags, list identifiers, and other qualifying information:

<cbc:Amount currencyID="EUR">250000</cbc:Amount>
<cbc:Name languageID="en">Highway Maintenance Services</cbc:Name>

Namespaces. eForms XML uses XML namespaces to avoid naming conflicts and identify the vocabulary being used. Common prefixes include cbc: (Common Basic Components from the UBL standard), cac: (Common Aggregate Components), and efbc: / efac: (eForms-specific extensions).

Schemas (XSD). XML Schema Definition (XSD) files define the structure, data types, and constraints for valid eForms XML documents. The eForms SDK (Software Development Kit) published by the Publications Office includes XSD schemas for each eForms version, enabling validation of notices before submission to TED.

The eForms XML lifecycle:

Notice creation. A contracting authority (or its e-procurement platform) creates a procurement notice using a user interface. The platform generates an eForms-compliant XML document containing all the required business terms (BT codes) for the specific notice type and subtype.
Validation. Before submission, the XML document is validated against the eForms SDK schemas. Validation checks include: structural compliance (correct element hierarchy), data type validation (dates in correct format, numbers within valid ranges), mandatory field presence (all required BTs populated), and business rule compliance (logical consistency between related fields).
Transmission. The validated XML is transmitted to TED through an authorized eSender system. The transmission uses standardized APIs that accept eForms XML as the payload.
Publication processing. TED receives the XML, performs additional validation, generates multilingual versions (auto-translating titles and key fields), and publishes the notice on the TED platform.
Data consumption. Published notices are available through the TED API in XML format. Procurement intelligence platforms, data analysts, researchers, and other consumers retrieve the XML and process it to extract structured procurement data for analysis, monitoring, and reporting.

eForms SDK versions. The eForms specification evolves through SDK versions (e.g., SDK 1.0, 1.7, 1.10, 1.12). Each version may introduce new business terms, modify existing ones, or update validation rules. The TED system supports multiple SDK versions simultaneously during transition periods, ensuring backward compatibility. The SDK version is encoded in the XML document's metadata.

XML vs. other formats. While XML is the canonical format for eForms notices, the data is also made available in other formats:

JSON: The TED API provides notice data in JSON format for easier integration with web applications and modern data pipelines.
HTML: TED renders notices as human-readable HTML pages for the web portal.
CSV/Bulk download: Aggregated procurement data is available in tabular formats for statistical analysis.

However, XML remains the authoritative format — it is the format submitted by contracting authorities, validated by TED, and published as the official legal record.

Legal Framework

The W3C XML 1.0 Recommendation (first published in 1998, with the latest edition being the Fifth Edition of 2008) defines the XML standard. While not specific to procurement, it provides the technical foundation for all XML-based procurement data exchange.

Implementing Regulation (EU) 2019/1780 (the eForms Regulation) mandates the use of XML-based electronic forms for publishing procurement notices in the Official Journal (OJEU). The regulation specifies that notices shall be prepared and transmitted in a structured electronic format compatible with the standard forms defined in its annexes.

Commission Implementing Regulation (EU) 2022/2303 (amending the eForms Regulation) introduced refinements to the eForms XML schema and business rules, addressing issues identified during the initial implementation period.

The eForms SDK is published by the Publications Office of the European Union and provides the complete technical specification for eForms XML, including:

XSD schemas defining the XML structure
Business rules (Schematron rules) for logical validation
Code lists (countries, CPV codes, NUTS codes, notice types, legal bases)
Documentation mapping business terms to XML paths
Sample XML files for each notice type

Universal Business Language (UBL) 2.3 is the underlying data model on which eForms XML is based. UBL is an OASIS standard for business document exchange, and eForms extends UBL with procurement-specific elements and attributes. The use of UBL ensures interoperability with broader e-government and e-commerce standards.

Directive 2014/55/EU (e-Invoicing Directive) complements the procurement XML ecosystem by requiring the acceptance of electronic invoices in public procurement. While e-invoicing uses a different XML standard (EN 16931 / UBL Invoice), the broader XML-based data exchange framework spans the entire procurement lifecycle from notice publication (eForms XML) through contract execution to payment (e-Invoicing XML).

Practical Examples

Example 1: Contract Notice XML Structure. A contract notice for office furniture procurement is encoded in eForms XML. The XML contains elements for the notice identifier, publication date, contracting authority details (name, national ID, address), procedure type (BT-105 = "open"), contract subject (CPV 39130000), estimated value (BT-27), place of performance (NUTS code), submission deadline, and award criteria. The entire notice is approximately 5-15 KB of XML, structured according to the eForms SDK schema for contract notice subtypes.

Example 2: Automated Monitoring Pipeline. A procurement intelligence platform queries the TED API daily, retrieving all newly published contract notices in XML format. The platform parses each XML document, extracts key fields (CPV codes, NUTS codes, estimated values, deadlines, buyer names), stores the structured data in a search database, and matches each notice against subscriber alert profiles based on CPV, geography, and value criteria. The XML format enables this automated processing without human intervention.

Example 3: Data Quality Validation. A national e-procurement platform prepares a contract notice XML for a municipality. Before submission to TED, the platform validates the XML against the eForms SDK. The validation identifies two errors: BT-27 (estimated value) is missing (a mandatory field for this notice subtype), and the deadline date (BT-131) is in the past. The platform returns the errors to the user, who corrects the notice before resubmission. This validation process prevents the publication of incomplete or incorrect notices.

Key Considerations for Suppliers

You do not need to read XML directly. While procurement notices are encoded in XML, you will typically interact with them through user interfaces — the TED web portal, your national e-procurement platform, or a procurement intelligence tool. These platforms parse the XML and present the information in human-readable format. Understanding that XML exists behind the scenes helps you appreciate how procurement data flows through the system, but you do not need XML technical skills to participate in procurement.

Use structured data to your advantage. Because procurement notices are published in structured XML, the data is machine-processable. This means you can use procurement intelligence platforms to automatically monitor, filter, analyze, and compare opportunities across the entire EU. Set up automated alerts based on CPV codes, NUTS regions, and value ranges. Use the structured data for competitive analysis (who wins contracts, at what prices) and market sizing (total procurement volume in your sector and geography).

Understand eForms field coverage. The eForms XML schema defines hundreds of business terms, but not all fields are mandatory for all notice types. The level of detail available varies by notice type, Member State, and contracting authority. Some notices provide rich data (detailed lot descriptions, comprehensive award criteria, full buyer contact details); others provide minimal required information. When analyzing procurement data at scale, be aware of these variations in data completeness.

Leverage the TED API for systematic market intelligence. The TED API provides programmatic access to the full XML dataset. If your organization has technical capacity (or works with a technology partner), the API enables sophisticated analysis: trend identification across thousands of notices, price benchmarking across geographies, buyer behavior analysis, and opportunity scoring based on your specific criteria. The XML format ensures that all published data fields are accessible for analysis.

Monitor eForms SDK version changes. The eForms specification evolves with periodic SDK updates that may add new fields, modify validation rules, or change data structures. While these changes primarily affect e-procurement platform developers, they can also affect the data available to suppliers. New business terms may provide additional information (such as more detailed award criteria breakdowns or sustainability requirements) that was previously not structured in the notice data.

eForms — The EU procurement notice specification that uses XML as its data format.
Business Term — The individual data fields (BT codes) that populate the XML elements in eForms notices.
Notice — The procurement document that is encoded, transmitted, and published in XML format.
TED — The platform that receives, validates, and publishes XML procurement notices.
CPV — Classification codes encoded as XML elements within procurement notices.
NUTS — Geographic codes encoded as XML elements within procurement notices.

Frequently Asked Questions

Why does EU procurement use XML rather than a simpler format like JSON or CSV?

XML was chosen for EU procurement for several reasons rooted in the historical and technical requirements of the system. First, XML has native support for schemas (XSD) that enable rigorous validation of document structure and content — critical for legally binding procurement notices. Second, XML supports namespaces, allowing eForms to build on the established UBL (Universal Business Language) standard without naming conflicts. Third, XML was the dominant machine-readable format when the EU's e-procurement infrastructure was designed (early 2000s), and the eForms framework maintains continuity with this infrastructure. While JSON is increasingly used for data consumption (the TED API supports JSON output), XML remains the canonical submission and storage format due to its validation capabilities and standards compliance.

Do all EU countries submit notices in the same XML format?

Since the mandatory eForms transition in October 2023, all EU Member States are required to submit above-threshold notices in eForms XML format. However, there is some variation in practice: different countries may use different eForms SDK versions during transition periods (the TED system accepts multiple versions), and national e-procurement platforms may implement optional fields differently. Additionally, below-threshold notices published only on national platforms may use national XML schemas rather than eForms. For above-threshold procurement on TED, the eForms XML standard ensures a consistent, pan-European data format.

How can I access the raw XML data of procurement notices?

There are several ways to access procurement XML data. The TED website allows you to download individual notices in XML format (look for the XML download option on the notice detail page). The TED API (api.ted.europa.eu) provides programmatic access to search and retrieve notices in XML or JSON format. The TED bulk download service provides complete datasets of published notices for offline analysis. All access is free of charge — there are no subscription fees or API keys required for basic access. Procurement intelligence platforms parse this XML data and present it through user-friendly interfaces with alerting, analytics, and collaboration features.