RSEG table — Incoming Invoice Document Item Table

One row in RSEG represents one item of an incoming invoice document created via logistics invoice verification. An invoice document can post several items against several purchase order lines, and a single PO item can be invoiced across multiple invoice documents, so RSEG is deliberately many-rows-per-invoice and many-rows-per-PO-item. The row carries what was invoiced on that line: quantity, amount in document currency, tax code, and the purchase order item it is being charged against. If goods-receipt-based invoice verification is active for the PO item, the row also carries a pointer back to the specific material document that the invoice quantity is checked against. RSEG does not carry vendor, payment terms, or total invoice amount; that belongs to the header table RBKP, joined on document number and fiscal year.

MANDT is implicit in any reasonable selection and should never be left off a direct SQL read. RSEG is never selected alone in practice; it is read with a known BELNR/GJAHR (coming from RBKP) or a known EBELN/EBELP (coming from EKPO), because neither field alone is selective enough on a live productive system with years of invoice history. Selecting by MATNR or WERKS without a date or company code restriction on RBKP first will scan a large range. When chasing a specific invoice, start from RBKP to confirm the document exists and get GJAHR, then filter RSEG on BELNR and GJAHR together, never BELNR alone, since the same document number is reused across fiscal years.

Symptom: a PO item shows as fully invoiced but the requester insists an invoice is still outstanding. Selection: filter RSEG on EBELN and EBELP for the PO item, sum WRBTR and MENGE across all rows, and check RBKP-STBLG/STJAH on each linked header for a reversal. If the sum of unreversed rows already equals the PO item value, the invoice was posted and matched; the requester is looking at the wrong PO item or a duplicate PO.

RSEG continues to exist as a transparent table in S/4HANA and logistics invoice verification still writes to it directly through the same postings as in ECC. There is no wholesale replacement of RSEG with a CDS-only model at the persistence layer; reporting and Fiori apps for invoice management sit on top of RSEG and RBKP rather than replacing them. Field content is unchanged for the fields listed above, so joins written against ECC continue to work.

A data question on RSEG belongs to the accounts payable or MM invoice verification process owner, since the table is populated purely by invoice postings. Purchasing gets pulled in when the dispute is about which PO item or quantity the invoice was matched to. Basis and technical teams have nothing to add here beyond confirming the table has not been archived for the period in question.

RBKP is the header table for the same invoice document and is the mandatory entry point before reading RSEG. EKPO and EKKO supply the purchase order side of the match. EKBE carries the PO history entries, including the invoice-type entries that should reconcile against RSEG rows. MSEG is the goods receipt line referenced through LFBNR when GR-based invoice verification is active. MIRO, MIR7, and MIRA are the transactions that write RSEG; MIR4 and the invoice display apps read it back.