SAP: Sales Document Date Fields Demystified

It’s not uncommon for me to receive questions regarding  date fields on SAP Sales Orders.  That should not be surprising considering that users will be confronted by no less than 10 date fields during normal order maintenance.  That number can rise to more than 15 depending on how you slice the numbers.  In this article, I will explore these date fields and how they impact other activities.  Read on for more on Sales Document Date Fields.

NOTE:  To simplify things, I’m going to only address the standard Sales Order screens — VA01, VA02, and VA03 — though, many of these dates will also appear on other document classes.

Since sales document date fields appear on all three layers of the Sales Order — Header, Item, and Schedule Line — and since there is a lot of overlap between many of these fields, it makes sense to organize this discussion by function.


Let’s get s a few basic ones out of the way.  The Created On date is the date that the sales order was saved to the database.  Not much else to say on that one.  It’s worth noting that there are also Changed On dates available in the header table (VBAK) and line item table (VBAP), though these aren’t available in VA01/2/3.

The Document Date is found on the header -> Sales tab.  The primary function of this date is to control when a sales document appears in management reports.  In SAP’s own words, the document date is “the date on which you want the sales document to become effective for sales management purposes”.  Typically this date is set to the Creation date.


Sales Order PO Date
Sales Order PO Date

The PO fields are typically some of the first fields entered during order entry. PO Date fields exist at both the header and item levels.  Why?  SAP doesn’t assume that you have a strict 1-PO-per-order structure.

Sales Order Line Item PO Date
Sales Order Line Item PO Date

You are allowed to group multiple PO’s into the order by maintaining separate PO numbers and dates on each line item.  In most cases, SAP will still expect you to have a PO number and date on the header, but you can change the item-level dates on the Item Overview, Sales, or Procurement tabs.

Traditionally, the PO date will correspond to the date that the customer created the PO in their system.  When it comes to the actual functionality behind the PO date field, there’s really not much to it.  You input the date and SAP saves it.  It may appear on some standard output such as Order Acknowledgements, but I am unaware of any other use for it.

You do have the option to default the PO Date to the current date; this setting is located on the Sales Document Type configuration screen in the IMG.


Sales Order Requested Delivery Date and Pricing Date
Sales Order Requested Delivery Date and Pricing Date

The Pricing Date is used by SAP to determine pricing conditions and exchange rates for the document.  You can think of this date as a “Pricing Valid On” date — only those pricing conditions valid on this date will be adopted on the document.

Configuration of the Default Sales Order Pricing Date
Configuration of the Default Sales Order Pricing Date. You can also see the ‘Lead time in days’ and ‘Propose’ settings that control if and how the delivery date is defaulted for new orders.

In most cases, the document’s pricing date will default to the Requested Delivery Date (more on that field later).  But the default pricing date can be changed on the document type configuration screen to use either  today’s date or the Requested Delivery Date.  Alternatively, Sales Documents with validity periods can also use the Valid-from Date or the Contract Start Date.  In any event, the user can manually overwrite the default pricing date on the order.  This, however, should probably be discouraged unless a valid reason exists for making this sort of manual change.

The Pricing Date is automatically adopted by the invoice in the billing process.  However, you can specify a new Pricing Date manually in both VF01 and VF04 transactions.  Keep in mind that this could impact pricing; changing the pricing date from the original document will trigger repricing for that billing document.


Here’s where things get interesting.  One of the more complicated date-related functions on the sales order involves determining when your customer receives their deliveries.  It’s complicated due to the amount of integration:  material master values, MRP, ATP, the factory calendar, customer calendars, shipping point settings, etc.  I’ll try to break this down into bite-sized chunks for easy absorption.

It all starts with the Customer Requested Delivery Date — labeled as “Req.” on most screens.  In most cases, this should default to the current date, but controls exist to change that proposal.  First, you can opt NOT to have a default date at all.  This is located on the order type configuration screen in the IMG.  On the same screen, you can also specify a lead time in days that will act as a buffer. In other words, a lead time of ‘1’ will propose tomorrow’s date (or the next business day) as the customer’s requested delivery date.

Multiple schedule lines on a Sales Order item
Multiple schedule lines on a Sales Order item

