ESSR table — Service Entry Sheet Header Table

One row in ESSR represents the header of a single service entry sheet, the document used to record that services under a service line of a purchase order have actually been performed, prior to acceptance and invoice verification. It carries the entry sheet number as its business key, the purchase order and item it was raised against, and a package number that links the header to the actual list of service lines stored separately. A single service PO item can generate several entry sheets over time as work is delivered in stages, so ESSR is one row per submission, not one row per PO item. The header also carries creation and status information used to drive the release/acceptance workflow, but no monetary values, quantities, or account assignment splits, all of which sit in child tables reached through the package number.

Always restrict on MANDT plus at least one of LBLNI or EBELN before running against ESSR in a productive system with heavy service procurement volume; a PO-restricted read is the normal entry point since users almost always come in asking about a specific purchase order, not a specific entry sheet number they already know. LBLNI is the fastest lookup once known, since it is the table's key field. Do not attempt to read ESSR by date range alone across company codes without a PO or vendor filter; entry sheets accumulate continuously and a broad ERDAT scan on a live system is a common cause of an unnecessary full or near-full table scan.

Symptom: an invoice is blocked because the service performed has not been accepted. Select ESSR by EBELN and EBELP for the PO item in question, note the LBLNI values returned, then check each entry sheet's status through the standard service entry sheet transaction or the linked release workflow record. If a sheet exists but shows no acceptance, the invoice block is legitimate. Then join to ESLL on PACKNO to see the actual service lines and confirm the value expected does in fact match what was entered before escalating as a data problem.

ESSR is retained in S/4HANA in the same structural role as in ECC; there is no compatibility CDS view replacing it as the primary persistence for service entry sheet headers. The Fiori app used to manage service entry sheets reads and writes through this table and its line-item counterpart underneath an OData layer, but the underlying table names and key structure are unchanged, so joins written against ECC continue to work.

Ownership of a data question on ESSR sits with the MM service procurement consultant responsible for the entry sheet configuration and release strategy, working with whoever owns the invoice verification process when the issue is a blocked invoice. Master data or authorization questions about who can create or release a sheet belong to the same functional owner, not to a Basis or FI team.

ESLL holds the actual service lines and values reached from ESSR through PACKNO. EKKO and EKPO hold the purchase order header and item the entry sheet was raised against. EKBE carries the posting history generated once a service entry sheet is accepted. The entry sheet is created and maintained through the standard service entry sheet maintenance transaction, and the underlying PO is displayed or changed through the standard purchase order transactions.