eForms FAQ

The following official sources provide information about eForms:

Legal and policy background

General information

Technical documentation (developers and eSenders)

Support and feedback

eForms notices may be linked to each other in different ways, depending on the notice type and the procedural context in which they are used.

Linking notices within the same procedure

Most eForms notices that belong to the same procurement procedure (for example Competition, Result, Change, or Modification notices) are linked using the Procedure Identifier (UUID version 4).

All notices that share the same Procedure Identifier are considered part of the same procedure, regardless of which system or eSender submitted them. The Procedure Identifier identifies the procedure itself and is not linked to a specific eSender. Notices belonging to the same procedure may therefore be submitted by different eSenders or platforms.

There are no practical limitations on the use of UUID version 4. It was chosen because the probability of two identical identifiers being generated independently is negligible.

Planning notices

Planning notices do not contain a Procedure Identifier as they may later lead to more than one procedure.

When a Planning notice is used to inform or prepare a later procedure, the link must be created by explicitly referencing the Planning notice using the appropriate planning reference fields, such as:

Cases where a specific previous notice must be referenced

In some situations, an eForms notice must explicitly reference a specific previous notice rather than relying only on the Procedure Identifier.

This applies in particular to the following cases:

If none of the dedicated reference fields apply, a previous notice may be referenced using:

These references ensure that the correct notice, contract, lot, or planning context is unambiguously identified.

Linking to legacy TED XML notices

Legacy TED XML notices do not contain a Procedure Identifier.

When an eForms notice needs to reference a legacy TED XML notice, the reference must therefore be established using the appropriate explicit reference field and the OJ S Notice Publication ID (format: XXXXXX-YYYY).

The generic Previous Notice (OPP-090) field should be used only when none of the more specific reference fields apply.

Publication requirement

Any referenced notice – whether an eForms notice or a legacy TED XML notice – must already have been published.

eForms do not use separate correction/corrigenda forms. Corrections and updates are handled through Change notices, which apply to both eForms notices and procedures that started with legacy TED XML notices.

Correcting notices originally published in TED XML

When a procedure was started using legacy TED XML forms, subsequent notices must be submitted as eForms.

In such cases:

What is a Change notice in eForms?

A Change notice is a reproduction of its parent notice that includes a dedicated Change section (BG-9) describing the modifications made.

Key principles:

Changes are described using:

Both the original notice and the Change notice are published on TED.

Important operational rules and limitations

The following rules are a frequent source of confusion and must be observed carefully:

This exception is acceptable only if the overall scope of the procedure remains coherent and is not significantly altered.

A Contract Modification Notice must always represent the consolidated state of the modified contract(s). It is not incremental: all applicable modifications to the contract must be reflected in the notice being submitted.

Key rules to observe:

The Contract Modification section is repeatable, and multiple contracts may be modified in a single notice, provided they all originate from the same previous notice. This is particularly relevant for lots with multiple winners, where a modification affects all associated contracts.

When contracts are modified, all updates for the modified contract(s) must be included in the same notice. Concurrent Contract Modification Notices are not allowed.

Examples of Contract Modification Notices can be found in the eForms SDK (files starting with can-modif…).

In addition to the standard eForms established by Implementing Regulation (EU) 2019/1780, other notice types exist within the Publications Office systems. These fall into two categories.

Voluntary extended forms (E1–E5)

E1, E2, E3, E4 and E5 refer to optional notice types included in the “Extended Annex” to Regulation 2019/1780 available at:
https://ec.europa.eu/docsroom/documents/43488

They were implemented through the second amendment to the eForms Implementing Regulation and introduced in SDK release 1.13.

These voluntary forms extend the standard notice set and correspond to:

Member States have been able to publish below-threshold notices via eForms since November 2022, provided they comply with the rules applicable to their equivalent above-threshold forms. National authorities may require additional fields for domestic publication; these fall outside the scope of eForms. Other legal bases may use eForms to publish notices on TED.

Other non-eForms regulatory notices

Five additional notice types exist in OP systems but are not part of the eForms Implementing Regulation.

They implement separate EU legal frameworks:

These forms coexist operationally with eForms but follow their respective legal bases.

The eForms Regulation (Annex 2) specifies that NUTS3 codes must be used for:

where such codes exist.

If a country does not have NUTS3 subdivisions, these fields are not required.

In practice:

Country identification is ensured through:

Where the country itself represents the geographical scope, subdivision codes are not required.

National tailoring requirements fall outside the remit of the Publications Office.

Both eNotices2 and the TED API validate notices exclusively against:

