Most businesses that use R/3 need their cash-application employees and their credit managers to work as a team. The FI module comes delivered with this requirement covered. It offers a few different ways to record incoming customer full/partial payments that, in turn, can be convinced to automatically populate a few different tables. These tables act as the source for both list-style and summary-style standard reports that credit managers can access, as shown in Figure 1.

Figure 1

Standard functionality in FI to cover cash-application vs. credit-management teamwork

All variables that affect the system’s ability to increase the accuracy of, and details within, the credit manager’s receiving side of this handoff exist in the A/R module, right? Anything on the G/L-sending side that deals purely with the G/L and not the customer does not play a role, right?

Logic says yes. Your R/3 system says no. Get ready for a surprise.

Notice in Figure 1 that I highlighted the G/L offset account number that receives the debit side of the cash-application entry. A relationship between a setting in that G/L account’s master and a data entry to your customer accounts in cash-application transactions impacts the Last payment amount and Last payment date values shown in standard credit management reports. (See Figure 2 for an example of such a report).

Figure 2

Standard report showing the customer’s last payment amount and date

To make things even more confusing for people not aware of this relationship, a third factor during cash applications can cause the last payment amount and date fields to be updated, leading to a frustrating mystery for the end users, who see two different results on two different occasions from doing what they probably perceive to be the same cash-application steps.¹

I will show you the secrets behind this particular FI/CO mystery so that you can avoid it (or, if it has already taken hold at your site, fix it). First, I’ll look at a third field in the G/L, called Payment amnt, which triggers an update of the Last payment fields. Next, I’ll identify for you the two different situations that I know of that cause the Payment amnt field to be populated during a cash-application transaction. Neither is particularly intuitive or obvious. However, the second case – a checkbox setting called Relevant to cash flow in the cash account’s G/L master – is almost impossible to be aware of unless you hear or read about it from someone who’s already had an unpleasant experience because of it.

As you’ll see via screenprints, the G/L account number that needs this setting is not the one linked to the customer master. Instead, it is the one that serves as the debit offset to the A/R credit entry – in other words, the G/L account number that represents cash. Yes, a setting in the G/L cash account’s master impacts what you see in a standard report about an A/R customer account’s master. I have tested this and found it to be true in all R/3 releases up to and including 4.6x. Surprise!

Understanding the Automatic Update of Last Payment Amount and Date

Assume that the customer you’re recording a payment from has the Payment history record checkbox active in the R/3 customer master (see Figure 3).

Figure 3

The payment history record checkbox

Then the rule is quite simple: If the G/L document that is generated in response to someone’s saving their cash-application data entry contains a value in the Payment amnt field (see Figure 4).

Figure 4

An FI document with Payment amnt populated

The system automatically updates the Last payment amount and Last payment date values stored in credit-management table KNKK (see Figure 5).²

Figure 5

R/3’s automated reaction to what’s shown in Figure 3

It is this KNKK database table that often acts as the source for both standard and do-it-yourself custom reports used by credit managers.

Two Ways to Trigger the Automatic Update of Payment Amnt

So, how does a value enter the Payment amnt field during a cash-application transaction? Well, one way that it doesn’t is direct entry. Your end users have no chance to manually type anything into the FI document’s Payment amnt field. It can only be populated automatically by the system. I know of two ways to make sure this happens:

1. During their cash-application data entry (e.g., with transaction code F-28, Post an Incoming Payment), end users navigate to the Residual Items screen to record a partial payment prior to saving.

2. The master data record for the cash-related G/L account number used as the offset (against the credit being applied to the customer) has its Relevant to cash flow checkbox active. The more interesting and useful of these two methods is the second case. Let’s take a closer look.

Notice in Figure 6 that customer number 873021 has had three payments (document type DZ) recorded into my R/3 system – one from July 22, one from August 2, and one from August 5.

Figure 6

Customer 873021 recorded payments

Yet, in the standard report shown in Figure 7 (which I ran at the end of August), the value for Last payment amount and date relates to the July 22 transaction. How can this be?

Figure 7

A standard report fails to pick up customer 873021’s latest payment

Based on the two ways for updates to occur, there are two possible answers to this mystery. One is that the July 22 cash posting was recorded as a residual item (i.e., partial), while the other two cash receipts were payments in full. The second possible answer is that two different G/L offset account numbers are being used for the debit entry to cash.³ One of these has its Relevant to cash flow checkbox on (see Figure 8).

Figure 8

G/L cash account 771529 with its Relevant to cash flow checkbox on

One does not (see Figure 9). The July 22 posting perhaps occurred with the G/L cash account from Figure 8, while the other two postings perhaps were made with the cash account shown in Figure 9.

Figure 9

G/L cash account 992701 without its Relevant to cash flow checkbox on

One way to think about R/3 is in terms of its ability to speed up, slow down, add detail to, or automate the division of labor handoffs that go on in your company every day. An example is the handoff between the employees who receive the cash payments from your customers and the employees who evaluate the day-to-day lines of credit offered to your customers. I used this article as a chance to warn you about the unpleasant handoff trouble you’ll experience if you don’t understand the relationship between the G/L cash account’s Relevant to cash flow checkbox and the A/R module credit management report.

² Note that the value for the Last payment comes from the system date at the time the cash application is recorded, and not from your end user’s choice of a posting or document date.

³ Perhaps this is because two different end-users are posting payments, or perhaps because the same end user was told to choose a different G/L cash account depending on criteria that have nothing to do with R/3, such as wire payment receipts vs. check receipts.

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.