Dijital İşletme Satışında Satın Alma Sözleşmesi Nedir?

Bir dijital işletmenin satın alma sürecinde LOI imzalanması, due diligence'ın tamamlanması veya fiyat üzerinde anlaşılması işlemin tamamlandığı anlamına gelmez.

Tarafların üzerinde anlaştığı ticari koşulların nihai bir sözleşmeye dönüştürülmesi gerekir.

Bu sözleşme, işlemin yapısına göre farklı isimlerle karşımıza çıkabilir.

Örneğin:

• Asset Purchase Agreement
• Share Purchase Agreement
• Stock Purchase Agreement

gibi sözleşme türleri kullanılabilir.

Micro-M&A işlemlerinde sözleşmenin temel amacı yalnızca:

İşletme X dolar karşılığında satılacaktır.

demek değildir.

Asıl amaç:

• tam olarak neyin satıldığını
• neyin satılmadığını
• ödemenin nasıl yapılacağını
• hangi riskin hangi tarafta kalacağını
• closing'in hangi şartlarla gerçekleşeceğini
• satış sonrası yükümlülükleri

açık şekilde belirlemektir.

Satın Alma Sözleşmesi Nedir?

Satın alma sözleşmesi, alıcı ve satıcının işletme devrine ilişkin nihai hukuki ve ticari koşulları düzenleyen sözleşmedir.

Genellikle bu sözleşmede:

• taraflar
• satın alınan varlık veya hisseler
• satın alma fiyatı
• ödeme yapısı
• closing koşulları
• satıcının beyanları
• alıcının beyanları
• tazminat hükümleri
• satış sonrası yükümlülükler

yer alır.

LOI çoğu zaman işlemin temel ekonomik çerçevesini belirler.

Satın alma sözleşmesi ise bu çerçeveyi detaylı ve uygulanabilir bir anlaşmaya dönüştürür.

LOI ile Satın Alma Sözleşmesi Arasındaki Fark Nedir?

LOI genellikle işlemin ana ticari şartlarını içerir.

Örneğin:

• teklif edilen fiyat
• ödeme yapısı
• işlem tipi
• due diligence süresi
• exclusivity
• tahmini closing tarihi

yer alabilir.

Ancak nihai satın alma sözleşmesi çok daha detaylıdır.

Örneğin sadece:

Kaynak kod devredilecektir.

demek yerine:

• hangi repository'lerin
• hangi branch'lerin
• hangi yazılım haklarının
• hangi third-party lisansların
• hangi teknik dokümantasyonun

devredileceği tanımlanabilir.

Bu nedenle LOI ile final agreement aynı belge değildir.

Asset Purchase Agreement Nedir?

Asset Purchase Agreement, yani varlık satın alma sözleşmesi, alıcının şirketin kendisini değil belirli işletme varlıklarını satın aldığı işlemlerde kullanılabilir.

Örneğin bir Micro-SaaS satışında devredilen varlıklar şunlar olabilir:

• domain
• source code
• marka
• müşteri sözleşmeleri
• database
• içerikler
• sosyal medya hesapları
• e-posta listesi
• dokümantasyon
• belirli SaaS hesapları

Bu işlemde satıcının şirket tüzel kişiliği satıcıda kalabilir.

Alıcı yalnızca anlaşmada belirtilen işletme varlıklarını alır.

Share Purchase Agreement Nedir?

Share Purchase Agreement veya Stock Purchase Agreement ise şirket hisselerinin satın alınmasına dayanır.

Bu durumda alıcı yalnızca belirli asset'leri değil, şirketin kendisini satın alır.

Dolayısıyla şirketin:

• varlıkları
• sözleşmeleri
• çalışanları
• yükümlülükleri
• geçmiş operasyonu

aynı tüzel kişilik içerisinde devam eder.

Bu nedenle share sale işlemlerinde historical liabilities daha fazla önem kazanabilir.

Sözleşmede İşlem Yapısı Açık Olmalı

