Tax management

• Tax determination in Procurement
• 514938 - FAQ: Tax and cash discount base, cash discount
• 2644237 - How non-deductible tax is calculated in transaction MIRO

• Tax determination in Sales and Distribution
• /S4 changes
• What is a VAT number? And how it is determined?
• Tax in the intercompany (cross-company) billing process
• Departure and destination country determination
• VAT registration number determination
• What fields do influence the tax determination in SD?
• Configuration 
• MWST condition type 
• Pricing schema
• Access sequence
• References
• 1911958 - Tax jurisdiction for export billing documents with ship-to party outside of the USA and Canada
• 1080399 - Cash discount and tax jurisdiction

Taxes in services (MM-SRV)

Tax determination in Procurement

Input tax: a tax that is charged by the vendor. A claim for refund of the deductible portion of the input tax can be submitted to the tax authorities.

Acquisition tax: Acquisition tax is due on the cross-border movement of goods and services within the European Union. The acquisition tax must be applied by the receiving party at the local rate (but can also be posted as input tax).  

Configuration 

• FTXP: Tax codes are defined in the customizing of Financial Accounting and they are dependent on the country
• T169V: for each company code which tax code(s) the System suggests when you enter incoming invoices/ credit memo/ subsequent debit/ subsequent credit
• OBZT: Per transaction and country, which tax codes are valid
• FS02: Edit the master record of a G/L account centrally in both the chart of accounts and company code specific areas.
• In Customizing for Logistics Invoice Verification, you configure for each partner which tax types and tax rates in transferred IDocs correspond to which tax codes in your system:
• The system uses table T076M to convert the tax code from the IDoc segment of type E1EDK04 (header) and type E1EDP04 (items).
• In the standard system, the tax code is determined in the form mrm_t_076_read.

Tax code in the PO :

• The tax code determines the tax rate.
• Taxes are calculated on a base amount with the tax rate from the tax code.
• The tax rate for the tax code is maintained in FI customizing (transaction FTXP ).
• Taxation is country specific; i. e. tax code N1 for India could mean another tax rate than N1 for Germany.
• Relevant for taxation in Purchasing is the country of the (receiving) plant.
• Taxes in the PO are calculated on item level (table EKPO).Tax code is stored in field EKPO-MWSKZ, Tax amount is stored in field EKPO-NAVNW.
•  Item ->  More functions  > taxes

Tax code determination in PO happens as below:

1. preceding item
2. contract
3. RFQ
4. info record
5. condition technique

(see Form MEPO_ITEM_FILL_MWSKZ include LMEPOF3Y  for the enjoy transaction PO and the UEBERNAHME_… - routines called from NEUE_POS_BESTELLUNG for the non enjoy transactions PO)

Condition technique for taxes in the PO 

• Condition type NAVS, customizing settings
• Condition class: 'D' (Taxes)                                    
• Calculation rule: 'B' (Fixed amount)                            
• Condition category: 'N' (Non-deductible input tax)  
• Scale type: ' ' (must remain empty)
• Access sequence (for condition tables): ‚003‘
• Maintain condition tables with transaction MEK2 (country specific!)
• Define tax indicators for material, plant, account assignment category in purchasing customizing (transaction OLME  -> Taxes) assign tax indicators for material in material master, purchasing tab.

Determination of tax code with condition technique is done in function module PRICING (from SD (Sales and Distribution), component SD-BF-PR)

PRICING is called in form PREISFINDUNG. Tax code is moved into EKPO-MWSKZ in PREISFINDUNG. (MEPO and SAPMM06E)

Interface structures for PRICING are KOMK and KOMP. They are filled in function modules ME_FILL_KOMK_PO and ME_FILL_KOMP_PO. (MEPO and SAPMM06E)

• KOMK-LAND1: country relevant for taxation, taken from (receiving) plant.
• KOMK-TXJCD: tax jurisdiction code, relevant for US tax (see below).
• KOMP-TAXIM, -TAXIK, -TAXIW, -TAXIL, -TAXIR: tax indicators, e. g. KOMP-TAXIM: Tax indicator for material, taken from material master.

Customizing for Taxes: Purchasing

• Define and assign tax indicators for material, plant, and account assignment:  IMG  > Material Management  > Purchasing  > Taxes
• (for material see also the ‚Purchasing‘-tab in material master)
• Check tax condition type:  IMG  > Material Management  > Purchasing  > Conditions  > Define Price Determination Process  > Define condition types
• Check calculation schema for PO:  IMG  > Material Management  > Purchasing  > Conditions  > Define Price Determination Process  > Define Calculation Schema
• Check entries of condition tables: transaction MEK2  > type in condition type (e. g. NAVS)  > choose table with radio button  -> type in country

 