SAP will attempt to confirm all shippable items for the Customer Requested Delivery Date.  A schedule line is created for each line item with the CRDD maintained.  As each item is entered, the ATP process will run to see whether or not the date can be met.  If so, the single schedule line is confirmed.  If not, then secondary schedule lines are created with dates on which the product CAN be confirmed.  These proposed dates are dependent upon several factors.  I won’t go into detail on each item, but here’s a short list:

  • ATP Configuration – Determines, among other things, what sources you consider when looking for incoming inventory.
  • Material Lead Times – Expected lead times when purchasing or manufacturing a product.  Also includes goods receipt lead times and QA lead times.
  • Shipping Lead Times – Time required for picking, packing, loading, etc.  I’ll discuss those in the next section.

SAP considers all of the above and then determines one or more product availability dates.  It is possible for SAP to determine several additional schedule line dates.  For example, if the customer requested delivery for this week (SL #1), but 1/2 of the product will not be available until next week (SL #2) and the remainder will be available the week after that (SL #3).  In this example, you would see three separate schedule lines with three different dates.


Schedule Line detail dates
Schedule Line detail dates

Since we’re on the topic of Schedule Lines, it makes sense to dive a bit deeper.  You can double-click a schedule line to pull up the schedule line details.  The Shipping tab reveals some additional dates used for logistics planning.  These dates and times all deal with lead times for the performing of specific shipping tasks.  Let’s discuss them one at a time starting with the bottom one.

The Transportation Planning Date is the date by which the planning must be completed in order to ensure the delivery is received/shipped on-time.  This date can be based upon a lead time in the route which is useful when, for instance, a carrier requires notification ahead of time.  A basic example would be a trucking company that requires at least 5 days notice before committing to a pick-up.

The Material Availability Date can also be considered the Picking Date.  This is the date on which picking should begin in order to meet the subsequent deadlines.  Similar to the Loading Date, the amount of time estimated for picking is controllable through the Shipping Point configuration and can consider several criteria: Shipping Point configuration and Route settings are two examples.

The Loading Date is the date/time on which loading should begin.  The amount of loading time can be determined from a combination of the Shipping Point configuration, the Loading Group of the material, and the Route.  Picking and Packing must be completed by this date/time.  Since the route is a major input to this date, SAP will assume zero lead time if a route is not specified.

The Goods Issue Date is the date on which the goods must physically leave the shipping point.  This primarily takes into consideration the customer requested delivery date and the transit time required for the delivery.  The latter of which is dependent upon the route.  If no route is determined on the sales order, SAP assumes zero transit time.

Lastly, you arrive at the Delivery Date.  This is the date and time that the customer expects the item(s) to arrive at their desired location.  This date, of course, must take into account the transit time between the point of origin and the destination.  The most common way to take this time into account is by using settings on the Route.


In common terms, the Billing Date is the date on which the billing document is to be generated.  Of course, there are several places you will find a “Billing Date” field.  The most common Billing Date you will see is on the ‘Billing Document’ tab in the header of the sales order.  This billing date is then copied to the item level where it can be freely maintainable if you wish to maintain the date manually.  This would make the most sense in an Order-related billing process in which the billing document is generated directly from the Sales Document.

For a Delivery-related process, the actual date of the invoice typically depends upon the delivery’s Post Goods Issue date.  That being the case, the Sales Order ‘Billing Date’ fields are pretty much moot.

If you are billing for a Service without a delivery, there is a separate date field called the Service Rendered Date which is located just below the Billing Date.  In standard SAP processing, the system will propose the service rendered date instead of the sales order billing date for this scenario.  Just to complete the loop, if a service is delivered alongside physical products on a delivery then the PGI date will be proposed for the Services Rendered date.

Sales Contract Billing Plan
Sales Contract Billing Plan

Finally, you will also commonly see Billing Dates on a Billing Plan.  I won’t delve into Billing Plans in this post — we would be here forever — suffice it to say that a Billing Plan is a schedule of billing dates on which billing documents are to be created.  Billing plans are commonly found on certain types of contracts, or sales orders intended to structure larger projects which are invoiced in a particular way.  Let’s talk about these date fields:

Start Date and End Date fields are fairly self-explanatory.  They determine the duration of the billing plan.  In the case of contracts, this will normally correspond to the validity period on the contract header.

The Dates from and Dates Until fields can be used to adjust the billing schedule for a single line item.  This would most often be used in conjunction with a Header-level Billing Plan.

The “Dates” portion of the screen contains individual line items with Settlement, To, and Billing Date fields.  The Settlement and Settlement To dates represent the billing period for the item.  The Billing Date will correspond to one of these dates depending on whether the billing is to be performed In Advance or not.

See Also

If you’re interested in SAP Sales Document date fields, you may also be interested in…

  • My infographic on SD Logistics Scheduling.
  • More information on SAP Scheduling in SAP Note 1644765 (Link)


Sales Document date fields are really easy to gloss over.  Most users just stick to the ones they need for their own purposes.  With as much integration as there is in SAP, it’s difficult to talk about dates without jumping around from object-to-object.  I hope that this nicely summarizes what’s going on in the background and can at least act as a starting point for exploring date-related scheduling options to improve your process.

11 thoughts on “SAP: Sales Document Date Fields Demystified

Add yours

  1. Hi Michael,

    The business which I work at is in the process of getting the entire organisation to use SAP. One of the major issues I have come across so far, in my role within the orgnisation is in relation to accrual/pricing condition trigger points.

    According to your page, you mentioned that the pricing date is the date which will trigger any accruals or discounts which are set up. Is this true for all versions of SAP? Can the date which triggers these conditions be changed by default to the requested delivery date?

    I ask, as this appears to be the current situation where I am employed, and both myself and a colleague, based in Australia, having been arguing with our IT department based in Europe about this, but are told that it is a SAP setting that cannot be changed?

    Would be great to hear what you have to say on this matter.


  2. Hi Russell,

    YES! The Pricing Date that is proposed can be defaulted to:
    o Today’s Date
    o Requested Delivery Date
    o Valid-from date (Agreements)
    o Contract Start date (contracts)

    To make this configuration change, you just need to change the Sales Document Type configuration setting for the “Prop.f.pricing date”. This is located in the section titled “Requested delivery date/pricing date/purchase order date”.

    …and fire your IT department. 😉


  3. Hi Michael, I recently joined a new company but doing almost the same tasks. However, I was surprised to find out that they are not keen into changing or updating the required delivery date even if the new delivery date is the one requested and agreed upon with the customer (can be due to receiver’s WH space availability or supply issue). I am aware that the tracking of OTC KPI also uses the required delivery date as basis – please correct me if I am wrong. Can you shed light on the importance of having the sales order updated accordingly and accurately?

  4. Hi Michael, I created 2 date determine rules in OVBS .
    – ZI Annual Billing on First of Month
    – ZJ Annual Billing on Last of Month

    My client wants to make ZI as a default by either specific customer or Sales item category. Our billing is driven by milestone billing plan.
    Is there a standard way to make ZI as a default?

    Thanks. for you help.

  5. That was an awesome explanation, and great effort. Could you pls throw some light on What’s the first date and the relation of it to RDD field in initial SO screen .

  6. Hi, We are trying to figure out what is the “first delivery date” is on the line items of a quote. By default, it is the Req. del. Date but it is a changeable field. Any ideas?
    We want to know what drives the Org. Del date on the Sales Order.

    1. Michel, thank you for the comment and apologies for the delayed response. I assume you are referring to some values that are displayed on a Quote output; please correct me if I’m wrong. The “first date” will most likely refer to the first date that SAP can commit some quantity of the respective item. If product is available, this will probably match the customer’s requested delivery date. If a customer requests delivery today but product is not available, the “First Date” will be the date that SAP calculates the product can be made available (via Purchase, Production, or Stock Transfer) to ship. For more information on this, you can research ATP. Does this make sense?

  7. Hi Michael
    Your article is very insightful, could you clarify this question for me
    Regarding RDD, when you said “In most cases, this should default to the current date”
    But as per my understanding RDD is the date on which customer wishes to receive goods. How can we deliver a product on the same day the order is created.
    We have a very dynamic delivery processing, where in we try to upgrade carrier to overnight shipping when the RDD is 1 day (if the material is available), so am trying to understand these subtle nuances.


    1. Bramra, Thank you for your question, and my apologies for the late response. You are correct! The Requested Delivery Date (RDD) is intended to be the date on which the customer would like to take receipt of the goods or services. Typically, a Customer Service / Order Entry person will get that date from the customer and manually make adjustments to the Sales Order field. However, in many cases the customer wishes to have the goods as soon as possible (or “Yesterday” in some cases). If this is the case, you can leave the RDD as Today’s Date. It all has to do with scheduling. SAP will first attempt to perform Backwards scheduling — start from the RDD, factor in transit times, loading time, pick/pack time, etc. If the “start date” is in the past, SAP will then switch to forward scheduling and propose dates based on this same information starting “Now” and progressing forward. Does that answer your question?

What say you?