They do not enforce national or regional publication requirements.

For example:

The same principle applies to notices submitted via:

Ensuring compliance with national tailoring rules remains the responsibility of notice authors and eSenders.

The technical implementation of eForms is governed through the eForms Software Development Kit (SDK), which defines schemas, validation rules, code lists, and supporting artefacts.

The SDK follows a structured versioning approach designed to clearly distinguish:

Versioning ensures that implementers can anticipate compatibility impacts and plan system updates accordingly.

Further details on versioning practices and release management are available in the SDK developer documentation.

eForms notices are displayed in a standardised format on the TED website and in eNotices2.

Notices can be previewed before submission using TED Viewer, which is available:

For technical implementations, the view templates available in the eForms SDK define the rendering logic used to generate HTML and PDF visualisations.

A sample viewer application is also available in the SDK repository to demonstrate how eForms notices can be visualised, though it is not production-ready.

All procurement notices published on TED, including eForms notices, remain publicly available on the TED website for 10 years from the date of publication.

No. The Publications Office does not provide XSL stylesheets for rendering eForms notices.

Instead, the technical rendering logic is defined through the view templates included in the eForms SDK. These templates describe how notices are visualised in HTML and PDF formats.

Users who need to render notices can either:

Yes. Sample XML notices are available in the eForms SDK repository.

These examples illustrate how eForms notices are structured and are aligned with the SDK schemas, validation rules, and documentation.

They are provided for technical reference and testing purposes and do not correspond to specific published notice renderings.

Technical documentation for eForms is published through the eForms Software Development Kit (SDK), available on GitHub.

The SDK provides all artefacts required to implement, generate, and validate eForms notices, including schemas, validation rules, documentation, examples, and supporting resources. All components are versioned together under a single SDK version to ensure consistency between schema, rules, and documentation.

The SDK is designed to support developers building applications that create, validate, or process eForms notices for submission via eNotices2 or the TED API. See also Creating eForms applications.

More information on SDK structure and usage is available in the eForms Developer Guide and related documentation.

The eForms SDK follows a versioned release model. Multiple SDK versions may remain active simultaneously, provided they are still supported by the applicable legal and business framework.

While the Publications Office aims to minimise breaking changes, some versions may be deprecated following transition periods, particularly where legal requirements mandate updates.

The lifespan of the various SDK versions is documented on the Active SDK versions page; however, eSenders should always consult the information provided by the TED API.

See also the Developer Operations API.

Business Terms (BTs) are implemented in the eForms XML schemas through structured field definitions provided in the eForms Software Development Kit (SDK).

While many Business Terms map directly to individual XML elements, this is not always a one-to-one relationship. Some fields are structured, repeated, or grouped depending on the business context defined in the regulation and implemented in the schema.

The authoritative mapping between Business Terms and their XML representation is provided through the SDK artefacts, including:

In particular, the fields.json file provides a machine-readable representation of field metadata.

This includes:

This metadata format is a custom implementation designed to support eForms systems (including eNotices2) and external developer applications. It does not aim to establish a separate standard but to provide a stable, consumable structure for technical integration.

For example, while the eForms Implementing Regulation does not define maximum length constraints for textual fields, such limits are included in the metadata to support system usability and publication requirements. Procurement notices are not intended to replace full procurement documentation, and excessively long text fields are therefore constrained at system level.

All schemas, documentation, and metadata artefacts are available in the eForms SDK repository.

No. National tailoring is not implemented within the eForms SDK itself.

The SDK provides the common European data model, schemas, and validation rules required by the eForms Implementing Regulation. Any additional national requirements – such as mandatory fields, validation constraints, or publication rules defined at Member State level – must be implemented locally within the user’s system or application.

Developers integrating the SDK should therefore ensure that national customisations are applied within their own solutions where required.

The SDK is updated regularly. Developers may use repository notification features (for example, the “watch” function on GitHub) to stay informed about new releases and changes.

All TED API services, endpoints, authentication methods, and integration guidance are documented in the TED API documentation portal.

This includes:

There is no qualification procedure for eForms.

Any organisation with:

can submit notices via the TED API, provided they comply with the Terms of Service that additionally apply to TED eSenders.

Two environments are available:

Notices can be validated in advance using the Central Validation Service (CVS) via the Validation API.

See also:

Authentication to TED APIs is handled via API keys issued through the TED Developer Portal.

API keys:

Full guidance on generation, pairing, renewal, and management is available in the API key management documentation.

The TED Developer Portal serves as the central hub for TED developer services. It provides access to API products, credentials management, and developer-related configurations.

