By Kamil Szcześniak in Legal & Compliance — 21 Aug 2026

The ViDA Dilemma: Why Your Logistics and Finance Teams Are About to Go to War

The VAT in the Digital Age (ViDA) directive is rewriting the rules of cross-border supply chains. The bottom line? By 2028, the classic Call-off stock simplification is legally dead, making way for a new One-Stop-Shop (OSS) scheme for Transfers of Own Goods (TOOG).

High-level advisors will tell you to simply "map the new legislation in SAP." But if you're a Solution Architect handling the actual configuration, you know this legislative shift is a ticking time bomb between your Logistics (EWM/SD) and Finance (FI/Tax) departments.

Let’s set the scene. When the business casually mentions, "we’re moving stock abroad," you need to instantly identify which of these three distinct legal scenarios you're actually dealing with:

The 3 Core Scenarios of Cross-Border Stock

SAP throws terms like "Consignment" and "STO" around pretty loosely. To survive ViDA, everything boils down to who owns the goods:

Cross-Company STO (Intercompany Sales): You ship goods from your entity (e.g., Company Code PL) to a foreign subsidiary (e.g., Company Code DE). Ownership transfers immediately at the border. This is a standard B2B transaction requiring an Intercompany Invoice (IV). ViDA doesn't change this.
Classic Customer Consignment (Call-off Stock): You ship goods to an external customer's warehouse. You retain ownership (Special Stock 'W') until consumption, deferring VAT and invoicing. This is exactly what ViDA is killing.
Intra-Company STO (Transfer of Own Goods - TOOG): You ship goods from your factory to your own rented 3PL warehouse abroad. You retain 100% ownership, moving stock between two plants under the same Company Code. This is the target architecture ViDA forces us into.

The Geographic Trap

Why does transferring your own goods suddenly require a system overhaul? It’s the clash between EU law and standard SAP logic.

If you replenish a consignment warehouse domestically, you just create a KB order and process the delivery. No change of ownership, no invoice, zero tax implications.

But if you replenish a warehouse across a border, the rules change. EU tax law defines the physical border crossing as a taxable event. Historically, businesses bypassed foreign VAT registration using the "Call-off stock" simplification, dumping values into a periodic VAT-UE declaration.

ViDA destroys this workaround, forcing you to report this movement via the new OSS module. The problem? To report via OSS, your system needs a structured financial baseline—taxable values, cross-border tax codes, and partner IDs. A purely logistical material document doesn't give you that.

The Crossroads: Mapping TOOG in S/4HANA

You have two choices to feed this data to the authorities. Both are going to hurt someone.

Path 1: The Logistics Illusion (Keep KB/KE) Your warehouse and sales teams will push hard to keep the standard Scenario 2 process.

The Pitch: "Why change the system? Just use Consignment Fill-up (KB), move it to Special Stock 'W', and issue it (KE) when consumed."
The Headache: SAP Document and Reporting Compliance (DRC)—your central engine for e-invoicing and tax—feeds on Billing Documents. A standard KB order generates a delivery and a PGI, but no invoice.
The Reality: Finance will have to manually extract values from material postings for the OSS declaration, or your developers will be writing heavy custom ABAP to force DRC to read a material document.

Path 2: The Tax Reality (Intra-Company STO) Finance will demand automated compliance, meaning you have to scrap the logistics team's favorite process.

The Pitch: "We need native integration with SAP DRC to report TOOG immediately. No manual work, no tax penalties."
The Headache: You must abandon Special Stock 'W' entirely. Instead, you set up an Intra-Company Cross-Border STO from your home plant to a "Virtual Plant" in the destination country.
The Reality: Upon PGI of the STO delivery, you generate a Proforma Invoice (e.g., F8). This proforma inherently captures the taxable value and OSS tax codes, flowing seamlessly into SAP DRC without a single line of custom code. When the customer consumes the stock, you trigger a standard local Sales Order (OR) from that virtual plant.

The Verdict

As an architect, you have to lay these trade-offs out for the steering committee.

