REGUH table — REGUH Payment Run Header Table

A row in REGUH represents one payee within one payment run: the combination of company code, payment run date, run identification, payee, house bank, and payment method that the payment program decided to pay together. It is a header record, not an accounting document. It carries the total amount and currency for that payee in that run, the value date, the payment method used, and the address data copied at the time of the run. Multiple open items belonging to the same vendor or customer, selected in the same run and payable through the same method and bank, get bundled into one REGUH row, with the individual items sitting one level down in REGUP. Proposal runs (not yet finalized into payment) and live runs both write to REGUH, distinguished by the proposal indicator.

MANDT is implicit in any client-specific query and rarely needs explicit thought, but never scan across clients. The real selectivity comes from LAUFD and LAUFI together with ZBUKR: a run is only unique across that triple, and there is no single natural key without it. Never query REGUH by amount or date range alone across all runs; the table accumulates every payment run the company has ever executed and full scans on large productive systems are slow and get flagged by Basis. If the run identifier is not known, start from the vendor or customer master (LIFNR or KUNNR) and a rough date window, then narrow to the specific LAUFD/LAUFI once a candidate row appears.

Symptom: a vendor claims a payment made three weeks ago was never received. Select REGUH where LIFNR equals the vendor and ZBUKR equals the paying company code, restricted to the plausible date window, and inspect LAUFD, LAUFI, RWBTR, WAERS, RZAWE, and VALUT. If a row exists, take LAUFD/LAUFI into REGUP to find VBLNR, then check BKPF/BSEG to confirm the accounting document actually posted and was not reversed. If no REGUH row exists at all for that vendor in the window, the item was never selected into a run in the first place, which points back to open item blocks or payment terms, not to a failed payment.

REGUH continues to exist and function the same way in S/4HANA. The automatic payment program architecture around it (proposal, run, payment media) has not been restructured the way the general ledger was with the move to ACDOCA. There is no compatibility view replacing REGUH for standard reporting; it remains a direct transactional table read by F110 and downstream payment medium processing, and consultants query it the same way in either release.

The temptation with REGUH is to treat a row as proof that money left the bank. It is proof that the payment program decided to pay, nothing more.

Payment run configuration and outcomes belong to the accounts payable or accounts receivable process owner running F110, with treasury involved once bank confirmation or return handling is in question. Basis or the technical team owns archiving policy for the table's growth. A functional consultant reading REGUH during an incident should already know which team configured the payment method and house bank before escalating.

REGUP holds the item-level detail bundled under each REGUH row and is the first place to drill from a header. PAYR holds the payment medium (check number or DME reference) produced from a run. BSIK and BSAK hold the vendor open and cleared items the run actually selected. BKPF and BSEG hold the accounting document the payment program posts once a run executes. The relevant transactions are F110 for running and monitoring payment proposals, FBZP for payment program configuration, and FB03 for inspecting the resulting accounting document.