Business Challenge

Technology serves as a key facilitator for optimizing processes. To identify areas for improvement in current operations, it's essential to have a thorough understanding of SAP's limitations, insights into existing business processes, the current SAP setup, and the organization's operational business model.

If achieving full VAT automation for Accounts Receivable (AR) and Accounts Payable (AP), as well as maintaining control, are critical objectives for your organization, it's important to pinpoint the reasons Standard SAP may not operate optimally from an indirect tax perspective.

Only with this understanding can you assess whether upgrades to Standard SAP functionality or the implementation of an external tax engine will meet the company's objectives.

When is Standard SAP Sufficient?

Standard SAP handles transactions within a single company code, meaning that its VAT determination logic is applicable only in specific scenarios, including:

  • AB Scenarios: Cross-border intercompany transactions.
  • AB Scenarios: Electronic invoices via EDI/iDoc.
  • Local ABC Scenarios: All transactions occurring within a single country, such as France.
  • Static ABC Scenarios: Scenarios where leg B-C always triggers the same VAT treatment.

In cases where Standard SAP’s VAT determination logic has gaps, these issues can often be resolved with minor adjustments. Overall VAT determination can be enhanced through the appropriate design of VAT condition tables, access sequences, tax codes, and the configuration of customer VAT registration numbers.

When is Additional VAT Functionality Required?

SAP's VAT determination logic was developed in the 1980s and has seen little change since, aside from the introduction of the "Plants Abroad" logic. In contrast, VAT rules and business models have evolved significantly over time.

The VAT landscape has become increasingly complex, transitioning from relatively straightforward regulations to intricate rules governing cross-border transactions. For example, intra-community transactions now involve unique formalities that must be navigated.

New business models have led to a rise in intercompany transactions, chain transactions, drop shipments, and pick-up transactions. These complexities pose challenges for implementing the Standard SAP VAT determination logic, which is insufficient to accommodate these dynamic business scenarios.

The primary issue is that both Standard SAP and bolt-on tax engines generally focus on individual transactions within a single company, failing to link current transactions to the VAT results of preceding ones. This is particularly significant when more than two parties are involved in a transaction chain:

  • ABC (D) Transactions: Involving supplies of goods transported to other Member States, necessitating clarity on where intra-EC and local supplies occur (see 'Cross Border Drop Shipments').
  • ABC Transactions: Involving three parties in the supply chain identified for VAT purposes in three different EU countries, where goods are transported directly from EU country A to EU country C. If specific country requirements are met, these may qualify as triangulation under simplified rules.
  • ABC (D) Transactions: Involving exported goods to locations outside the EU, where identifying the export point is essential for determining VAT impacts on other chain parties.
  • ABC (D) Transactions: Involving goods imported into the EU, similarly requiring clarity on the export point to assess VAT implications accurately.

Consider the complexities inherent in drop shipments, where there may be a mismatch between invoice flow and the physical flow of goods. For instance, if Party B requests Party A to deliver goods directly to Party C in another Member State, Standard SAP will assess VAT based only on the 'ship-from,' 'ship-to,' 'material,' and 'customer tax classification' data in the system—disregarding Party B's multiple VAT registrations. This leads to incorrect VAT treatment not just for transaction A-B, but also for B-C.

Legally, only one transaction can qualify as a zero-rated intra-EC supply. In such ABC cases, one of the two transactions must incur local VAT, unless all requirements for the simplified triangular arrangement are fulfilled, which may allow both transactions to be zero-rated under strict conditions.

Financial Impact

The supplier bears the responsibility for ensuring all criteria for applying the zero VAT rate are met. Failure to do so could result in tax authorities attempting to recover taxes from the supplier through tax assessments. For example, if the applicable VAT rate is 25%, the tax assessment would be calculated as 25/125 of the charged consideration, and this amount would increase with interest and penalties, leading to a significant financial burden.

If Standard SAP settings are not adjusted, incorrect VAT treatments will occur, leading to non-compliance risks.

Patch-Up Solutions

One approach to deal with these challenges is to rely on assumptions integrated into the system, resulting in predefined VAT treatments (hard-coding). For instance, assuming that the company always purchases goods with local VAT in the vendor country and consequently sells using that vendor's VAT number.

This reliance on assumptions means that VAT treatment will no longer rely on actual transactional data captured in SAP. Such assumptions may be implemented incorrectly or become outdated post-go-live, resulting in incorrect VAT treatments and increased compliance and financial risks. If managing VAT risk is a priority for the company, regular VAT audits must be established as a detective control to remain within the company's risk tolerance.

This can lead to additional man-hours spent, increased costs due to rework (including issuing credit/debit notes), and the need for retrospective corrections or disclosures.

To effectively resolve these issues, it's essential first to thoroughly understand the root causes. We must acknowledge that the problem may encompass more than is immediately evident and will likely require more resources than initially anticipated.

An important question to consider is: what tools are available in the market that can achieve full VAT automation without relying on assumptions and can determine VAT treatment based on real-time, VAT-sensitive data within SAP?

Solving the real problem

phenix10

Specific SAP VAT areas of attention

Cross border drop shipment

Specific considerations about triangulation

  • DK company code sells to DK customers
  • Stock is not available and is purchased from NL Company code with NL stock location
  • Direct shipment from Plant NL01 to customer

Result: wrong VAT treatment with potentially twice an 0% rated intra EU supplies
Root cause: Standard SAP cannot link the VAT treatment of AP and AR as data is gathered at company code level and cannot be linked to AP and AR

Simplified triangulation

Specific considerations about drop shipments

  • Country specify rules apply when triangulation is allowed (country by country deviation). Different local rules apply when Party B is VAT registered in the ship-to country where the customer receives the goods
  • If the supplier (plant or third party) is not set up in SAP the ship-from location will not be known during billing and sales
  • Standard SAP requires manual intervention

Import / export transactions ABC transactions

Specific considerations about export/import

  • Define the correct legal partner for VAT
  • Determine the correct ship-to country
  • Differentiate between export/import and out of scope

Customer pick up

Specific considerations about customer pick up

  • Country specific rules apply when a customer picks up the goods and the goods leave the country
  • 0% VAT rate for intra EU is only allowed if supplier can prove that goods have left the country
  • If proof is not available, the tax authorities could assess the supplier for VAT

Services

Specific considerations about services

  • Default place of supply rule should be the country of establishment of your customer
  • Standard SAP: place of supply is by default ship-to
  • Default rule has exceptions (e.g. repair services connected to immovable property)