Business Term (BT)

technicalAlso: BT Code, BT Field, eForms Fieldv1.0.0

Business Term (BT)

A Business Term (BT) is a standardized field identifier in the eForms specification that represents a specific piece of information within a European public procurement notice. Each BT carries a unique numeric code and a precise semantic definition, enabling consistent data extraction, validation, and exchange across all EU Member States. Business Terms form the foundational vocabulary that transforms free-text procurement notices into structured, machine-readable datasets.

How It Works

The Business Term system was introduced as part of the eForms regulation to replace the inconsistent data fields that existed under the legacy TED XML schema. For background on the eForms standard, see our guide on what are eForms. Under the old system, different Member States encoded equivalent procurement information in different ways, making cross-border data analysis difficult. Business Terms solve this problem by assigning a universal identifier to every discrete piece of information that a procurement notice can carry.

Each BT is defined in the eForms SDK (Software Development Kit), which specifies the field's data type, cardinality (whether it can appear once or multiple times), the notice subtypes in which it is mandatory or optional, and validation rules governing acceptable values. The SDK is versioned, with new releases adding, deprecating, or modifying Business Terms as the specification evolves.

BT codes follow a structured numbering convention. Core business terms use a three-digit format such as BT-27 for Estimated Value or BT-131 for Deadline Receipt Tenders. Extended business terms use a four-digit format, such as BT-1451 for Contract Conclusion Date. The specification also includes OPT-series codes for optional technical fields that support system interoperability but are not part of the legal notice content, and OPP-series codes for fields that were used in earlier versions but have since been deprecated.

When a contracting authority fills out a procurement notice using an eForms-compliant platform, they are effectively populating BT fields. The platform then serializes these fields into XML documents that conform to the eForms schema. Receiving systems can parse these XML documents and extract individual BT values with full confidence in their meaning, regardless of which Member State published the notice.

The cardinality rules attached to each BT determine how many times the field may appear in a given context. Some BTs are single-value (the notice has exactly one publication date), while others are repeatable (a lot may have multiple CPV codes). Some are mandatory for certain notice types and optional for others. For example, BT-27 (Estimated Value) is mandatory in contract notices but not required in prior information notices published solely for transparency.

Commission Implementing Regulation (EU) 2019/1780 establishes the eForms framework and, with it, the authoritative catalogue of Business Terms. This regulation was adopted under the empowerment granted by Article 73 of Directive 2014/24/EU, which allows the European Commission to establish standard forms for the publication of notices.

The regulation mandates that all EU Member States use eForms for above-threshold procurement notices published on TED (Tenders Electronic Daily). Since October 2023, the use of eForms has been mandatory, meaning that every above-threshold notice published in the EU must encode its data using the BT system. Member States may extend this requirement to below-threshold procurement at their discretion, and several countries -- including Germany and France -- have adopted eForms for a broader range of national notices.

The regulation is updated periodically through amendments that add new Business Terms, modify existing ones, or change their mandatory/optional status. Each amendment is accompanied by a new version of the eForms SDK, which national procurement platforms must implement within a defined transition period. This versioning mechanism ensures that the BT vocabulary can evolve to accommodate new policy requirements, such as green procurement indicators or social criteria, without breaking backward compatibility.

Practical Examples

Consider a public hospital publishing a contract notice for medical imaging equipment. The contracting authority fills in the notice form, and the underlying eForms platform encodes the data as BT fields. BT-05 records the notice type (contract notice). BT-27 captures the estimated total value of the procurement. BT-131 specifies the deadline by which tenders must be received. BT-26 identifies the main CPV code (in this case, likely 33110000 for imaging equipment), while BT-262 records any additional CPV codes. BT-500 captures the organization identifiers for the hospital itself and, eventually, for the winning supplier.

In a procurement divided into lots, each lot carries its own set of BT values. A city government procuring IT services across three lots would have BT-27 values at both the procedure level (total estimated value) and the lot level (BT-271, estimated value per lot). Each lot would also have its own CPV codes, submission deadlines, and award criteria weights.

A modification notice illustrates how BTs link notices together. When a contracting authority modifies an existing contract, BT-758 (Changed Notice Identifier) references the original contract award notice, creating a traceable chain from the initial award to each subsequent modification. This linkage is essential for contract lifecycle analysis and compliance monitoring.

Key Considerations for Suppliers

For economic operators responding to procurement opportunities, understanding Business Terms is valuable even though suppliers typically interact with BT data through user-friendly portal interfaces rather than raw XML. Awareness of key BTs helps suppliers interpret notice data more precisely when searching for opportunities across multiple EU markets.

Suppliers monitoring opportunities across borders should know that BT-05 (Notice Type) determines whether a publication is a prior information notice, a contract notice, or a contract award notice. BT-131 (Deadline Receipt Tenders) is the critical date by which all tenders must arrive. BT-27 and BT-271 provide estimated values at procedure and lot levels, helping suppliers gauge whether an opportunity matches their capacity. BT-539 (Award Criterion Type) indicates whether the award will be based on lowest price or the most economically advantageous tender, which affects bid strategy significantly.

Suppliers also benefit from understanding that the BT system enables powerful search and filtering. Modern procurement intelligence platforms use BT fields to offer structured searches by CPV code, geographic scope, value range, deadline, and award methodology. Suppliers who understand the underlying data model can craft more targeted searches and set up more precise alerts for relevant opportunities.

  • eForms - The specification that defines and governs all Business Terms
  • XML - The markup language format in which BT fields are serialized
  • Notice - The procurement document that contains BT data
  • CPV - Classification codes referenced by BT-26 and BT-262
  • TED - The publication platform where eForms notices appear

Frequently Asked Questions

How many Business Terms exist in the eForms specification?

The eForms specification defines over 300 Business Terms, covering every aspect of a procurement notice from basic identifiers and dates through to detailed award criteria, lot descriptions, and contract performance conditions. The exact number changes with each SDK version as new fields are added and legacy fields are deprecated. The full catalogue is maintained in the eForms SDK documentation published by the Publications Office of the European Union.

Can Member States add their own custom Business Terms?

No, Member States cannot create new BT codes. The BT catalogue is centrally maintained by the European Commission to ensure interoperability. However, Member States can make optional BTs mandatory at the national level, and they can use the existing OPT fields for national extensions. If a Member State identifies a data need not covered by existing BTs, the standard process is to request a new BT through the eForms governance procedure.

What happens when a mandatory BT field is missing from a notice?

When a mandatory BT field is absent, the notice fails schema validation and cannot be published on TED. The eForms validation service checks every notice against the SDK rules for the relevant notice subtype and SDK version. If validation fails, the notice is rejected and the contracting authority must correct the data before resubmission. This enforcement mechanism is a key reason why eForms data quality is significantly higher than under the previous TED XML format.


Want to monitor procurement opportunities? Start your free trial or subscribe to our newsletter for weekly insights.

liked this article?

get data-driven procurement insights delivered weekly.