İlk kritik konu işlemin tam olarak ne olduğudur.

Örneğin:

XYZ SaaS işletmesinin tüm ticari faaliyetleri satılmaktadır.

ifadesi tek başına yeterince açık olmayabilir.

Daha doğru yaklaşım:

• hangi asset'lerin transfer edildiğini
• hangi liabilities'in devredildiğini
• hangi unsurların işlem dışında kaldığını

ayrı ayrı tanımlamaktır.

1. Satın Alınan Varlıklar

Asset sale işleminde satın alınan varlıkların mümkün olduğunca açık listelenmesi gerekir.

Örneğin:

Dijital Varlıklar

• domain
• subdomain'ler
• website
• mobile applications
• source-code repositories
• database
• cloud configurations

Intellectual Property

• trademark
• brand name
• design files
• source code
• proprietary documentation
• content rights

Ticari Varlıklar

• customer contracts
• supplier contracts
• partnership agreements
• subscriber lists

Hesaplar

• analytics
• email marketing
• support systems
• social accounts
• app-store assets

Ancak üçüncü taraf platformların hesap devir kuralları ayrıca kontrol edilmelidir.

Her hesap doğrudan transfer edilebilir olmayabilir.

2. Excluded Assets

Satılmayan varlıkların da belirtilmesi önemlidir.

Örneğin satıcının:

• kişisel e-posta hesabı
• başka projelerde kullandığı cloud hesabı
• kişisel sosyal medya hesabı
• şirket banka hesabındaki belirli nakit
• işlem dışında kalan domain'ler

devredilmeyebilir.

Excluded assets açık şekilde tanımlanmazsa closing sırasında anlaşmazlık çıkabilir.

3. Liabilities

Sözleşmede borç ve yükümlülüklerin hangi tarafta kaldığı belirlenmelidir.

Örneğin:

• geçmiş vergi borçları
• refund talepleri
• chargeback'ler
• customer credits
• unpaid contractor invoices
• geçmiş dönem hukuki talepler

kim tarafından karşılanacak?

Asset sale işlemlerinde alıcı çoğu zaman yalnızca açıkça kabul ettiği liabilities'i üstlenmek isteyebilir.

Share sale işleminde ise şirketin geçmiş yükümlülükleri şirket içerisinde devam edebilir.

4. Purchase Price

Satın alma fiyatı açık şekilde yazılmalıdır.

Ancak yalnızca toplam fiyat yeterli olmayabilir.

Örneğin:

Purchase Price: $400,000

olabilir.

Bunun:

• ne kadarı closing'de
• ne kadarı deferred
• ne kadarı seller financing
• ne kadarı earn-out
• ne kadarı holdback

olduğu ayrıca belirlenmelidir.

5. Cash at Closing

Cash at closing, closing sırasında satıcıya ödenen tutardır.

Örneğin:

Toplam fiyat:

$400,000

Ödeme:

• $300,000 closing'de
• $50,000 12 ay sonra
• $50,000 earn-out

şeklinde olabilir.

Bu durumda headline purchase price $400,000 olsa da satıcının closing gününde aldığı para $300,000'dır.

6. Deferred Payment

Deferred payment, satın alma bedelinin bir kısmının gelecekte ödenmesidir.

Sözleşmede açıkça belirtilmesi gereken noktalar:

• ödeme tarihi
• ödeme tutarı
• faiz olup olmadığı
• erken ödeme şartları
• default durumunda ne olacağı

olabilir.

Belirsiz deferred payment hükümleri daha sonra ciddi anlaşmazlık yaratabilir.

7. Earn-Out

Earn-out, satın alma fiyatının bir bölümünün işletmenin gelecekteki performansına bağlı olmasıdır.

Örneğin:

Önümüzdeki 12 ay içerisinde ARR $500.000'i aşarsa satıcıya ek $100.000 ödenecektir.

Ancak earn-out maddesinde yalnızca hedef yazmak yeterli değildir.

Şunların da açık olması gerekir:

