Inbound supplier invoices into logistics invoice verification

On the buying side, Lakeside Components sends Contoso its invoices as X12 810s. Process Orchestration maps them to inbound INVOIC IDocs, and SAP posts them as supplier invoices in logistics invoice verification (LIV), with the same three-way match against purchase order and goods receipt that Ana in accounts payable performs manually in MIRO. Done well, most Lakeside invoices post without anyone touching them.

The IDoc interface

SAP's documentation for invoices received via EDI names message type INVOIC and process code INVL (logistics invoice verification); the older code INVM belongs to conventional invoice verification. INVL runs the inbound function module IDOC_INPUT_INVOIC_MRM. The same documentation still lists basic type INVOIC01; many systems use INVOIC02, so check the function module assignment in WE57 for the basic type your middleware sends. Lakeside's inbound line in WE20 sits on its supplier profile, partner type LI, number 17300001, next to ORDRSP and DESADV.

The three Customizing activities

In Customizing for logistics invoice verification, the EDI node has three activities that answer three questions SAP cannot answer from the IDoc alone.

Tax conversion is where most go-live defects live. Lakeside's rotors are production inputs for Contoso and are invoiced without sales tax under Contoso's manufacturing exemption; Lakeside sends a zero rate with an exemption indicator. In company code 1710 the conversion maps that to Contoso's exempt input tax code. When it was missing in CMQ, every test invoice failed with 51 and a message that no tax code could be assigned, the incident sap-edi-208 uses as its example.

Referencing the purchase order

Each invoice item must reference the purchase order item, so the supplier must send Contoso's PO number and item, carried in the item reference segment E1EDP02 with the PO qualifier. Lakeside echoes the PO data it received in the 850. With goods-receipt-based invoice verification, SAP matches the invoiced quantity against the quantity received for that item; the supplier's own invoice number becomes the reference on the supplier invoice, which also drives the duplicate invoice check.

What EDI invoices cannot do

• Create subsequent debits or credits.
• Settle planned delivery costs.
• Post with purchase order units of measure that vary from the PO.
• Post invoices for blocked purchase order items.
• Settle unplanned delivery costs or post directly to G/L or material accounts, unless you implement enhancement MRMH0002 (customer exits EXIT_SAPLMRMH_014 and EXIT_SAPLMRMH_015).

These limits come straight from SAP's documentation, and they are design inputs: if Lakeside charges freight as a separate line, Contoso either agrees that freight is in the price, implements the exit, or accepts that those invoices fail and are entered manually.

Onboarding checklist for a supplier invoice channel

1. Agree the 810 content: Contoso PO number and item on every line, invoice recipient identifier, tax data format, remit-to, credit memo handling.
2. Maintain the WE20 inbound line: LI 17300001, INVOIC, process code INVL, processing mode and permitted agent (AP team).
3. Maintain the three EDI Customizing activities for the partner and company code 1710, through a transport approved by finance.
4. Confirm purchasing data: GR-based invoice verification flag and tolerances on Lakeside's POs.
5. Test in CMQ through XQ1: happy path, price variance, quantity variance, missing PO, unknown tax data, credit memo, duplicate.
6. Agree the cut-over date with Lakeside so paper or PDF invoices stop the day the 810s start, avoiding duplicates.

The last point is not trivial. Suppliers moving to EDI often keep emailing PDFs for a while, and AP teams enter them out of habit. The duplicate invoice check catches exact matches on supplier, reference and amount, but a PDF entered with a slightly different reference slips through. Ana's team keeps a list of EDI-enabled suppliers and does not key their invoices manually after the cut-over date.