514938 - FAQ: Tax and cash discount base, cash discount

1. Question: Why is it possible to set tax base = gross/net and discount base = gross/net?

Answer: The rule as to how the base amount for the calculation of the value-added tax and the base amount for the calculation of the cash discount are to be determined is subject to the relevant federal state law.

In Great Britain, for example, the base amount for the value-added tax is calculated as the invoice amount minus the agreed cash discount. The base amount for the calculation of the tax is net in this case.

In Germany, for example, the possible deduction of cash discount is initially also taxed when you post the document. A tax adjustment is then performed during payment clearing. The base amount for the calculation of the cash discount is gross in this case, that is, including value-added tax.

2. Question: What does tax base/cash discount base = net mean and what are the Customizing transactions?

Answer: Tax base = net

The tax base amount is reduced by the cash discount portion. The 'Tax Base is Net Value' indicator is to be set in the following transaction:

OBCP (field TTXJ-XMWSN): if tax calculation with jurisdiction

Code

OBY6 (field T001-XMWSN): otherwise

Cash discount base = net

The tax portion is not included in the cash discount base amount. The 'Discount Base is Net Value' indicator is to be set in the following transaction:

OBCP (field TTXJ-XSKFN): if tax calculation with jurisdiction

Code

OBY6 (field T001-XSKFN): otherwise

3. Question: What is the purpose of the tax category of the cash discount clearing account?

Answer: In the case of the document type 'Net posting', the system creates a cash discount clearing posting. The value

of this posting depends on the tax code of the cash discount clearing account:

Cash discount clearing account is non-taxable: Gross cash discount clearing amount (including tax)

Cash discount clearing account is tax-relevant: Net cash discount clearing amount (without tax)

All cash discount clearing accounts in a document must have the same setting with regard to tax relevance.

4. Question: Which possible combinations are there regarding the tax base, cash discount base and tax category of the cash discount clearing account and what are the corresponding postings in accounting?

Answer:

a) Tax base = gross and discount base = gross

Invoice amount: EUR 110.00

Cash discount percentage: 3 %

Tax percentage rate: 10 %

Material value: EUR 100.00

Since the cash discount base is gross, the cash discount amount is calculated from the

invoice amount:

3 % of EUR 110.00 = EUR 3.30

Since the tax base is gross, the tax is also calculated from the

material value:

10 % of EUR 100.00 = EUR 10.00

Post posting for document type net if cash discount clearing account is non-taxable (SKB1-MWSKZ = SPACE):

BS Account Amount

31 Vendor 110,00 und cash discount amount = 3.30 (= BSEG-KZBTR)

86 Expense 96.70

40 Tax 10.00

40 CDC 3.30

Post posting for document type net if cash discount clearing account is tax-relevant (SKB1-MWSKZ = SPACE):

BS Account Amount

31 Vendor 110,00 und cash discount amount = 3.30 (= BSEG-KZBTR)

86 Expense 97.00

40 Tax 10.00

40 CDC 3.00

b) Tax base = gross and cash discount base = net

Invoice amount: EUR 110.00

Cash discount percentage: 3 %

Tax percentage rate: 10 %

Material value: EUR 100.00

Since the cash discount base is net, the cash discount amount is calculated from the net

amount:

3 % of EUR 100.00 = EUR 3.00

Since the tax base is gross, the tax is calculated from the

material value:

10 % of EUR 100.00 = EUR 10.00

Post posting for document type net if cash discount clearing account is non-taxable (SKB1-MWSKZ = SPACE):

BS Account Amount

31 Vendor 110,00 und cash discount amount = 3.00 (= BSEG-KZBTR)

86 Expense 97.00

40 Tax 10.00

40 CDC 3.00

Post simulation for document type net if cash discount clearing account is tax-relevant (SKB1-MWSKZ = SPACE):

Error message M8 129 'Account &(G/L account no.) &(company code) for deductions/cash discounts cannot be tax relevant' is displayed because there is no valid combination.

c) Tax base = net and cash discount base = net

Invoice amount: EUR 109.70

Cash discount percentage: 3 %

Tax percentage rate: 10 %

Material value: EUR 100.00

Since the cash discount base is net, the cash discount amount is calculated from the

net amount:

3 % of EUR 100.00 = EUR 3.00

