From the revenue recognition point of view, it is a best practice to create an invoice only when the customer has confirmed the arrival of the goods. The revenue recognition perspective asserts that revenues should not be recognized by a company until they are realized and earned by the company. This means that customers should be billed only when the delivery occurs or services are rendered properly.

Based on my experience, I’ve witnessed several companies implement complex custom workarounds for delivery receipt confirmations. Many users are unaware of the standard R/3 POD functionality that can replace your elaborate customization work with a simple solution for delivery confirmations. In this article, I’ll explain a few key advantages of POD and show you how to configure POD in your system.

Why Should You Use POD Functionality?

In addition to confirming deliveries, POD records the goods receipt date, the actual quantity received by the customer, and the reason for any quantity differences. Some reasons why quantities vary in day-to-day situations include misplaced or stolen goods, certain hazardous characteristics of the goods (such as volatility), or damaged goods during the shipment process.

The POD functionality tracks and stores these reasons in your system automatically so you can evaluate the lifecycle of delivered goods. This type of information is particularly useful when you follow up with forwarding agents, vendors, or customers — the quantity differences and the reasons why are accurately recorded in your system. Use POD to settle discrepancies between the actual goods delivered and the goods invoiced. This data is also useful for vendor evaluations.

POD enables you to issue accurate invoices when a customer confirms the goods received and you do not need to create several credit memos. Credit memos are required when there is a mismatch between what the customer claims to have received and what is billed to the customer. In the POD process, the customer is billed only for the quantity confirmed by the customer and you do not need to issue a credit note.

How to Configure POD

The following six steps explain how to configure the proof of delivery functionality in your system.

Step 1. Set up POD relevance. Follow IMG menu path Logistics Execution>Shipping>Deliveries>Proof of Delivery>Set POD-Relevance Depending on Delivery Item Category. The POD relevance overview screen appears automatically.

In my example, I’ll illustrate the process for maintaining the POD-relevant standard delivery item TAN. Click on the POD-relevant field for the item TAN. Select X from the drop-down menu to indicate that item TAN is POD-relevant (Figure 1).

Figure 1

Maintain POD relevance overview screen

If you select the POD automatic field in Figure 1, the ship-to party transfers the POD to your SAP system via standard IDoc type DELVRY03 to verify the delivery quantities. In my example, I leave this field blank because I want to process the POD verification manually instead of automatically.

Step 2. Define reasons for quantity differences. In this step, define the reasons for quantity deviation. Standard SAP provides two reasons for quantity variance:

• DFG1 for overdelivery, reason unknown
  
  
• DGF2 for underdelivery, reason unknown

Overdelivery refers to the situation in which the quantity of goods delivered is more than the ordered quantity. Underdelivery refers to the situation in which the quantity of goods delivered is less than the ordered quantity.

Follow IMG menu path Logistics Execution>Shipping>Deliveries>Proof of Delivery>Define Reasons for Quantity Differences to access the Reason for Variance in POD overview screen (Figure 2). Click on the New entries button and enter the details of the variance in the Reason for variance field. During the POD verification process, several reasons for differences between quantities posted as goods issued and quantities received by the ship-to party are entered in the system for each delivery item. In this example, enter DMGD (damaged goods) and save the entry by clicking on the save icon.

Figure 2

Reason for variance descriptions in POD

The Quantity calculation field controls whether the quantities that are verified must be subtracted from the delivery quantity. This usually happens for underdelivery or damaged goods scenarios. You must create a separate variance reason for damaged goods because you know the exact reason for underdelivery. Based on your business requirements, you could create several known variance reasons for under- and over-delivered goods.

When the system creates billing documents for the delivery item categories that are marked as relevant to POD, it copies the verified quantity rather than the requested delivery quantity. Delivery quantity is available in the delivery document and indicates the quantity of posted goods issues upon delivery.

Step 3. Maintain relevant for POD indicator in customer master. Execute transaction code VD02 and enter the customer number (10000171) in the sales area data screen that appears (Figure 3).

Figure 3

Relevant for POD indicator is selected

