Roadmap to tax function effectiveness

Download Booklet



Contact us

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

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

13 September 2013

By Robbert Hoogeveen and Richard Cornelisse.

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.

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

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 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 hierarchy: 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.

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.”


Take aways 

We combine technical knowledge with industry understanding and knowhow of technologically advanced tools and methodologies available in the market or developed by ourselves.

  • Focus on tax processes that could be improved
    • Manual process: same data requests are made by different stakeholders
  • As Is assessment
  • Anticipate future changes and the data needed
    • What are tax trends?
    • What is happening locally and what should be considered across jurisdictions where you operate?
    • Anticipate new stakeholders and their data needs or requests (internal and external)
  • Define scope and actions for short, mid and long term
  • Write business case for change
  • Realize sponsorship for implementation
  • What tax data is requested and by whom?
  • What tax process can be improved and what can be automated?
    • CIT, VAT, tax data warehouse
  • What is the Return on Investment?
    • Hard saving: process improvement
    • Meeting (new) tax requirement
  • What systems are in use: SAP, Oracle, etc
    • By which entities?
  • How many end-use computing tools (e.g. excel spreadsheet) do we have?
  • How do we avoid an ad-hoc solution?
    • Understand the bigger picture
    • Real problem and not the symptom

Technology-related tax risk: understand and address the potential harms and benefits of (new) technology.

Ascertaining proper IT support for ensuring efficient, timely and reliable reporting.

VAT should be considered in every aspect of the process, from concept through completion and beyond. Managing by design — looking at any process or transaction from end to end and factoring in all the requirements and controls essential to designing and optimizing a compliant VAT process.

We speak the language of the business and IT and no translation is needed.