Satıcılar pan-Avrupa fulfillment süreçlerini outsource etmeli mi?
24 Mayıs 2026
Temu’ya verilen DSA cezası, AB’de cross-border satıcıların ürün güvenliği yükümlülükleri için ne anlama geliyor?
30 Mayıs 2026
FLEX. Lojistik
Avrupa'daki çevrimiçi perakendecilere lojistik hizmetleri sunuyoruz: Amazon FBA hazırlığı, FBA kaldırma siparişlerinin işlenmesi, Fulfillment Center'lara yönlendirme — hem FBA hem de Vendor gönderileri.
Avrupa Komisyonu'nun Dijital Çağda KDV (ViDA) 2026 Çalışma Programı uzak bir politika tartışması değildir. Bu, Ocak 2027'deki ilk dalga son tarihiyle birlikte sıralı bir teknik zorunluluktur ve doğrudan sınır ötesi AB satıcılarının üye devletler arasında nasıl kayıt yaptırdığını, raporladığını ve envanter taşıdığını etkiler. Çok ülkeli dağıtım ağları işleten markalar için asıl soru artık uyum sağlayıp sağlamamak değil, hangi yükümlülüklerin önce devreye girdiği, organizasyon içinde her birinin kime ait olduğu ve mevcut KDV teknoloji yığınının yeni mimarinin gerektirdiği veri alanlarını gerçekten üretebilip üretemediğidir. Bu makale altı uygulama eylemini ayrıntılarıyla inceliyor, 2027'den 2030'a kadar olan aşamalı uygulamayı haritalandırıyor ve parçalanmış eski sistemlerin gelen merkezi raporlama modeli altında en büyük risk altında olduğu operasyonel kontrol noktalarını tespit ediyor.
Altı Uygulama Eylemi: 2026 Çalışma Programının İncelenmesi
2026 Çalışma Programı, ViDA geçişini mevcut KDV altyapısının belirli bir katmanını hedefleyen altı farklı uygulama eylemine yapılandırıyor. İlk eylem, topluluk içi işlemler için gerekli veri alanlarının teknik standardizasyonunu ele alıyor ve her dijital raporlama bildiriminin taşımak zorunda olduğu minimum veri setini belirliyor. İkinci eylem, KDV Bilgi Değişim Sistemi'nin (VIES) yeniden tasarlanmasını yönetiyor ve bunu periyodik toplu sorgu modelinden neredeyse gerçek zamanlı doğrulama mimarisine taşıyor. Üçüncü eylem, 1 Ocak 2027'de devreye girecek belirli kamu hizmeti kategorileri için yeni modüller de dahil olmak üzere genişletilmiş Birlik Tek Noktadan Kayıt (OSS) modüllerini tanımlıyor. Dördüncü ve beşinci eylemler, Temmuz 2028 için hedeflenen zorunlu Tek KDV Kaydı (SVR) ve Kendi Mallarının Transferi (TOOG) çerçeveleri için yasal ve teknik zemini hazırlıyor. Altıncı eylem ise geçiş hükümlerini ve üye devlet derogasyon pencerelerini kapsıyor. Her eylem farklı bir uyum katmanı oluşturuyor ve bunları tek, farklılaşmamış bir reform olarak ele alan satıcılar hazırlık çabasını yanlış yönlendirecek ve sıralama mantığını tamamen kaçıracaktır.
Dijital Raporlama Gereklilikleri: Nelerin Yakalanması Gerekiyor
ViDA kapsamındaki Dijital Raporlama Gereklilikleri (DRR), işlem düzeyindeki verilerin tedarik noktasında yapılandırılmış, zaman damgalı ve standartlaştırılmış bir formatta iletilebilir olmasını zorunlu kılar. Sınır ötesi satıcılar için bu, her topluluk içi B2B işleminin tanımlanmış bir dizi veri alanını taşıması gerektiği anlamına gelir: tedarikçi KDV numarası, müşteri KDV numarası, fatura tarihi, vergiye tabi tutar, uygulanan KDV oranı ve alıcının gelen kaydıyla eşleştirilebilecek bir işlem referansı. Kritik operasyonel kontrol noktası, bu verilerin raporlanmadan önce temiz ve çıkarılabilir bir durumda mevcut olmasıdır — depo yönetim günlüklerinden veya taşıyıcı manifestolarından sonradan yeniden oluşturulması değil. İşlem verilerini kalem düzeyinde yakalamak yerine aylık olarak toplayan ERP sistemlerine dayanan satıcılar, DRR mimarisiyle yapısal bir uyumsuzlukla karşı karşıya kalacaktır. Veri katmanı, raporlama aşamasında sonradan eklenmek yerine sipariş-fatura iş akışına entegre edilmelidir.
Veri Katmanı Eksik Olduğunda Neler Bozulur
Bir satıcının KDV teknoloji yığını talep üzerine temiz, alan düzeyinde işlem verisi üretemediğinde, yeni DRR modeli altındaki sonuçlar gecikmiş bir bildirimin ötesine geçer. Yeniden tasarlanan VIES, tedarikçi bildirimlerini alıcı tarafı kayıtlarıyla neredeyse gerçek zamanlı olarak çapraz referanslayacaktır. Eksik bir KDV numarası, yanlış bir fatura tarihi veya alıcının beyan ettiği girdisiyle uyuşmayan bir vergiye tabi tutar gibi nedenlerle oluşan bir uyuşmazlık, otomatik bir tutarsızlık bayrağını tetikler. Mevcut periyodik sistemde bu tür uyuşmazlıklar genellikle yıllık mutabakat sırasında sessizce çözülür. Gelen mimaride ise işaretlenen bir tutarsızlık, hata düzeltilip yeniden gönderilene kadar işlemin KDV geri alma durumunu askıya alabilir. Birden fazla AB sınırı boyunca yüksek hacimli B2B stok taşıyan satıcılar için tutarsızlık bayrakları kalıbı sadece bir uyum sıkıntısı değildir. Bu, veri kaynağı sistem düzeyinde düzeltilene kadar her etkilenen işlemde biriken bir nakit akışı riskidir.
VIES Yeniden Tasarımı: Gerçek Zamanlı Denetime Hazırlanmak
VIES'in teknik yeniden tasarımı, ViDA'nın geri kalanını uygulanabilir kılan altyapı değişikliğidir. Mevcut formunda VIES, sorgu bazında KDV numarası doğrulamasına izin verir ancak üye devletler arasında işlem verilerini gerçek zamanlı olarak çapraz referanslamaz. Yeniden tasarlanan sistem, topluluk içi bir arzın her iki tarafından yapılandırılmış işlem kayıtlarını alacak ve asimetrileri otomatik olarak işaretleyecektir. Satıcılar için bu, denetim maruziyet modelini temelden değiştirir. Önceden, bir KDV denetimi belirli bir risk sinyaliyle tetiklenen periyodik, belge ağırlıklı bir süreçti. Yeni VIES mimarisinde her topluluk içi işlem, bir insan denetçi hiç dahil olmadan önce veri katmanında etkili bir şekilde ön denetlenir. Manuel KDV mutabakatına veya tek ülkeli eski KDV yazılımına dayanan satıcılar, bu araçların yeni sistemin beklediği yapılandırılmış çıktıyı üretmediğini görecektir. Pratik hazırlık adımı, mevcut fatura veri alanlarının standartlaştırılmış DRR veri setine karşı boşluk analizinin 2027 ilk dalga son tarihinden çok önce tamamlanmasıdır.
OSS Genişlemesi ve Tek KDV Kaydı Yolu
ViDA kapsamında Tek Noktadan Kayıt (OSS) çerçevesi önemli ölçüde genişletiliyor ve Ocak 2027 değişiklikleri, daha önce merkezi raporlamaya uygun olmayan tedarik kategorilerini kapsayan yeni Birlik OSS modüllerini getiriyor. E-ticaret satıcıları zaten B2C mesafe satışları için OSS kullanıyorsa, genişletilmiş kapsam, ürün karışımlarındaki yeni uygun tedarik türlerinin mevcut OSS kaydına konsolide edilip edilemeyeceğini veya ayrı bir modül seçimi gerektirip gerektirmediğini gözden geçirmek anlamına gelir. Yapısal olarak daha önemli değişiklik, Temmuz 2028'de zorunlu Tek KDV Kaydı'nın (SVR) getirilmesidir; bu, satıcıların stok tuttukları her üye devlette yerel KDV kaydı tutma zorunluluğunu kaldıracaktır. SVR kapsamında, envanteri bir Polonya fulfillment merkezine, bir Almanya dağıtım merkezine ve bir Fransa iade işleme tesisine taşıyan bir satıcı, bu yükümlülükleri üç ayrı ulusal dosyalama yerine tek bir kayıt noktası üzerinden yönetecektir. SVR ile birlikte devreye girecek Kendi Mallarının Transferi (TOOG) mekanizması, bir satıcının kendi depoları arasındaki sınır ötesi stok hareketlerinin KDV tedavisini ele alacaktır — şu anda her yargı alanında dikkatli manuel işlem gerektiren bir işlem türü. Çoklu depo düğümleri arasında pan-Avrupa dağıtım stratejisi işleten satıcılar için SVR ve TOOG birlikte, tüm ViDA paketindeki en operasyonel açıdan önemli değişikliği temsil etmektedir.
Ocak 2027 Öncesinde Denetlenecekler
İlk pratik adım, mevcut KDV kayıt ayak izinin gelen OSS modül kapsamına karşı yapılandırılmış bir denetimidir. Satıcılar, AB ürün kataloglarındaki hangi tedarik türlerinin Ocak 2027'den itibaren Birlik OSS raporlamasına yeni uygun hale geldiğini ve mevcut OSS dosyalamasının bu kategorileri kapsayıp kapsamadığını veya varsayılan olarak hariç tutup tutmadığını teyit etmelidir. İkinci denetim katmanı fatura veri mimarisidir: mevcut ERP veya sipariş yönetim sistemi, işlem düzeyinde standartlaştırılmış DRR alanlarını yakalıyor mu, yoksa gönderimden önce manuel çıkarım ve yeniden formatlama gerektirecek şekilde veri mi topluyor? Üçüncü kontrol, tüm aktif ticaret hatları boyunca EORI ve KDV numarası tutarlılığıdır — gelen gümrük beyannamelerinde kullanılan tanımlayıcılar ile OSS dosyalamalarında kullanılanlar arasındaki herhangi bir uyuşmazlık, yeni VIES çapraz referanslamasının ortaya çıkaracağı bir mutabakat boşluğu yaratır. AB gümrük clearance hizmetleri kullanan satıcılar, gümrük komisyoncusunun OSS hesaplarında kullanılan aynı KDV tanımlayıcılarını yakaladığından ve ilettiğinden emin olmalıdır.
Parçalanmış KDV Yığınlarının SVR Altında Nerede Başarısız Olduğu
Çok ülkeli satıcılar arasında en yaygın zayıf varsayım, Temmuz 2028 SVR son tarihinin hazırlığı ertelemek için yeterli süre tanıdığıdır. Pratikte SVR geçişi, satıcıların mevcut her yerel KDV kaydını yeni tek kayıt yapısına eşlemesini, tarihsel dosyalama verilerini taşımasını ve depo yönetim ile sipariş yönlendirme sistemlerinin geçişin ilk gününden itibaren stok hareketlerini TOOG çerçevesine doğru şekilde atfedebilmesini gerektirir. AB varlığını kademeli olarak genişleten satıcılar — önce bir Alman deposu, sonra bir Fransız iade merkezi, sonra bir Polonya fulfillment düğümü ekleyerek — genellikle farklı yerel danışmanlar tarafından farklı yazılım çıktılarıyla yönetilen KDV kayıtlarına sahiptir. Bunları tek tutarlı bir SVR dosyalamasına konsolide etmek, son teslim tarihinden önceki son haftalarda tamamlanamayacak veri standardizasyon çalışması gerektirir. Başarısızlık modu kaçırılmış bir dosyalama tarihi değildir. SVR geçişine üç yargı alanında uyumsuz veri formatlarıyla ve tarihsel topluluk içi stok hareketlerinin birleştirilmiş bir kaydı olmadan varmaktır.
Owner Map: Who Holds Each ViDA Obligation
A practical owner map for ViDA compliance separates the obligations by function rather than treating them as a single tax department task. The DRR data architecture is owned by the ERP or order management system operator — typically the IT or finance systems team — because the structured data fields must be built into the transaction capture layer, not added downstream. The OSS filing obligation is owned by the VAT compliance function, whether in-house or outsourced to a tax advisor, but that function depends on clean data inputs from the systems layer. The TOOG framework, once live, will require the logistics operations team to flag every cross-border stock movement between owned warehouse nodes as a distinct transaction type with its own VAT treatment. If the warehouse management system does not distinguish between a customer order shipment and an inter-warehouse stock transfer, the TOOG record will be incomplete. For sellers using a third-party logistics provider for EU warehousing, the contractual question is whether the 3PL's warehouse management system produces the movement-level data that the TOOG framework will require.
The Staged Blueprint: Transitioning to Single VAT Registration
The ViDA rollout follows a deliberate staging logic that sellers can use to sequence their own preparation. The January 2027 wave is primarily a scope expansion for OSS and the introduction of DRR technical standards — it does not yet mandate real-time transaction reporting for all sellers, but it establishes the data format requirements that subsequent waves will enforce. The July 2028 wave is where the structural change lands: SVR becomes mandatory, TOOG goes live, and the VIES redesign reaches operational status. The 2030 phase extends DRR obligations to additional transaction categories and closes remaining derogation windows for member states that have been permitted to maintain legacy reporting systems. The practical preparation error is treating 2028 as the planning horizon when the data infrastructure work required to support SVR and TOOG must be completed well before the transition date. A seller who begins their ERP data architecture review in early 2027 — after the first-wave changes are live — will have approximately twelve months to complete a data standardisation project that typically takes six to nine months in a complex multi-country setup. That is a workable but tight window, and it assumes no significant rework cycles. Sellers who defer the review to late 2027 are building in execution risk that the staging logic was specifically designed to avoid. The Commission's sequencing is not arbitrary: the 2027 changes are the technical foundation that the 2028 structural changes are built on top of.
Pre-2027 Data Readiness Checklist
- DRR field mapping: Confirm your ERP captures supplier VAT number, customer VAT number, invoice date, taxable amount, VAT rate, and transaction reference at line-item level.
- OSS scope review: Identify all supply types in your EU catalogue and confirm which are newly eligible for Union OSS modules from January 2027.
- EORI and VAT identifier consistency: Verify that identifiers used in customs declarations match those in your OSS account exactly.
- Invoice data extraction test: Run a sample extraction of last quarter's intra-community transactions in DRR-compatible format and check for gaps.
- Customs broker data alignment: Confirm your EU customs clearance provider transmits the same VAT identifiers used in your OSS filing.
Pre-2028 SVR and TOOG Readiness Checklist
- VAT registration audit: Map every active local VAT registration across EU member states and identify the advisor or system managing each one.
- Historical filing consolidation: Assess whether historical filing data from each jurisdiction is in a format that can be migrated to the SVR structure.
- Warehouse movement tagging: Confirm your warehouse management system distinguishes customer order shipments from inter-warehouse stock transfers as separate transaction types.
- 3PL data contract review: Check whether your logistics provider's system produces movement-level data compatible with TOOG reporting requirements.
- SVR transition timeline: Build a project plan with a data standardisation phase completing no later than Q1 2028 to allow testing before the July deadline.
Building the VAT Tech Stack for the 2027–2030 Window
The practical implementation sequence starts with the data layer, not the filing layer. Before a seller can evaluate which OSS modules apply, which TOOG movements need to be tracked, or whether their SVR transition plan is viable, they need to know whether their current systems produce clean, structured, field-level transaction data. That assessment should be completed as a discrete project with a defined output: a gap analysis document that maps current ERP data fields against the DRR standard and identifies every field that is missing, aggregated, or inconsistently populated. The second phase is remediation — either configuring the existing ERP to capture missing fields, or implementing a middleware layer that extracts and structures data before it reaches the VAT reporting system. The third phase is testing: running a parallel DRR-format submission against actual transaction data to verify that the output is clean before the live deadline. The fourth phase is the OSS module review, which can only be completed accurately once the data layer is confirmed. Sellers who attempt to reverse this sequence — starting with the OSS filing question and working backward to the data architecture — typically discover the data gaps at the worst possible moment: during a live submission cycle with a deadline approaching. For sellers operating multi-node EU distribution, the physical inventory layer adds a further dimension. Every warehouse node that holds stock generates intra-community movement records, and those records must be attributable to the correct VAT treatment under both the current rules and the incoming TOOG framework. Pan-EU distribution strategy built on clean inventory movement data is not just a logistics efficiency question under ViDA — it is a compliance prerequisite.
Inventory Movement Data as a Compliance Asset
Under the incoming ViDA architecture, the record of where stock physically moves between EU warehouse nodes is not just an operational log — it is the source data for TOOG VAT treatment. A seller moving a pallet from a Dutch consolidation hub to a German fulfilment centre generates a Transfer of Own Goods event that will require a structured VAT record under the 2028 framework. If the warehouse management system records that movement only as an internal stock transfer with no VAT-relevant data fields, the TOOG record cannot be reconstructed from the available data. The practical implication is that sellers should evaluate their current warehouse management and inventory tracking systems not only for operational efficiency but for their ability to produce movement-level records in a format compatible with future automated monthly OSS reporting. Third-party logistics providers who operate multi-country warehouse infrastructure and track itemised cross-border inventory movements with clean data trails are positioned to support this requirement directly — because the compliance data and the physical movement record originate from the same system rather than being reconciled after the fact across separate platforms.
January 2027: First Wave
New Union OSS modules for specific utility supply categories go live. DRR technical data standards are published and enforceable. Sellers must confirm OSS scope coverage and complete the ERP data field gap analysis before this date.
July 2028: Structural Shift
Mandatory Single VAT Registration replaces local multi-country filings. Transfer of Own Goods framework activates for inter-warehouse stock movements. VIES near-real-time cross-referencing reaches operational status across member states.
2030: Full DRR Scope
Digital Reporting Requirements extend to additional transaction categories. Remaining member-state derogation windows close. Sellers with legacy single-country VAT software face full exposure if data architecture remediation has not been completed.
What Cross-Border Sellers Should Lock In Now
The ViDA staging logic gives sellers a preparation window, but that window is shorter than the headline deadlines suggest. The January 2027 first wave is not a soft launch — it establishes the data standards that the July 2028 structural changes depend on. A seller who treats 2027 as a monitoring year and 2028 as the action year is compressing a multi-phase data architecture project into a single execution sprint with no margin for rework. The decisions to lock in now are: which team or advisor owns the DRR gap analysis, whether the current ERP can produce field-level transaction data in the required format, and whether the logistics infrastructure generating intra-community stock movement records is capable of producing TOOG-compatible data from day one of the 2028 transition. For sellers operating across multiple EU warehouse nodes, the physical distribution layer and the VAT compliance layer are no longer separate workstreams. The inventory movement record is the compliance record. Sellers who have not yet mapped their EU distribution footprint against the incoming TOOG framework should treat that mapping as an immediate priority, not a 2027 task. The B2B European fulfillment infrastructure a seller uses today will either support or obstruct their ViDA compliance posture — and that determination can be made now, before the first implementing act goes live.
FLEX. operates multi-country warehouse infrastructure across the EU with inventory tracking systems that produce movement-level data at the transaction and transfer level. If your current logistics setup cannot cleanly distinguish customer order shipments from inter-warehouse stock transfers — or if your 3PL cannot confirm that its warehouse management system will produce TOOG-compatible records — that is an operational gap worth addressing before the 2027 deadline, not after. Verify your legal and tax obligations with a qualified VAT advisor. For the operational and logistics layer — clean inventory movement data, multi-node EU warehousing, and cross-border distribution infrastructure aligned with the incoming compliance architecture — contact FLEX. to discuss your current setup.