Go with Path 1, and you save logistics some training time, but you saddle IT with fragile custom interfaces and force Finance into manual reporting.

Go with Path 2, and you force logistics to adapt to STOs and virtual plants, but you secure bulletproof, standard tax compliance for the upcoming wave of e-invoicing mandates.

My advice from the trenches? Take Path 2. Never customize tax reporting if a standard proforma process gets the job done. The Call-off stock simplification is dead—stop trying to keep it artificially alive in SAP.

The Architectural Blueprint

Here is what the collision between these two paths looks like under the hood of S/4HANA:

sequenceDiagram
    autonumber
    participant LOG as SAP Logistics (SD/MM/EWM)
    participant TAX as SAP Finance & Billing (FI/SD-BIL)
    participant DRC as SAP DRC Cloud

    Note over LOG,DRC: PATH 1: The Logistics Illusion (Custom Code Hell)
    LOG->>LOG: Consignment Fill-Up (KB) & PGI
    Note over LOG,TAX: ❌ BLOCK: No standard Billing Document is created.
    LOG-.->>DRC: Custom ABAP required to extract XML from Material Doc
    
    Note over LOG,DRC: PATH 2: The Tax Reality (Standard Compliance)
    LOG->>LOG: Intra-Company STO to Virtual Plant & PGI
    LOG->>TAX: Trigger TOOG Proforma Invoice (F8)
    Note over TAX,DRC: ✅ SUCCESS: Proforma natively feeds DRC.
    TAX->>DRC: Standard e-Invoice Extraction
    DRC-->>TAX: Government Status Update (Accepted)
    
    Note over LOG,TAX: LATER STAGE: Customer Consumption
    LOG->>TAX: Local Sales Order (OR) from Virtual Plant
    TAX->>DRC: Generate Local Domestic e-Invoice

FAQ from the Trenches

When you pitch this architecture to your team, expect pushback. Here are the most common objections you will face, and how to shut them down.

"Wait, can't we just trigger a Proforma Invoice directly from the KB delivery?" Technically, yes. But choosing a Proforma from a KB delivery versus an STO delivery is the difference between a custom-code nightmare and standard compliance. Here is why:

The Nightmare: Proforma from KB
- The Valuation Void: A KB order moves goods to a warehouse you do not own. Standard pricing procedures for KB do not calculate a true taxable basis—the stock just hangs in a financial void.
- The Tax Hack: How do you determine a hard intra-EU tax code on a document that is neither a real sale nor a transfer to your own plant? You can't, unless you artificially hack your Pricing Procedures and Copy Control (VTFL) logic just to trick the tax engine.
The Standard: Proforma from STO (Delivery Type NL)
- Native Valuation: An STO is a physical movement of your own valuated stock from Plant A to Plant B. The proforma generated from the NL delivery naturally catches the true value (e.g., based on VPRS cost or a PI01 transfer price). This provides a bulletproof tax basis for the government.
- Out-of-the-box Mechanisms: SAP has used STO proformas for decades for customs clearances (like exports to Switzerland or the UK). The system is already perfectly trained to determine cross-border tax codes purely based on the goods crossing a frontier.

"What if our company doesn't use SAP DRC?" Not every S/4HANA system runs SAP DRC. Many companies still rely on third-party middleware (like Edicom, Seeburger, or local providers) using standard IDocs or custom APIs. But here is the reality: the architectural problem is exactly the same. Whether you send data to SAP DRC or a third-party tax engine, that system needs an invoice (like an INVOIC02 IDoc) to understand the tax structure. If you don't have DRC, trying to map complex tax reporting fields directly from a logistical material document into a custom interface is even more painful. You still need the Proforma (F8).

Want the full picture? This update is just one piece of our massive 2026 SAP Architecture Radar. We’ve compiled 17 critical changes across FI, SD, EWM, and TM that every Solution Architect must know this year. Drop your email below to unlock the full 2026 Radar report. [Tu formularz zapisu Ghost]