BSEC table — One-Time Customer/Vendor Data Segment

One row in BSEC represents the master-data-like information entered directly on a single document line item that was posted against a one-time account, identified in BSEG by the CPD flag. Rather than pulling name, address, bank details and tax numbers from KNA1 or LFA1, the system lets the person posting the invoice or payment type these values in at the time of entry, because setting up a full permanent master record for a party who will only transact once is not worth the administrative overhead. The row is tied one-to-one to the document line it belongs to; it carries no independent existence and is never shared across documents, even if the same one-time party is used again on a later posting.

Always restrict on MANDT first. Beyond that, the practical selection is the full document key: company code, document number, fiscal year, and ideally the line item number, since a BSEC row is meaningless without knowing which line it belongs to. The table is small compared to BSEG because only CPD-flagged lines generate a row, so there is little value in scanning it broadly by name or address fields; those are free-text and not indexed for search. If the starting point is a business partner name rather than a document, it is faster to search BSEG for CPD-flagged lines within a date or company code range first, then pull BSEC for the specific line items found.

Symptom: a payment run sent funds to the wrong bank account for a one-time vendor. Take the document number, company code and fiscal year from the payment or the originating invoice, select BSEG for that key with XCPDD equal to X to confirm it is a one-time posting, then select BSEC on the same BUKRS/BELNR/GJAHR/BUZEI and compare BANKL and BANKN against what the vendor actually communicated. A mismatch confirms the wrong bank details were typed in at entry, not a master data or bank master problem.

BSEC is retained in S/4HANA and continues to be populated the same way for documents posted to one-time accounts through classic FI posting transactions. It has not been absorbed into ACDOCA, because ACDOCA is built around universal journal line items and does not carry free-text address or bank fields; BSEC remains the authoritative source for that data. The Business Partner model used for other master data does not change how one-time account postings capture this information, so lookups and joins written against BSEC continue to work unchanged.

Accounts payable or accounts receivable teams posting one-time invoices and payments own the accuracy of what goes into BSEC, since it is entered manually at posting time. Configuration ownership of the CPD reconciliation accounts themselves sits with the FI configuration team. Any decision to convert a recurring one-time party into a permanent master record is a master data governance question, not a BSEC data question.

BSEG carries the line item and the CPD flag that determines whether a BSEC row exists; BKPF supplies the document header. BSID and BSIK carry the open item positions for one-time customer and vendor postings against the CPD reconciliation account. Transactions such as invoice entry and manual posting screens where the one-time account indicator is set are where BSEC rows originate; there is no dedicated maintenance transaction for BSEC itself since it is only ever written as a byproduct of document posting.