SAP: Exploring SAP Backorder Processing in SD (Part 1)

Empty Shelves

The term “backorder” is common across most industries. They are also the bane of most customer service organizations who are often caught in between struggling processes and angry customers.  In this two part series, I’ll discuss how to recognize an SAP backorder issue, approaches to identify sources, and how SAP can help.  Let’s explore SAP backorders!

What Is An SAP Backorder?

In its simplest definition, an SAP backorder occurs when there is insufficient inventory to cover a sales order item’s demand.  It usually involves apologizing to the customer and providing a future date when the product will be available to ship.  Though it’s simple enough to define, it can be quite challenging to identify and fix the root cause of the shortage.

SAP Backorder Example

I was supporting a client who was struggling to meet customer demand after a challenging implementation.  [Disclaimer/CYA: I was not a member of the implementation team.]  Orders were flowing nicely into the system, but product was trickling out.  The customer service personnel found themselves trying to prioritize customer orders and manually allocate material to them — often unsuccessfully.  Making matters worse, many of the items sold were kits consisting of several items and, in most cases, one of those items was out of stock preventing the whole kit from being shipped.

One or two of the standard SAP backorder tools were implemented and running, but hadn’t been fully thought-out or explained to the client.  Unfortunately, the conclusion drawn by those involved in this process was that SAP was not working.  Of course, this couldn’t be further from the truth.  SAP was working, the business process was not.

Generally, when an SAP backorder issue is identified, two main concerns come to the forefront:  satisfying upset customers, and getting things back on track.  To help organize your efforts, it can be helpful to address the following questions:

  • Which products are affected?  Hopefully, not many.  Finding the scope of your product shortage will help you start pulling together vested individuals — Product Managers, Buyers, Warehouse personnel — to get a resolution identified quickly.
  • Which customers are affected?  This can help you get your arms around the size and scope of the issue and prioritize shipments in the short-term.
  • What is causing the shortage and how do I fix it?  This is at the heart of the problem.  In many cases, a Backorder is a symptom — not a problem — and it requires digging in and understanding the whole supply chain to find a resolution.

Some of these are very big questions — particularly that last one — and I won’t be able to address them in detail.  What I would like to focus on in this article is outlining a general business process and explaining how SAP can help.

Do I Have An SAP Backorder Problem?

Don’t worry: your customers will let you know.  A bit tongue-in-cheek, I know, but it’s a valid question and one that should be asked on a regular basis.  SAP Backorders can have many sources: seasonal demand spikes, inefficient shipping & transportation planning, struggling production lines, procurement delays, and the list goes on.  But the first step in finding the source is recognizing the problem to begin with.  SAP provides some tools to help you do exactly this.  I’m going to review a few of these reports and I’ll start with the least invasive.


Transaction V.15
Transaction V.15

Transaction V.15 is a simple Backorder report with several different reporting views.

  • Fast display/Document overview
    Displays a header-level report showing Sales Document, Shipping Point, Goods Issue Date, Ship-to, and Delivery Block information by default.  The Settings –> Layout –> Change… menu will allow you to add additional columns.  The only useful ones are the  Delivery Date and Sales Area fields.  Though you will see some Line Item fields available, this report is header only.
  • List Variant ‘ ‘: Display values for month
    With the ‘Fast display’ checkbox unticked, you have the option to show one of several standard layouts.  The first shows ONLY a snapshot summary by month of the current dollar amount relating to backorders.
  • List Variant ‘1’: Customer
    In addition to the monthly summary, this report shows a list of Sales Orders along with the Ship-to party name, Order Value, and GI Date.  Unfortunately, no additional columns can be added to this layout.
  • List Variant ‘2’:  Material
    Like above, this report adds the item level material description to the monthly summary alongside the Order number, Order value, and GI date.
  • List Variant ‘3’:  Customer and material
    Unfortunately, this report variant does not merge the two above reports.  It simply shows all three components in sequence:  Monthly summary, Customer report, and Material report.
Transaction V.15 - Additional Columns
Transaction V.15 – Additional Columns

