When is standard SAP (in)sufficient?

Standard SAP determines VAT reliably for simple, single-company-code transactions, but it was not built for today's multi-party chains. This guide explains exactly where native SAP VAT determination works, where it breaks down for drop shipments, triangulation and import/export chains, what the financial exposure is, and how to decide between enhancing standard SAP and implementing a dedicated external tax engine.

The business challenge: why SAP VAT determination needs scrutiny

Technology is a key enabler for optimising business processes, but realising that potential depends on understanding where the technology falls short. To identify genuine opportunities for improvement in current operations, an organisation needs a clear view of SAP’s limitations alongside an understanding of its existing business processes, its current SAP configuration, and the operating model the system is meant to support.

For many organisations, achieving full VAT automation across Accounts Receivable (AR) and Accounts Payable (AP) — while retaining control over the tax outcomes — is a critical objective. Meeting it requires pinpointing precisely why standard SAP may not perform optimally from an indirect tax perspective. Only with that understanding can a company make an informed decision about whether enhancements to standard SAP functionality, or the implementation of a dedicated external tax engine, will deliver the intended results.

When is standard SAP sufficient for VAT determination?

Standard SAP processes transactions within a single company code, and its VAT determination logic was designed with that boundary in mind. As a result, it performs reliably in a number of well-defined situations. It handles straightforward two-party (A–B) transactions effectively, including cross-border intercompany supplies and electronic invoices exchanged via EDI or iDoc. It also copes well with local ABC scenarios in which every step of the transaction occurs within a single country, such as France, and with static ABC scenarios where leg B–C consistently attracts the same VAT treatment.

Where gaps do appear in these comparatively simple situations, they can usually be closed with modest adjustments. Carefully designed VAT condition tables, well-structured access sequences, an appropriate tax code framework, and correctly maintained customer VAT registration numbers will together resolve most determination issues without any need for additional tooling.

When does SAP need additional VAT functionality?

The limitations of standard SAP become apparent once transactions grow more complex. SAP’s VAT determination logic dates back to the 1980s and has changed little since, the most notable addition being the “Plants Abroad” functionality. VAT legislation and commercial models, by contrast, have evolved dramatically over the same period.

The indirect tax landscape has shifted from a relatively simple set of rules to an intricate framework governing cross-border trade; intra-community transactions, for example, now carry their own formalities that must be carefully observed. At the same time, new business models have driven a steep increase in intercompany dealings, chain transactions, drop shipments, and pick-up arrangements. Standard SAP’s determination logic was never designed for this degree of dynamism, and it struggles to accommodate it.

The underlying problem is structural. Standard SAP — and, in most cases, bolt-on tax engines as well — evaluate each transaction in isolation within a single company, and neither links the current transaction to the VAT outcome of the one preceding it. This shortcoming becomes critical the moment more than two parties are involved in a supply chain, as is the case in the various forms of ABC and ABC(D) transactions.

In ABC and ABC(D) supplies of goods dispatched to other Member States, the parties must establish precisely where the intra-EC supply takes place and where the local supply occurs. In a classic ABC supply, three parties identified for VAT purposes in three different EU countries trade goods that move directly from country A to country C; where the relevant national requirements are met, this may qualify as a triangulation under the simplified rules. Other ABC(D) chains involve goods exported outside the EU, where the point of export must be identified to determine the VAT consequences for the remaining parties, or goods imported into the EU, where the same clarity is needed to assess the implications accurately.

Drop shipments illustrate the difficulty well, because the invoice flow and the physical movement of goods often diverge. Suppose Party B asks Party A to deliver goods directly to Party C in another Member State. Standard SAP will determine the VAT treatment using only the ship-from, ship-to, material, and customer tax classification data held in the system, and it will disregard the fact that Party B may hold multiple VAT registrations. The consequence is incorrect treatment not only of the A–B transaction but of the B–C transaction as well.

This matters because, in law, only one transaction in such a chain can qualify as a zero-rated intra-EC supply. One of the two transactions must therefore bear local VAT, unless every condition for the simplified triangulation arrangement is satisfied — a strict test that, when met, allows both transactions to be zero-rated.

What is the financial impact of incorrect VAT determination?

The commercial risk falls on the supplier, who is responsible for ensuring that all the conditions for applying the zero rate are met. If they are not, the tax authorities may seek to recover the unpaid tax through an assessment. Where the applicable VAT rate is 25 percent, for instance, the assessment is calculated as 25/125 of the consideration charged, and that liability grows further once interest and penalties are added — a potentially significant financial burden. In short, leaving standard SAP unadjusted in these scenarios produces incorrect VAT treatment and exposes the business to non-compliance risk.

