All companies incur transportation costs. Not necessarily for each and every outbound sales order shipment (sometimes the customer agrees to be billed directly). Not necessarily for every inbound purchase order goods receipt (sometimes the vendor agrees to be billed directly). However, freight costs — both inbound and outbound — are unavoidable.

They’re also not so easy to account for. The challenge comes from timing differences. On Tuesday, your company ships five units of product XYZ. Perhaps you have built the cost of shipping into the sales price per unit. Or perhaps you list a freight charge separately on the customer’s invoice. Either way, you often might not know the real cost for a month or so until the carrier’s invoice to you shows up in the mail.

This situation is often worse in purchasing. If you have agreed to receive billing for the transportation separate from billing for the goods, you might have to rely on what your vendor tells you the carrier’s freight charge is going to be so that you can do your accounting. However, your vendor is not the one sending you that bill. The carrier is.

One functionality in SAP R/3 that can potentially help accountants with the timing issue is referred to as the “accrual” option in sales order and in purchase order (pricing) condition types. This may or may not be useful for you. To decide, you must first get past one confusing aspect of this field setting — it behaves differently in sales orders than it does in purchase orders! One setting. Two results. Not nice.

I’ll use the remainder of this article to demonstrate via screenprints what kind of automatic accounting the “accrual” checkbox gives you. After that, you should be in a much better position to decide for yourself if it is worth the set-up and documentation effort to introduce at your site.

The Accrual Option in Purchase Orders

Automatic accounting in the purchasing cycle occurs with two end-user transactions: goods receipt for purchase order (PO) and invoice verification. One possible result is shown in the entries listed on the left side of Figure 1. On the right side is an example of an entry someone would manually record in response to a carrier’s invoice for multiple shipments.

Figure 1

Automatic accounting on a PO goods receipt and invoice receipt for a material that has freight expense reflected in its standard rate but not in it's PO, and an example of a manual entry of a carrier's invoice

The trouble with what’s shown in Figure 1 is the freight expense entry. The freight is already accounted for in the standard rate of the material. However, once the carrier’s invoice for multiple deliveries shows up, you are stuck putting the $70 onto your P&L to net against the phony purchase price variance (PPV) credits that are recorded during each goods receipt. Therefore, what you would probably prefer is the automatic accounting result shown in Figure 2 (the debits and credits net against just one balance sheet account number).

Figure 2

Automatic accounting on a PO goods receipt and invoice receipt for a material that has freight expense reflected in its standard rate and in it's PO, plus an example of a manual entry of a carrier's invoice

One way to achieve the automatic accounting in Figure 2 is shown in Figures 3, 4, and 5. Notice in Figure 3 that the condition type FRA1 has its Accruals checkbox active. This is an instruction for R/3 to read an account key code (code FR1 in Figure 4) from the Accrls column (and not from the ActKy column) in the purchasing pricing procedure.

Figure 3

he Accruals checkbox in a condition type maste

Figure 4

The Accruals account key in a purchasing pricing procedure

Figure 5

The account key mapping table in the transaction code OBYC automatic accounting table

As with all purchasing-related condition types, you can set this up to allow for manual entry or for an automatically retrieved value (percent of purchase price or a flat cost amount). The question of whether a condition type obtains its value from an end user or from an automatic process is controlled by the access sequence field. In the FRA1 example I am using, the access sequence field is blank, meaning that the value has to come from manual entry into the PO’s pricing/ conditions screen.

How about the question of which G/L account number R/3 should post that manually-entered value to? The answer is shown in Figure 5 — i.e., each account key in a purchasing pricing procedure has a row available in the automatic accounting mapping table found via transaction code OBYC.

The Accrual Option in Sales Orders

Automatic accounting in the sales cycle occurs with two end-user transactions: sales order billing and goods issue to delivery.

Let’s imagine the case in which the customer has not agreed to pay you extra as a way to cover your costs of shipping the product to them. When the sales order is ready for billing, one possible automatic accounting result is shown in the entry listed on the left side of Figure 6, with an example manual entry made in response to a carrier’s invoice for multiple shipments shown on the right side.

Figure 6

Sales cycle automatic accounting, plus an example manual entry of a carrier's invoice

The trouble in Figure 6 is a lack of a freight expense entry. You have overstated your profit margin as being the $105 sales revenue less the $75 cost of goods sold. In reality, you have also incurred a shipping cost. Yes, eventually you did receive the carrier’s $70 invoice. However, this often arrives in a different fiscal period than when you recorded your revenue. It also is very difficult to divide up that $70 (reflects multiple shipments for multiple sales orders) to each of the products as a way to more accurately view each sales billing’s gross margin. Therefore, what you would probably prefer is the automatic accounting result shown in Figure 7.

Figure 7

Revised automatic sales cycle accouting exampl

One way to achieve the Figure 7 automatic accounting is shown in Figures 8 and 9. (Note that there is no difference at all between purchasing and sales condition types in regards to setting one up as an accrual condition. Therefore, I am not including a screenprint of the ZFR1 sales-related condition type you see in the first row in Figure 8.)

Figure 8

The accruals account key column in a sales pricing procedure

Figure 9

The account key mapping table in the transaction code VKOA automatic sales accounting table(s)

Notice in Figure 8 that the three-digit account key for an accruals condition type in a sales-related pricing procedure goes into the exact same Accrls column as with the purchasing-related pricing procedure you saw in Figure 4. But hold on, because a surprise is coming.

Take a look at Figure 9 now. It is a commonly used automatic accounting mapping table for the SD module. However, the reaction by R/3 here to an accruals condition type is different than it is in the purchasing-related mapping table you saw in Figure 5. In the case of a sales accrual, R/3 looks for two G/L accounts — one on the P&L side (such as outbound freight expense) and one on the balance sheet side (such as accrued freight expense).

Yes, it’s true. The exact same settings exist in purchasing and in sales with the exact same SAP terminology, and yet each performs a different function. In the case of purchasing, an accruals condition type posts its monetary value to one G/L account number. In the case of sales billing, an accruals condition type posts its monetary value to two G/L account numbers.

Kurt Goldsmith

Kurt Goldsmith is a senior business consultant for Enowa Consulting, specializing in the diagnosis and resolution of productivity-related integration issues between a company’s division of labor (end users, managers, executives) and SAP software (R/3, BW, APO, CRM). He also has a lifetime performance record of one win and two third-place finishes from five career starts as a thoroughbred racehorse trainer.

You may contact the author at kurt.goldsmith@enowa-consulting.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.