• ARR nasıl hesaplanacak?
• Refund'lar düşülecek mi?
• Annual contract'lar nasıl ele alınacak?
• Buyer pricing'i değiştirirse ne olacak?
• İşletme başka ürünle birleştirilirse performans nasıl ölçülecek?

Earn-out hükümlerinde ölçüm metodunun objektif olması önemlidir.

8. Holdback

Holdback, satın alma bedelinin belirli kısmının geçici olarak tutulmasıdır.

Örneğin:

• purchase price: $300,000
• closing payment: $270,000
• holdback: $30,000

olabilir.

Holdback belirli:

• warranty breach
• indemnification claim
• unresolved liability

risklerini karşılamak amacıyla kullanılabilir.

Belirli süre sonunda claim yoksa satıcıya ödenebilir.

9. Working Capital

Her Micro-M&A işleminde working capital adjustment gerekmez.

Ancak özellikle:

• e-commerce
• agency
• employee-heavy business

işlemlerinde önem kazanabilir.

Örneğin işletmenin closing günü:

• belirli minimum cash
• inventory
• receivables
• payables

seviyesiyle teslim edilmesi kararlaştırılabilir.

10. Seller Representations and Warranties

Representations and warranties, satıcının işletmeyle ilgili belirli beyanlarda bulunduğu hükümlerdir.

Örneğin satıcı:

• işletmenin varlıklarına sahip olduğunu
• finansal verilerin doğru olduğunu
• IP haklarının kendisine veya şirkete ait olduğunu
• açıklanmamış önemli borç bulunmadığını
• ciddi hukuki ihtilaf bulunmadığını
• sözleşmelerin geçerli olduğunu

beyan edebilir.

Bu hükümler alıcının yalnızca due diligence sırasında gördüğü verilere değil, satıcının hukuki beyanlarına da dayanmasını sağlar.

11. Financial Representations

Finansal beyanlar özellikle Micro-M&A'da önemlidir.

Satıcı örneğin:

• sunulan revenue rakamlarının doğru olduğunu
• açıklanan giderlerin tam olduğunu
• gizli borç bulunmadığını
• payment processor verilerinin doğru olduğunu

beyan edebilir.

Due diligence önemli olsa da alıcı her işlemi tek tek doğrulayamayabilir.

Bu nedenle representations sözleşmede ek güvence oluşturabilir.

12. Intellectual Property Representations

Dijital işletmelerde en kritik alanlardan biri IP'dir.

Satıcı örneğin:

• source code'un kendisine ait olduğunu
• gerekli freelancer IP assignment'larının bulunduğunu
• markanın kullanım hakkına sahip olduğunu
• bilinen ciddi IP ihlali bulunmadığını

beyan edebilir.

Özellikle geçmişte freelancer veya ajans kullanılmışsa bu alan detaylı incelenmelidir.

13. Customer and Contract Representations

Satıcı aşağıdaki konularda bilgi verebilir:

• material customer contracts
• cancellation notices
• major customer disputes
• partner agreements
• supplier agreements

Örneğin en büyük müşterinin bir hafta sonra sözleşmeyi iptal edeceği biliniyorsa bu bilgi alıcı için material olabilir.

14. Disclosure Schedule

Representations çoğu zaman belirli istisnalarla birlikte verilir.

Örneğin sözleşmede:

Şirket hakkında devam eden herhangi bir dava bulunmamaktadır.

yazarken disclosure schedule içerisinde:

ABC Ltd. ile devam eden küçük ticari ihtilaf bulunmaktadır.

şeklinde istisna açıklanabilir.

Bu yapı satıcının bildiği istisnaları şeffaf şekilde sunmasını sağlar.

15. Indemnification

Indemnification, belirli bir sözleşme ihlali veya geçmiş yükümlülük nedeniyle zarar doğarsa kimin sorumlu olacağını düzenler.

Örneğin satıcının:

Tüm source code şirkete aittir.