Since the tax base is net, the tax is also calculated

from the net amount (material value minus the cash discount):

10 % of EUR 97.00 = EUR 9.70

Post posting for document type net if cash discount clearing account is non-taxable (SKB1-MWSKZ = SPACE):

BS Account Amount

31 Vendor 109,70 und cash discount amount = 3.00 (= BSEG-KZBTR)

86 Expense 97.00

40 Tax 9.70

40 CDC 3.00

Post simulation for document type net if cash discount clearing account is tax-relevant (SKB1-MWSKZ = SPACE):

Error message M8 129 'Account &(G/L account no.) &(company code) for deductions/cash discounts cannot be tax relevant' is displayed because there is no valid combination.

d) Tax base = net and cash discount base = gross

This combination is only allowed for tax calculation with a tax jurisdiction code. A posting example is listed in SAP Note 111850.

5. Question: Why is the maximum cash discount debited to the cash discount clearing account during 'net posting' regardless of the baseline date for payment?

Answer: If you post invoices with a net document type and payment terms in Logistics Invoice Verification, the system always calculates the maximum cash discount and debits the cash discount clearing account accordingly. The reason for this is that the cash discount percentage rate with which the invoice will ultimately be paid is not known at the time of the invoice entry. This depends on the actual time of payment or on a changed payment term in the vendor line item of the accounting document.

In any case, the cash discount clearing account is completely cleared again when the payment is made. Any differences occurring as a result of a deviating cash discount percentage rate when the payment is made are posted to lost cash discount accounts or cash discount received accounts.

6. Question: Does the cash discount base amount determined always correspond to the total value of the invoice items?

Answer: a) In the case of 'gross posting (document type gross), the cash discount base amount (SKFBT) of an invoice is always calculated on the basis of the invoice amount (regardless of whether some items are marked as not relevant for cash discount).

Posting example:

Document type = gross,

Cash discount and tax base = gross, cash discount clearing account is tax-relevant

Gross amount EUR 225.00

Tax 10% EUR 20.00

Cash discount 3%

Item 1 EUR 100.00 'Without Cash Discount' = 'X'

Item 2 EUR 100.00 'Without Cash Discount' = ' '

BS Account Amount

31 Vendor 225.00 and cash discount base = EUR 225.00

86 Expense 100.00

86 Expense 100.00

40 Tax 20.00

40 Small difference 5.00

b) During 'net posting' (document type net), the cash discount base amount (SKFBT) of an invoice is calculated on the basis of the invoice items that qualify for a cash discount. If you have set the 'Without Cash Discount' indicator in an invoice item, this is not taken into account when calculating the cash discount base amount. This results in a cash discount base amount that deviates from the invoice amount.

Posting example:

Document type = net,

Cash discount and tax base = gross, cash discount clearing account tax-relevant

Gross amount EUR 220.00

Tax 10% EUR 20.00

Cash discount 3%

Item 1 EUR 100.00 'Without Cash Discount' = 'X'

Item 2 EUR 100.00 'Without Cash Discount' = ' '

BS Account Amount

31 Vendor 220.00 and cash discount base = EUR 110.00

86 Expense 100.00

86 Expense 97.00

40 Tax 20.00

40 CDC 3.00

c) The small difference or manually accepted difference is not taken into account for the calculation of the cash discount in Logistics Invoice Verification in the case of the document type 'Net posting'. This means that the small difference and manually accepted difference are not relevant for cash discount. If you want the above differences to be taken into account during the calculation of the cash discount, please use the document type 'Gross posting' or enter the cash discount amount manually.

Posting example:

Document type = net,

Cash discount and tax base = gross, cash discount clearing account tax-relevant

Gross amount EUR 225.00

Tax 10% EUR 20.00

Cash discount 3%

Item 1 EUR 100.00 'Without Cash Discount' = ' '

Item 2 EUR 100.00 'Without Cash Discount' = ' '

BS Account Amount

31 Vendor 225.00 and cash discount base = EUR 220.00

86 Expense 97.00

86 Expense 97.00

40 Tax 20.00

40 CDC 6.00

40 Small difference 5.00

2644237 - How non-deductible tax is calculated in transaction MIRO

Contrary to the deductive type of tax, non-deductible should be considered as an additional cost to the regular procurement process as it is not refunded by the tax authorities. This is the reason why this type is added to the gross amount and not considered as a tax transaction.

