ML81N — Maintain Service Entry Sheet

ML81N is the transaction for creating, changing, and displaying service entry sheets against a service purchase order. It is the service-procurement counterpart to a goods receipt for materials. The structural fact that explains most confusion is that a service entry sheet is a two-step object: saving the sheet only records which services were rendered against the PO's service lines, while acceptance is a separate action that posts the equivalent of a goods receipt document, reduces the PO's open service value, triggers the accrual reversal, and unlocks invoice verification. A sheet that is entered and saved but never accepted looks complete on screen but has not touched financials, PO history, or account assignment postings, and will not be available as a reference for MIRO.

ML81N is reached for whenever a purchase order or contract release order carries a service item category or a limit item with a service specification attached, after the vendor has actually performed the work. The requester, the vendor through a portal, or the buyer creates the entry sheet referencing the PO's service package, selects which planned or unplanned service lines were delivered, and enters actual quantities and prices. In S/4HANA, Fiori apps for entry sheet creation and approval are increasingly the intended front end for business users, but ML81N remains the transaction consultants drop into for troubleshooting, mass display, and fixing sheets stuck at an unaccepted or unreleased status, because it exposes account assignment and acceptance status the simplified apps abstract away.

Pull ESSR for the sheet number and check the status field first: if the sheet is saved but the accepted indicator is not set, nothing downstream has posted. Then check EKBE for the corresponding PO item, filtered on the history category used for service entries - if no row exists there, PO value has not moved and invoice verification against that item will fail or valuate incorrectly. Cross-check ESLL quantities and unit price against EKPO's service specification for the same package number to confirm the entry matches what the PO actually expects.

ML81N continues to work unchanged in S/4HANA, still driven by ESSR, ESLL, and ESKN. What changed is the front end: Fiori apps for creating and approving service entry sheets are the intended entry point for business users and for approval workflows tied to a release strategy, while ML81N remains the transaction consultants use for direct editing, mass processing, and diagnosing sheets stuck in an unaccepted or unreleased state. No table structure or posting logic changed between ECC and S/4HANA for this object.

Almost always a functional MM/procurement problem - acceptance status, release strategy, tolerance keys, and account assignment are configuration and process, not code. Escalate to FI only when the accrual account or automatic account determination behind the acceptance posting is wrong. Escalate to Basis/ABAP only if a release strategy step or custom validation exit fails to trigger. A good handover states the sheet number, its exact status flag, the PO and service line it references, and whether the block occurs at save or at acceptance.

Trace the service specification back to the contract it came from using ME33K, since many service POs are release orders against a framework contract rather than standalone. Once an entry sheet is accepted, follow it downstream into invoice verification with MIR7 for parking or MIR4 for display, since the invoice must reference the entry sheet rather than the PO item when GR-based invoice verification is active. Check MK03 when a service vendor's account group or payment terms seem to be interfering with acceptance or invoice matching.