Partner Functions and Partner Determination Procedures in Sales Documents
Learn how partner functions (Sold-to, Ship-to, Bill-to, Payer) are defined, grouped into partner determination procedures, and assigned to account groups and sales document types so the correct business partners flow automatically into every sales transaction.
Explanation
Every sales order, delivery, and billing document needs to know who ordered, who receives goods, who gets billed, and who pays. SAP handles this through partner functions and partner determination procedures, which are the configuration backbone connecting customer master data to transactional documents. Partner functions are roles such as Sold-to Party (AG), Ship-to Party (WE), Bill-to Party (RE), and Payer (RG). Each function has a defined purpose in the document flow: the Sold-to is the legal contracting party, the Ship-to determines the delivering plant and shipping conditions, the Bill-to receives the invoice document, and the Payer is who Finance dunns and applies incoming payments against. A single customer master can hold multiple partner functions simultaneously, or a business network can split them across different customer numbers (a common pattern for retail chains where headquarters is Sold-to/Payer and individual stores are Ship-to). Partner determination procedures group the allowed and mandatory partner functions for a given object type: customer master account group, sales document header, sales document item, and delivery. Configuration defines which functions are mandatory, which are optional, which can be changed manually in the document, and the source of the default value (usually inherited from the customer master's own partner determination, then overridden if item-level shipping conditions differ, such as a partial shipment to an alternate Ship-to). At runtime, when a sales order is created, the system reads the Sold-to's customer master partner data, resolves the procedure assigned to the sales document type, and populates the partner tab automatically. If a Ship-to differs from the Sold-to's default, the user can change it, provided the customer master maintains a valid ship-to relationship (via customer hierarchy or explicit partner assignment). Downstream, delivery creation and billing document creation reread the same procedures to ensure consistency; the Bill-to on the invoice must always trace back through a valid partner assignment, or the billing document will not release correctly to accounting. Misconfiguration typically shows up as sales orders failing to default a mandatory partner (blocking save), or invoices going to the wrong Bill-to because the account group's default determination points to the Sold-to instead of a maintained Bill-to relationship. In S/4HANA, the underlying partner function framework is functionally similar to ECC, but partner data is now stored and displayed through the Business Partner object; the classic customer partner screens are technically mapped onto BP relationships (BP roles FLCU00/FLCU01 and related relationship categories), so consultants troubleshooting partner defaults in S/4HANA often need to inspect the BP relationship maintenance rather than only the classic customer transaction, especially when relationships were created through data migration rather than manual maintenance. Getting this configuration right matters commercially: incorrect Bill-to determination causes invoices to reach the wrong entity, delaying payment and creating credit management noise; incorrect Ship-to determination causes goods to be shipped to the wrong location, generating costly logistics corrections and customer dissatisfaction.
Real project scenario
A consumer goods client onboarded a large retail chain where headquarters negotiates contracts and pays invoices, but forty individual stores each receive separate deliveries. The project team modeled headquarters as the Sold-to and Payer, and each store as a distinct customer number acting as Ship-to, linked through customer hierarchy and explicit ship-to partner assignments on the headquarters record. During UAT, testers found that orders entered against headquarters defaulted correctly to the headquarters address for billing but required the ship-to to be manually selected per order line for split deliveries. The team updated the item-level partner determination procedure to allow ship-to override at item level (not just header level) so a single sales order could ship to multiple stores in one document, matching the client's centralized ordering process.
Common mistakes
• Assuming one customer master automatically implies correct partner defaults without checking the account group's assigned partner determination procedure • Making a partner function mandatory at header level when the business process actually requires it to vary at item level (e.g., split shipments) • Forgetting that Bill-to and Payer are distinct roles; treating them as interchangeable causes invoices and dunning notices to go to different, sometimes incorrect, parties • In S/4HANA, editing customer partner data directly without checking the corresponding Business Partner relationship, leading to inconsistent records between the classic view and BP • Not testing partner defaulting end-to-end through delivery and billing, only checking the sales order screen
Best practices
• Map out required partner roles during the business blueprint phase before configuring account groups and procedures • Keep partner determination procedures as simple as possible per document type; avoid excessive optional functions that confuse end users • Test the full document flow (order, delivery, billing) whenever a partner determination procedure changes, not just the sales order transaction • In S/4HANA, validate BP relationship categories align with the classic partner functions expected by SD, especially after data migration from ECC • Document which partner function drives credit management exposure (typically the Payer) so Finance and Sales share a common understanding
Interview angle
Interviewers often probe whether a candidate understands the difference between the Sold-to, Ship-to, Bill-to, and Payer roles and can explain a real scenario where all four are different customers. A strong answer describes the partner determination procedure's role in defaulting these values and explains what happens downstream in delivery and billing if the Bill-to or Payer configuration is wrong, showing awareness of the financial impact, not just the configuration mechanics.