Publications Office of the EU
Minutes - TED eForms
DisplayCustomHeader
MyPortal
Nyelvválasztó
magyar
BasketSummary
Menü megjelenítése
Minutes - TED eSender workshop Q2 2026

 

Q&A summary of the TED eSender workshop (18 June 2026)  

 

These consolidated questions and answers have been reviewed and may have been regrouped or modified to provide a more cohesive and complete response. Some answers might no longer be accurate, as the Publications Office (OP) has updated its approach based on feedback.    

The presentation slides as well as the recording of the live session are available in the agenda section.   

  

Questions from the participants:   

  • Roadmap – Is the SDK 2.0 release in 2026 still realistic? 

Answer: SDK 2.0 is still expected in 2026. The scope has grown compared with the initial objective. 

Additional work is now needed for EFX 2, client-side validation, stricter type checking, ontology alignment and the need to support two major SDK versions in parallel. However, most of the work is already there and the 2026 roadmap is still considered realistic. 

 

  • SDK 1.15 was previously presented as the final SDK 1.x release before SDK 2.0. Why is there SDK 1.16?  

Answer: SDK 1.15 was originally expected to be the final SDK 1.x release before SDK 2.0. However, issues were identified that needed to be addressed without waiting for SDK 2.0. 

SDK 1.16 is now planned as the final SDK 1.x release. It will also include the redesigned undisclosed fields, as this change can be delivered in SDK 1.x without being a breaking change. 

This also allows the deployment to be phased: the redesigned undisclosed fields can be introduced in SDK 1.16, while SDK 2.0 can focus on the EFX 2 changes. 

 

  • SDK 2.0 – Are any major breaking changes to EFX 2 expected after alpha.3? Would SDK 2.0 beta.1 be stable enough for Member States to start implementation projects, or should they wait for RC.1 or the final release? 

Answer: Some changes are still expected before the beta release. The language itself is not expected to change significantly, but the way the language is formally defined will change. The grammar is expected to be simplified, which means that implementations with their own parsers may need to adapt them. The syntax and functionality are expected to remain largely the same. 

SDK 2.0 beta.1 should be stable enough to start planning implementation work. For implementations mainly using eForms metadata, the migration should be limited, as SDK 2.0 will contain the same types of files as SDK 1.16. For implementations using EFX interpreters or compilers, beta.1 should be stable enough to start planning and implementing the necessary adaptations. 

Additional files may still be added later in the “forward” folders that will be introduced with SDK 2.0. However, it should not be necessary to migrate to all new SDK 2.0 components immediately. 

 

  • Migration – Will a migration guide from SDK 1.x to SDK 2.0 be provided? Will any migration tools or reference implementations for EFX 2 be provided?  

Answer: Documentation will be provided, but it may not cover every possible use of the SDK in the form of a full step-by-step migration guide. 

For example, guidance on moving from EFX 1 data structures to EFX 2 data structures, and on the changes in the language and what needs to be addressed in interpreters or compilers, is expected. However, more specific cases, such as converting custom EFX 1 expressions or custom validation rules, may be too complex to cover fully in documentation. 

Some existing open-source components already serve as reference implementations, such as the eForms Core Library, the EFX Toolkit and the Notice Viewer. 

Further migration support is being considered, including possible tools to help translate EFX 1 expressions into EFX 2, or to rewrite expressions using business entities instead of field references. However, these tools were not promised before the release of SDK 2.0, as they require further work, documentation and testing. 

 

  • Strategic direction / migration planning – For new eForms projects starting in 2026, which SDK version would you recommend? Would it be more efficient to migrate directly from SDK 1.13 to SDK 2.0? 

Answer:  This depends on the project timeline, technical setup and which parts of the SDK are used. 

For new eForms projects, SDK 2.0 would be the preferred target if the project can start development without needing to go live before SDK 2.0 is available. If the project needs to go live earlier, a current SDK 1.x version may still be needed. 

For existing implementations, the most efficient migration path depends on the implementation. If the system is metadata-driven, it may be possible to move progressively through the SDK versions and deal with the changes as they come. If the system requires more manual adaptation, it may be more efficient to make a larger move directly from SDK 1.13 to SDK 2.0. 