beyanının yanlış olduğu ortaya çıkarsa alıcı ekonomik zarara uğrayabilir.

Indemnification hükümleri bu riskin nasıl yönetileceğini belirleyebilir.

16. Indemnification Cap

Satıcının sorumluluğu her zaman sınırsız olmayabilir.

Örneğin:

• purchase price'ın %10'u
• purchase price'ın %20'si
• belirli sabit tutar

gibi cap belirlenebilir.

Ancak fraud gibi durumlar farklı ele alınabilir.

Gerçek yapı işlemin taraflarına ve hukukuna göre değişebilir.

17. Survival Period

Representations ve indemnification haklarının ne kadar süre devam edeceği belirlenebilir.

Örneğin bazı hükümler:

• 12 ay
• 18 ay
• 24 ay

devam edebilir.

Vergi veya IP gibi bazı alanlarda farklı süreler uygulanabilir.

18. Closing Conditions

Sözleşme imzalandığı anda closing her zaman gerçekleşmeyebilir.

Önce belirli closing conditions tamamlanabilir.

Örneğin:

• domain transferinin hazırlanması
• third-party consent alınması
• kritik müşteri sözleşmesinin devam etmesi
• payment provider transition planının tamamlanması
• belirli IP belgelerinin imzalanması

gibi koşullar bulunabilir.

19. Third-Party Consent

Bazı sözleşmeler otomatik olarak devredilemez.

Örneğin:

• enterprise customer contract
• distribution agreement
• software license
• partner agreement

transfer için karşı tarafın onayını gerektirebilir.

Bu nedenle due diligence sırasında assignment veya change-of-control hükümleri incelenmelidir.

20. Domain ve Dijital Hesap Transferi

Dijital işletme sözleşmesinde transfer planının ayrıca belirtilmesi faydalı olabilir.

Örneğin:

• domain registrar
• GitHub
• cloud
• analytics
• email
• social accounts
• App Store
• Google Play

gibi varlıkların hangi sırayla aktarılacağı belirlenebilir.

Closing sırasında herkesin aynı anda ne yapacağı bilinmelidir.

21. Payment Processor Riski

Stripe, Paddle, PayPal veya benzeri ödeme hesapları her zaman doğrudan transfer edilebilir değildir.

Dolayısıyla sözleşmede:

• mevcut account'un devam edip etmeyeceği
• yeni account açılıp açılmayacağı
• subscription migration
• payout transition

gibi konular ele alınabilir.

Gelir akışının kesilmesi satın alma sonrası en önemli operasyon risklerinden biridir.

22. Transition Support

Özellikle founder-led işletmelerde seller transition support önemlidir.

Örneğin satıcı:

• ilk 30 gün haftada 10 saat
• sonraki 60 gün haftada 5 saat

destek verebilir.

Transition kapsamı:

• technical onboarding
• customer introductions
• supplier introductions
• process training
• troubleshooting

içerebilir.

Sadece:

Satıcı makul destek verecektir.

gibi belirsiz ifade yerine:

• süre
• saat
• kapsam
• iletişim şekli

tanımlanması daha sağlıklı olabilir.

23. Non-Compete ve Non-Solicit

İşlemin hukukuna göre mümkün olduğu ölçüde taraflar rekabet veya müşteri/çalışan transferine ilişkin bazı sınırlamalar üzerinde anlaşabilir.

Örneğin satıcının hemen ertesi gün aynı ürünü yeniden kurması alıcı açısından önemli risk olabilir.

Ancak bu tip maddelerin:

• süresi
• coğrafi kapsamı
• faaliyet alanı
• uygulanabilirliği

hukuki sınırlamalara tabi olabilir.

Bu nedenle profesyonel hukuki değerlendirme gerekir.

24. Confidentiality

Closing sonrasında da gizlilik yükümlülükleri devam edebilir.

Satıcı artık sahip olmadığı işletmenin:

• müşteri verilerini
• finansal bilgilerini
• source code'unu
• ticari sırlarını

