Tax payable posting to vendor account

Hello SAPers!

Standard report RFUMSV00 “Advance Return for Tax on Sales/Pur.” (for the purposes of this article also referred to as tax report) can be used for different tax reporting purposes. Apart from purely analytical purposes, it can also be used to generate files in .txt / .xml format for electronic exchange of reports as well as posting tool to calculate amount of tax payable and post it to so called “netting account”. Overview of both scenarios can be found in my previous article “Tax return in SAP”. This is a follow-up article that provides additional information on customizing options behind “posting mode” of this report. I would like to note that the information presented in this article shouldn’t be considered as a best-practice-scenario. This is rather an article that explores pros and cons of the approach. Whether or not it will suit your business requirements, that’s another question.

You can also find this blog post on Medium platform under the following link.

Standard setup for program RFUMSV00 (Advance Return for Tax on Sales/Pur.) implies that “netting account” that is used for posting of tax payable amount is a GL account. Consequently, if you use this setup, the flow of your accounting entries might look as follows:

1. Business operations relevant to VAT executed during the month resulted in debit balances on “Input tax account” (i.e. VAT credit from business perspective) and credit balances on “Output tax account” (i.e. VAT liability). Let’s suppose these amounts are equal to 6000 and 7200 UAH respectively.
2. You run tax report in “posting mode” to post tax payable (assuming, that your VAT liability exceeds your VAT credit), which results in the following accounting entries:

3. The next logical step would be to post payment to tax authority to cover this liability. Considering that payments in SAP are usually based on open items associated with vendor accounts (at least that’s a best practice), you should first do an additional accounting entry e.g. via transaction code FB60 to generate open item:

4. The next step in this process would be to run automatic payment program (APP) and post bank statement (EBS). There are different customizing options behind these two functionalities (e.g. APP run with or without postings; posting of bank statement with one or two posting areas, with / without automatic clearing of vendor open items etc.) but the result would be posting of payment:

This posting scheme involves additional manual posting (i.e. transfer of tax payable to vendor account), which can be avoided with proper customizing. Simplified posting scheme might look as follows:

Customizing behind this option can be reached via t-code OB89 or via the following menu path:

SPRO → Financial Accounting (New) → General Ledger Accounting (New) → Periodic Processing → Report → Sales / Purchases Tax Returns → Define Accounts for Automatic Tax Payable Transfer Posting.

Once in customizing menu, press “Posting Key” button to configure posting key for transaction “UMS”. Standard setup implies posting keys 40 / 50 for debit / credit posting. These posting keys are limited to GL accounts, therefore you cannot post tax payable to vendor account directly. To enable direct posting to vendor, change the setting by indicated posting keys 21 / 31 for debit / credit to vendor accounts and save your changes.

Return to previous menu and indicate vendor code.

Returning to program RFUMSV00, initiate posting of tax payable. Please refer to article “Tax return in SAP” for more details regarding specific options of this menu. Run the program.

As can be seen from the following screenshot total balance to pay equals 1200 UAH.

The result of batch input execution is summarized in the following typical log.

Screenshot of the resulting financial document can be found attached below:

Please note that there some drawbacks of this approach. One of them is that the program generates a lot of vendor line items. In this simplified example, it generated one transfer posting per each tax code. Considering that tax reporting and analytics in SAP is usually tax-codes-based, typical implementation for a company especially in countries with complicated tax regimes (Brazil, Russia, Ukraine etc.) might easily involve 50-60 tax codes. Because of these architecture, posting of tax payable directly to vendor account might involve a lot of “extra” vendor line items.

Depending on customizing options, posting of tax payable might be executed on more detailed level. This applies for instance to those cases when companies use document splitting functionality from New GL. If document splitting based on profit centers is used, posting of tax payable will generate one vendor line item for each unique combination of tax code and profit center.

The last aspect to cover in this article is related to processing of tax payable transfer documents from automatic payment program (APP) point of view. Though the net amount to pay in this example (1200 UAH) represents accounts payable position, APP doesn’t know about that. During proposal run only credit line items will be considered as eligible for payments, whereas debit line items will be included into exception list.

This issue might be easily solved by a simple workaround – clearing of vendor open items. Go to transaction code F-44, indicate references to vendor code, clearing date etc. and proceed to clearing. I would suggest to opt for clearing with residual item, which will clear two previous line items and generate new document with one open item, which can be easily processed by APP. Another drawback, however, is that it doesn’t inherit baseline date from the source document, but that’s not a big issue.

I hope it was an interesting article and you have learn something useful. I’m looking forward to your comments and remarks.

Best regards, 

Bohdan Petrushchak

P.S. Disclaimer.

All sensitive information used in this example is invented by my own. If there is some coincidence with real-life companies, it is a purely accidental one.

P.S. Acknowledgements.

This is not an original idea of my own. I’ve stumbled upon it in a post by Paul Ovigele and decided to explore different options behind its usage.