Unfortunately, this report is old, short on detail, and short on functionality.   Inline filtering and sorting is not supported.  Nor is exporting to Excel like an ALV report.  It’s primarily a display-only report providing some key figures.  Quick and Dirty.  It does allow the user to click on the document number to jump into the target document, which is nice.


Though not supported in more recent SAP versions, transaction V_R1 is used to create or display a list of backordered items.  The program is intended to be run in background with the “Analyze existing list” option blank.  This creates the a list which can be viewed later with the “Analyze existing list” set to “X”.  The existing list can then be reviewed with the available filtering criteria.  This report is not available in my version:  SAP ECC 6.0, EhP7.


Transaction V_RA
Transaction V_RA

This report is a more recent addition and contains some advanced functions for handling backorders.

  1. Launch V_RA and input your selection criteria.  You must include either material or customer information.  Execute.
  2. Review the report results which contain all the identified backorders for the selection criteria.  You can double-click items to jump into their respective orders.
  3. Check the records which you would like to process and click the “Backorders” button.
  4. There appears to be some functionality included on the “Backorder Processing – Overview” screen to adjust material confirmations manually, but only for confirmations meeting certain circumstances.  There is also the ability to view details on ‘Pegged Requirements’ as well as the ‘Order Report’ — which is an MD04 screen.
Transaction V_RA - Results
Transaction V_RA – Results

Transaction V_RA - Order Report
Transaction V_RA – Order Report

While trying to manually re-allocate confirmed inventory using this report is tempting, I believe that this action could be considered ‘treating the symptom’ and are not recommended as a viable long-term solution.  I hope to address approaches for the cure, so to speak, in the next article.


Transaction V.21
Transaction V.21

The V.21 transaction is used to display logs for collective operations in SAP SD — most commonly used for Billing and Delivery creation.  For Deliveries (Type “L”), this report contains important information regarding deliveries created during collective processing.  HOWEVER, it also contains valuable information about which deliveries DID NOT get created — due to insufficient inventory levels, for example.  Having that information is critical to staying in front of a SAP backorder situation.  Your shipping group should already be reviewing this report at least once daily and should have a course of action when inventory-related issues arise.

Reviewing the report is simple:

  1. Launch V.21 and maintain your selection criteria:  Type “L” is required, but shipping point and date range will also come in handy.  Execute.
  2. You will see basic statistics including the number of ‘Created documents’ (abbreviated as ‘No.’) and the ‘Number of Errors’ (abbreviated as ‘Err.’).
  3. Select one of your rows containing errors and click the ‘Notes’ button (it looks like a chart or table).
  4. You will see a listing of errors including those with material availability issues.  You’ll see the Sales Order and line item number; clicking it should jump you into the respective Sales Document.
  5. At this point you should have enough information to notify your customer service and/or planning groups about the issue.

Transaction V.21 - Results
Transaction V.21 – Results
Transaction V.21 - Error Details
Transaction V.21 – Error Details

SAP Backorders: Consider the Source

Now that we’re aware of an issue with SAP backorders, it’s time to perform some analysis to determine the source (or sources).  Unfortunately, there’s no single SAP report that will show you the weaknesses in your supply chain.  Get your detective’s hat on; it’s time to go all ‘Sherlock Holmes’ on your processes.

There are many ways to go about this process, but considering I’m an SD consultant the best place to start is with the Sales Order  and work backwards.  Here is one approach for digging deeper:

  1. Once backordered materials are identified, compile a sample list of Sales Order lines that are affected.
  2. Using the Change Log for each order, do some research and paint a picture of what’s happening to your order lines.  The Environment –> Changes menu path is easily accessible from the Sales Order Overview screen.  One recommendation is to include a specific line item in your selection screen, select the “Additional info” checkbox, and sort the list by “Time of change”.  This will present a chronological listing of changes for you to analyze.  What you’re looking for are clues that may help to identify when the issue started.
  3. Next, I would analyze the Stock/Requirements list using transaction MD04.  This will give you visibility into the demand and supply for your items.  It’s at this point in time where you should start to get a general idea of where the problem is.  In most cases, you will see a disproportionately low amount of supply.  Some things to look for:
    • Missing or unconverted planned orders
    • Un-received production orders or purchase orders
    • Mis-matched supply and demand — demand is pulling from an incorrect Storage Location
  4. From here, you have to follow the breadcrumbs and see where they lead.  For instance, if planned orders are not being converted you need to follow-up with the MRP planners to see who, if anyone, is monitoring that product.  If production orders are un-received, find out why.  Keep in mind that there could be multiple root causes contributing to the issue — incorrectly executed processes and bad data are a couple of perennial favorites.

