Electronic Settlement Matching


Electronic Settlement [|Matching] is an interoperable data processing standard issued in 2019 by the Energy Traders Europe 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. 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. And it's been perceived as a facilitator for faster settlement with the potential to increase liquidity in OTC markets and bring parity between OTC and exchange trading.
eSM makes use of the Commodity product Markup Language and is based on the AS2 communication protocol, ensuring Authentication, Confidentiality, Data Integrity, and Non-repudiation.
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 of the EU commission and can be mapped to the European standard EN 16931.

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. Version 4.0 was released in 2025 and contains a syntax mapping to Peppol BIS 3.0.

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. 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.


2024-07-22

EFET
2007

Power
AREAEIC
MWh
EUR
2024-06-01
2024-06-30
Fixed
Physical
PositiveOrZero
SUPPLIERVATID_PARTYEIC
CUSTOMERVATID_PARTYEIC


Process flow

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.
The matching process in eSM comprises the following steps:
  1. Suppliers send settlement data which they intend to invoice as an eSM OfficialDocument, based on the sales order data in their systems.
  2. Customers send settlement data which they expect to be invoiced as an eSM ShadowDocument, based on the purchase order data in their systems.
  3. 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, determining technical details needed to dispatch the eSM Document and to steer the eSM matching process ;AggregationKeys, determining the contents of an eSM Document ;InvoiceData and LineItems, 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' must be equal in both OfficialDocument and ShadowDocument.



true
NonStrict
OfficialDocumentIssuer
INV_20240701_1234567890supplier.com
1
SUPPLIERVATID_PARTYEIC
CUSTOMERVATID_PARTYEIC
Live


2024-07-22

EFET
2007

Power
AREAEIC
MWh
EUR
2024-06-01
2024-06-30
Fixed
Physical
PositiveOrZero
SUPPLIERVATID_PARTYEIC
CUSTOMERVATID_PARTYEIC


1234567890
2024-07-01

DEVATID
EUR
Supplier Name
SUPPLIERPARTYEIC
EIC
COM REG NUMBER
LOCAL DISTRICT COURT
HEADQUARTER TOWN
DE
eSM Service Provider A

HEADQUARTER STREET
HOUSE NUMBER
HEADQUARTER TOWN
ZIP CODE
ISO CODE


contactsupplier.com


...
...



ITVATID
Customer Name
CUSTOMERPARTYEIC
EIC
eSM Service Provider B

HEADQUARTER STREET
HEADQUARTER TOWN
ZIP CODE
ISO CODE


contactcustomer.com



8338079.52
EUR

32592.0

0
0
EUR
0
GBP
Reverse Charge - Customer To Account For VAT
0.85
EUR/GBP


8338079.52
EUR

false
Some text here



87654321
3840.0
MWh
Reference: 19644691

334.0
EUR

1282560.0
EUR

2024-06-01
2024-06-30

0
0
2022-12-15
2024-01-01
2024-12-31