• NAV - Input tax, not deductible and not assignable: when this tax type is used, a posting on a separate account is created for this amount. The GL Account used for this transaction is assigned in FI transaction OB40.
• NVV - Input tax, not deductible and assignable: when this tax type is used, no separate line is created for the tax amount. This one is added to the stock account or to the subsequent account (Price difference account (PRD) or account maintained in the Purchasing document (KBS)) if no stock is available. The GL account used for this last case would be the one assigned in the Purchasing Document subject to tax.
• VST - Input tax, deductible.
• This input tax is paid to the vendor, who passes this on to the tax authorities. The offsetting entry for the tax is posted to a separate input tax account, on the basis of this account and the sales tax account, Financial Accounting can calculate the difference between the tax received and tax paid and pay this amount to the appropriate tax authority.The system creates a line for every tax code you enter. If various line items have the same tax code, the tax postings are added together.

Tax determination in Sales and Distribution

Output tax: tax levied on customers at all levels of production and trade. Output tax represents a tax liability.

/S4 changes

New tables

• DFKKBPTAXNUM Tax Numbers for Business Partner
• TFKTAXNUMTYPE_C  Customer Selection: Business Partner Tax Number Categories

Mapping to the tax category and internal fields: 

• Tax category ending in 0 --- Goes to field tax “VAT Reg. No” (STCEG)
• Tax category ending in 1 --- Goes to field “Tax Number 1” (STCD1)
• Tax category ending in 2 --- Goes to field “Tax Number 2” (STCD2)
• Tax category ending in 3 --- Goes to field “Tax Number 3” (STCD3)
• Tax category ending in 4 --- Goes to field “Tax Number 4” (STCD4)
• Tax category ending in 5 --- Goes to field “Tax Number 5” (STCD5)

...with the following exception for Germany:

• Country Germany (vendors)
• For vendors the rules are:
• Tax category DE1 -- Goes to field “Tax number” (STENR)
• Tax category DE2 -- Goes to field “Tax number 1 ” (STCD1)
• Tax category DE5 -- Goes to field “Tax number” (STCD2)
• Note that for customers in country Germany, the rule follows the general one (DE1 to STCD1, DE2 to STCD2, DE5 to STCD5).

and to other countries..

What is a VAT number? And how it is determined?

A VAT number is a registered tax identification number in tax systems that use Value-Added Tax (VAT). When you register for VAT in a single country, you receive a VAT number for their tax system.

Important note: A VAT number is not the same as a local tax number or tax ID. A VAT number is exclusively for the Value-Added Tax scheme.

The VAT number is important for businesses within the EU. Based on the existence of the VAT number business processes are considered as export or domestic.

If a customer is also registered for tax in more than one EU country, then the additional VAT number(s) can be stored in table KNAS which is changeable by clicking on the button ’Other…

During sales order processing both the tax departure country and tax destination country can be changed manually at the header level on the ’Billing Document’ tab.

• During sales order processing the VAT number (TKOMK-STCEG) determination is done in include: FV45PF0P_PREISFINDUNG_VORBEREI.
• During billing document creation the VAT number (VBRK-STCEG) is set in include: LV60AA95.

Tax in the intercompany (cross-company) billing process

A characteristic of the intercompany sales business is that the sales organization in which the sales order is created and the delivering plant are assigned to different company codes.

Departure and destination country determination

In the standard, the tax departure country is determined from the country of the company code (T001-LAND1) in intercompany billing.

• The tax destination country is determined from the country of the internal customers' sales organization
• If it is necessary to use the country of the delivering plant as a departure country instead of the country of the company code.  
• Using the country of the plant as the country of departure
• Using the country of the ship-to party from the order as the destination country
• Using the sales organization country as the country of departure

The tax destination country is determined by the country of the internal customer sales organization (KUWEV_LAND1). 

For this USEREXIT_PRICING_PREPARE_TKOMK, in include RV60AFZZ is applicable. Field TKOMK-TXJCD can be filled from KUWEV_AUFT-TXJCD.   

VAT registration number determination

The VAT registration number is determined from the country of the customer in his/her master data first. In addition, the system may determine the VAT registration number concerning the above 'Destination country' field which is the same as the country of the ultimate consignee as a ship-to party. This is the standard system response.

In some cases, however, it is required to determine the VAT registration number for a country different from the destination country of the ultimate consignee.

RV60AFZZ/USEREXIT_EMPFANGSLAND_SETZEN

What fields do influence the tax determination in SD?