SAP Backorders: Fix the Process, Fix the Data

SAP is a deeply integrated system, and it requires a deeply integrated team of users and support resources to keep it working smoothly.  Issues such as this will oftentimes require a group effort to arrive at a solid resolution.  However, I’ve seen cases where individual groups — obviously feeling pressure — try to work unilaterally to fix things.  Customer Service tries manually allocating inventory or MRP Controllers try changing material MRP settings to force a certain behavior.  You’ll probably find the highest degree of success with a small, designated, cross-functional team to take the lead and coordinate efforts.  This is the best way to fully understand the problems and work together to find the best solutions.

I will also recommend that once a solution is identified that it be fully implemented.  In addition to designing or developing the solution, proper communication and documentation should be made.  Unfortunately, these are frequently overlooked.  Having a formalized training plan — or, at minimum, a robust communication plan —  can assure that everyone has been notified about the process.  Proper documentation assures that processes and data standards are accessible and clearly understood.  It can be time consuming to do this, but frequently pays dividends down the road.

A Quick Note About Backorders in SAP S/4HANA

In S/4HANA has replaced the traditional SAP Backorders process with a newer Backorder Processing (BOP).  I will write another article comparing and contrasting these two methods as soon as I have time to work a bit with BOP.

SAP Backorder Processing PART 1 Wrap Up

I didn’t originally intend for this to be a multi-part series but I realized that there was a LOT of ground to cover with this topic.  It started to feel like that it may never get published at all if I don’t get at least part of it rolling.

In this first article we defined backorders and identified a few ways to determine whether you’re wrestling with a problem.  I also mentioned a few approaches for analyzing your backordered items to help find a root cause for the shortage.  Finally, I covered the importance of solving the issues as a team and properly documenting and communicating any actions taken to resolve the issues.  In the next article, I will cover some of the functions that help manage SAP backorders.