kullanmamalı veya paylaşmamalıdır.

25. Employees ve Contractors

İşletmede çalışan veya freelancer varsa devir şekli açık olmalıdır.

Sorular:

• Çalışanlar yeni yapıya geçecek mi?
• Freelancer sözleşmeleri devam edecek mi?
• Maaş ve borçlardan kim sorumlu?
• Accrued vacation veya bonus var mı?
• IP assignment tamam mı?

Özellikle productized agency ve daha operasyonel işletmelerde bu konu önemlidir.

26. Customer Credits ve Refunds

Dijital işletmelerde geçmiş satışlardan kaynaklanan gelecekteki obligations bulunabilir.

Örneğin:

• prepaid annual subscriptions
• customer credits
• refund rights
• lifetime deals

alıcıya ekonomik yükümlülük yaratabilir.

Örneğin müşteriler yıllık aboneliklerini önceden ödediyse satıcı nakdi almış ancak hizmeti gelecek 10 ay boyunca alıcı sunacak olabilir.

Bu durum purchase price ve working capital analizinde dikkate alınmalıdır.

27. Lifetime Deal Kullanıcıları

Lifetime deal bulunan SaaS işletmelerinde bu kullanıcılar ayrıca ele alınmalıdır.

Müşteri geçmişte tek seferlik ödeme yapmış olabilir.

Ancak yeni sahibi:

• hosting
• API
• storage
• support

maliyetlerini uzun yıllar taşımaya devam edebilir.

Bu nedenle LTD obligations işletmenin ekonomik yükümlülükleri arasında değerlendirilmelidir.

28. Closing Deliverables

Closing sırasında tarafların teslim etmesi gereken belgeler ve erişimler liste halinde hazırlanabilir.

Satıcı örneğin:

• domain transfer code
• repository ownership
• cloud admin access
• database backup
• IP assignment
• signed agreement
• customer contract copies

teslim edebilir.

Alıcı ise:

• purchase price
• executed documents
• gerekli corporate approvals

sağlayabilir.

Bu liste closing'in daha kontrollü ilerlemesini sağlar.

29. Closing'den Sonra Ne Olur?

Closing sonrasında:

• purchase price transfer edilir
• asset veya share ownership değişir
• kritik hesaplar aktarılır
• satıcının gereksiz erişimleri kaldırılır
• transition dönemi başlar

Ancak bazı yükümlülükler devam edebilir.

Örneğin:

• deferred payment
• earn-out
• indemnification
• transition support
• confidentiality

closing sonrasında da geçerli olabilir.

Örnek Basit Deal Structure

Bir Micro-SaaS satışını düşünelim.

İşletme

• Revenue: $250.000
• SDE: $120.000

Purchase Price

$360.000

Ödeme

• $300.000 closing'de
• $30.000 12 ay deferred
• $30.000 holdback

Devredilen Varlıklar

• domain
• source code
• database
• brand
• customer contracts
• support documentation

Transition

• 30 gün: haftada 10 saat
• sonraki 60 gün: haftada 5 saat

Holdback

12 ay içerisinde belirli indemnification claim oluşmazsa satıcıya ödeniyor.

Bu örnekte headline price $360.000 olsa da transaction economics yalnızca bu rakamdan ibaret değildir.

Ödeme zamanı ve risk dağılımı da önemlidir.

Satıcı Açısından Kritik Sorular

Satıcı final agreement öncesinde şunları anlamalıdır:

• Gerçekte ne satıyorum?
• Closing'de ne kadar para alacağım?
• Hangi ödeme geleceğe bırakılıyor?
• Earn-out varsa kontrolüm dışındaki faktörlerden etkilenebilir mi?
• Ne kadar süre sorumlu kalacağım?
• Hangi representations veriyorum?
• Transition yükümlülüğüm ne kadar?
• Holdback ne zaman serbest kalacak?

Alıcı Açısından Kritik Sorular

Alıcı ise şu konulara odaklanabilir:

