ERPClimb logoERPClimb
IDoc message typeObjectINVOICModuleBTP_INTEGRATION

INVOIC message type — INVOIC IDoc Message Type

INVOIC is the IDoc message type that carries an invoice or credit memo document between SAP and a trading partner or middleware layer. Outbound, it represents a billing document leaving SD for an EDI subsystem or integration platform. Inbound, it represents a vendor invoice arriving for posting into Logistics Invoice Verification or directly into FI.

This page covers what the INVOIC IDoc carries, its main segments, the partner profile and process code setup needed for it to flow, and the ordered checklist for diagnosing a stuck or failed INVOIC idoc. It also flags the mismatches between IDoc status and actual business posting that trip up consultants new to this message type.

Published 16 Sept 2026· 1,087 words

What it carries

INVOIC moves invoice and credit memo data as an IDoc rather than a printed or PDF document. Outbound, SAP generates it from a billing document (VF01/VF02 output) and sends it to a customer, an EDI subsystem, or an integration platform such as Cloud Integration for onward transformation. Inbound, INVOIC arrives from a vendor or a service provider representing a supplier invoice and is posted either into Logistics Invoice Verification against a purchase order and goods receipt, or directly into FI as a vendor invoice without PO reference. The direction is not symmetrical in processing logic: outbound INVOIC is a copy of an existing SD document, inbound INVOIC triggers creation of a new MM or FI document, which is why inbound failures are usually more consequential than outbound ones.

Segments

The structure follows the standard invoice-type IDoc layout shared with related SD/MM message types.

  • E1EDK01 - document header: document type/category, currency, reference document number, invoice date
  • E1EDKA1 - partner segment, repeated per partner function: sold-to, bill-to, vendor, ship-from
  • E1EDK03 - date segment: invoice date, service period, delivery date references
  • E1EDK14 - organizational qualifiers: sales organization, purchasing organization, document category codes
  • E1EDK17 - terms and conditions: Incoterms, terms of payment key
  • E1EDP01 - item segment: item number, material or reference item, quantity, unit price
  • E1EDP19 - item object identification: material number, EAN, customer/vendor material number
  • E1EDP04 - tax segment per item: tax type, tax rate, tax amount
  • E1EDS01 - summation segment: total invoice amount, total tax amount, control totals used for reconciliation

Configuration

For outbound INVOIC, the trigger is output determination on the billing document: an output type (often the standard EDI output for invoices) with a processing routine that generates the IDoc via message control (NAST), tied to a partner profile in WE20 for the customer or EDI partner with INVOIC as the outbound message type, a matching port in WE21 pointing at the RFC destination or the integration middleware, and a process code that calls the standard IDoc creation logic. For inbound INVOIC, the receiving partner profile must have INVOIC configured as an inbound message type with a process code that routes to the invoice verification or FI posting function module, and the port must accept the file or tRFC call from the sending system or middleware. Missing or inactive entries in any of these three places - output type not set to trigger, partner profile absent for the partner type actually sending, or port pointing at a dead RFC destination - stop the IDoc before it is even created or received.

What to inspect when it fails

Work from the IDoc outward, not from the business document inward, or the real cause gets missed.

  • WE02 or WE05 - find the IDoc, read its current status and the full status history, not just the last line
  • If status 51 (application error): open the status record text, it names the exact field or check that failed (tax code, GR/PO mismatch, duplicate invoice, missing vendor)
  • If stuck before 03/12 (outbound) or never created inbound: check NAST entries on the billing document for the output type, and confirm the output actually processed rather than staying on the output list
  • WE20 - confirm the partner profile exists for the correct partner type (KU, LI, or the EDI partner) and that INVOIC is listed with the right process code and matching message variant
  • WE21 - confirm the port is active and, for file ports, that the directory or connection is reachable
  • For inbound to MM: check tolerance limits and duplicate invoice check settings, since a valid IDoc can still fail application posting on these grounds
  • For a BTP Integration Suite scenario: check the Cloud Integration monitor for the corresponding message, since the IDoc adapter can accept the payload on the SAP side while the flow fails upstream in mapping or connectivity, leaving no trace in WE02

Whose problem this is

Functional SD or MM/FI owns the mapping logic, the output determination, tolerance settings, and any field-level errors reported in the status text. Basis or the integration team owns the partner profile, port, and RFC/middleware connectivity, and should be engaged first when the IDoc never arrives or never leaves. Hand over to ABAP only when the status text points to a custom user exit or a Z-enhancement in the process code logic.

Common pitfalls

Reprocessing the failed IDoc from BD87 without reading the status 51 text first. It either fails again with the same error, wasting a cycle, or worse, it succeeds and creates a second posting because the original partial processing already created something (a parked document, a partial tax posting) that the reprocessing does not detect. Mass reprocessing of a batch of failed INVOIC idocs without grouping by error text is the same mistake at scale: it treats a config problem (wrong tax code mapping) and a data problem (one vendor invoice with a genuine duplicate) as the same fix.

  • Status 53 (posted) does not mean the posting is correct, only that the IDoc's data passed the update rules; a valid IDoc can still post to the wrong GL account or cost center if the mapping is wrong
  • Credit memos and invoices share the same message type; the distinction lives in a document type field inside E1EDK01, easy to overlook when building a filter or a monitoring query
  • Tax totals in E1EDS01 must reconcile against the sum of E1EDP04 line items; rounding differences of a few cents cause a hard posting failure that looks unrelated to tax at first glance
  • Inbound INVOIC for logistics invoice verification depends on the purchase order and goods receipt being referenced correctly; a missing or wrong PO reference does not always error out, it can post against a default account, which is far worse than a visible failure
  • An IDoc sitting at status 30 (ready for dispatch) for hours often means the RFC destination behind the port is down, not that anything is wrong with the invoice data itself

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-idoc/invoicERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.