One of its core components is the Developer Profile, which eSenders must complete in both the Preview and Production environments before generating API keys.

The Developer Profile allows eSenders to:

As part of onboarding, the Developer Profile identifier should also be used as the identifier of the eSender organisation in the XML notices submitted via the TED API.

eSenders are advised to use a functional or shared email address rather than a personal one, particularly in the Production environment. It is recommended to maintain a single organisational account in Production, while allowing separate developer or tester accounts in Preview.

The Developer Portal is also used for operational communications. Human-generated messages – such as announcements about downtimes, events, or service updates – are sent to:

To ensure receipt of these communications, eSenders must keep their contact information up to date. The Publications Office does not manually maintain distribution lists outside the Developer Portal.

Making a Developer Profile publicly visible is optional. Where consent is provided, public profile information is used to generate a public catalogue of eSenders using eForms services.

There is currently no fixed functional limit on the number of lots, organisations, or overall notice size that can be submitted via the TED API.

However, requests to TED API services are subject to processing time constraints. The primary operational limitation is the request timeout.

The current timeout is 3 minutes per request. This applies to:

Factors affecting processing time

The time required to validate and submit a notice depends on multiple factors, including:

Performance improvements

Processing performance is continuously improved through:

Validation of large notices has improved significantly in later SDK versions, particularly from versions 1.10 and 1.13 onward.

For large notices, using a more recent SDK version is strongly recommended.

Practical recommendation

For very large Result notices, splitting content into multiple notices is recommended. This:

Yes. The Publications Office provides a Conversion API that transforms published TED XML notices into partial eForms drafts.

Because eForms contain more structured information than legacy TED XML notices, converted drafts must be completed, validated, and submitted before publication.

The converter supports major legacy notice types such as PIN, CN, and CAN. For notice types that the converter does not cover, the information from the previous TED schema form will need to be entered again in the eForm for procedures that span the transition period. If a field in a TED XML notice doesn’t exist in eForms, it’s only possible to use the free text of Additional Information field (BT-300).

The XSLT code for the TED XML to eForms Converter (TEDXDC) is published on GitHub.

The service is available in Preview and Production environments.

No. Notices submitted via the Publication API must be complete and valid.

eSenders should manage the notice lifecycle exclusively through the API.

Notice statuses can be queried via the Publication API.

For the authoritative description of lifecycle stages, status transitions, and operational timing, see:

Notice lifecycle (Publication API documentation).

This section explains:

Additional operational recommendations are provided in Tips for eSenders.

When submitting notices via the Publication API, eSenders must provide metadata including:

These are used to notify the buyer about publication outcomes and validation results via automated notifications sent by eNotices2 and include the eSender’s main email address as a CC.

eSenders should rely primarily on API status queries for system tracking. Notification emails are primarily sent to the Notice Author email address provided in the notice metadata. eSenders must therefore ensure that the buyer’s contact details are correctly provided so that notifications are received.

Yes. Using BT-738 Notice Publication Date Preferred, the sender may request a preferred publication date.

When a preferred date is provided:

For example, a notice submitted on Thursday with a preferred publication date on Sunday will be published on Monday (assuming it’s not a holiday).

The preferred publication date may be set up to 60 days in the future.

If no preferred publication date is specified, the notice is published at the earliest possible issue of the OJ S after successful submission and validation.

This field can allow buyers to coordinate national and EU-level publication timing or meet other procedural needs.

Grouping of lots is optional. Some Member States have chosen not to implement this feature of eForms.

It allows buyers to handle certain lots together at competition stage, for example by:

At result stage, grouping does not change the legal structure of the award. Each lot remains independent:

Every notice must contain at least one lot.

If a procedure contains only one lot, that lot is considered a technical lot and must still have a lot identifier using the LOT-XXXX pattern.

If a procedure contains multiple real lots:

To ensure traceability across notices or between procedure stages, use your own lot identifiers in:

BT-22 Internal Identifier

rather than relying on the technical lot identifier.

The same principle applies to Parts in planning notices.

OPT and OPP fields are technical fields introduced in the eForms schema implementation.

They are not Business Terms (BT) defined in the eForms Regulation.

These fields support technical implementation and internal processing and may not have a direct business meaning in the regulation.

There is no general one-to-one mapping between OPT/OPP fields and Business Terms (BT) or Business Groups (BG). Where relevant, their usage is documented in the schema and SDK documentation.

In eForms, each organisation included in a notice is defined once and assigned a technical identifier following the pattern ORG-XXXX (e.g. ORG-0001).

