A customer calls about an invoice. The price is wrong, not catastrophically, about four percent low on one line. Someone pulls up the sales order and confirms it: the order carried that price too, and the delivery and the billing document dutifully copied it forward.
So who set it?
Nobody did. That is the thing about SD that catches people who come to it from other modules. The price on that order was never entered by a person or stored anywhere as a value. It was **found**, the result of a search through condition records that ran at the moment the line item was created, and would run differently today.
In SAP SD, a price is not a value. It is the output of a search. Testing that a price is correct means testing that the search found the right thing, which is a different assertion entirely.
This piece covers what that means for validating order-to-cash, what agents in this flow actually decide, why detecting an SD error late is disproportionately expensive, and the five areas where assertions belong.
Pricing Is a Search, Not a Value
The condition technique is SD’s signature, and it is worth restating precisely because the testing implication follows directly from the mechanics.
When a line item is created, SAP determines a pricing procedure from the sales area, the document pricing procedure and the customer pricing procedure. That procedure contains condition types in sequence. Each condition type has an access sequence, an ordered list of condition tables to check. SAP walks that list and stops at the first table where it finds a matching condition record.
Which means the price depends on a chain of things, none of which is the price:
- Which pricing procedure was determined, driven by three configuration values on the customer and document type?
- Which condition records exist, and their validity dates, which change without any document being touched.
- The order of the access sequence, a customer-material record found before a material-only record produces a different price than the reverse.
- Which conditions are active, statistical, or excluded, condition exclusion can suppress a record that was found successfully.
Change any one of those and the price changes, on documents nobody edited, with no error and no audit event that says “price changed.”
A condition record with a validity date that rolled over last night will reprice every order created today. Nothing broke. Nothing was edited. The search simply found something different.
The testing consequence: asserting that a price equals an expected number tells you very little, because the expected number was itself derived. The assertion that holds is on the **derivation**, that the correct condition type applied, from the intended condition record, at the expected access level. SAP exposes this in the pricing analysis for exactly this reason, and it is the layer validation should target.
What Agents in the O2C Flow Decide
Agent-assisted activity in order-to-cash tends to cluster in four places, and each carries a different validation requirement.
- Order capture and enrichment. Interpreting an incoming order, from an email, a portal submission or an EDI message, and creating the sales document with the right sold-to, ship-to, material, quantity and requested delivery date. Interpretation errors here propagate through the entire chain.
- Exception handling on blocks. Deciding what to do when an order hits a credit block, an incompletion log entry or a delivery block. The question is whether the agent releases something it should have escalated.
- Availability and date commitment. Responding to an ATP result, accepting a partial confirmation, proposing an alternative date, splitting a schedule line. These are commitments to a customer, made by an agent.
- Billing exception resolution. Handling items stuck on the billing due list, deciding whether a billing block should be removed, resolving why a document will not invoice.
The second and fourth are the ones worth watching most closely. Both involve an agent deciding that’s where humans belong in agentic testing, and blocks exist because somebody once decided a human should look.
Why Late Detection Costs More Here
SD is a document chain, order to delivery to goods issue to billing to accounting, with each document copying from its predecessor through copy control configuration. That structure has a property worth designing testing around.
In FI, a wrong posting is reversed with a reversal document. Unpleasant, contained, one step. In SD, the cost of correcting an error scales with how far down the chain you find it.
| Found at | To Correct | Cost |
| Sales order | Change the order | Minutes, no downstream impact |
| Delivery | Reverse the delivery, amend the order, redo | Hours; picking and packing may need redoing |
| After goods issue | Reverse goods issue, reverse delivery, amend, redo | Inventory and COGS postings both unwound |
| After billing | Cancel the invoice, unwind the chain, rebill | Accounting reversal; customer already has the invoice |
| After payment | Credit memo, potential refund, reconciliation | Commercial conversation, not just a correction |
That gradient is the argument for validating at order creation rather than at billing. Most SD testing concentrates on billing because that is where the money is and where errors become visible, which is precisely the most expensive place to find them.
Everyone tests billing because that is where errors surface. Billing is the most expensive place to find an error that started at order entry.
It is also why the agent decisions above matter disproportionately. An agent making a wrong interpretation at order capture seeds an error at the cheapest point to catch and the most expensive point to leave uncaught.
Five Assertion Areas
1. Pricing derivation, not pricing value
Assert on which condition type applied, from which condition record, at which access level, rather than on the resulting figure. A price can be numerically correct today because two errors offset, and wrong tomorrow when one of them changes.
Worth including: that condition exclusion behaved as intended, that manual condition entries are where they should be and absent where they should not, and that the net value reconciles to the sum of active conditions.
2. Availability and confirmed dates
The ATP result is a commitment to a customer. Assert that the confirmed quantity and date reflect the intended checking rule and scope of check, and, for partial confirmations, that the schedule line split is correct rather than merely present.
The failure that hurts is a confirmation the system produced correctly from misconfigured settings: a date that is wrong but internally consistent, which no error will surface.
3. Credit management behaviour
Both directions. That an order exceeding available credit is blocked, and that an order within limits is not, the second is skipped far more often and is the one that quietly obstructs revenue.
Also worth asserting: that credit exposure updated correctly after the document posted, since exposure drift produces increasingly wrong decisions on every subsequent order.
4. Copy control fidelity
Copy control determines what carries from order to delivery to billing. Assert that the values which should propagate did, and, equally, that values which should be redetermined were, rather than copied stale.
Pricing at billing is the classic case. Whether the billing document repeats order pricing or redetermines it is a copy control setting, and both behaviours are correct in different business contexts. Testing needs to assert the one your configuration intends.
5. Billing to accounting
The billing document creates the FI document through revenue account determination. Assert that revenue posted to the correct account, that tax was determined and posted correctly, and that the accounting document reconciles to the billing document.
This is the handoff where SD errors become financial statement errors, and it is validated with SAP FI/CO agent testing.
The Customer Sees This One
One property separates SD from the other transactional modules and it is worth stating plainly.
A wrong posting in FI/CO is an internal problem until someone reports on it. A wrong purchase order in MM affects a vendor relationship you can usually call about. An incorrect invoice in SD has already reached your customer, through output determination, automatically, before anyone noticed.
The order confirmation went out. The delivery note went out. The invoice went out. Each of those is a document your customer holds, and correcting the underlying data does not retrieve them.
That does not change what you assert. It changes how much validating order entry is worth relative to validating billing, because the cheapest correction happens before any document leaves the building.
How Sofy fits in your testing strategy:
Sofy’s SAP Test agents validate at the data layer, which for SD means asserting on the document tables rather than on what a Fiori screen displayed.
Against the five areas: pricing is validated at the derivation level, which condition type, which record, which access, rather than on the resulting figure; confirmed quantities and dates are checked against the intended ATP configuration; credit behaviour is tested in both directions including the negative case; copy control fidelity is asserted across the order, delivery and billing documents; and the resulting accounting document is validated with the same rigour as any financial posting.
Because validation runs across the whole chain rather than per document, an error introduced at order creation is caught at order creation, which, given the cost gradient above, is the difference between a correction and an unwind.
For orders arriving through EDI during SAP integration testing, the same principle extends to the inbound interface: the IDoc processing successfully is not the same as the sales order it created being correct.
And agents adapt through quarterly support packs rather than requiring rework after each one, which matters in SD because pricing and output configuration are among the areas most frequently touched.
What Still Needs a Human
Two limits, stated plainly.
Validation confirms that pricing derived according to your configuration. It cannot tell you whether that configuration reflects the commercial agreement. If a condition record was maintained with the wrong value or the wrong validity period, every assertion passes and the customer is still billed incorrectly, testing validates conformance to configuration, and someone with commercial context validates the configuration.
And genuine pricing disputes remain human work. Whether to honour a price a customer believed they had, whether an exception justifies a credit memo, whether a relationship warrants absorbing an error, none of that is derivable from the system, and it is the part of order-to-cash that actually requires judgment.
Frequently Asked Questions
What should SAP SD testing assert about pricing?
The derivation rather than the value. A price in SD is the output of the condition technique, a pricing procedure determined from configuration, running access sequences that search condition tables until a record matches. Asserting that a price equals an expected figure is weak, because the figure was itself derived. Assert which condition type applied, from which condition record, at which access level.
Why can prices change without anyone editing anything?
Because the price is found rather than stored. A condition record reaching the end of its validity period, a new record created at a more specific access level, or a change to condition exclusion will all produce different pricing on documents created afterwards. No document was edited, nothing errored, and the search simply found something else.
Where in the order-to-cash chain should validation run?
As early as possible, because correction cost scales with chain position. An error found at the sales order is a document change taking minutes. The same error found after billing requires cancelling the invoice, reversing goods issue and delivery, amending the order and rebilling, with the customer already holding the original invoice. Most SD testing concentrates on billing, which is where errors become visible and the most expensive place to find them.
What is copy control and why does it need testing?
Copy control is the configuration determining what carries forward between documents, order to delivery, delivery to billing, order to billing. It needs testing in both directions: that values which should propagate did, and that values which should be redetermined were rather than copied stale. Whether billing repeats order pricing or redetermines it is a copy control setting, and both are correct in different business contexts.
What is different about testing agents in SD versus other modules?
Customer exposure. Output determination sends order confirmations, delivery notes and invoices automatically, so an agent error in SD reaches the customer before anyone reviews it. A wrong FI posting stays internal until someone reports on it. That does not change the assertions, but it raises the value of validating at order entry relative to validating at billing.
The Bottom Line
SD rewards a different testing instinct than the modules around it. In FI you validate that a posting landed correctly. In SD you validate that a derivation resolved correctly, because the number on the document was never entered, it was found, and it will be found again differently when a condition record changes.
Pair that with a document chain where correction cost rises at every step, and the conclusion is uncomfortable for how most teams allocate testing effort. Billing is where errors surface. Order entry is where they start, where they are cheapest to fix, and where almost nobody is looking.
Catch It at Order Entry, Not at Billing
See agents validate pricing derivation, ATP commitments and copy control across the full order-to-cash chain, at the point where correction is still cheap.