eSM (electronic Settlement Matching) is an interoperable data processing standard issued in 2019 by the Energy Traders Europe (formerly European Federation of Energy Traders[1]) for the exchange and reconciliation of settlement data and invoices in wholesale energy trading.
The standard consists of the definition of the settlement matching process, describing message flow, message content, and message structure, together with matching criteria and business validation rules. By those means, eSM renders itself as an automated risk-control and risk-mitigation in the settlement process and aims at fostering straight-through processing.[2] It is expected to reduce the costs of application integration in internal and intra-company business processes and to lead to significant increase of efficiency.[3]
eSM makes use of the Commodity product Markup Language (CpML) and is based on the AS2 communication protocol, ensuring Authentication (verification of identity), Confidentiality (document encryption), Data Integrity (document signing), and Non-repudiation (undeniable proof of document reception and sending).
Defining an XML-based structured data format which contains all legally required elements of an invoice and which allows for automatic and electronic processing, the standard meets the eInvoicing Directive (2014/55/EU) of the EU commission and can be mapped to the European standard EN 16931.[4]
History
While the first draft of the eSM Standard was released in December 2007, no further drafts were published between 2008 and 2018 and the first final version 1.0 was released in February 2019.[2] Version 4.0 was released in 2025[5] and contains a syntax mapping to Peppol BIS 3.0.[4]
Matching
For data reconciliation purposes, eSM introduces the concept of an AggregationKey that determines the contents of a settlement document, i.e., which line items must be part of the document (if provided; see section Document structure). The strict scope definition of trades that are subject to settlement is needed to allow for automated matching of purchase orders and sales orders across companies.
According to the following AggregationKey, for example, the settlement document must contain all fix-priced Power trades, physically delivered in June 2024 at delivery location AREAEIC in the agreed volume unit MWh, in accordance to the EFET 2007 agreement signed between supplier SUPPLIERVATID_PARTYEIC and customer CUSTOMERVATID_PARTYEIC with an agreed payment date of July 22nd 2024 and an agreed settlement currency of EUR.
Flow of settlement documents and result matches in eSM
Counterparties exchange settlement data via their preferred eSM service providers, who are implementing the official eSM standard and may offer value-added services like a web frontend that helps with conducting and monitoring the eSM process.
Suppliers send settlement data which they intend to invoice as an eSM OfficialDocument, based on the sales order data in their systems.
Customers send settlement data which they expect to be invoiced as an eSM ShadowDocument, based on the purchase order data in their systems.
Each company, respectively via their eSM service provider, compares the OfficialDocument and ShadowDocument according to the eSM matching criteria and rules, and exchanges the eSM MatchResult according to the eSM process.
In case OfficialDocument and ShadowDocument do not match, counterparties resolve the mismatch outside of the eSM process and may resend corrected OfficialDocuments and/or ShadowDocuments. The web frontends of eSM service providers may highlight the root causes for mismatches.
A matched eSM OfficialDocument is considered an issued and legally binding invoice.
Document structure
eSM documents are specified using CpML and contain all legally required elements of an invoice, i.e., once matched, counterparties may automatically fetch and process all relevant settlement data into their IT systems.
At root level, an eSM Document has the following sections:
ProcessInformation (mandatory), determining technical details needed to dispatch the eSM Document and to steer the eSM matching process (e.g., whether or not to require strictly matching LineItems);
AggregationKeys (mandatory), determining the contents of an eSM Document (see section Matching);
InvoiceData (mandatory) and LineItems (optional), where InvoiceData renders header information determining all required elements of an invoice.
eSM makes use of VAT numbers and EICs to identify counterparties and delivery locations, and IBANs and BICs to identify bank accounts.
Example document
An example eSM document with InvoiceData and LineItems is shown below. OfficialDocuments and ShadowDocuments use the same XSD schema. For a match, only the values of 'matching fields' (as defined by the standard) must be equal in both OfficialDocument and ShadowDocument.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
