IDOC_INPUT_INVOIC_MRM — Inbound Function Module for INVOIC IDocs Into MM Invoice Verification
IDOC_INPUT_INVOIC_MRM is the standard SAP inbound processing function module that converts an incoming INVOIC IDoc into a logistics invoice verification document (a vendor invoice posted against a purchase order) in Materials Management. It is invoked by the ALE/IDoc dispatcher via the process code configured in the inbound partner profile, not normally called directly from custom code. Business failures show up as IDoc status errors, not ABAP exceptions.
This page covers what IDOC_INPUT_INVOIC_MRM does when an INVOIC IDoc lands in the system for invoice verification, its parameter shape, and why the function module raising almost no hard exceptions is the single most important thing to understand when diagnosing a failed posting. It also covers the recurring MM-side causes of failure, the safe calling pattern, and where responsibility sits between the EDI/interface team and the invoice verification functional team.
Published 16 Sept 2026· 1,117 words
What it does
IDOC_INPUT_INVOIC_MRM is the standard released inbound handler for message type INVOIC where the target application is logistics invoice verification (MRM) rather than financial accounting document posting. It is triggered by the ALE/IDoc inbound framework once an IDoc reaches the stage where the assigned process code points at this function module in the inbound partner profile. Internally it maps the incoming header, item, tax, and reference segments onto the fields needed to create a vendor invoice against one or more purchase orders, and drives the same posting logic used by manual invoice entry. It is released for customer use as an inbound handler, but it is designed to be called by the ALE dispatcher and workflow, not directly from custom code, except for controlled test or reprocessing scenarios.
Parameters
- INPUT_METHOD (importing) - single character controlling whether the IDoc is posted immediately or collected into a batch input session for later processing.
- MASS_PROCESSING (importing) - flag indicating that many IDocs are being processed together, which affects locking behaviour and how aggressively the function module commits.
- IDOC_CONTRL (tables, EDIDC-shaped) - control records identifying the IDoc(s) being processed, including sender partner, message type, and IDoc number.
- IDOC_DATA (tables, EDIDD-shaped) - the actual segment data: invoice header amounts, reference to purchase order, line items, tax, and partner segments.
- IDOC_STATUS (tables, EDIDS-shaped) - returned per-IDoc status records; this is where the real outcome of the call lives, success or error, with a message class and number.
- RETURN_VARIABLES (tables) - returned application references, in particular the created invoice document number when posting succeeds.
- WORKFLOW_RESULT, APPLICATION_VARIABLE, IN_UPDATE_TASK, CALL_TRANSACTION_DONE (exporting) - standard exporting parameters shared across most IDOC_INPUT_* function modules, used by the ALE framework to decide whether to trigger a workflow item and how to handle the update task.
Exceptions
- WRONG_FUNCTION_CALLED - raised when the IDoc type or basic type passed does not match what this function module is built to process; in practice this means the partner profile process code is pointing at the wrong inbound handler, not a data problem on the invoice itself.
- Almost every real MM-side failure does not raise an ABAP exception at all. It is written into IDOC_STATUS as an error record (status 51) carrying the actual invoice verification error text - purchase order not found, goods receipt missing under GR-based invoice verification, price or quantity variance outside tolerance, tax code invalid, vendor blocked, duplicate invoice reference.
- Swallowed-error effect: a caller that checks only the return code of the function call and ignores the contents of IDOC_STATUS will treat the call as successful even though no invoice document was created. The IDoc sits in error status in the monitor, the vendor invoice is simply not posted, and nothing downstream notices until someone checks the IDoc queue or the vendor complains about a missed payment run.
How to call it safely
In production this function module is called by the ALE/IDoc dispatcher, triggered when an INVOIC IDoc reaches the process code bound to it in the inbound partner profile. Direct manual calls are mainly for controlled reprocessing or test simulation, and require IDOC_CONTRL and IDOC_DATA filled with segments matching the INVOIC IDoc type variant in use, including the extension segments MRM expects for tax and reference data. After the call, the only reliable signal is the IDOC_STATUS table: a success status confirms the invoice document number returned in RETURN_VARIABLES; an error status must be read for its message text rather than assumed away because no exception fired. Update task handling should be left to the framework unless the calling program explicitly manages commits.
ECC vs S/4HANA
IDOC_INPUT_INVOIC_MRM is classic ALE/IDoc technology and remains functional in S/4HANA for logistics invoice verification inbound processing; there is no confirmed formal successor function module. Under clean-core principles, new integration builds for incoming supplier invoices are steered toward API-based approaches rather than extending this function module directly. Where extension is unavoidable, it should go through the BAdIs published for invoice verification processing rather than modification of the standard inbound handler, keeping the IDoc-based path as a legacy but supported channel.
Common pitfalls
- Treating a clean function call return as proof of a posted invoice, when the actual outcome sits unread in IDOC_STATUS - this is the most common source of missed vendor payments traced back to this function module.
- Reprocessing a failed IDoc repeatedly without fixing the underlying master data (blocked vendor, missing goods receipt, wrong tax code) just accumulates status history and hides the real cause under a pile of retry entries.
- Mass reprocessing many IDocs referencing the same purchase order in parallel causes lock waits on the PO and invoicing plan, and in some race conditions can create near-duplicate invoices before the duplicate check catches up.
- Custom exits or BAdI implementations wrapped around this call that suppress or downgrade error status records make the IDoc queue look clean while invoices are silently not posted.
- Forcing INPUT_METHOD to batch input as a workaround for a persistent posting error hides the error inside a batch input session instead of surfacing it, and the session then needs separate monitoring and cleanup.
Whose problem this is
First responder is normally the accounts payable / invoice verification functional owner on the MM side, since the failures that matter are almost always master data or tolerance related. The EDI or middleware integration team owns the partner profile, process code assignment, and message mapping into the IDoc structure. Basis or ABAP involvement is only needed for dumps, performance problems on mass reprocessing, or genuine lock contention issues.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/idoc-input-invoic-mrmERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.