1. Country of departure 
• It is the country of the delivering plant (T001W-LAND1) or manually defined at the header level
2. Destination country \the country of the ship-to party (KUWEV-LAND1)
3. VAT registration number for business within the EU
• If no Customizing for the determination of the VAT no. was stored, the VAT no. is determined according to the following rules: SPRO > Sales and Distribution > Basic Functions > Taxes > Maintain Sales Tax Identification Number Determination
• 
• If the payer has a VAT no. in the customer master and payer <> sold-to party, the VAT no. and the tax classification is taken from the payer (the ship-to party then becomes irrelevant).
• If the ship-to party has a VAT no. or the sold-to party does NOT have a VAT no., the VAT no. and tax classification is taken from the ship-to party.
• Otherwise, the VAT No. and tax classification will always be determined from the sold-to party. Customer tax classification is determined from the customer master for the relevant partner function for which the VAT no. is also determined. Tax classification of the materialThe tax classification is determined from the material master and you can change it manually in the Sales and Distribution document at the item level.
4. Date of services rendered
• Tax condition records are determined for the date of services rendered and NOT for the pricing date.
• At first, the system checks the sales documents for requested delivery date. 
• If one exists, the system checks whether the requested delivery date falls after the creation date of the document. 
• If this is the case, the system uses the requested delivery date for the SD tax determination. 
• If this is not the case, the creation date for the document is taken as the basis for the date of services rendered. 
• However, you can also change this automatically determined date of services rendered manually at the header level and the item level of the sales document. 
• It is possible that the date of services rendered in the sales document and accordingly the determined tax differs from the later billing document
• In the billing document, the date of services rendered is transferred from this goods issue date in the case of delivery-related billing if a goods issue date exists. If no goods issue date exists, the billing date is used.
• In the case of order-related billing, the system uses the billing date as the date of services rendered. 
• If the billing is carried out for a billing plan date, the system uses the to-date of the settlement deadline as the date of services rendered in the case of a periodical billing plan. In the case of a milestone billing plan, the system transfers the billing date of the relevant milestone billing date to the billing document as the date of services rendered.
• For billing, you should use a pricing type that redetermines the tax conditions, for example, pricing type "G". This ensures that the tax condition is redetermined at the time of billing with the date of services rendered that is now known. Only in case of the returns process it is required to keep the tax condition with the date of services rendered of the previous logistic process. Therefore, the pricing type "D" that does not redetermine the tax rate is used.

What is the configuration? 

• Condition type: The tax condition with condition class "D" must always be determined automatically; set the tax condition type as group condition to ensure a potentially necessary rounding difference comparison
• Access sequence: The pricing conditions 7 and 8 are assigned to the accesses.
• Pricing procedure 
• Include the tax condition type; positioning the tax condition after the non-statistical conditions; The tax condition is assigned to the account key that was specified by Financial Accounting.
• Pricing condition 10 is assigned to the tax condition in the schema. It checks for a supplying plant. It is necessary to determine the plant because this specifies the tax departure country. Alternatively, the tax departure country can be entered manually in the Sales and Distribution document header in the billing view.
• Use basis formula 16 to ensure that the net item value is used as the tax condition type basis. If possible, you should NOT refer the tax condition to a different step of the pricing procedure with a FROM-TO step. This could cause an incorrect determination of the tax condition basis. Tax basis and tax condition value must have the same sign.

Configuration 

MWST condition type 

• As calculation type, the only percentage is supported
• Manual processing of MWST should not be allowed to prevent inconsistencies.
• If the condition is set as 'Group condition' (field T685A-KGRPE) in customizing transaction V/06 then the calculation happens first on item level and then on the header level.
• A difference of '1' is determined between the amount calculated at item and header level, therefore a rounding difference will be:
• assigned to the item whose condition has the highest absolute condition basis (technically KAWRT)  if the calculation type (T685A-KRECH) is set to 'B' or 'T'
• assigned to the item whose condition has the highest absolute condition value (technically KWERT)  if the calculation type (T685A-KRECH) is set to any other value than 'B' or 'T
• If the condition base values are the same for all the items, the rounding difference comparison is assigned to the last item.
• The rounding difference comparison is done when you save the document or display header conditions: the system runs function PRICING_COMPLETE with which the condition group functionality is performed and KDIFF is assigned if necessary.
• Rounding difference comparison is only done if no grouping routine (T685A-KGRPE) is used or if the flag 'RoundDiffComp' (T685A-RDIFA) is set. The system runs function PRICING_COMPLETE with which the condition group functionality is performed and KDIFF is assigned if necessary.
• During billing document creation the conditions are re-evaluated.

Pricing schema

