VAT on down-payments
Here is another post, where I’d like to share a couple of details about SAP’s functionality. This time about handling of down-payments. I hope you’ll find something interesting for you.
Down-payment is a special payment that the company receives prior to goods issue to customer or is sending to vendor before goods / service receipt. Consequently, we can distinguish between incoming and outgoing down-payments.
SAP specifics for down-payments processing implies use of Special GL indicators (SGL-indicator). SGL-indicator in the case of down-payment can be considered as a special attribute of transactional data that re-routes the posting from regular AP/AR reconciliation account to a dedicated reconciliation account for down-payments (i.e. down-payments made / down-payments received). Separate reconciliation account for down-payments is not a mere technical feature, but as a rule legal requirement.
Certain countries for example Ukraine or Russia consider down-payments as events which increase companies’ VAT liability / credit. Therefore, certain customizing and master data prerequisites should be met to ensure that these events can be accounted for correctly in SAP.
This post explains the functionality behind calculation / posting of VAT on down-payments on so called “gross basis”. “Gross basis” is not official accounting term, rather a popular description behind the approach. This approach assumes that total amount of down-payment is a sum of tax base + VAT amount.
Accounting postings for typical vendor down-payment process would be as follows*:
- This example assumes tax rate of 20 %;
- Input VAT amount is posted to in correspondence with “VAT on down-payments made” account, which can be considered as clearing account;
- “Deferred” input VAT represents a temporary GL account, which might be used in some countries to account for VAT amounts before they are re-posted to “target” GL account i.e. before input VAT can be considered as deductible. This reposting can be made via deferred tax transfer programs or by special localization-specific program. This topic by itself is very broad and cannot be covered as part of this post.
Accounting treatment for incoming down-payments is similar:
2. Overview of customizing
Posting scheme for VAT on down-payments requires configuration of clearing accounts for VAT on down-payments. Configuration of automatic accounts determination can be reached via t-code OBXB or via the following menu path:
SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business Transactions → Down-Payments Made → Define Account for Tax Clearing.
Relevant transaction keys for VAT on down-payments are MVA – for incoming down-payments and VVA for outgoing down-payments:
Add account modification A and clearing GL account for input VAT:
Do the same for output tax clearing:
Account determination for clearing VAT accounts can be universal (i.e. the same GL account will be used regardless of vendor’s / customer’s reconciliation account) or can be dependent on account modification. Go posting rules’ settings and activate checkbox “Input/output tax clearing” to enable account modifications:
Once account determination is maintained, proceed to customizing of special GL indicators in t-code FBKP or via the following menu path:
SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business Transactions → Down-Payments Made → Define Alternative Reconciliation Account for Down Payments.
As a rule, most companies use SGL-indicator A for down-payments, but other indicators might be used as well. Check which of them are relevant for your company and if they have type “Down payment / down payment request”:
Indicate account modification A for those vendor reconciliation accounts, which are subject for VAT calculation. If you have several account modifications, you can have different account determination for example for local vs. foreign down-payments.
Perform similar customizing for customer down-payments:
3. Master data prerequisites
So far, the setup is complete from configuration point of view. But there are a few prerequisites for master data of GL accounts / tax codes that are involved into the posting:
Prerequisites for incoming down-payments:
- Reconciliation GL account for incoming down-payments should have tax category +B;
- Posting of incoming down-payment should involve tax code with type “A” (i.e. output tax);
- Clearing account for output VAT on down-payments should have tax category “>” and should not be managed on open items basis.
Prerequisites for outgoing down-payments:
- Reconciliation GL account for outgoing down-payments should have tax category -B;
- Posting of outgoing down-payment should involve tax code with type “V” (i.e. input tax);
- Clearing account for input VAT on down-payments should have tax category “<” and should not be managed on open items basis.
Tax categories of GL accounts can be checked in t-code FSS0, whereas settings of tax codes can be verified in t-code FTXP.
4. Examples in the system
Example of incoming down-payment can be found below*:
* Note: just in case, transaction key UAM is a custom key for output VAT, instead of standard key MWS.
Example of customer invoice can be found below:
Example of clearing of customer’s open items can be also found below:
I hope that you have learn something useful once you reached this sentcen. I’m looking forward to your comments and remarks.
From your example of customer down payment, what if the event of down payment received (let say period 4) is in the different period with the event of customer invoice (say period 6)?
Account Def. Output Tax must be paid first according to local tax law since it is a liability in the balance sheet. This account will be cleared by a payment to tax office. In this case, when customer invoice is posted, no more open item of Def Outout Tax to match. Hope my question is clear to you and you still around to read this.
Need your enlightments on this.
Thank you and regards,
From accounting perspective everything is fine. Please note that this GL account i.e. deferred output VAT was posted to three times:
As a result, credit posted in sales invoice will be cleared by debit posting from clearing document. Please note - clearing document in this case is used for clearing of customer's open items. In other words, if your GL account for deferred output VAT is managed on open item basis, you might have additional clearing of VAT.
We have exactly the same treatment of VAT in Ukraine as you mentioned and this posting scheme works fine.
Thank you very much Bohdan. This article and your explanation are very helpful.
My client's demand is to cut the withholding tax with the down payment. So in that case what will be the configuration?
Hi Shishir Kumar,
Well, I'm not the biggest expert on withholding taxes, but I would say that in this context these are two functionalities, which can work independently from one another. Do the configuration for withholding tax, update vendor master data accordingly and see how it works together with VAT.
Thanks for sharing the knowledge. What a great blog. I have done all the setting according to your blog for VAT on down-payments. All steps are working fine but during the clearing of customer’s open items I am facing this issue the output tax amount posted twice. Screen Short has been attached for your understanding.
Hi Shahid Islam,
It's difficult to tell why you have two pairs of output VAT without access to the system. My suggestion is: could you please check if there are any differences in CO-assignments for Output VAT in particular profit center?
Thanks for your reply actually I am using the wrong clearing T.Code for this process. Later on I found the right clearing T.code (FB15 - Assign/Clear Open Items ) for that process. So I have resolved the issue may self. Screen short of clearing document is attached.
Do we need any custom code to be added for the solution to work?
I have done all the configuration required and while I simulate, VAT is not getting calculated for vendor advance payment.
Hi Gyanaranjan Samantaray,
No custom coding is necessary for the solution to work. Please check carefully step by step all requisites, maybe you missed someting.
Thanks for the quick revert.
I have done all the configurations following your blog.
I tried to post down payment from ME2DP and calculate tax check box is disappearing automatically while simulating. Because of this, VAT line item is not appearing.
Congrats, really good explanation.
I have a question. We are facing a problem for a Customer downpayment posted. After the payment but before delivery the customer is allowed to cancel the order, thus we need to give the money back.
We don't manage to created the opposite entry via standard and get the taxes posted correctly as it seems "credit note cannot be posted to the advance account".
Did you see anything similar or do you have any suggestion on how to process the refund with the corresponding cancelation of the 1st downpayment?
I do not want to post the VAT lines during the incoming payment.
How could this be done?
Hi Paul Van Belle ,
There are two options: if VAT on down-payment is not relevant for a country at all, you can adjust the tax category of reconciliation GL accounts by removing +B/-B tax indicators. During entry of down-payments make sure to use a tax code with a 0% rate i.e. ideally speaking it should be the same tax code as it is configured in t-code OBCL.
If you have VAT on down-payments in some cases, but no VAT in other cases - you can control it solely via use of tax codes with zero and non-zero tax rates.
Thanks for the input, I did the same setting but I used standard account key MWS instead of UAM. when post down payment only one line for VAT. Another one of MVA is not poped when simulating. Could you know what's the reason maybe?
Hi LIANG ZHOU,
It's not a problem to use MWS. MWS or UAM is just a key in tax calculation procedure. If you post a down-payment, but it is posted with one line only, then you probably missed some configuration or master data requirement. Please check once more all configurations & master data step by step. If you do everything the same way, it should work.