An organisation may have one or more contact points (“TouchPoints”), each assigned an identifier following the pattern TPO-XXXX.

These identifiers are used internally within the notice to reference organisations and their contact points in different roles (e.g. buyer, review body, information provider). The references are made using dedicated technical fields such as OPT-300 and OPT-301.

The numbering does not need to be sequential, but each identifier must be unique within the notice.

For structural and implementation details, see the Parties section of the eForms schema documentation: Parties.

Joint tendering (including consortia) is modelled using the Tendering Party structure.

A Tendering Party may consist of one or more individual tenderers acting jointly. The notice identifies the Tendering Party, and the participating organisations are listed within it.

See: Direct Award Pre-announcement, Competition Results, Contract Completion.

“Multilingual text” means that a field exists in different languages within the same notice.

When a notice is published in more than one official EU language, textual fields that support multilingual content must be provided in each selected language.

For BT-500 (Organisation Name), multilingual capability depends on context:

BG-8 defines how certain data in eForms can be temporarily withheld from publication.

When a field is marked as “Not Immediately Published,” its structure remains in the XML, but the actual value is masked in TED’s public outputs:

The relevant business terms are:

If a date is given in BT-198, the Publications Office will automatically republish the notice once that date is reached, revealing the actual data. If no date is provided, the information remains unpublished permanently.

Each republication keeps the same Notice ID but receives a new Publication ID. The Unpublished Accessibility Date must be between 2 days and 10 years after the Dispatch Date (BT-05).

Example: If the framework value (BT-118) is unpublished, it will appear as “unpublished” on TED until the date in BT-198 is reached, after which the notice is republished with the value visible.

A notice may be published in one or more official EU languages.

If more than one language is selected:

Due to technical constraints, one language is designated as the primary NoticeLanguageCode in the XML, while additional languages are declared separately. This distinction has no legal implication.

See: eForms Schema Usage.

BT-125 and BT-1251 are used when a procedure refers to a prior PIN-only (Planning) notice.

A Planning notice may contain one or more “Parts”.

These Parts may later:

BT-125 identifies the previous Planning notice.

BT-1251 identifies the specific Part within that notice that led to the Lot or procedure.

See: eForms Schema Usage.

From SDK 1.14 onwards, BT-634 must only be used in Result notices.

It indicates that a procedure or lot is being relaunched after cancellation or non-award.

It must not be used in Competition notices.

This ensures clear statistical reporting while keeping competition notices focused on active procedures.

For a LotResult marked as “not yet awarded”, the following fields are mandatory:

These fields ensure that the status of the lot is correctly reported even when no award has yet been made.

Business Rules are business-driven rules used to ensure the quality, consistency and legal compliance of the information reported in a procurement notice.

They define or constrain the existence of business information in a notice, for example:

Business Rules have their origin in:

They may also reflect logical consistency requirements derived from those legal bases.

The technical validation rules (including Schematron rules and example XML files) are published as part of the eForms Software Development Kit (SDK) on GitHub:

eForms Software Development Kit (SDK)

For background on the legal framework:

The Extended Annex spreadsheet was published to provide additional technical clarification alongside Table 2 of the Annex to the eForms Implementing Regulation: DocsRoom - European Commission.

As indicated in the spreadsheet itself, it is identical to Table 2 of the Regulation, with certain additional implementation details that are useful for technical purposes.

In particular, the Extended Annex:

The Extended Annex is provided for information and implementation support. The legally binding text remains the eForms Implementing Regulation.

Yes.

All notices submitted via the API or through eNotices2 are validated by the Central Validation Service (CVS).

For API submissions, the validation report includes a text element containing the error or warning message. This message is returned in the language specified in the API request.

For all submissions, an automated notification is also sent via eNotices2 indicating which validation rules were triggered. For API submissions, eSenders should ensure that:

Translations of validation messages are maintained as part of the eForms SDK.

The Extended Annex to the eForms Implementing Regulation provides a legal overview of Business Terms and their expected use.

Technical validation and implementation logic, however, is defined in the eForms SDK. The SDK encodes:

The fields.json file is a technical field metadata repository used to assemble forms and interpret field behaviour in practice. It reflects how fields and business terms are implemented in real notices, including context-specific logic that may not be explicit in the Regulation.

Because the legal Annex expresses rules at a high level, and the SDK operationalises those rules for validation and implementation, some differences in representation or technical logic may appear between the Annex and the SDK artefacts.

Where differences appear:

Some XML elements are technically defined as mandatory inside their parent structure.

