A return that was re-priced, over-freighted, and lost its reason
Invoice 90012345, dated 05.03, bills 20 EA of material 4711 at a list price of 45.00 EUR with an 8% customer discount and a freight condition of 60.00 EUR, totalling 888.00 EUR. On 12.03 the list price in the condition record rises to 50.00 EUR. On 20.03 the customer returns 5 EA because of a quality complaint. The clerk creates a return order with reference to invoice 90012345, posts the returns delivery and goods receipt, and creates a credit memo request. The resulting credit memo is 290.00 EUR: 5 × 50.00 less 8%, plus the full freight of 60.00. The customer expected 222.00 EUR: 5 × 45.00 less 8%, plus 15.00 of freight. The controller also notes that the return reason is blank on the credit memo although the clerk selected quality in the return order, and that the credit memo is already posted to FI.
1. Explain each difference between the credit memo and the customer's calculation, and identify which setting produces it.
Read the worked answer
Three separate effects. Conflating them leads to the wrong change.
- Price. 5 × 50.00 instead of 5 × 45.00 means the credit memo re-priced from the current condition record rather than adopting the invoice's price components. That is the pricing type in the copy control for the reference documents: new pricing recalculates, while copying price components carries the reference document's values forward. The 12.03 price increase became visible only because of it.
- Freight. 60.00 instead of 15.00: the freight condition was recalculated at full value instead of being apportioned to the returned quantity. Copying price components alone does not fix this - freight needs proportional reduction or deliberate redetermination on the return quantity. Decide explicitly who bears return freight; that is a contract question, not a customizing question.
- The 8% discount is correct in both figures. It was found again on the return, which tells you the customer pricing procedure and access sequence are intact - rule out a pricing master data chase early.
All three feed the FI posting and the tax base, so they must be settled before the document is posted, not after.
2. The controller asks you to correct the posted credit memo. What is the correct handling, and what would you refuse to do?
Read the worked answer
Refuse: changing the credit memo after it has produced an accounting document. Billing documents with FI documents cannot be repriced in place; doing so creates a divergence between SD and FI that reconciliation has to chase for weeks.
Correct handling:
- If the credit memo is still open and no follow-on document exists, cancel it with the reversal reason intended for data errors and re-create it with corrected reference settings. The reversal generates its own accounting document - that is normal and auditable.
- If the customer has already been credited and the amount is small, a subsequent debit or credit memo is usually cheaper than reversal plus re-creation.
- Fix the cause for all future documents: the copy control pricing type and the freight behaviour. A one-off correction without the configuration change guarantees a repeat next month.
- Record the difference and its cause in the internal note of the credit memo request, so the returns analysis can separate a configuration error from a genuine customer complaint.
3. The return reason selected in the return order is blank on the credit memo. Explain why this matters and how you would trace it.
Read the worked answer
Why it matters. The return reason drives the follow-up activity in the returns process (inspection, scrap, refund versus replacement), it is the dimension by which quality and finance analyse return rates, and in many designs it determines whether a credit is granted at all. A blank reason on the document finance actually looks at breaks the analysis at its weakest point.
How to trace it, document against document:
- Is the reason present on the return order item? If not, the problem is at entry - for example a default that a later field change overwrote.
- If it is on the return order but not on the credit memo, it is a data transfer issue between the documents: the field is outside the reference copy scope, or the credit memo request was created without reference to the return order.
- Check the item category used for the return item; a custom item category can exclude the field from the copy.
Fix forward, not backward. Add the field to the copy scope and re-create open documents. And before you raise it as a systemic data quality issue, measure how many credit memos in the last quarter actually lack the reason - one document proves a symptom, not a trend.