• Satın aldığım asset'ler tam olarak hangileri?
• IP ownership güvenli mi?
• Açıklanmamış liability var mı?
• Critical contracts transfer edilebilir mi?
• Revenue doğrulandı mı?
• Seller representations yeterli mi?
• Teknik transfer tamamlanabilir mi?
• Founder knowledge nasıl aktarılacak?
• Closing sonrası ortaya çıkabilecek riskler nasıl paylaşılacak?

Satın Alma Sözleşmesi Kontrol Listesi

Deal Structure

• Asset sale mı?
• Share sale mı?
• Satın alınan varlıklar açık mı?
• Excluded assets açık mı?

Price

• Toplam purchase price?
• Cash at closing?
• Deferred payment?
• Earn-out?
• Holdback?

Liabilities

• Hangi liabilities satıcıda kalıyor?
• Hangileri alıcıya geçiyor?
• Refund ve credits nasıl ele alınıyor?

Representations

• Financial statements
• revenue
• IP ownership
• contracts
• litigation
• customer information

ile ilgili beyanlar mevcut mu?

Closing

• Closing conditions açık mı?
• Third-party consents gerekli mi?
• Closing deliverables listelenmiş mi?

Transfer

• Domain
• source code
• hosting
• database
• analytics
• payment infrastructure
• customer contracts

için transfer planı mevcut mu?

Post-Closing

• Transition support
• deferred payment
• earn-out
• indemnification
• confidentiality

hükümleri net mi?

Yaygın Hatalar

Sadece Fiyata Odaklanmak

Headline price önemli olsa da ödeme yapısı en az fiyat kadar önemlidir.

Satılan Varlıkları Belirsiz Bırakmak

"Business assets" gibi genel ifadeler dijital işletmelerde yetersiz kalabilir.

Third-Party Transfer Kurallarını Geç Kontrol Etmek

Closing günü kritik hesabın transfer edilemediğini öğrenmek ciddi sorun yaratabilir.

Earn-Out Formülünü Belirsiz Yazmak

"Gelir artarsa ek ödeme yapılacaktır" yeterince açık değildir.

Founder Transition'ı Tanımlamamak

Satıcının ne kadar destek vereceği açık değilse closing sonrası anlaşmazlık çıkabilir.

Liability'leri Görmezden Gelmek

Prepaid subscription, refund veya customer credit gibi kalemler gerçek ekonomik yükümlülük olabilir.

Sonuç

Dijital işletme satın alma sözleşmesi yalnızca satış fiyatının yazıldığı bir belge değildir.

İyi hazırlanmış bir sözleşme işlemin bütün ekonomik mantığını tanımlar:

• neyin satıldığını
• neyin satılmadığını
• paranın ne zaman ödeneceğini
• hangi riskin kimde kalacağını
• işletmenin nasıl transfer edileceğini
• closing sonrası tarafların hangi yükümlülüklerinin devam edeceğini

belirler.

Micro-M&A işlemlerinde özellikle:

• source code
• domain
• payment accounts
• customer contracts
• SaaS hesapları
• intellectual property
• transition support

gibi dijital unsurların açık şekilde ele alınması önemlidir.

LOI tarafların anlaşmaya niyetini ve temel ticari yapıyı gösterir.

Due diligence riskleri ortaya çıkarır.

Nihai satın alma sözleşmesi ise bu bulguları ve ticari anlaşmayı uygulanabilir bir işlem yapısına dönüştürür.

Bu nedenle closing öncesindeki temel soru yalnızca:

Fiyat üzerinde anlaştık mı?

değildir.

Daha doğru soru şudur:

Satın aldığımız şey, ödeme mekanizması ve taraflar arasında kalan riskler yeterince açık şekilde tanımlandı mı?

Not: Satın alma sözleşmeleri işlem yapısına ve uygulanacak hukuka göre ciddi şekilde değişebilir. Bu içerik genel bilgilendirme amaçlıdır ve hukuki veya vergisel danışmanlık yerine geçmez.