• In SD pricing procedure (transaction V/08) requirement 10 is assigned to MWST where the system checks whether the plant and departure country is filled.
• The standard condition base value formula is 16 (base value = net value).
• In standard circumstances, the Account key MWS is entered.
• The tax condition must be placed after special conditions (eg. down payment condition).
• Active surcharges should be placed before the tax condition.
• Avoid to have „From To” steps for tax condition

Access sequence

• To domestic business cases requirement, 7 is assigned. Within this requirement, the country of the origin and destination country are checked. If these countries are identical, then this requirement is met.
• To export business requirement 8 is set in standard. This requirement is only met if departure and destination countries are different, in the case of EU members the VAT number also has to be filled.

References

1911958 - Tax jurisdiction for export billing documents with ship-to party outside of the USA and Canada

1080399 - Cash discount and tax jurisdiction

If the tax jurisdiction function is active, the system determines the cash discount conditions SKTO (cash discount after tax) or SKTV (cash discount before tax) incorrectly.

In the SD pricing, the standard system provides only the check on the indicators XMWSN and XSKFN at company code level (table T001). However, if the tax jurisdiction function is active, you must check these indicators at the level of the tax jurisdictions (table TTXJ)

1009170 - Date of services rendered in credit memo process

If you create delivery-related credit memos for returns, the date of services rendered is determined from the goods receipt of the delivery.
If you then want to redetermine the tax condition in the credit invoice, the redetermination is performed at the date of the goods receipt posting of the returns delivery.

517089 - Value-added tax deduction procedure

2136305 - Threshold check for reverse charge

Sixth law for changing excise duty law §13 of the German Turnover Tax Act on JUL 01, 2011.

In particular, this affects cellular phone devices and integrated circuits as of a delivery value of EUR 5,000.00.

In this case, the reverse charge procedure must be used.

For this purpose, SAP Note 1610367 describes the use of the minimum sales order value function to check the total net value of a sales and distribution document.

However, this check with the help of the minimum sales order value is too inaccurate and the threshold values at document header level cannot be checked precisely.

Depending on the total net value of the sales and distribution document, a reverse charge tax condition should be determined in SD with a zero percentage tax rate. This reverse charge procedure must be noted on the invoice printout.

No threshold check at total net value level is envisaged in pricing.

The minimum sales order value function (condition AMIW/AMIZ) is too imprecise for the reverse charge procedure.

Comment:

The desired pricing result in accordance with §13 of the German Turnover Tax Act with regard to tax determination can be displayed only if you have carried out the determination of the total price for the document, since the 5,000 euro limit refers to the entire document.

The determination of total price (function module PRICING_COMPLETE) takes place when you save the document, during activation on the header condition screen, and when you exit the header condition screen. Before these actions, it is not always possible to identify which tax is active in the document. However, the tax result is determined correctly when the document is saved at the latest.

Price determination takes place in order documents and in billing documents. If milestone billings occur, the total net value of the billing document can differ from the total net value of the order. If the tax determination in the order needs to match the tax determination in the billing document, organizational measures must be taken to ensure that billing takes place in full only.

This check of the total net value can be mapped in SD with two help conditions (here ZMIW and ZMIZ) that check the total net value of the document and compare it with the 5,000 euro limit.

Furthermore, two tax condition types are required: One with the reverse charge tax code and one with the standard output tax code. Depending on the total net value, one tax condition is deactivated while the second remains active.

If the 5,000 euro limit is not reached, the tax condition ZW14 with the inactive indicator 'W' (KONV-KINAK = 'W ') is deactivated. The tax condition MWST remains active and the document is therefore taxed.

If the 5,000 euro limit is reached, the tax condition ZW14 remains active and the tax condition MWST with the inactive indicator 'W' (KONV-KINAK = 'W ') is deactivated. The SD document is posted to financial accounting with a zero percent tax rate and a reverse charge tax code.

The tax condition MWST is created with the normal tax amount. The tax condition ZW14 is created with zero percent and a tax code for reverse charge. As a result, the tax liability is transferred to the service recipient. A net invoice is transferred to financial accounting.

However, the service recipient must transfer the tax to the tax office. This special reverse charge tax code must therefore be checked in the billing document printout and, if appropriate, a text must be printed on the billing document printout stating that this is a reverse charge tax that the service recipient must pay.

2550830 - Tax classification is not copied to sales order header

During the sales order creation the tax classification of the customer master is only needed for the tax determination. As a result this field will be taken and only transfered to structure TKOMK that is needed as an interface structure for pricing. This information about the tax classification of the customer will NEVER be copied into the sales order header.