SDK 1.14 and SDK 1.15 are mainly maintenance releases. SDK 1.16 introduces the redesigned undisclosed fields, while SDK 2.0 introduces EFX 2. If a direct move from SDK 1.13 to SDK 2.0 is feasible, this is the shortest path. If an intermediate step is needed, SDK 1.16 would be the most useful step before SDK 2.0. If SDK 1.16 is considered too difficult because of the redesigned undisclosed fields, SDK 1.15 could also be considered. 

 

  • SDK 1.x lifespan – How long will SDK 1.15, SDK 1.16 and future SDK 1.x releases be supported after SDK 2.0 is released? When will SDK 1.15 and SDK 1.16 expire? 

Answer: SDK 1.13, 1.14, 1.15, 1.16 and SDK 2.0 are expected to remain active in parallel. From a regulatory point of view, there is currently no reason to stop the older SDK versions until there is a future SDK implementing the 3rd amendment to the eForms Regulation. 

The current expectation is that SDK 1.15 and SDK 1.16 will remain available at least until the end of 2027. This should allow time for a future SDK implementing the 3rd amendment to be released and for eSenders to migrate to it. 

However, older SDK versions may stop receiving updates, such as changes to view templates or labels. The longer an implementation remains on an older SDK version, the bigger the eventual migration step may become.  

 

  • Do you happen to know by what date the various European countries must have a national gateway for sending notices?  

Answer: There is currently no European legislation setting a common deadline by which Member States must have a national gateway for sending notices. This is decided at national level. 

The situation differs between Member States. Some countries already have national gateways or hubs, while others have a more decentralised approach. Information on national arrangements could be collected through a future Member State survey to then publish clearer information on TED. 

 

  • In Italy, the national gateway is ANAC, but there are still some customers who use our platform to send notices. Are there any regulations or criteria that you know of that prevent them from going through ANAC? 

Answer: This depends on the national arrangements in Italy. The question will need to be followed up with ANAC in order to clarify the applicable Italian policy and how the process should work for providers and users in Italy. 

 

  • Is it possible for national gateways to schedule meetings to clarify specific aspects of the SDK, in order to align national processes with those of TED?  

Answer: Coordination with national gateways depends on the arrangements in each Member State. The Publications Office does not control national processes and cannot enforce how coordination is organised at national level. 

Questions on how national authorities coordinate with operators and service providers could be included in our future survey. For specific national situations, the most useful approach may be to focus on the country concerned and clarify the process with the relevant national authority. 

 

  • eNotices2 – Can eSenders continue using eNotices2 as a verification tool for API-submitted notices? Is the API to check if a notice has been published still available? Will we get the publication date of the notice via API? 

Answer: eNotices2 was not designed as an eSender-specific user interface. eSenders using the API are expected to manage their notices through the API. 

Checking notice status through the eNotices2 interface is a read-only action and is expected to continue working. However, for workflow actions such as stopping publication, eSenders are encouraged to use the API rather than the eNotices2 user interface. The expected workflow is to submit through the API, stop publication through the API if needed, and retrieve the notice status through the API. 

The API to check whether a notice has been published is available. Searching for a notice by notice ID returns its status, including whether it is published. 

The publication date and the expected publication date are also returned through the API. See Publication API :: TED Developer Docs 

 

  • Technical suggestion: regarding the plan to remove successful validation reports, please use “410 Gone” instead of “404 Not Found”. 

Answer: The suggestion was acknowledged. The distinction between “404 Not Found” and “410 Gone” could help distinguish between a resource that never existed and a resource that existed before but has since been removed. 

This will be looked at further in the context of the proposal to remove successful validation reports. 

 

  • Technical question: How should we interpret equals() in EFX? For example, BT-809-Lot has a forbidden rule referring to BT-821-Lot, but there may be multiple instances of BT-821. 

Answer: The question relates to a known ambiguity around equals() and not equals(), but the details could not be handled during the session. 

The issue is being followed up on GitHub at https://github.com/OP-TED/eForms-SDK/issues/1383. 

 

  • Any update on KoSIT’s request to modify eforms XSD to allow national UBL extensions to fulfil German legal requirements?  

Answer: This question is being followed up on GitHub at https://github.com/OP-TED/eForms-SDK/issues/1247. The proposal is still being discussed internally, and a definitive answer will be provided once the internal assessment is completed. 

 

  • I opened a discussion concerning tailored lists that remains unanswered. Who should I contact to move this forward? 

Answer: This question has since been answered on GitHub at https://github.com/OP-TED/eForms-SDK/discussions/1374.

 

-

 

Last update: 14 July 2026