Richard Cornelisse

Case study: cross-border chain transactions and the weakness of Standard SAP

In Audit Defense, Benchmark, Business Strategy, EU development, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, Technology on 12/09/2013 at 2:35 pm

Taxmarc™ SAP solution2

By Robbert Hoogeveen and Richard Cornelisse

Richard CornelisseRobbert Hoogeveen The business models of many enterprises have radically changed over the last years and have become increasingly complex. SAP, however, has failed to keep up, which has resulted in the standard functionality of SAP being no longer sufficient for complying with VAT obligations.

Practical solutions must be found within the flexibility and static organization of SAP regarding indirect tax. Because of this, SAP Indirect Tax Consultants in the market can only patch up the existing SAP framework.

Cross-border chain transactions with third parties or within a group of company (intercompany transactions) have become the rule rather than the exception.

Below you will find a case study re cross border intercompany transactions.

This example is representative for overall Standard SAP weaknesses from an indirect tax perspective.

Standard SAP issue – intercompany transactions – a case study

Chain of transactions:

  • Company A, manufacturing, is established in Frankfurt DE
  • Company B, sales, is established in Rotterdam NL
  • Customer C established in Amsterdam NL
  • Company B sells to Customer C in country NL from a plant that belongs to Company A (Frankfurt DE)

Standard SAP set up

In Standard SAP the country of departure is based on the plant (Frankfurt DE) and the country of destination is based on the ship to customer (Amsterdam NL). The country of departure and destination are for both Company A and Company B the same.

  • SAP transaction from perspective Company A: plant is DE01 (Frankfurt DE), Sold to is Company B (Rotterdam NL) and Ship-to is Customer C (Amsterdam NL)
  • SAP transaction from perspective Company B: plant is DE01 (Frankfurt DE), Sold to is Customer C (Amsterdam NL) and Ship-to is Customer C (Amsterdam NL)

With Incoterm CIF – Company B arranges transport – both transactions would qualify in Standard SAP set up as an Intra Community Transaction as a valid VAT number in NL for both Company B and Customer C and proof of transport from DE to NL is available.

From a VAT perspective the transaction between Company A and Company B should however be treated as an Intra Community Transaction and the transaction between Company B and Customer C as a local NL transaction with 21% NL VAT.

Without adjustment of Standard SAP setting a wrong VAT treatment would be determined causing non compliance risks.

Transactions seen from Standard SAP perspective

SAP is only processing a transaction in a specific company code. When processing the sales transaction from Company  A to Company B only the red area is taken into account.

Native SAP garbage in  out 1

When processing the sales transaction in Company B then again only the red area is taken into account.

Native SAP garbage in  out 2

The result of this silo vision in Standard SAP  is that  in principle only the red area is seen (read: used) and that means for VAT determination the respective relevant data of white area is missed resulting in wrong VAT qualification.

For a correct VAT determination the VAT relevant data of Company A and B should be linked real time. That means a helicopter view is needed to make that happen.

This is only possible if tax logic is based and generated on a higher SAP’s hierachy: Client Level combined with implementing the basic tax rules into the logic. Client level includes all the company codes working on the same SAP platform.

In case the first transaction qualifies as an EU transaction then for the second transaction the relevant departure country is not DE but NL. Not as a defaulting assumption but based on actual transactional data. The rule will be different if another Incoterm (FCA) is used.

Case study via slides

A perspective from SAP AG

‘In this presentation from the SAP Control for VAT Compliance conference 2011, Lars Gartenschläger, Product Manager for SAP ERP Financials, gives an overview of SAP’s perception of their customers’ needs, an insight into some of their VAT development challenges, as well as the increased focus that national tax administrations are placing on auditing ERP system data.”

Access SAP presentation here

  1. Could it be that the problem can be avoided by changing the underlying internal movements?
    If company B arranges from sales from company A to company C then we have two transactions: A tax free inter-company (within the same corporation) sale from DE to NL and a regularly taxable sale within the NL. This can easily be established in SAP.

    • The main issue with these type of changes in the fact that the implementation of a efficient Intercompany process in SAP is not driven by VAT. Changing the basic transaction into 2 separate transactions will reduce the benefits for the intercompany process and will require approval from other process areas like Logistics and Sales. This is not always easy to achieve. Although it could be technically established in SAP there are often organizational and procedural bottlenecks.

      Robbert Hoogeveen

  2. Hi Robbert and Richard,
    I have implemented exactly this scenario in the work which I work for. Actually, it is not SAP standard setup, but this triangle scenario is possible in case you introduce a code to the main userexit of the delivery note creation in order to fill in the fields related to inter-company scenario. Of course, you will have to create a specific key combination to handle the VAT rate determination via ship-to location.

    Best regards.
    Marcelo Chamon

    • Hi Marcelo

      Great to see that you have found a solution for this VAT type of issue. Our statement was that in STANDARD SAP there is an issue en you have solved this issue by modifying the VAT relevant data via the userexit which is almost by definition not the standard SAP VAT logic anymore. We have seen this type of solution in other companies as well. With a very “stable” and straightforward business model it could work very well. There is only a risk that when other changes are implemented there are sometimes an unexpected dependencies (incorrect results) and that the overall solution is not fully transparent.

      Would be great to discuss in more details with you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: