In the many years I have been consulting in the FI area, almost every U.S. client I have worked with has had a common issue — 1099 MISC reporting. The question they have had is how to deal with data outside their SAP system that is subject to 1099 MISC reporting. The good news is that starting with Release 4.7 (Enterprise), they can post that data directly in their R/3 system via a commonplace data entry field that has a new use — the special G/L indicator. (See the sidebar, “What Is a Special G/L Indicator?”) The Generic Withholding Tax Reporting program (new as of Release 4.7) now allows the selection of vendor invoices posted in SAP R/3 both with and without a special G/L indicator (Figure 1). Now, why would you want to post a vendor invoice with a special G/L indicator merely for a 1099 tax report?     To answer that question, you need to know two things. First, the special G/L indicator, when used, drives the debit or credit value posted to a vendor to a unique, not-typically-used, balance sheet account number. (See the sidebar, “What Is a Special G/L Indicator?”) Second, several normal business events can lead to a condition in which some 1099-relevant data is not in your SAP system. If you want to add that data into your SAP system, you run the risk of double-counting the vendor amounts on your balance sheet report. Not good. I’m going to give you some examples of how 1099-relevant data can end up outside of your SAP system. After that, I’ll take one of those examples and walk you through the steps on how to apply the old functionality (special G/L indicator) to the new functionality (the Generic Withholding Tax report) to get all your 1099 data in one place without double-counting on your balance sheet. Here are three quick examples of how 1099-relevant data can end up outside your SAP system:

• Your company uses procurement cards for purchases, and you only pay the procurement card issuer on a monthly basis without entering the single purchases in your SAP system. (I’ll explain this example more fully later.)
• Different A/P data sources are not integrated, and you want to report all 1099 transactions from R/3.
• You just went live with SAP in the middle of the year and need to convert your 1099 MISC transactions from the beginning of the year through your SAP go-live date.
  Disadvantages of Reporting from Different Systems

  Reporting 1099 MISC transactions from different systems presents the following drawbacks:

  • As every taxpayer knows, the tax reporting requirements change from year to year. I cannot remember when I was able to use the same forms and instructions for more than one year. If you have the requirements in more than one system, you need to do your adjustments multiple times. This repetition is time-intensive and increases the costs of your ongoing system support. However, SAP does provide you with the latest legal changes in reporting requirements and form changes as part of your service agreements.
    • Cumbersome audit trail. It is difficult to track data changes in outside SAP data or in custom tables within SAP. In the case of an IRS 1099 tax audit, you are required to provide detailed supporting documents for each transaction. This can be difficult if your 1099 MISC data resides in different systems. SAP, however, provides a change history for all transaction data.
    • Merging different 1099 files usually requires programming knowledge and file reconciliation procedures. The IRS requires strict deadlines for 1099 forms (January 31) and 1099 file submissions to the IRS (March 31). Since missing these deadlines results in heavy penalties, you do not want to rely on too many factors in preparing your 1099 forms and files.

 

Options Prior to Release 4.7

Can you report on those 1099 MISC transactions from different systems? Sure. One method is to print the 1099 MISC forms and then merge the 1099 files. Another approach is to upload outside transactions into custom-defined SAP tables (commonly known as “Z” tables, because custom-defined SAP tables need to start with the letter Z) and modify the SAP standard 1099 MISC reporting tools in order to include the data in your “Z” tables. Both of these approaches have common disadvantages. (See the sidebar, “Disadvantages of Reporting from Different Systems.”)

Post Procurement Card Data into R/3

To more easily see how the special G/L indicator functionality allows you to get all of your 1099-relevant data into R/3 without requiring lots of extra data entry from your end users or creating extra confusion for accounting report analysts, let’s use the example of procurement cards. A lot of companies use procurement cards to streamline their purchasing process. Usually procurement cards are issued to various departments with dollar limits, and these departments can purchase smaller items like office supplies without purchase orders. Then, on a monthly basis, the procurement card provider (i.e., MasterCard or Visa) sends a statement, and the entire amount due is paid to the card provider. This process may be beneficial for your procurement department. However, your accounting department is missing the amount and vendor information for each single purchase in your system that is necessary for proper 1099 MISC reporting. To solve this dilemma, all single purchases with your procurement card have to be entered into your system. Your accounting department may argue that by posting these transactions again, you inflate invoices and payments and therefore report misleading cash flow statements. Using the following method, you can post these transactions without any effect on your current account balances or cash flow statements.

Accounting Document Flow

To help you understand how the postings flow through your SAP system without impacting your cash flow statements, I’m using an example of two purchases that are relevant for 1099 reporting (Figure 2). During 2003, say you purchased two items from Vendor 45000. You purchase the first item ($1,500 USD) through your regular purchasing process. To simplify my example, let’s have the cost directly posted to an expense account instead of a GR/IR account. The invoice is entered in A/P (Document 1). This debits the expense account and credits the vendor’s normal B/S reconciliation account (which is defined in the vendor master data). During the regular payment process, you’ll end up crediting the bank account and debiting that normal vendor reconciliation account (Document 2). Item 2 ($800 USD) is a purchase with a procurement card from Vendor 45000. The invoice is already processed and paid to Vendor 31000, which represents the procurement card provider. The accounting postings are the same for Vendor 45000 and Vendor 31000. Document 3 represents the invoice and Document 4 the payment. Normally you would not enter any additional documents in SAP. However, by stopping here, you would only report $1,500 USD for Vendor 45000 to the IRS, instead of the correct amount of $2,300 USD. In order to report the correct amount, you need to enter two additional documents — an invoice and a payment in the amount of $800 USD for Vendor 45000. According to the requirements of your accounting department, the documents must not hit the normal vendor reconciliation and bank account. Otherwise, you would issue incorrect cash flow statements. You can avoid incorrect statements by posting the invoice with a special G/L indicator. This changes the normal vendor reconciliation account. In my example, I’m posting with special G/L indicator Y (Document 5). The contra account for the invoice should be an account that is not included in your normal financial statement account range. This account is debited during invoice entry and credited during payment (Document 6). The net effect on this account is zero. You have accomplished two things so far. First, the non-SAP data is posted in SAP without influencing the financial statement reporting. Second, the non-SAP data is now available for 1099 reporting. Next, I’ll explain how to create the necessary G/L accounts and customize the settings for the special G/L transactions.

