Pazaryerine ürün aktaran bir yazılım satın almakla belirli bir destek programının yararlanıcısı olmak farklı değerlendirmelerdir. Ticari teklifte “entegrasyon” yazması, şirketin o başlıktan yararlanabileceğini göstermez. İlk kontrol yazılımın fiyatından önce destek türüyle başvuru sahibi statüsünü eşleştirmek olmalıdır.
“e-ihracat entegrasyon desteği” araştırmasında bu ayrımı teklif aşamasında yapın. Hibe Raporu ile görüşmede şirket türünü, kullanılan platformları ve alınacak hizmeti ayrı açıklayın. Aşağıdaki yöntem bir yazılım seçimi veya destek onayı vermez; araştırmanın yanlış başlıktan başlamasını önlemeyi amaçlar.
Genel şirket tanımıyla özel yararlanıcı statüsünü karıştırmayın
İncelenen genelgenin 17. maddesi bu destek için E-İhracat Konsorsiyumları, perakende e-ticaret siteleri ve pazaryerlerini sayıyor. Dolayısıyla yalnız yurt dışına satış yapan bir şirket olmak bu maddede aranan statüyü kendiliğinden sağlamaz. Şirketin hangi statüyle değerlendirileceği belgeleri üzerinden netleştirilmelidir.
Aynı maddede ürünlerin entegrasyonla listelenmesine ilişkin SKU koşulu ve ön onay yolu da bulunuyor. İncelenen metin en az 1.000 SKU listelenmesini öngörüyor. Bu tek koşulu sağlamak bütün şartların tamamlandığı anlamına gelmez; diğer hüküm ve ekler birlikte okunmalıdır.
E-ihracat teşvikleri içindeki başka bir başlığın yararlanıcı tanımını bu maddeye taşımayın. Reklam, komisyon veya başka giderlerin kendi koşulları bulunabilir. Bir şirketin bir destek unsuruna uygun görünmesi başka bir unsur için aynı sonucu otomatik üretmez.
Teklifte hangi iki sistemin bağlandığını gösterin
Entegrasyonun başlangıç ve bitiş noktalarını yazın. Ürün kataloğu, stok, sipariş, fatura ve sevk verisi farklı iş akışlarıdır. Hangi alanın hangi kaynaktan alınacağı, hangi sıklıkla güncelleneceği ve hatanın nasıl izleneceği teknik kapsamda açıklanmalıdır.
Örneğin stok aktarımı çalışan bir çözüm sipariş iadesini karşı tarafa bildirmiyor olabilir. Bu durumda bütün satış döngüsünün eksiksiz bağlandığını söylemeyin. Test planında her akış için beklenen sonuç ve gözlenen sonuç ayrı bulunsun. Destek dosyasında kullanılacak kanıtlar ilgili resmî gerekliliklerle ayrıca karşılaştırılır.
E-ihracat danışmanlığı görüşmesine hazırlanırken kullanılan hesapların hangi şirkete ait olduğunu da belirtin. Farklı hesapları tek teknik şemada göstermek ticari sahipliği açıklamaz. Parola veya gizli erişim anahtarını belge paketine koymadan hesap ve görev ilişkisini tarif edin.
Lisans, geliştirme, bakım ve komisyonu ayırın
Teklifin tek toplam olması giderlerin aynı nitelikte olduğu anlamına gelmez. İlk geliştirme, kullanım dönemi, bakım ve satışa bağlı kesintiler ayrı alanlarda izlenmelidir. Hizmet sağlayıcıdan bu ayrımı açıklayan kapsam eki isteyin; belirsiz kalan kısmı kendi varsayımınızla tamamlamayın.
Pazaryeri komisyon desteği araştırmasıyla entegratöre ödenen satış kesintisini aynı başlık gibi kullanmayın. Önce kesintiyi kimin hangi hizmet için aldığı anlaşılmalıdır. Bir satırın dosyada ayrı gösterilmesi, onun belirli programdan destekleneceği sonucunu vermez.
Amazon satış raporu destek başvurusu dosyasında kullanılan rapor teknik test kanıtından farklı amaç taşır. Birincisi ticari hareketi, ikincisi sistemler arası aktarımı açıklayabilir. Aynı sipariş kimliği üzerinden ilişki kurulsa da her belgenin neyi doğruladığı belirtilmelidir.
Ön onay ve şirket içi kabul için farklı kayıt tutun
Yazılımın kendi ekibinizce kabul edilmesiyle programdaki ön onay aynı olay değildir. Teknik kabul listesi, sipariş ve stok akışlarının çalışmasını açıklayabilir. Resmî başvurunun hangi aşamada bulunduğunu ise ilgili işlem kaydı gösterir. Dosyanın durum alanlarında bu iki adı farklı tutun.
E-ihracat destek başvurusu hazırlığında tarih çizelgesine teklif, sözleşme, resmî işlem, teslim ve ödeme olaylarını ayrı yazın. Bu çizelge bir işlem sırası kuralı koymaz; somut programa göre hangi adımın ne zaman yapılacağını kontrol etmenize yardım eder.
Yazılım kabul testi rehberindeki şirket içi kontrol yaklaşımı yararlı olabilir; ancak oradaki program başlığını e-ihracata aynen taşımayın. Hibe Raporu ile yapılacak incelemenin sonunda teknik ihtiyaç ve araştırılacak destek yolu ayrı ayrı anlaşılmış olmalıdır.
Şirket içi test kaydı örneği
| Akış | Kontrol sorusu | İç kayıt |
|---|---|---|
| Ürün aktarımı | Seçilen örnek ürünün kodu ve açıklaması hedef platformda doğru görünüyor mu? | Kaynak ürün kimliği, hedef kayıt ve test tarihi |
| Stok değişimi | Kaynakta yapılan örnek değişiklik hedef hesaba beklenen biçimde geçti mi? | Önceki ve sonraki değer, işlem günlüğü |
| İade bildirimi | İade olayı hangi sisteme ve hangi durum bilgisiyle döndü? | Sanal sipariş kimliği ve gözlenen sonuç |
Bu tablo resmî başvuru eki değildir. Test için sanal kayıt kullanıldıysa gerçek satış veya müşteri sonucu diye paylaşılmamalıdır.
Resmî kaynaklar ve kontrol yolu
11 Kasım 2026 tarihinde erişilen 13.04.2026 tarihli E-İhracat Genelgesinin 17. maddesi incelendi. Başvuru öncesinde güncel metin ve ekleri yeniden esas alınmalıdır.
Önce statüyü, sonra teknik kapsamı doğrulayın
Yararlanıcı statünüzü, platformu ve yazılım teklifini Hibe Raporu e-ihracat ön incelemesinde birlikte paylaşın. Hizmetin ticari adının destek başlığıyla aynı olması yeterli değildir.
Son stok iki mağazada aynı anda satılınca hangi kayıt kapanır?
Şirketin deposunda tek lamba kalmış ve iki mağazadan saniyeler arayla sipariş gelmiş olsun. Yazılım demosunda ürünleri mağazaya yüklemek bu durumu sınamaz. Ekip e-ihracat entegrasyon desteği için teknik kapsamı çıkarırken deneme ortamında son birimi iki siparişe ayırtmayı deneyebilir. Hangi siparişin stoğu rezerve ettiğini, diğer mağazaya stok bilgisinin ne zaman gittiğini ve karşılanamayan siparişin operatöre nasıl gösterildiğini kaydedin. Teklifte yalnız ürün aktarımı varsa rezervasyon çakışmasını çözme işinin de fiyatlanıp fiyatlanmadığı bu denemeyle açıklığa kavuşur.