However, if you want to override this tax classification from customer master, then you could enter manually the following fields:

1. The tax classification of the customer (VBAK-TAXK1), or
2. The tax classification of the material (VBAP-TAXM1).

That is the reason why in the sales order header it is called: 'ALTERNATIVE tax classification'. You can check in ABAP source code that it is designed this way:

PROG FV45KFAK_VBAK_FUELLEN_KUAGV

FORM VBAK_FUELLEN_KUAGV.

********

LOCAL: VBAK-AWAHR.

LOCAL: VBAK-STCEG_L. "eu-tax

*>>>> START OF INSERTION <<<<

* the fields VBAK-TAXK1, ..., VBAK-TAXK9 must be made local because

* they are not filled by customer master data, they are only changed

* manually by user

*******

1032869 - Tax determination in intercompany billing

The system determines the partner roles of the sold-to-party (SP), payer (PY), bill-to-party (BP), and ship-to-party (SH) in intercompany billing according to a special logic and this differs from the customer billing document.
Based on these partner roles and depending on the business process, tax determination is carried out within SD pricing based on different tax-relevant data.
Due to the complexity, consultation is required for the cross-company code process or the internal billing document.

Note 308989 describes the cross-company code processes in more detail and Note 872449 provides more detailed information about tax determination in Sales and Distribution.

The following points describe the standard logic in ERP and show how you can deviate from this standard logic in order to meet the individual requirements.

Section I contains the partner determination display in intercompany billing; section II deals with the determination of the tax-relevant data based on the partner data; section III deals with process-dependent details.

I Partner Determination in Intercompany Billing

The partner roles sold-to-party (SP), bill-to-party (BP), and payer (PY) are set to the internal customer (ICB customer). The internal customer is transferred to the structure KUWEV/ XVBPA at this point.

The partner role ship-to party (SH) is filled with the real physical ship-to party.

The "real" physical ship-to party is transferred to the structure KUWEV_AUFT/ XVBPA_WE_AUFT.

One possible deviating requirement for determining the partner data in intercompany billing is the differentiation of the (header) partner roles SP, BP, and PY. This is possible using the user exit RV60AFZD (see Note 141676).

II Tax-Relevant Data in Intercompany Billing

1. Determining the country of departure and the destination country

In the standard ERP system, the tax departure country is determined from the country of the company code (T001-LAND1) in intercompany billing.

The company code itself is determined from the table T001K.

In some cases, you want to use the country of the plant as the country of departure and not the country of the company code. Case 2a) from Note 10560 provides a solution for this.

In the standard ERP system, the tax destination country is determined from the country of the sales organization of the internal customer in intercompany billing (KUWEV_LAND1). The structure KUWEV is filled with the internal customer.

In some cases, you want to use the country of the ship-to party from the order as the destination country instead of the intercompany billing customer. Case 2b) from Note 10560 provides a solution for this.

If case 2b) from SAP Note 10560 is used, that means that the country of the physical ship-to party from the order is set as the recipient country. In this instance, the tax jurisdiction of this ship-to party should also be transferred from the order in case of tax jurisdiction. For this purpose, in RV60AFZZ, USEREXIT_PRICING_PREPARE_TKOMK, the field TKOMK-TXJCD can be transferred from XVBRP-TXJCD.

 

2. Determining the value added tax registration number (VAT registration number) in intercompany billing

In the standard ERP system, the VAT registration number is determined from the customer master record of the internal customer with the destination country in intercompany billing.

In some cases however, the VAT registration number with regard to a country different from the ship-to party country of the end customer must be determined; for example, from the country of the internal header partner (PY). Note 371764 provides a solution via the user exit RV60AFZZ.

3. Determining the tax classification of the customer and the material

The customer tax classification is determined from the master record of the internal customer (as with the VAT registration number).

The material tax classification is read from the material master and corresponds to the classification of the customer billing document.

III Process-Dependent Details

For the order-related ICB document (see Note 63459), the ICB document is created on the basis of the customer billing document and tax determination is carried out for the internal customer.

If you want to use the ship-to party (SH) from the order instead of the internal customer, the modification from Note 202377 provides a solution.

1255945 - Pure tax posting from SD

There is a legal requirement to create an SD billing document with a pure tax posting. Therefore, only the tax is posted to accounting by the billing document.
This consultation note explains the necessary settings in the SD application.

