power bi

Sold-to, ship-to, bill-to and payer in SAP: who is actually your customer?

Sold-to, ship-to, bill-to and payer in SAP explained with a concrete example: who gets the invoice, whose account the receivable sits on, and which customer to use in your reports.

Sketch of a sales order surrounded by four partner roles: a contract (sold-to), a parcel (ship-to), an envelope (bill-to) and two euro coins (payer).

Every sales order in SAP carries at least four partner roles: sold-to, ship-to, bill-to and payer. Most of the time all four point to the same customer. Once you sell to larger organisations, with a central purchasing team, a separate accounts payable department and sites in different locations, the roles start to split.

That is when the same question keeps coming up: if I sell to one party and invoice another, whose account does the receivable end up on? This article walks through the four roles with a concrete example and looks at what happens in the books on both sides.

The four partner roles

Each role answers a different question about the same order. By default, SAP copies the sold-to into the other three roles. You can change any of them separately, either in the customer master data or on the order itself.

RoleSAP code (EN / DE)Question it answers
Sold-to partySP / AGWho places the order, and who is the contract with?
Ship-to partySH / WEWhere do the goods go?
Bill-to partyBP / REWho receives the invoice?
PayerPY / RGWho owes us the money?

Sold-to is the commercial customer. SAP uses it to determine prices and discounts, and it is the customer your sales reporting books the revenue under. By default, the VAT number on the invoice also comes from the sold-to.

Ship-to is the delivery address. The goods go there, and it also drives things like transport planning and shipping conditions.

Bill-to only receives the invoice. Its address is printed on the invoice, and the invoice itself (on paper, by email or through EDI) is sent there. Financially, this role barely matters in SAP.

Payer is where the accounting happens. The open receivable sits on the payer's customer account, SAP checks the credit limit against the payer, and dunning letters go to the payer.

People who say the bill-to is the party that has to pay usually mean the payer. The bill-to decides where the invoice goes. The payer decides whose account the receivable is on.

An example: coffee machines for a hotel group

Say you sell professional coffee machines to a hotel group with hotels across Belgium.

  • Sold-to: Hotel Group Belgium NV, the central purchasing team in Brussels. They negotiated the framework agreement and place the orders, so their contract prices apply.
  • Ship-to: the hotel in Ghent that needs the machine.
  • Bill-to: the group's shared service centre in Antwerp, which processes all incoming invoices.
  • Payer: Hotel Group Belgium NV again, or a holding company that pays all suppliers centrally.

Purchasing negotiates, the hotel gets the machine, accounts payable gets the invoice and treasury pays. One order, four addresses, each with its own job.

What happens in your books?

As the seller, you post one sale and one receivable. The four roles do not create four postings.

  • Revenue goes to your revenue account, with the sold-to as the dimension for sales and margin analysis.
  • The receivable (debit customer, credit revenue and VAT payable) is posted to the payer's customer account in FI-AR, SAP's accounts receivable module.
  • When the payment comes in, you clear it against the payer's open item.
  • The bill-to does not appear in the posting at all. It only decides where the invoice is sent.

In the example, the receivable sits on Hotel Group Belgium NV (or the holding company), even though the invoice physically lands in Antwerp.

And on the customer's side?

For the customer, it all comes down to one question: are the sold-to and the bill-to the same legal entity?

Same company, different addresses. This is the most common case. The bill-to is simply an address, such as “Hotel Group Belgium NV, attn. Accounts Payable, Antwerp”. The group books one purchase invoice, deducts the VAT and charges the cost to the Ghent hotel through a cost centre.

Different companies. This is where you need to be careful. An invoice has to show the name and VAT number of the customer you have the contract with. If the sold-to is company A but the invoice goes to company B, B may not be able to deduct the VAT, and A and B will have to recharge the cost between them.

That is why most companies make sure the sold-to and the payer are the same legal entity, and use the bill-to only to get the invoice to the right department.

Why this matters for your reporting

If you bring SAP data into Power BI or Microsoft Fabric, you will run into this sooner or later. Sales reporting and receivables reporting each start from a different customer role. Mix them up and your numbers will not reconcile.

ReportCustomer roleSAP table and field
Revenue by customer, order bookSold-toKUNAG in VBAK and VBRK
Deliveries by locationShip-toKUNNR in LIKP
Open items, DSO, dunningPayerKUNRG in VBRK, KUNNR in BSID or ACDOCA

So a customer with high revenue but no open items is not necessarily an error. Another company in the same group may simply be paying.

In short

The sold-to is the contract and the prices. The ship-to is the delivery address. The bill-to is the mailbox for the invoice. The payer is the debtor in your books.

Working with SAP data and want reports where sales and finance see the same numbers? At Data Panda we build Power BI and Fabric solutions for Belgian SMEs that model these differences correctly from day one. Get in touch for a no-obligation conversation.

Liked this piece? Let's talk.

A no-strings advisory call. We'll tell you honestly what's realistic, or point you elsewhere.

Book a discovery call