24 thoughts on “SAP: Exploring SAP Backorder Processing in SD (Part 1)

  1. Hi Michael,

    Great work here to help beginners with the Back order process. Could you please get the second part out as soon as possible covering rescheduling as well.


    1. Sumit,

      I have a draft article going for Part 2. I’ll see what I can do to expedite publishing, but my schedule has not been favorable as of late.


  2. Hay,

    Great article, Availability check and its related areas are always confusing and challenging to many ..many SAP guys.
    Thanks for a great one in this area.
    Please share more on this area and many..many SAP guys will be
    thankful to you.

  3. Excellent article.
    Do you know if there is any way to combine backorders from different orders in one single delivery?


    1. Cristian: Thank you for the comment. Yours is a good question. Unfortunately, I am unaware of any backorder-specific delivery combination functionality. There are some general delivery combination functions that already exist. You can search online for these, but it will most likely include selecting an delivery combination attribute on your customer and making sure specific copy controls are in place between your sales order and delivery. Good luck. Please let me me know if you find anything that works. -Michael

  4. Hello, I’m the bigginer in SAP SD so don’t be astonished by my question :-). I’m reading about V.15 and while executing this t-code I can’t find List Variant 1, 2, 3. Where is this ? Thank you in advance.

  5. Hi Michael,
    I realize this is a very old thread, but possibly you are still listening.
    My scenario is a MTO environment which by definition everything is back-ordered at first.
    Our problems stem from frequent changes to customers’ priorities, their Ship-To’s, the use of sales scheduling agreements with delivery orders, and stock availability.
    Have you written anything that would be relevant for MTO like this?

    1. I’m always listening, Rory… Thanks for the question. I have not written anything specific to Backorders for MTO processes. MTO usually means that a Production or Assembly order is involved and Production Planning has its own process for identifying and expediting missing parts or sub-assemblies. In this case, your Sales Order line should be confirming against the scheduled completion date from the Production/Assembly order. Where exactly are the gaps located in your existing process? -Michael

  6. HI Mike,
    Thanks for responding so quickly.
    Our use of sales scheduling agreements with delivery orders, combined with customer behavior, gives us ATP-type problems when there is more than one outbound delivery for the same material at the same time (no PGI).
    2 ODs are vying for the same stock.
    I want to learn more about V_V2, how it works and why it is needed so that I can test better in our Quality system.

    1. Rory, I would look at your availability checking rule. Typically, in order for a delivery to be created, there must be a Sales Order confirmation. A Sales Order can confirm against unrestricted stock, or an inbound PO/STO, or a scheduled Production Order. You can also configure your ATP checking rule to confirm against a Total Replenishment Lead Time (defined in the material master). In this latter scenario, every Sales Order for those products will confirm after a particular number of days. I recommend taking a look at your availability checking rule assigned to those materials and see if it is behaving the way you want. By the way, V_V2 will only help with undelivered Sales Orders; deliveries are considered a hard allocation and cannot be changed with rescheduling. Hope this helps. -Michael

  7. Hello,
    What is the best practice in communicating to the customer delivery date changes and/or backorder processing changes that take place in the system by the transactions you mention here? How to automate this via email and or commerce portal etc. Thank you.

    1. Great question, Kyle. Thank you for asking. Most clients I work with will use a report to identify those orders that are at risk of shipping late and then reach out to customers via phone or email. I don’t know off-hand of any companies who have chosen to automate a notification. I’m sure there are, but I would be very careful if going down that path. I’ve automated EDI messages that triggered when a sales order changes and ended up with a TON of activity. Most companies do have some sort of an Advanced Ship Notice (ASN) which could also fill this requirement. What type of solution are you looking for?

  8. Hello, I am a planner and I would like to see a list of all backorders and future open orders that are not shipped yet on a customer and material detail level. Which report can I use in SAP?

    1. Hello Esra. Sorry for the delay; I just realized today that I have a backlog of comments for me… To find all open orders, I would start with the VA05 report. That allows you to pull up a list of open orders (or all orders) by certain criteria (customer/partner number, Material, Sales Area, etc.). You can also look at VA05N which shows similar data. Backorders are really just open line items, so one of those reports will include item level details. There are separate transactions for show SAP Backorder reports if you are using that process.

    1. Hello Sameer. In ECC, the V_V2 report is what you would want to run. That report updates sales order confirmations and will consider newly available inventory. I frequently see this program setup as a scheduled job to run periodically, but there are some places that prefer to run it manually. It will assign available inventory to open orders based on criteria selected on the parameters screen.

  9. Hi Michael,
    Great article. Hope I can get your view/proposal on how to cope with a practical problem. We are running rescheduling with different parameters per plant in background jobs. We have many sales organizations across the globe and the sales personnel need to review and act on the results of the rescheduling run using tx. V_R2. From our findings the rescheduling results are overwritten by the latest rescheduling job for a plant – thus removing the basis for reviewing/acting on the results by the respective sales personnel. Do you have any proposal/idea as to how we can persist or find the results data from all/more rescheduling runs. Of course, we could run just 1 rescheduling job/day for all plants with the same parameters.

    1. Hello. Thanks for the question. It’s an interesting one. I don’t have a great answer for you. It seems like you’re interested in reviewing historical Rescheduling runs. I’m not sure exactly how the V_R2 report works. It may not have a proper log file that it’s writing to. The thing about Rescheduling is that the report becomes outdated pretty much as soon as you run it — any sort of goods movement or new demand could affect those results. How often are you running Rescheduling? Are the results you’re getting between runs drastically different? -Michael

Leave a Reply

Your email address will not be published. Required fields are marked *