On October 25, 2023, the European Union completed one of the most significant technical changes in procurement history. Every contracting authority publishing above-threshold notices was required to switch from the legacy TED XML format to a new standard called eForms. This was not a cosmetic change. It restructured how procurement data is created, transmitted, validated, and published across all 27 member states.
For suppliers and procurement technology companies, eForms created both challenges and opportunities. The data is richer, more consistent, and more machine-readable than anything that came before. But the transition also introduced complexity that the market is still absorbing.
This guide explains what eForms are, how they differ from the old system, what BT codes mean, and what the practical impact is for companies that track and respond to public tenders.
What are eForms?
eForms is the standardized format for publishing procurement notices in the Official Journal of the European Union (OJEU) via TED (Tenders Electronic Daily). It replaces the legacy TED XML schema that had been in use since the early 2000s.
The legal basis is Commission Implementing Regulation (EU) 2019/1780, which defines the standard forms for the publication of notices in the field of public procurement. The regulation was amended by (EU) 2022/2303 to finalize the technical specification.
At its core, eForms does three things:
- Standardizes data fields across all notice types using Business Terms (BT codes)
- Defines validation rules that ensure notices contain required information before publication
- Provides an SDK (Software Development Kit) that member states and vendors use to implement the standard
The result is a procurement data standard that is far more granular, consistent, and analytically useful than anything that existed before.
The problem eForms solved
The legacy TED XML system was built incrementally over two decades. It worked, but it had structural problems that made procurement data harder to use than it needed to be.
Inconsistent structure
The old system used approximately 40 fixed notice templates (Standard Forms 1 through 25, plus variations). Each template was a rigid XML structure with fields specific to that form type. This meant that the same concept — say, the contract value — could appear in different XML elements depending on which form template was used.
Limited data granularity
Many important procurement details could not be captured in structured fields. Contracting authorities resorted to putting critical information in free-text fields, making it impossible to extract systematically. Lot-level details, award criteria weightings, and environmental requirements were particularly affected.
National divergence
Member states had flexibility in how they mapped their national data to TED XML, leading to inconsistencies. A framework agreement notice from Germany might structure its data differently from an equivalent notice from France, even though both followed the same EU directives.
Poor machine readability
While technically XML (and therefore "structured"), the legacy format was designed primarily for human-readable publication. Extracting specific data points programmatically required custom parsers for each form type, with extensive exception handling.
How eForms work: the BT code system
The fundamental innovation of eForms is the Business Term (BT) system. Instead of fixed form templates, eForms defines a vocabulary of standardized data elements, each identified by a unique BT code.
Understanding BT codes
Every piece of information in an eForms notice maps to a BT code. Here are some key examples:
| BT Code | Name | Description |
|---|---|---|
| BT-21 | Title | Official title of the procurement |
| BT-23 | Main Nature | Supplies, services, or works |
| BT-27 | Estimated Value | Estimated contract value |
| BT-36 | Duration Period | Contract duration |
| BT-65 | Subcontracting Obligation | Whether subcontracting is required |
| BT-77 | Financial Terms | Payment terms and financial arrangements |
| BT-106 | Procedure Type | Open, restricted, negotiated, etc. |
| BT-195 | Award Criterion Name | Name of each evaluation criterion |
| BT-541 | Award Criterion Weight | Numerical weight of each criterion |
| BT-771 | Tender Submission Deadline | Deadline for bid submission |
| BT-142 | Winner Chosen | Whether an award decision has been made |
The full specification contains over 300 BT codes, covering:
- Notice metadata (type, language, publication date)
- Procedure information (type, legal basis, joint procurement)
- Organization details (buyer, service provider, reviewer)
- Object of the contract (description, CPV codes, location, value)
- Lot-level details (individual lot descriptions, criteria, conditions)
- Award information (winner, value, criteria scores)
- Regulatory compliance (environmental, social, innovation criteria)
Notice sub-types replace form templates
Instead of 40+ rigid form templates, eForms uses notice sub-types built from combinations of BT codes. Each sub-type defines which BT codes are mandatory, optional, or forbidden. This modular approach means:
- New data requirements can be added by making existing BT codes mandatory
- National extensions can add BT codes without breaking the core standard
- Analytics tools can query across all notice types using consistent field names
Example: lot-level granularity
Under the old system, a multi-lot procurement might describe all lots in a single text block. Under eForms, each lot has its own structured data:
- BT-21 (Title) at lot level — each lot has its own title
- BT-27 (Estimated Value) at lot level — individual lot values
- BT-5141 (CPV code) at lot level — specific classification per lot
- BT-195/541 (Award Criteria) at lot level — different criteria per lot
This lot-level granularity is transformative for suppliers who bid on specific lots within large procurements.
The eForms SDK
The eForms standard is implemented through an SDK (Software Development Kit) maintained by the EU Publications Office. The SDK is the technical package that e-procurement platforms, eSender systems, and TED itself use to create, validate, and process notices.
The SDK includes:
- XML schemas — The formal XSD definitions for eForms notice structures
- Schematron rules — Business validation rules that go beyond basic XML validation
- Code lists — Standardized value sets (procedure types, CPV codes, country codes, etc.)
- View templates — Rendering instructions for human-readable notice display
- Documentation — Field-by-field descriptions and usage guidance
SDK versioning
The SDK follows a versioning scheme (e.g., SDK 1.7, SDK 1.10, SDK 1.12) with regular updates. This is important because:
- TED accepts notices created against multiple SDK versions simultaneously
- National systems must update their implementations when new SDK versions are released
- Data consumers must handle notices from different SDK versions in their parsers
- New BT codes may be introduced in new SDK versions
As of early 2026, the active SDK versions in production are 1.10 through 1.12, with earlier versions being gradually deprecated.
The adoption timeline
The eForms transition was not instantaneous. It followed a structured timeline with significant milestones:
Phase 1: Voluntary adoption (November 2022 - October 2023)
Member states could voluntarily accept eForms notices from November 14, 2022. During this period, both legacy TED XML and eForms were accepted. Early adopters like the Netherlands, Austria, and the Nordic countries began transitioning their national systems.
Phase 2: Mandatory adoption (October 25, 2023)
From this date, all above-threshold notices submitted to TED were required to use the eForms format. The legacy TED XML system stopped accepting new submissions. This was the hard cutover.
Phase 3: Stabilization (2024-2025)
The first year after mandatory adoption saw significant practical challenges:
- Some national eSender systems experienced validation issues
- Data quality varied as contracting authorities learned the new system
- Historical data queries needed to bridge legacy and eForms formats
- SDK updates required ongoing platform adjustments
Current state (2026)
By early 2026, the eForms ecosystem has largely stabilized. The major challenges remaining are:
- Below-threshold divergence — National platforms below EU thresholds may still use their own formats
- Data quality improvement — Optional BT codes are unevenly populated across member states
- Cross-format analytics — Historical analysis still requires bridging pre-2023 legacy data with post-2023 eForms data
The legal framework
eForms is mandated through a layered legal structure:
- EU Procurement Directives (2014/24/EU, 2014/25/EU, 2014/23/EU) — Establish the requirement to publish notices and define what information must be included
- Implementing Regulation (EU) 2019/1780 — Defines the eForms standard as the mandatory format
- Amending Regulation (EU) 2022/2303 — Finalizes technical specifications and the mandatory adoption date
- SDK releases — Technical implementation of the legal requirements, maintained by the Publications Office
Member states are required to ensure their national e-procurement systems can produce valid eForms notices for above-threshold procurement. Many have extended eForms adoption to below-threshold procurement voluntarily, recognizing the data quality benefits.
When you will encounter eForms as a supplier
Reading notices on TED
Every notice you find on TED since October 2023 is an eForms notice. The human-readable presentation looks similar to the old format, but the underlying data is structured according to BT codes. This means:
- Lot-level information is clearer and more consistently presented
- Award criteria are more likely to include specific weightings
- Environmental and social criteria have dedicated structured fields
- Buyer and supplier identification is more standardized
Using procurement monitoring tools
The biggest impact of eForms for suppliers is indirect — through the tools and platforms they use to find opportunities. Because eForms data is more granular and consistent, monitoring platforms like Duke can offer:
- More precise filtering (by specific BT code values)
- Better lot-level matching
- More reliable value and deadline extraction
- Improved cross-country comparisons
Analyzing market data
If you analyze procurement data for business intelligence — spending patterns, competitor tracking, buyer behavior — eForms dramatically improves what is possible. The structured lot-level data, standardized organization identifiers, and consistent classification make analytical queries more reliable.
Practical implications for suppliers
Better data means better decisions
The increased granularity of eForms data translates directly into better market intelligence. When award criteria are captured in structured BT codes with explicit weightings, you can analyze what buyers actually prioritize — not just what they claim in policy documents.
Cross-border comparisons become feasible
Before eForms, comparing procurement practices between Germany and France required reconciling fundamentally different data structures. With eForms, the same BT codes apply regardless of the contracting authority's country, making cross-border analysis practical for the first time.
Historical discontinuity
The flip side is that eForms created a data discontinuity. Pre-October 2023 notices use a completely different schema. Any trend analysis spanning the transition requires careful handling of both formats. This is a technical challenge that procurement analytics platforms must solve for their users.
National variation persists
eForms standardizes the TED publication format, but it does not standardize national procurement procedures, document templates, or submission requirements. A German contracting authority and a French one both publish eForms notices to TED, but the underlying procurement process, national legal requirements, and tender documentation format remain different.
Common misconceptions
"eForms only changed the technical format." eForms changed what data is collected, not just how it is formatted. New mandatory fields mean contracting authorities now disclose information they previously could omit, including lot-level values, environmental criteria, and subcontracting requirements.
"All procurement data is now standardized across Europe." eForms standardizes the TED publication layer. National platforms, below-threshold procurement, and supplementary documentation remain diverse. eForms is a major step toward standardization, but it is not the finish line.
"The transition is complete." While mandatory adoption is in effect, the ecosystem is still maturing. SDK versions continue to evolve, data quality varies by country and contracting authority, and many analytics tools are still catching up to the full richness of eForms data.
"Suppliers need to understand BT codes." Suppliers interact with the human-readable presentation of notices, not the underlying XML. BT codes matter for platform developers, data analysts, and policy makers. For a supplier reading a notice on TED, the experience is largely unchanged — just better structured.
How Duke helps
The eForms transition created a significant data engineering challenge. Processing notices from before and after October 2023 requires maintaining parsers for two fundamentally different schemas. Cross-referencing eForms notices with data from national platforms — which may use different formats entirely — adds further complexity.
Duke handles this complexity behind the scenes. The platform normalizes data from TED eForms, legacy TED XML archives, and national platforms across Europe into a unified data model. For suppliers, this means:
- Seamless historical analysis — Query procurement data across the format transition without worrying about schema differences
- Granular lot-level filtering — Leverage the new lot-level data eForms provides
- Cross-platform matching — Connect TED notices with corresponding national platform listings
- Structured award intelligence — Extract competitive insights from the richer eForms award data
The eForms standard made EU procurement data significantly more useful. Duke makes it accessible without requiring you to become a BT code expert.
Conclusion
eForms represents the most important structural change to EU procurement data in two decades. By replacing 40 rigid form templates with a modular, BT-code-based standard, it created a foundation for better transparency, better analytics, and better market access for suppliers across Europe.
The practical impact is still unfolding. Data quality is improving as contracting authorities become more comfortable with the new system. Analytics capabilities are expanding as platforms fully exploit the richer data. And the standard itself continues to evolve through regular SDK updates.
For suppliers, the key takeaway is that EU procurement data is now fundamentally better. More structured, more consistent, more granular. Whether you access it directly through TED or through a procurement intelligence platform, the opportunities for data-driven decision making in public procurement have never been greater.
Related resources
- What Is OJEU -- The publication system eForms powers
- What Are CPV Codes -- The classification system eForms standardizes
- Complete Guide to Procurement Notice Types -- All the notices eForms defines
- Digital Transformation of European Procurement -- The broader tech evolution
- EU Procurement Transparency by Country -- How eForms affects data quality
Duke normalizes eForms, legacy TED XML, and national platform data into a unified model. Explore EU procurement data or learn about CPV code classification.