REGUP table — Payment Run Line Items Table
REGUP stores one row per open item selected by a payment run (F110), either in the proposal step or the final run step. It records which vendor or customer document is being paid, the amount selected, the payment method and house bank chosen, and eventually the payment document number generated. It is history written by F110, not a live cleared-item status table.
This page covers what a REGUP row actually represents in a payment run, the fields worth trusting, and the joins back to REGUH, PAYR and the open-item tables. The pitfalls section focuses on the most common misreading: treating a proposal row as proof of payment.
Published 15 Sept 2026· 1,033 words
What it stores
One row in REGUP represents a single open item that a payment run picked up for processing, tagged to a specific payment run identification. The same open item can appear twice across the life of a run: once when the proposal is generated (flagged as proposal) and again when the final run executes and actually creates a payment document. Rows cover both vendor payments and incoming customer payments, since the same run structure handles both. The table is written exclusively by the payment program (F110); nobody enters or edits REGUP rows manually. Because it is populated per run, the same underlying invoice can show up in several different run IDs over time if it was rejected, deselected, or re-run, so row count is not the same as payment count.
Key fields
- MANDT - client
- LAUFD - payment run date, part of the run identification key
- LAUFI - payment run identification, the free-text ID entered when the run was scheduled
- XVORL - marks the row as belonging to the payment proposal versus the final executed run
- ZBUKR - paying company code that actually disburses or receives the funds
- LIFNR - vendor account number, populated when the item is an outgoing vendor payment
- KUNNR - customer account number, populated when the item is an incoming customer payment
- BUKRS - company code of the underlying accounting document being paid
- BELNR - accounting document number of the open item selected for payment
- GJAHR - fiscal year of that accounting document
- BUZEI - line item number within that document
- WRBTR - amount in document currency selected for payment on that item
- ZLSCH - payment method applied to the item
- HBKID - house bank ID chosen for the payment
- VBLNR - number of the payment document generated, the pointer into PAYR
How it joins the data model
- REGUP-LAUFD/LAUFI/XVORL/ZBUKR = REGUH-LAUFD/LAUFI/XVORL/ZBUKR to reach the run header, bank data and totals
- REGUP-BUKRS/BELNR/GJAHR/BUZEI = BSEG-BUKRS/BELNR/GJAHR/BUZEI to reach the actual open item line being paid
- REGUP-BUKRS/BELNR/GJAHR/BUZEI = BSIK/BSAK-BUKRS/BELNR/GJAHR/BUZEI for vendor open or cleared status
- REGUP-BUKRS/BELNR/GJAHR/BUZEI = BSID/BSAD-BUKRS/BELNR/GJAHR/BUZEI for customer open or cleared status
- REGUP-VBLNR = PAYR-VBLNR to reach the check or DME payment document actually produced
How to read it safely
MANDT is the client field as usual. The table is not selective on any single field except the run identification, so a query should always start with LAUFD and LAUFI, then XVORL, before broadening to vendor or company code. Without a run ID, REGUP behaves like BSEG in scale: on a busy AP shop it accumulates a very large number of rows across years of runs, since old runs are not routinely purged. Restrict ZBUKR next if the site pays through several paying company codes. Only pull LIFNR or KUNNR after the run is pinned down, otherwise the same vendor across dozens of historical runs returns noise.
How to prove it in the data
Symptom: a vendor claims an invoice was not paid in a specific run. Select REGUP with LAUFD/LAUFI matching that run, LIFNR equal to the vendor, and BELNR equal to the invoice document. No row at all means the item was never picked up, likely blocked, not yet due, or excluded by parameters; check BSIK for its block indicator and due date. A row with XVORL set and no counterpart at XVORL blank means it made the proposal but was dropped or deselected before the final run executed.
ECC vs S/4HANA
REGUP is retained in S/4HANA and is still populated directly by the payment program; there is no known compatibility view replacing it the way ACDOCA-based views sit over BSEG. Payment run processing logic and the REGUH/REGUP/PAYR structure remain functionally the same, so joins and diagnostic approaches built on ECC continue to apply without a structural rewrite.
Common pitfalls
- A proposal row (XVORL set) is not proof of payment. Proposals are routinely edited, items deselected, or the whole proposal deleted and rerun; only a final-run row with a populated VBLNR corresponds to an actual generated payment document.
- REGUP is not the authoritative source for cleared status. An item can appear in REGUP and still fail downstream (bank rejection, reversed payment run) without REGUP being cleaned up in the way a consultant expects. Always confirm against the clearing document field on BSAK or BSID/BSAD before declaring an item paid.
- Joining on BELNR alone without GJAHR and BUZEI produces duplicate or wrong matches when document numbers repeat across fiscal years or the document has multiple lines.
- Counting REGUP rows to answer 'how many times was this paid' overstates reality, since the same open item legitimately generates multiple rows across proposal, rerun, and rejected-and-resubmitted runs.
- WRBTR reflects the amount selected for payment at proposal or run time, not necessarily the amount that actually left the bank after cash discount or withholding tax adjustments applied later; reconcile against REGUH totals or bank statement data for the final transferred amount.
- Assuming the table is purged after archiving jobs run. Unless archiving for payment runs has actually been executed and confirmed, historical REGUP rows persist indefinitely and the table keeps growing.
Whose problem this is
The AP or AR functional consultant owns interpretation of what a given payment run row means for a specific vendor or customer. Treasury or cash management ownership applies to house bank determination and payment method configuration behind ZLSCH and HBKID. Basis owns retention and archiving of the historical volume.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/regupERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.