VA02 — Change a sales order
VA02 is the change transaction for an existing sales document. You open the order by number and adjust quantities, dates, partners, rejection reasons or conditions within what configuration and authorisation allow. The document is updated in place, so planning, the delivery due list, credit exposure and the document flow all react to what you save.
Change mode for sales documents: what can still be changed, what the change triggers downstream, and the checks to run before saving.
Reviewed by an ERPClimb SAP consultant on 13 Sept 2026· 698 words
What VA02 is for
VA02 is the maintenance side of sales order processing. It opens an existing sales document in change mode so a consultant or a business user can correct what was captured at creation, or react to something the business has since agreed: a revised quantity, a new requested delivery date, an added or rejected item, a different ship-to party, or a manual condition that a supervisor has approved. Because the document is updated in place rather than copied, everything hanging off it reacts immediately. Requirements are passed to planning again, the delivery due list changes, credit exposure is recalculated, and the document flow keeps one audit trail instead of a second competing order.
When it is used in order-to-cash
In a normal order-to-cash cycle VA02 sits between order creation and delivery, and it is where most day-two support work happens. Typical triggers are a customer changing quantity before picking starts, a blocked order that needs a released credit check, an incomplete document that shipping cannot process, or a line that must be rejected because it will never be supplied. Once a delivery or a billing document exists, the room to change narrows sharply, so support teams read the document flow before promising a change to the business. Knowing which changes are still legal is more valuable here than knowing the screen layout.
How it is used in practice
You enter the sales document number, or search by customer, purchase order reference or material when the number is unknown. The system opens the overview with the same header, item and schedule-line views used at creation. Work at the level the change belongs to: header views for terms, partners and pricing that apply to the whole document, item views for material, plant, quantity and rejection reason, and schedule lines for dates and confirmed quantities. Re-run pricing only when the business intends prices to change, because an unintended update can overwrite manually agreed conditions. Review the incompletion information and any block or status before saving, because the save is what releases the change downstream. On S/4HANA the classic transaction remains available while Fiori sales apps offer an alternative way in for the same document.
Fields and objects that matter
- Sales document number, the entry point that identifies the order being changed
- Order quantity and requested delivery date at item and schedule-line level, which drive availability and the delivery due list
- Reason for rejection at item level, the controlled way to close a line that will not be supplied
- Partner functions such as ship-to and bill-to, when the change is a shipping or invoicing change rather than a quantity change
- Header and item conditions, where manually agreed pricing is visible and where a pricing update can overwrite it
- Sales document header VBAK, item data VBAP and schedule lines VBEP, the persisted data the change is written to
Common pitfalls and how they show up
- Changing an order that already has a delivery or an invoice and expecting the follow-on document to correct itself; read the document flow first
- Triggering a full pricing update and silently losing a manually agreed condition
- Deleting a line instead of rejecting it, which destroys the reason code the business needs for reporting
- Leaving the document incomplete, so shipping cannot create the delivery and nobody is told why
- Missing a block that was set automatically after the change and assuming the order is ready to ship
- Changing a quantity without checking the confirmed schedule line, then promising a date availability never confirmed
- Making the same change twice in parallel sessions, so one user overwrites the other without noticing
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.