To activate POD processing, select the Relevant for POD indicator on the Shipping tab of the customer’s master data. If necessary, maintain the number of days expected before the recipient confirms a proof of delivery in the POD timeframe field. For example, enter 7.00 to indicate seven business days. If there is no confirmation during seven business days, the delivery is confirmed automatically when this time period is over and no variances are recorded. Therefore, the recipient does not need to enter the POD date and time manually. Instead, the system automatically updates the POD confirmation date after the expected POD time frame expires.

Step 4. Create a billing document before POD verification. Now you are ready to use POD functionality for outbound deliveries. You follow the same steps required to create a sales order after the delivery is received and confirmed goods issued are posted.

Begin by creating a sales order for 10 units. As a result, the delivery is created for 10 units and the goods issued are also posted for 10 units. Next, create a billing document that is based on the actual quantity received and confirmed by the customer. In the absence of the POD verification, you cannot create billing documents. If you attempt to create a billing document for an unconfirmed shipment, the error message shown in Figure 4 appears automatically.

Figure 4

Example of a billing document error log

Step 5. POD verification for outbound delivery. In this step, you perform the POD verification for an outbound delivery. Follow menu path Logistics>Logistics Execution>Outbound Process>Goods Issue for Outbound Delivery>Proof of Delivery (transaction VLPODL) and select Change Single Document for single-delivery document or Work list Outbound Deliveries for POD for a full list of delivery documents.

In the screen that appears, enter the outbound delivery number (8000004020, in my example). Press Enter to generate the screen shown in Figure 5.

Figure 5

POD differences are reported

When the ship-to party verifies receipt of the goods, you must manually enter the POD date (07/18/2007) and time (10:45) in the POD date field, the reason for quantity deviation, and the deviation in quantity actually delivered, which you determine during the POD verification process. All other values in the outbound proof of delivery screen are automatically populated based on the delivery number entered, including the ship-to party. The document date defaults automatically to the current date.

In this example, the customer confirms that 2 quantities are received in damaged condition (DMGD in the Reas. [reason] field) and should not be billed. Therefore, enter 2 quantities in the QtyDiffinSalesUn field and an applicable reason code DMGD in the Reas. field. At this stage in the verification process, the POD status field contains the status B Differences reported. The POD quantity is reduced to 8 quantities accordingly. The Delivery quantity minus the QtyDiffinSalesUn determines the POD quantity, as shown in Figure 5.

To confirm the POD, click on the confirm POD icon and then click on the save icon. The confirmed POD verification screen appears automatically and the POD status is now updated to C Confirmed (Figure 6).

Figure 6

POD is confirmed

Now the delivery is open for billing with the billed quantity equal to the POD quantity. In this example, 8 quantities are billed to the customer as confirmed during the POD verification instead of 10 quantities of goods issue. Figure 7 displays the status overview of the sales order.

Figure 7

Sales order confirmation shows eight quantities are fully invoiced and billed

The open status is the quantity that still needs to be processed with reference to the original sales order. It is applicable for all three stages in the sales process. For the delivery status, the open quantity is 0.00 because all of the 10.00 quantity was delivered successfully, as required in the sales order. Similarly, the open quantity is 0.00 for the goods issue status. However, for the billing status, 2.00 quantities are open because only 8.00 quantities were billed and the original sales order requested 10.00 quantities. This open status and quantity is for informational purposes only.

Step 6. Create a report. To generate a standard report on differences and reasons for the variance, follow menu path Logistics>Logistics Execution>Outbound Process>Goods Issue for Outbound Delivery>Proof of Delivery>Worklist Subsequent Processing for POD (transaction VLPODF). In the screen that appears, enter the selection criteria (Figure 8). Click on the execute icon to produce a standard report for your records.

Figure 8

Report on reasons for differences

After you complete the configuration steps described in this article, you can use POD functionality to issue accurate invoices based on the customer’s confirmation of goods received. This increases the billing process accuracy, expedites invoices, and does not require extensive rework. Recording the reasons for deviation offers valuable insight on transportation damage, theft, and other reasons, which you can then analyze to improve your logistics process.