A new sales organization, an incomplete customer extension, and a zero credit limit
Your company went live in SAP S/4HANA with a new sales organization 1710 (distribution channel 01, division 00) serving company code 1710. Customer 0000100234 already trades through sales organization 1010 and was extended to 1710 by a data-load job. The job created the sales area data but filled only the partner functions Sold-to party and Ship-to party; Bill-to party and Payer were left blank. Order entry in 1710 works, deliveries run, and goods issue posts. However, every 1710 invoice stays in the billing due list with the message that no payer could be determined, so no FI document is created - roughly 40 invoices per day. The order types used in 1710 do not mark the payer as a mandatory field, so orders save with a blank payer. The key user also reports a credit limit of 0.00 EUR for 1710, although 250,000 EUR exists for 1010. Company code 1710 posts to credit control area 1710; company code 1010 to credit control area 1010.
1. Orders save and deliveries run, but billing blocks. Explain the failure chain and state, in order, which master data you inspect.
Read the worked answer
Why the order still succeeds. The payer is a header field only. Because your order types do not treat it as mandatory, the incompletion procedure never fires, and delivery and goods issue do not need a payer. The defect surfaces only where the payer is consumed.
Why billing blocks. The billing document takes the payer from the order, and the accounting interface needs a customer with company code data for the billing company code. With a blank payer no debtor can be determined, so the document stays in the due list.
Inspection order, cheapest first:
- Open an affected order and confirm the payer is blank - this proves it is master data, not billing customizing.
- Display customer 0000100234 in the BP transaction for sales area 1710/01/00 and check the partner function assignments for bill-to and payer.
- Check that the assigned payer BP itself carries the customer role with company code 1710 data (reconciliation account, payment terms).
- Only then look at billing customizing - 1010 bills correctly with the same configuration, so customizing is the least likely cause.
2. Is the 0.00 credit limit a bug? Recommend a decision and justify it.
Read the worked answer
No - it is expected behaviour. A credit limit is not sales-area data. It is maintained on the business partner in the credit management role, per credit control area (and per credit segment where used). The 250,000 EUR exists for credit control area 1010 only. Company code 1710 is assigned to a different credit control area, so customer 0000100234 has no credit account there and the exposed limit is zero.
This is a business decision before it is a configuration task:
- Option A - assign company code 1710 to credit control area 1010. You inherit the 250,000 EUR, but the limit is then shared: exposure from 1010 and 1710 is aggregated against one number. Sensible if both entities are managed as one credit risk.
- Option B - keep a separate control area and create a limit for 1710. Cleaner if the legal entities carry separate credit insurance or separate risk owners, at the cost of two limits and two review cycles.
Whichever you choose, check the credit check rule on the order types. With a limit of zero, orders are either blocked at entry or waved through depending on the setting for zero-limit customers - an inconsistency that will hide the problem until month end.
3. Design a control that would have caught this before go-live, and say what it checks.
Read the worked answer
Use a data-quality report, not a checklist.
- Select all customers with at least one completed sales area and verify that each partner function required by the order-to-cash cycle (sold-to, ship-to, bill-to, payer) is filled and points to a BP holding a valid role and company code data.
- Run it as a mass check on the migrated population, and then as a recurring job, because the same gap appears whenever an existing customer is extended into a new sales area later.
- Complement it at runtime: make the payer mandatory in the incompletion procedure for the order types involved. The order then fails while the clerk still has the customer on the phone, instead of three days later in billing.
- Add a smoke test to the rollout playbook: one order → delivery → goods issue → invoice → FI document for each new sales area and order type. It costs an hour and would have failed on the very first invoice.