SAP SD Partner Determination — Who Orders, Who Receives, Who Pays
The four functions · BP roles · configuration · worked example · troubleshooting · Last updated September 2026
One customer places the order. Another location receives the goods. A third office gets the invoice. Head office pays it. SAP has to connect all four to a single sales order — and get each of them right, because they drive completely different things.
That is partner determination. This guide covers the four functions and what each one controls, how a BP role differs from a partner function, how partners travel from the customer master into the order, the configuration behind it, and what to check when the wrong partner appears.
Written for SAP S/4HANA on-premise and Private Edition; the logic is unchanged from ECC, and in Public Edition the same settings are maintained through configuration apps rather than SAP GUI.
On this page
The four partner functions
Every sales order carries at least these four. They are often the same customer — a small business orders, receives, is invoiced and pays from one account — but SAP keeps them separate because each one drives different data.
Sold-to party
Who placed the order?The commercial relationship: pricing, the sales area, partner defaults, output. Every sales document needs one, and the other three default from its master record.
Ship-to party
Where do the goods go?The delivery address, and with it shipping point and route determination, delivery scheduling and often tax. One sold-to party can have many ship-to parties.
Bill-to party
Who receives the invoice?The address the invoice is sent to, and the output that carries it. It receives the document, not the debt.
Payer
Who pays it?The receivable, payment terms, dunning and credit management. This is the account that carries the open item, which is why it matters to finance.
The distinction interviewers probe: bill-to versus payer. The bill-to party receives the document; the payer owes the money. Credit limits, payment terms and dunning all follow the payer — so in credit management it is the payer’s limit that blocks the order, not the sold-to party’s.
The codes above are the English ones. On a German-language system the same functions appear as AG (sold-to), WE (ship-to), RE (bill-to) and RG (payer) — worth recognising, because plenty of documentation and older projects use them. Beyond the four, standard SAP also delivers functions such as employee responsible, forwarding agent and contact person.
BP role vs partner function
These two get confused constantly, because both sound like “the role the customer plays”. They answer different questions.
BP role — what data exists
A Business Partner role decides which views you can maintain: FLCU00 for company code data, FLCU01 for sales area data. It is a property of the master record and has nothing to do with any document.
Partner function — what it does
A partner function is the job a partner performs in a document: sold-to, ship-to, bill-to, payer. The same business partner can hold several functions in the same order, and a different function in the next one.
The two meet in one practical rule: a business partner can only act as a partner in a sales order if it has the sales role and is extended to that sales area. “The customer is not defined for sales area…” is a BP role problem wearing a partner determination costume.
From customer master to sales order
Partners are maintained once, on the sold-to party’s master record: in the BP transaction, sales area data, on the Partner Functions tab (Customer: Sales Area Data in ECC terms). Each line says “for this function, use this customer”.
When a user enters the sold-to party on an order, SAP reads those lines and fills the order’s Partners tab. If a function has exactly one partner, it is filled silently. If it has several — the usual case for ship-to — SAP proposes one and offers the rest for selection. Users can change what was proposed, unless the function is flagged as not modifiable.
To inspect the result, open the order and go to the Partners tab at header level, or the Partners tab of an item when partners differ per item. That tab is the first place to look in any partner problem: it tells you what SAP actually used, which is often not what the person reporting the issue assumed.
Partner determination configuration
Configuration lives in VOPAN (older systems: VOPA), under Sales and Distribution → Basic Functions → Partner Determination → Set Up Partner Determination. You configure one partner object at a time — customer master, sales document header, sales document item, delivery, billing header, billing item — and each has the same four-part structure: partner functions, procedures, functions in the procedure, and the assignment of the procedure.
Check the partner functions exist
VOPAN → Partner functions
Standard SAP already delivers SP, SH, BP and PY (AG, WE, RE and RG in German), plus employee responsible, forwarding agent and contact person. You only create new ones for genuinely new roles.
Build the procedure for the customer master
VOPAN → Customer master → Partner functions in procedure
List the functions a customer record may hold, and flag each one as mandatory or not modifiable. Mandatory here means the customer cannot be saved without it, which is how SAP guarantees an order always finds a ship-to, bill-to and payer.
Assign the procedure to the account group
VOPAN → Customer master → Partner determination procedure assignment
Sold-to customers (account group 0001) get the full procedure; ship-to (0002), payer (0003) and bill-to (0004) get much shorter ones, because a ship-to record does not need a payer of its own.
Restrict which account groups may fill a function
VOPAN → Customer master → Account groups — function assignment
This is what stops a ship-to-only record being entered as the payer. If a user cannot pick a customer for a function, this table is usually why.
Do the same for the sales document
VOPAN → Sales document header (and item) → procedure and assignment
The header procedure is assigned to the sales document type, and decides which partners the order must carry and whether users may change them. The item procedure is assigned to the item category and is what allows a different ship-to per item.
And for delivery and billing
VOPAN → Delivery / Billing header and item
Delivery and billing documents have their own procedures, assigned to the delivery type and billing type. In practice they copy what the order already determined — the procedures mainly control what may still be changed.
Two flags do most of the work: mandatory guarantees the partner exists, and not modifiable stops anyone changing it in the document. Payer is the classic candidate for both — finance rarely wants a sales user reassigning who owes the money.
Worked example: four parties, one order
A retail chain buys centrally, receives locally and pays from head office. Four customer records, one order.
Scroll the diagram sideways to see all of it →
One sales order, four partner functions — each pointing at a different location of the same customer.
| Function | Partner | Why it matters |
|---|---|---|
| SP — Sold-to party | RetailChain Purchasing Office, Gurugram (account group 0001) | Places the order and negotiates prices. Entered on the order; everything else defaults from its master record. |
| SH — Ship-to party | RetailChain Store, Noida (0002) | Receives the goods. Drives the delivery address, the shipping point and the route. |
| BP — Bill-to party | RetailChain Accounts Office, Noida (0004) | Receives the invoice document and its output. |
| PY — Payer | RetailChain Head Office, Mumbai (0003) | Carries the receivable, the payment terms and the credit limit. Dunning goes here. |
Only the sold-to party is typed in. The other three are maintained once on its master record and appear automatically. Setting it up needs the ship-to, bill-to and payer records to exist in the right account groups, each extended to the sales area, and the sold-to party’s Partner Functions tab to point at them.
The consequences run through the whole process: the Noida store’s address drives shipping point and route determination, the accounts office receives the printed invoice, and head office’s credit limit is the one checked when the order is saved. Point any one of them at the wrong record and the error surfaces somewhere else entirely — a delivery to the wrong city, or a credit block nobody expected.
Delivery and billing
Deliveries and billing documents have their own partner procedures, but they rarely start from scratch: the partners are copied from the sales order and then filtered by the procedure assigned to the delivery type or billing type. The delivery follows the ship-to party; the invoice follows the bill-to party and the payer.
One consequence is worth remembering: changing a partner on the order after the invoice exists does not change the invoice. Documents already created keep the partners they were created with, so the correction belongs in a credit memo or a cancellation, not in the order.
Troubleshooting
The order asks for a partner the user cannot supply
- ·The function is mandatory in the sales document header procedure but is not maintained on the sold-to party
- ·The customer master procedure does not include the function, so it was never maintained
Fix: Add the missing partner on the sold-to party’s master record, in the sales area data. The order picks it up on re-entry; existing orders need the partner added manually.
The wrong ship-to or payer appears on the order
- ·The sold-to party’s master record has more than one partner for the function and SAP proposed the default
- ·The order was created with reference to an older document and copied its partners
- ·Somebody changed the partner manually on the order
Fix: Open the Partners tab on the order and compare it with the customer master. If the master is right and the order is not, it came from a reference document or a manual change — not from configuration.
A customer cannot be entered for a function
- ·The customer’s account group is not allowed for that function
- ·The customer is not extended to the sales area of the order
Fix: Check the account group to function assignment in the customer master procedure, and check that the customer exists in the order’s sales area.
The user cannot change a partner on the order
- ·The function is flagged as not modifiable in the sales document header procedure
Fix: That is the flag doing its job — usually set for the payer so nobody can move a receivable to another account. Change it only with finance’s agreement.
Interview questions
What are the four mandatory partner functions in a sales order?
Sold-to party, ship-to party, bill-to party and payer. The sold-to is entered; the other three default from its customer master, and they can all be the same customer.
What is the difference between the bill-to party and the payer?
The bill-to party receives the invoice document. The payer carries the receivable, the payment terms and the credit limit, and receives the dunning. In most orders they are the same customer, and interviewers ask precisely because they often are not.
What is the difference between a BP role and a partner function?
A BP role says what data a business partner has — FLCU00 for company code data, FLCU01 for sales area data. A partner function says what that business partner does in a document: sold-to, ship-to, bill-to, payer. A BP needs the sales role before it can act as a partner in a sales order.
Where are partner determination procedures configured?
In VOPAN (or VOPA), per partner object: customer master, sales document header and item, delivery, billing header and item, contact person and sales activity. The customer master procedure is assigned to the account group; the sales document header procedure to the sales document type; the item procedure to the item category.
A customer has 50 ship-to locations. How does the order pick one?
All of them are maintained as ship-to partners on the sold-to party. When an order is created, SAP proposes the default and the user can choose another from the list. Restricting the choice is a master data question, not a configuration one.
How do partners reach the delivery and the invoice?
They are copied from the sales order, then filtered by the delivery or billing procedure. The delivery follows the ship-to party, the invoice follows the bill-to and payer. That is why changing a partner on an order after delivery does not fix an invoice already created.
Where this sits in the SD landscape
Partner determination is one of the first things that happens in the Order-to-Cash process, and almost everything downstream depends on it: the ship-to party feeds shipping point determination, the payer feeds credit management, and the records themselves are Business Partners in S/4HANA.
Frequently Asked Questions
What is partner determination in SAP SD?
Partner determination is how SAP decides which business partners appear in a sales document and in which role. Partner determination procedures list the allowed functions for each object — customer master, sales document, delivery, billing document — and say which are mandatory and which may be changed.
What is the difference between sold-to, ship-to, bill-to and payer?
The sold-to party places the order, the ship-to party receives the goods, the bill-to party receives the invoice and the payer pays it and carries the receivable. They are often the same customer, but each drives different data: pricing, delivery address, invoice address and payment terms respectively.
Which transaction is used for partner determination?
VOPAN (older systems also use VOPA), reached in customizing through Sales and Distribution → Basic Functions → Partner Determination → Set Up Partner Determination.
What is the difference between a BP role and a partner function?
A BP role defines which master data views a business partner has, such as FLCU00 for company code data and FLCU01 for sales area data. A partner function defines the role the partner plays in a document. A partner function cannot be used if the business partner does not have the matching role and sales area data.
Why is the wrong ship-to party appearing in my sales order?
Usually the sold-to party has several ship-to partners and SAP proposed the default, the order was created with reference to an older document, or the partner was changed manually. Compare the order’s Partners tab with the customer master first.
Can a sales order have a different ship-to party per item?
Yes, if the partner determination procedure assigned to the item category includes the ship-to function. Items with different ship-to parties are then delivered separately.
Can one customer be all four partners?
Yes, and this is the most common case. A single customer master record can act as sold-to, ship-to, bill-to and payer at the same time.
Written by
Rahul Narain Saxena
SAP SD Solution Architect with 17+ years of hands-on implementation experience across SAP ECC and S/4HANA. Every guide on The SD Vault is written from live project experience, not summarised from documentation.
“What is the difference between bill-to and payer?”
It sounds like a beginner question until you have to explain which one the credit check uses. The SD Vault has 230+ depth-graded questions and 38 real configuration scenarios — including a four-party partner determination scenario — built from live projects.
Get Lifetime Access →Or start free with the sample pack, Business Partner guide, and Order-to-Cash guide.