G/L Account Creation

You have to create two new accounts for your special G/L transactions. Both accounts can be created with transaction FS00 (menu path Accounting> Financial Accounting>Master records>Individual Processing> Centrally). Account 1 — Creation of vendor reconciliation account. This account is used as the vendor reconciliation account for your 1099 MISC postings with a special G/L indicator. It has to be created as a balance sheet account and reconciliation account for account type vendor. Account 2 — Contra account for 1099 invoice/payment postings. This is a contra account that is debited during invoice entry and credited during payments. The net effect is always zero. This account has to be created as a balance sheet account.

Customization Steps

To post the invoice/payment with a special G/L indicator, you must carry out three customization steps: Step 1: Define special G/L indicator You can create a new special G/L indicator for vendors within customization via transaction OBXT (menu path Financial Accounting>Accounts Receivable and Accounts Payable> Business Transactions>Postings with Alternative Reconciliation Account> Other Special G/L Transactions> Define Alternative Reconciliation Account for Vendors). On the first screen, click on create. A sub-screen appears (Figure 3) that lets you define a new special G/L indicator. For my example, I chose G/L indicator Y. Fill in the name and description, and click on enter on the Special G/L - List screen. On the Special G/L - Properties screen (Figure 4), fill in the Posting Key description for the Debit and Credit posting and click on Accounts. The other checkboxes are not relevant. On the Special G/L — Accounts screen (Figure 5), you assign the new vendor reconciliation account that you earlier defined to your regular reconciliation account. After you assign your account, click on save. Step 2: Define Posting Keys for incoming invoices on the Enjoy screen The second customizing step is to assign the posting keys for the SAP Enjoy transactions (FB60). You can define the postings keys in transaction OBXJ (menu path Financial Accounting>Accounts Receivable and Accounts Payable> Business Transactions>Incoming Invoices/Credit Memos>Incoming Invoices/Credit Memos Enjoy>Define Posting Key for Incoming Invoices/Credit Memos). On the configuration screen (Figure 6), double-click on the line Vendor item with Special G/L indicator (transaction EGX). Enter Posting Key 29 as the debit Posting Key and 39 as the credit Posting Key. For my example, I chose the SAP predefined posting keys for a special G/L transaction. However, you can define your own posting keys with transaction OB41. Step 3: Define Debit Posting Key as a payment transaction The third customizing step is to set the Debit Posting Key 29 as a payment transaction. This step is important because the standard 1099 reporting program only reads payment transactions. In this case, I assume you want to report only those 1099 MISC postings actually paid within the year. You can define the postings keys in transaction OB41 (menu path Financial Accounting>General Ledger>Business Transactions>Check Out And Check Document Settings>Define Posting Keys). On the screen Posting Keys – List, double-click on Posting Key 29 and select the Payment transaction checkbox (Figure 7).

Data Entry Example

That is all that needs to be done from a customizing prospective. Next, I’ll show you a posting example with the two invoices and standard 1099 reporting. As in my theoretical example above, say you purchased two items from Vendor 45000. The first invoice ($1,500 USD) is entered directly in A/P with transaction FB60 (Figure 8). The expenses are charged to a cost center within your organization. The second invoice ($800 USD) represents a single purchase with a procurement card (Figure 9). In this case, the invoice is entered with special G/L indicator Y. This ensures that the invoice is posted to the special vendor reconciliation account you defined in Step 1 and assigned to special G/L indicator Y in Step 2 of the customizing section. Note that the G/L account in the invoice document is the balance sheet account from Step 1. This account will be debited in the invoice and credited during the payment. The first invoice is paid during your normal payment run (transaction F110). This is a common process in your A/P department that does not need to be described in detail in this article. The second invoice is paid with transaction F-53 (menu path Accounting> Accounts Payable>Document Entry> Outgoing Payment>Pay). Note that the bank account is the same account you entered during invoice entry in Figure 8. Therefore, the net effect is zero once the payment is posted (Figure 10). So far you have entered all the documents. In the last step, the standard SAP 1099 reporting program is executed, and you see both items to be considered for 1099 purposes.

1099 Reporting with the Generic Withholding Tax Reporting Tool

Now you are ready to include special G/L transactions in the Generic Withholding Tax Reporting Program (RFIDYYWT). Use transaction S_P00_07000134 (menu path Accounting>Financial Accounting> Accounts Payable>Withholding Tax>General). I showed you the initial screen in Figure 1. Use Process Type US_1099 and Output Group US2. Both the process type and the output group are predefined by SAP for 1099 reporting. On the Generic Control portion of the screen, type in the special G/L indicators you want to be included in your 1099 reporting. In my scenario, I’m using indicator Y. After you enter all other information such as company code or reporting period, click on execute. The resulting report shows all documents that are relevant for 1099 reporting. As you can see, both items were selected and the correct amount ($2,300) is shown for Vendor 45000 (Figure 11).

---