Lesson 2 of 6
INVOIC02 structure and mapping to 810 and EDIFACT
8 min
Listen to this lesson
An integration specialist reading an INVOIC02 IDoc should be able to point at any value on the customer's 810 and say where it came from. That skill makes mapping reviews fast and defect triage precise. The structure follows SAP's classic header, item and summary pattern, and most segments are qualified: the same segment occurs several times, and a qualifier field says what each occurrence means.
The segments that matter most
| Segment | Content | Qualifier field and typical values |
|---|---|---|
| E1EDK01 | Header: currency, document type, invoice number, payment terms basics | Not qualified |
| E1EDKA1 | Header partners: bill-to, sold-to, ship-to, invoicing party | PARVW, for example RE bill-to, AG sold-to, WE ship-to, RS invoicing party |
| E1EDK02 | Header references | QUALF, for example 001 customer PO number, 009 invoice number |
| E1EDK03 | Header dates | IDDAT, for example invoice date and PO date |
| E1EDK04 / E1EDP04 | Taxes at header and item level | Tax code (MWSKZ), rate (MSATZ), amount (MWSBT) |
| E1EDK05 / E1EDP05 | Conditions: surcharges and discounts | ALCKZ + or -, condition type and amount |
| E1EDK18 | Payment terms | QUALF per term line: days and percentage |
| E1EDP01 | Item: quantity, unit, price, item number | Repeats per billing item |
| E1EDP19 | Item object identification | QUALF 001 customer material, 002 supplier material |
| E1EDP26 | Item amounts | QUALF per amount type, for example net value |
| E1EDS01 | Summary totals | SUMID, for example 011 invoice total, 005 total tax |
Key INVOIC02 segments. Confirm qualifier values for your release in the IDoc documentation (WE60).
Two warnings save hours. First, qualifier values are not intuitive and some differ between documentation sources, so the mapping specification must quote the values from WE60 in your system, not from a blog. Second, totals in E1EDS01 are calculated by SAP from the billing document; if the customer's 810 total disagrees with the item lines, check conditions in E1EDK05 and E1EDP05 before suspecting the mapping.
Mapping to the X12 810
| INVOIC02 | X12 810 | EDIFACT INVOIC |
|---|---|---|
| E1EDK01 invoice number, E1EDK03 invoice date | BIG: invoice date and number | BGM (380 invoice, 381 credit note) and DTM+137 |
| E1EDK02 qualifier 001 customer PO | BIG: PO number (and PO date) | RFF+ON |
| E1EDKA1 partners | N1 loops, for example BT bill-to, ST ship-to, RE remit-to | NAD+IV, NAD+BY, NAD+DP, NAD+SU |
| E1EDK18 payment terms | ITD terms of sale | PAT |
| E1EDP01 + E1EDP19 items | IT1 quantity, unit, price, buyer and vendor part numbers | LIN, PIA, QTY+47, PRI |
| E1EDK04 / E1EDP04 taxes | TXI tax information (including exemptions) | TAX with MOA |
| E1EDK05 / E1EDP05 conditions | SAC allowances and charges | ALC with MOA |
| E1EDS01 totals | TDS total amount (implied two decimals), CTT line count | UNS, then MOA totals in the summary section |
The X12 TDS segment is a classic defect source: it carries the total amount without a decimal point, so 12,000.00 becomes 1200000. A mapping that sends 12000 invoices Great Lakes for $120.00, and the 997 will still be positive because the syntax is valid. Only a business-level check catches it, which is why Lesson 5 reconciles totals, not just counts.
Reading the inbound direction
The same structure works in reverse for supplier invoices. When Lakeside's 810 arrives, Process Orchestration fills an inbound INVOIC02: the invoice number and date from BIG go to the header and reference segments, Contoso's PO number from BIG goes to the PO reference, the N1 loops become E1EDKA1 partners (including the invoicing party and the invoice recipient that SAP uses for company code determination), each IT1 line becomes an E1EDP01 with an E1EDP02 PO item reference, TXI becomes tax segments and TDS becomes the E1EDS01 total. Lesson 3 shows how SAP reads those segments to post the supplier invoice.
When you review an inbound mapping, check three things first: the PO number and item on every line, the tax data in the form the tax code conversion expects, and the invoice recipient identifier that drives the company code. Most inbound invoice failures in the first weeks trace back to one of the three.
- INVOIC02 has header (E1EDK*), item (E1EDP*) and summary (E1EDS01) segments, most of them qualified.
- Key qualifiers: E1EDKA1 PARVW for partners, E1EDK02 QUALF 001 for the customer PO, E1EDS01 SUMID for totals; confirm values in WE60.
- X12 810: BIG, N1, ITD, IT1, TXI, SAC, TDS, CTT; EDIFACT INVOIC: BGM, DTM, RFF, NAD, LIN, QTY, TAX, ALC, MOA.
- TDS carries implied decimals; syntactically valid 810s can still carry wrong amounts.
Check your understanding · not graded
Lesson check
1. Which INVOIC02 segment, with qualifier 001, typically carries the customer's PO number?
2. Which segment and field identify the partner role, such as bill-to RE, in the IDoc header?
3. A 12,000.00 USD invoice arrives at the customer as $120.00 with a positive 997. What is the likely cause?
4. Where should the mapping specification take qualifier values from?