BAPI_CUSTOMER_GETLIST — BAPI_CUSTOMER_GETLIST customer master lookup

BAPI_CUSTOMER_GETLIST searches the customer master by criteria rather than by a known customer number. It acts on the general data and address segments of the customer object, the same data a user would search against on the customer search help or the classic XD03 matchcode. It does not return company code data (reconciliation account, payment terms) or sales area data (pricing, delivering plant, customer group). Interfaces call it when they need to resolve a customer from partial information, for example matching an incoming EDI partner by name and postal code, or building a picklist for an integration scenario where the exact customer number is not yet known. It is a finder, not a full master data extract, and every downstream step that needs commercial data has to follow up with a separate read.

The interface is selection-in, list-out, with no update capability. Key parameters, described where the exact field structure is not something to state with certainty:

There is nothing to commit. BAPI_CUSTOMER_GETLIST only reads; it does not open a database LUW that needs BAPI_TRANSACTION_COMMIT, and calling commit after it is a harmless no-op. The risk on this BAPI is not a missing commit, it is a caller assuming the read reflects the very latest state of a customer changed moments earlier in a parallel session and not yet committed there, which produces a stale or missing row rather than a locking error.

RETURN is a table, and on a clean search with matches it is typically empty even though CUSTOMERLIST is full of rows. That is the first trap: a caller who checks RETURN for content and treats empty as failure will incorrectly abort a perfectly successful zero-match search, because a legitimate no-match result also leaves RETURN empty. The correct read is to check RETURN for entries of type E or A first, and only then interpret an empty CUSTOMERLIST as a genuine no-match rather than an error. The second trap is MAXROWS truncation: when the row cap is hit, the call does not raise a warning in RETURN, it simply stops filling CUSTOMERLIST, so a caller who assumes the returned list is complete builds downstream processing on a partial customer population without any signal that data was cut off. Interfaces that page through large customer master files by calling this BAPI repeatedly with an incrementing range need to detect the truncation themselves by comparing returned row count against MAXROWS, since the BAPI will not tell them.

On S/4HANA the customer master is a business partner with customer role, and customer-vendor integration keeps the classic customer tables populated for compatibility. BAPI_CUSTOMER_GETLIST still runs and still returns results, but new integration builds are steered toward business partner search capabilities, including the business partner API service, rather than this legacy BAPI. It remains acceptable for maintaining existing ECC-era interfaces; it is not the recommended starting point for a new build.

Most incidents trace back to treating the returned list as more complete or more detailed than it actually is.

This sits with the interface developer first, since the failure modes are almost entirely about how the caller reads RETURN and handles MAXROWS, not about the master data itself. Functional gets pulled in only when the search genuinely returns the wrong customers, in which case they need the exact selection criteria used and a screenshot of the equivalent manual search for comparison.

The manual equivalent is the customer search on XD03 or the business partner transaction. The underlying tables are the general customer master table and its address table. The natural sibling for write operations is BAPI_CUSTOMER_CHANGEFROMDATA1, used once the correct customer number has been resolved from a GETLIST search.