Are hard-coded VAT assumptions a safe fix?

A common response to these shortcomings is to build assumptions directly into the system, producing predefined — effectively hard-coded — VAT outcomes. A business might assume, for example, that it always purchases goods subject to local VAT in the vendor’s country and therefore always sells under that vendor’s VAT number.

The drawback is that VAT treatment then no longer reflects the actual transactional data captured in SAP. Such assumptions may be implemented incorrectly in the first place, or they may simply become outdated after go-live as the business changes. Either way, the result is incorrect VAT treatment and heightened compliance and financial risk. Where managing VAT risk is a priority, the organisation will need to establish regular VAT audits as a detective control in order to remain within its risk tolerance — and even then it is likely to incur additional effort, rework costs such as issuing credit and debit notes, and the burden of retrospective corrections or disclosures.

Resolving these issues properly begins with understanding their root causes. It is worth acknowledging at the outset that the problem is often larger than it first appears and will usually demand more resources than initially expected. The key question to ask is therefore this: which tools available in the market can deliver full VAT automation without relying on assumptions, determining the correct treatment instead from real-time, VAT-sensitive data already held within SAP?

Specific SAP VAT areas of attention

Several recurring scenarios deserve particular attention, each illustrating where standard SAP tends to reach its limits.

Cross-border drop shipments and triangulation

Consider a Danish company code selling to Danish customers where the stock is not available locally and is instead purchased from a Netherlands company code holding NL stock, with the goods shipped directly from plant NL01 to the customer. Standard SAP can produce an incorrect outcome here, potentially treating both legs as zero-rated intra-EU supplies. The root cause is that standard SAP gathers data at company-code level and cannot link the VAT treatment of the AP and AR sides of the chain.

Simplified triangulation and drop shipments

The rules on when triangulation is permitted vary country by country, and a different local treatment applies where Party B is VAT-registered in the ship-to country in which the customer receives the goods. A further practical complication arises when the supplier — whether a plant or a third party — is not set up in SAP, because the ship-from location is then unknown during sales and billing. In these cases, standard SAP requires manual intervention.

Import and export ABC transactions

For chains involving import or export, the priorities are to define the correct legal partner for VAT purposes, to determine the correct ship-to country, and to distinguish properly between export, import, and transactions that fall outside the scope of VAT.

Customer pick-up

Where a customer collects the goods and then removes them from the country, country-specific rules apply. The zero rate for an intra-EU supply is available only if the supplier can prove that the goods have actually left the country; absent that proof, the tax authorities may assess the supplier for the VAT.

Services

For services, the default place-of-supply rule should be the country in which the customer is established. Standard SAP, however, defaults to the ship-to location. The general rule is also subject to exceptions — repair services connected to immovable property being one example — that the system must be able to handle correctly.

Frequently asked questions

When is standard SAP sufficient for VAT determination?

Standard SAP is sufficient for transactions inside a single company code: straightforward two-party (A–B) supplies, cross-border intercompany supplies, EDI/iDoc electronic invoices, fully local ABC scenarios within one country, and static ABC scenarios where leg B–C always attracts the same VAT treatment. Minor gaps can be closed with condition tables, access sequences, tax codes and correct VAT registration setup.

Why does standard SAP get drop shipments and chain transactions wrong?

Its VAT logic evaluates each transaction in isolation at company-code level and cannot link the current transaction to the VAT result of the preceding one. With three or more parties, it determines treatment only from ship-from, ship-to, material and customer tax classification, ignoring a party’s multiple VAT registrations — so it can wrongly zero-rate more than one leg of the chain.

What is the financial risk of incorrect VAT determination in SAP?

The supplier bears the risk. If the conditions for the zero rate are not met, tax authorities can assess the unpaid VAT — for example 25/125 of the consideration charged at a 25% rate — and add interest and penalties, creating a significant liability.

Can I just hard-code VAT assumptions to fix the gaps?

You can, but it is fragile. Hard-coded assumptions stop reflecting actual transactional data, may be implemented incorrectly, and can become outdated after go-live, increasing compliance and financial risk. They usually require regular VAT audits as a detective control plus rework such as credit and debit notes.

Do I need an external tax engine or can I enhance standard SAP?

It depends on your objectives. Minor gaps in simple scenarios can be solved by configuring standard SAP. Full VAT automation for complex, multi-party chains generally needs functionality that determines treatment from real-time, VAT-sensitive data and can link related AR and AP transactions — something standard SAP and many bolt-on engines do not do.

How does standard SAP handle VAT on services?

The default place-of-supply rule should be the customer’s country of establishment, but standard SAP defaults to the ship-to location. The general rule also has exceptions, such as repair services connected to immovable property, which the configuration must accommodate.