However, if the parent structure itself is optional, then the field is only required when that structure is used.

In other words:

The eForms XML schema defines the structural requirements of a notice (for example, element structure and data types).

Schematron files are used to check the validity of notices in accordance with the eForms Regulation. All validation rules and constraints are implemented in Schematron as part of the eForms SDK.

These Schematron rules are used by the Central Validation Service (CVS) to validate notices before publication on TED.

The Schematron files are available in the official eForms SDK repository:

Schematron files in the eForms SDK

For each version of the SDK, the business rules are available to download as CSV files at Business rules.

The validation rules for eForms are provided in technical form as Schematron files within the eForms SDK.

The CSV files also contain the validation rules using the eForms expression language (EFX) as well as the rule texts, which may make them easier to understand than the Schematron rules.

There is no formal entity-relationship diagram of the eForms domain, but eForms notices are modelled in the eProcurement ontology.

To explore the technical artefacts of the SDK – including Schematron files – users may use the eForms SDK Explorer, which provides a structured interface for browsing and comparing SDK components across versions.

Yes.

If mandatory fields are not completed, or if required code values are not provided, the notice will fail validation and cannot be submitted for publication.

Validation is performed automatically by the Central Validation Service (CVS), which applies the XML schema and Schematron rules defined in the eForms SDK.

In addition to technical validation, certain notices may trigger a warning. In such cases, the notice may be subject to manual review by the Publications Office before publication.

Only notices that successfully pass validation and any required review are published on TED.

See: eForms Metadata Reference.

Yes.

Notices submitted for publication on TED must conform technically to the eForms XML schema, including the defined element structure, XPaths and field identifiers. Any notice that does not conform to the schema will fail validation.

However, how notices are displayed at national level is under the responsibility of the national authorities. National systems may use national terminology or presentation formats, even if the corresponding notice published on TED follows the EU terminology defined in eForms.

Technical conformity to the eForms schema is required for publication on TED; presentation at national level may differ.

Yes.

Regarding dispatch dates (also referred to in the Directives as “transmitted”, “sent” or “dispatched”), two Business Terms are relevant:

The dispatch date must always reflect the real situation. It cannot be artificially backdated or future-dated.

The Central Validation Service (CVS) dynamically checks the value of BT-05 (and BT-803, if provided) against the actual reception date and time of the notice. Inconsistent dispatch dates (for example, dates that do not correspond to the actual transmission time) may lead to validation failure.

The dispatch date is a legally relevant element under the Procurement Directives and must be accurate.

The Notice Dispatch Date (or the eSender Notice Dispatch Date if provided) must not be more than 1 day earlier than the date of submission. This limitation ensures that the Publications Office has enough time to publish the notice in the OJ S within 5 calendar days after dispatch by the buyer.

Yes.

Regular expression patterns are used in validation to check the format of certain fields. Many of these patterns apply to identifiers, such as:

There are also validation patterns for fields such as amounts, email addresses, URLs and telephone/fax numbers.

Postal codes are not validated using a fixed regular expression pattern, as formats vary across countries and may evolve over time.

The regular expression patterns used for validation are defined in the SDK metadata (e.g. in the fields.json file under the relevant regex or pattern definitions).

The authoritative source for eForms codelists for implementation purposes is the eForms SDK.

The codelists available in the codelists folder of the SDK repository should be used when developing eForms applications.

Some codelists are also published on the EU Vocabularies website. However:

For implementation, developers should rely on the versioned codelists included in the eForms SDK.

eForms codelists in the SDK are provided in the OASIS Genericode format (using the .gc file extension).

The files contain the coded values and their translations in the 24 official EU languages. For convenience, translations are also available in the SDK translation files.

See: Codelists in eForms.

Some eForms Business Terms use predefined coded values drawn from EU Vocabularies.

EU Vocabularies are published and updated according to a standard release schedule, which is available at:

EU Vocabularies – Releases and planning

However, for eForms implementation purposes, developers should always rely on the versioned codelists included in the relevant release of the eForms SDK.

Only concepts marked with the EFORMS use context in the EU Vocabularies datasets are applicable for eForms.

The eForms SDK provides the authoritative codelists to be used when creating and validating notices.

eForms includes Business Groups related to ESPD requests (e.g. BG-701 and BG-702).

While certain information may be aligned between eForms notices and ESPD processes, eForms does not replace the ESPD. The ESPD remains a separate instrument under the Procurement Directives.

For more information, please see section 4.1.2.1 of the eForms Policy Implementation Handbook.