PAYR table — PAYR Table for Payment Medium Data

One row in PAYR represents a single payment medium item created by the payment program for a specific company code, house bank, and house bank account. This is not limited to physical checks: the CHECT field is a sequential number assigned to any payment medium the payment program generates, including wire transfers and other electronic methods, so the table is really the payment medium ledger of the payment run, not a check-only table. Each row points back to the payment run that produced it and to the accounting document that was cleared by that payment. It also carries the amount, currency, payee, and value date actually printed or transmitted, plus void information if the check was cancelled or reissued after the run.

MANDT is the client and should already be fixed by the system logon, never selected on manually. Never select on PAYR by RWBTR, ZALDT, or NAME1 alone; none of these are strongly indexed and a broad range on a productive client can return an unusable result set. The safe entry point is the composite key ZBUKR plus HBKID plus HKTID plus CHECT for a single lookup, or LAUFD plus LAUFI when starting from a known payment run and joining through REGUH. Restrict to company code first in every case; the same check or payment medium number can legitimately repeat across different company codes or house banks, since CHECT is only unique within that combination.

A vendor claims a check was never received. Find the payment document number and company code from the vendor line item, then select PAYR where ZBUKR and VBLNR match. Read CHECT, HBKID, HKTID and ZALDT from the result, and check VOIDR and VOIDD to see whether the check was voided or reissued after the original run. If VOIDR is populated, follow up with the void/reissue transaction history rather than treating the original PAYR row as the final answer.

PAYR is retained in S/4HANA in the same shape and is still written by the classic payment program that underlies both the older payment run transaction and the newer payment run applications built on top of it. It has not been replaced by a CDS compatibility view and is not part of the ACDOCA universal journal, since it is a payment medium record rather than a financial document. Consultants working payment or check disputes on S/4HANA still query it exactly as on ECC.

Most PAYR investigations go wrong from one of a handful of wrong assumptions about what the table actually records.

Accounts payable and treasury own questions about specific checks or payment references, since they own the payment run configuration and the house bank setup that feeds PAYR. FI configuration owns the payment method and house bank master data that determines which company code and account combinations can appear in the table. A GL or reporting team rarely has reason to query PAYR directly.

REGUH and REGUP hold the payment run proposal and header data that PAYR is generated from, and are the usual starting point when investigating a specific payment run rather than a single check. BKPF and BSEG hold the accounting document that the payment cleared. The payment run itself is executed and monitored through the automatic payment program transaction, and check-specific follow-up actions such as voiding or reprinting are done through the dedicated check management transactions rather than by editing PAYR directly.