A specific pricing schema is created in SD pricing, which is used for these specific tax postings.
The tax condition refers to a statistical price condition. Since statistical conditions are not transferred to financial accounting, only the tax condition in the accounting document is posted.

2747473 - Free-of-charge delivery for which tax is paid by sales organization

In some countries (such as Italy and Egypt), there is a requirement that the value-added tax has to be paid for a gift invoice. The tax is then assumed by the sales organization itself and posted to a different G/L account.

A possible implementation for such a scenario is described below. It is an example solution. Please verify with your tax consultant what a solution has to look like for your specific circumstances.

The solution is a special case of the implementation already presented in SAP Note 34526. It is described in more detail here.

Implementation steps:

1) Create a separate order type for these free-of-charge deliveries. Call transaction VOV8 and create the order type, such as 'ZKL'.

2) Create a separate account key, such as 'ZK', and assign it to a G/L account. You can do this with transaction OV34 and then assign the G/L account to the account key in transaction VKOA.

3) You then have to create the following conditions in transaction V/06:

Z001 100% discount (copy of K020)

Z002 100% discount (copy of K020)

4) Then create your own pricing procedure using transaction V/08, for example, 'ZKL001'.

Step CTyp From To Manu CoCtr

-----------------------------------------------------------

10 PR00 ERL

20 MWST MWS

30 Z001 10 ERL

40 Z002 20 x ZK

5) You now have to assign the order type to the pricing procedure.

SPRO: Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define and Assign Pricing Procedures

To do so, use the appropriate customer pricing procedure and the document pricing procedure.

How does the implementation work now?

You create a sales document with a price PR00 in the amount of 8 euros, for example. To make it a free-of-charge delivery, you now grant a 100% discount, Z001. The document now only contains the value-added tax. At a price of 8 euros and a tax rate of 19%, this equals EUR 1.52. You now clear this with discount Z002, resulting in a zero invoice. MWST and Z002 cancel each other out. As a consequence, the net value of the document, which is calculated from all the prices and discounts, becomes negative. The VAT and net value total to zero again.

The sales document then looks like this:

PR00 Price 8.00 EUR 8.00 EUR

MWST Output tax 19.000% 1.52 EUR

Z001 100% discount 100.000- % 8.00- EUR

Z002 100% discount 100.000- % 1.52- EUR

Final amount 0.00 EUR 0.00 EUR

Item net value (VBAP-NETWR): 1.52- EUR

Tax 1.52 EUR

The document then looks like this in FI:

1 50 800000 8.00- EUR A1

2 50 175100 1.52- EUR A1 Tax posting

3 40 XXXXXX 8.00 EUR Expenditure/revenue reduction for discount

4 40 YYYYYY 1.52 EUR Expenditure/revenue reduction for VAT to pay

Line 4 may not be a tax item.

 

2381462 - Tax classification change effects every sales organization

Tax classification (KNVI-TAXKD) in XD02 is changed for a sales organization, then this tax classification is transferred to all other sales organizations of the customer.

In table KNVI the sales area is not present thus the changes are transferred to all sales areas.

A different system response can only be achieved with following workaround.

Fields KVGR1-KVGR5 in table KNVV can be used to define different tax indicators for customers in different sales areas.

These fields can be set in customer master (XD02) under path Extras > Additional Data. The newly added KNVV field has also to be set up in the pricing table and access sequence of the affected tax condition.

In that way different tax classifications can be maintained for a single customer in different sales areas.

In OVK3 a new tax category has to be created

In OVK1 the new tax category has to be assigned country wise

For example following tax categories could be set up

Condition Sequence Tax classification

MWST 1 2

ZWST 2 3

For the second tax category an own access sequence is needed, where instead of TAXK1 field TAXK2 is used.

Make sure that the newly created condition has a tax code and amount maintained.

Additional information

1927327 - Tax line items from SD

When you release an billing document with multiple billing items in SD, you expect one tax line item per billing item to be generated in the accounting document. But only one tax line item is generated after the first sales item and you want to know how the tax line item is determined in accounting document.

• In pricing procedure, you define the tax item after sales item.
• For postings from SD, the tax line items in the accounting document are always summarized to the first tax line item even no summarization settings are maintained in transaction OBCY.

Please note this is a modification (See SAP note 170183).

Other

1. 872449 - Tax determination in Sales and Distribution
2. 91109 - VAT registration number of customer disappears 
3. 2865204 - Mapping Business Partner Tax Number Categories to customer/vendor Tax Number fields
4. SD Tax Configuration and Troubleshooting Guide
5. 1466873 - Different condition value between order and invoice