SAP FICO anlatımı: implementasyonları bozan 7 şey

SAP FICO, tek bir modül gibi çalışan iki modüldür. Finansal Muhasebe (FI), denetçilerin ve düzenleyicilerin gördüğü rakamları üretir. Kontrolling (CO), yönetimin işi yürütmek için kullandığı rakamları üretir. S/4HANA'da ikisi de tek bir Universal Journal'a kayıt atar. Bu makale, bir S/4HANA finans çalışma kolunu başlatan, yürüten ya da kurtarmaya çalışan finans liderlerine, program direktörlerine ve FICO danışmanlarına yönelik. FI ile CO'nun nasıl birleştiğini, SAP'nin geri kalanıyla nerede bağlandığını ve implementasyonları bozan yedi kararı anlatıyor. Kullanıcı kabul testine (UAT) girmeden önce, sonlara doğru yer alan hazırlık kontrol listesini kullanın.

SAP FICO projelerinde, blueprint'ten desteğe kadar tüm yaşam döngüsü boyunca 25 yıldır çalışıyorum ve aynı örüntüler tekrar ediyor. Bazı sorunlar teknik. Daha çoğu, başta aceleye getirilmiş ya da gözden kaçmış kararlardan doğuyor.

2026'da zamanlama önemli. SAP ECC, 2027 sonunda ana akım bakımdan çıkıyor; bu yüzden hâlâ ECC'de olan finans ekiplerinin çoğu ya geçişin ortasında ya da başlamak üzere. Aşağıdaki hatalar bir S/4HANA programında ECC'dekinden daha pahalıya mal olur, çünkü Universal Journal kötü tasarımı sonradan emmeye daha az yer bırakır.

Finansal Muhasebe (FI) dışarıya bakar. Yasal uyumluluk, bilanço, gelir tablosu; şirketten dışarı çıkan rakamlar. SAP'deki her finansal işlem sonunda FI'ye ulaşır.

Kontrolling (CO) içeriye bakar. Yönetim kararları için maliyet izleme, bütçeleme ve karlılık. Maliyet merkezleri paranın nerede harcandığını gösterir. Karlılık analizi marjı müşteri, bölge ya da ürün bazında gösterir.

Pratikte ikisini ayıramazsınız. Borç Hesapları'ndaki bir tedarikçi faturası Genel Muhasebe'ye kayıt atar ve maliyet merkezi raporlarına akabilir. Bir varlık alımı defterleri günceller ve maliyet planlamasını etkiler. FI'nin nerede bittiğini, CO'nun nerede başladığını ve nerede örtüştüklerini bilmek, finans bilgisini düğme bilgisinden ayırır.

S/4HANA'da sınır daha da bulanıklaşır. Universal Journal (ACDOCA tablosu), FI ve CO kalemlerini tek bir kayıtta tutar. Tasarım açısından iki sonuç önemli. Maliyet unsurları artık ayrı ana veri değil, maliyet unsuru kategorisi olan GL hesaplarıdır. Ve SAP'nin önerdiği karlılık modeli Marj Analizi'dir (hesap bazlı CO-PA). Maliyet bazlı CO-PA şirket içi kurulumda ve private edition'da hâlâ var. Yine de SAP'nin eğitim materyali net: S/4HANA Cloud'da mevcut değil ve yeni yatırım Marj Analizi'ne gidiyor.

Bir FICO ekibinin konfigüre ettiği ana bileşenler şunlar:

Bileşen	Alan	Neyi yönetir
Genel Muhasebe (FI-GL)	FI	Tüm finansal işlemlerin merkezi kaydı; yasal raporlamanın temeli
Borç Hesapları (FI-AP)	FI	Tedarikçi faturaları, ödemeler, yükümlülükler
Alacak Hesapları (FI-AR)	FI	Müşteri faturaları, tahsilatlar, kredi
Varlık Muhasebesi (FI-AA)	FI	Sabit kıymetlerin edinimi, amortismanı, elden çıkarılması
Banka Muhasebesi	FI	Banka ekstreleri, mutabakat, nakit pozisyonu
Maliyet Merkezi Muhasebesi	CO	Departman ya da fonksiyon bazında maliyetler
İç Siparişler	CO	Etkinlikler, kampanyalar, küçük projeler için geçici maliyet toplayıcılar
Kâr Merkezi Muhasebesi	CO	İş birimi bazında gelir ve maliyet
Marj Analizi (CO-PA)	CO	Müşteri, ürün, kanal ya da bölge bazında marj

FI ile CO arasındaki mutabakat ortadan kalktı. Tek bir defter ve ayrı toplam tabloları olmadığı için, ECC'de danışman günlerini yiyen dönem sonu mutabakatı büyük ölçüde ortadan kalkıyor. Madalyonun öbür yüzü: maliyet merkezi tasarımı ve karlılık özelliklerinin tasarım aşamasında doğru olması gerekiyor. Hataları gizleyecek bir toplulaştırma katmanı yok.

Konsolidasyon ve planlamanın yeni adresleri var. SAP, konsolidasyon için S/4HANA Group Reporting'i SAP Business Planning and Consolidation'ın (BPC) halefi, planlama için de SAP Analytics Cloud'u konumlandırıyor. BPC'nin ana akım bakımı 2027'de sona eriyor. SAP BPC rehberim, hâlâ kullanıyorsanız ne yapmanız gerektiğini anlatıyor.

Joule gerçek, ama dar. SAP'nin 2025 ortası yapay zeka sürüm notları, sabit kıymet ana verisi oluşturma ve banka ekstrelerini Joule üzerinden izleme gibi finans kullanımlarını listeliyor. Vadesi geçmiş kalemlerin peşine düşen bir alacak hesapları ajanını da anlatıyorlar. Mayıs 2025'ten beri genel kullanıma açık olan SAP Joule for Consultants, konfigürasyon sorularını SAP Notları ve Activate içeriğinden yanıtlıyor. Hepsi temiz veriyle daha iyi çalışıyor. Hiçbiri kötü tasarımı düzeltmiyor.

Clean core, “özelleştirmek” kelimesinin anlamını değiştiriyor. S/4HANA Cloud Public Edition'da çekirdeği hiç değiştiremezsiniz. Private edition'da ve şirket içi kurulumda değiştirebilirsiniz, ama her değişiklik yükseltme eforu ve regresyon riski ekler. ECC alışkanlıkları (kayıt kuralları için Z tabloları, vergi mantığı için geliştirmeler, CO-PA'da ABAP türetmeleri) artık standart konfigürasyona ya da SAP BTP üzerindeki yan yana uzantılara ait. Bu, aşağıdaki 4. hatanın riskini yükseltiyor.

FICO neredeyse her SAP modülüne bağlanır. Entegrasyon sorunlarının çoğu devir noktalarında yaşanır: her ekip kendi alanını test eder, bağlantıyı kimse test etmez.

Modül	Entegrasyon noktası	S/4HANA'da ne olur
MM (Malzeme Yönetimi)	GR/IR mahsubu, fatura kaydı, stok değerleme	Mal girişi ACDOCA'ya bir GR/IR kaydı atar; tedarikçi faturası onu mahsup eder ve Borç Hesapları'na kayıt atar
SD (Satış ve Dağıtım)	Faturalama, gelir, alacaklar, kredi	Faturalama Universal Journal'daki geliri ve alacakları günceller; sözleşmelerin gerektirdiği yerde IFRS 15 için Revenue Accounting and Reporting kullanılır
PP (Üretim Planlama)	Üretim maliyeti, devam eden iş (WIP), sapmalar	Sipariş maliyetleri ACDOCA'da birikir; WIP ve sapmalar aynı defterin içinde uzlaştırılır
HCM / bordro	Bordro kaydı, maliyet atama	Bordro sonuçları FI'ye gider ve yükümlülük olarak kaydedilir, maliyet merkezlerine akar
PS (Proje Sistemi)	Bütçeler, uzlaştırma, proje geliri	Proje maliyetleri ve geliri FI/CO'ya anında görünürlükle kaydedilir
PM (Tesis Bakımı)	Bakım siparişi maliyetleri	İşçilik ve malzeme maliyetleri siparişlerde toplanır ve CO'ya uzlaştırılır
Group Reporting	Konsolidasyon	ACDOCA'yı doğrudan okur; ayrı konsolidasyon veritabanı yok

Universal Journal, bu entegrasyonların nasıl başarısız olduğunu değiştirir. ECC'de FI-CO farkları bir mutabakat sorunu olarak ortaya çıkıyordu. S/4HANA'da yanlış hesaba giden bir MM kaydı, ters kayıtla düzeltilip yeniden kaydedilmesi gereken gerçek bir yevmiye kaydı oluşturur. Denetim bulguları daha hızlı gelir. Bu devir noktalarının lojistik tarafı için SAP SD ve SAP PP rehberlerime bakın.

1. 01MM'de mal girişiStok ve envanter güncellenir
2. 02Hesap belirlemeDeğerleme sınıfı GL hesaplarını seçer
3. 03ACDOCA'da GR/IR kaydıFI ve CO için tek bir Universal Journal satırı
4. 04Tedarikçi faturasıGR/IR kaydını mahsup eder
5. 05Borç HesaplarıGL'ye kaydedilir ve maliyet merkezi raporlarına akabilir

FI ve CO'nun ikisinin de okuduğu tek bir yevmiye kaydı

1. Sahibi olmayan ana veriler

Çoğu proje birinci haftada ana verinin temizlenmesi gerektiği konusunda anlaşır. Sonra konfigürasyon devralır, son tarihler sıkışır ve ana veri geride kalır. Teste kadar.

BAE'deki bir perakende müşterimin maliyet merkezi hiyerarşisi eksiksiz görünüyordu. Etiketler uyuyordu. Toplamlar tutuyordu. Entegrasyon testinde mağaza maliyetleri anlamsız bölge sorumlularının altında göründü ve bazı veriler hiç yoktu.

Yapı, mağazaların gerçekte nasıl çalıştığıyla hiç karşılaştırılmamıştı. İmplementasyon ekibinin varsayımları üzerine kurulmuştu. Maliyet merkezi eşlemesini ve raporlama mantığını yeniden yapılandırmak, iyi insanlar tam odaklanmışken iki hafta sürdü.

Olağan şüpheliler tanıdık. Güncel raporlama ihtiyaçları kontrol edilmeden eski sistemden kopyalanan GL hesapları. Eskimiş vergi verisi ya da eksik banka bilgisi olan tedarikçi ana kayıtları. Maliyet akışını değil organizasyon şemasını izleyen maliyet merkezi hiyerarşileri. Geç eklenen kâr merkezleri. Blueprint kapanmadan önce ana veriye isimli bir sahip verin. Yapının, kullanımın ve boşlukların kaba bir incelemesi bile sonradan yapılacak temizliğin çoğunu önler.

2. Kontrolörler sürece dahil edilmeden konfigüre edilen CO

Kontrolling (CO) genellikle ikinci sırada gelir. FI erken tasarlanır, gözden geçirilir ve test edilir. CO, daha basit olduğu ve sonra tamamlanabileceği düşüncesiyle daha az dikkatle takip eder.

Tamamlanamaz.

Çalıştığım bir telekom projesinde CO-PA geç konfigüre edildi. Testler iyi görünüyordu. Kayıtlar geçti ve raporlar çalıştı. Sonra satış ve finans marjları inceledi ve öne çıkan ürünler negatif karlılık gösterdi. Kilit maliyet unsurları eşlenmemişti ve türetme kuralları eksikti. Düzeltmek, daha önce onaylanmış raporlama yapılarını yeniden tasarlamak anlamına geliyordu.

CO, ancak raporları okuyan kişiler, yani kontrolörler ve finans direktörleri tasarımına katkıda bulunduğunda işe yarar. Onlar sistem akışıyla değil, maliyet davranışı ve marjla düşünür. Onları kullanıcı kabul testi aşamasında değil, blueprint aşamasında devreye alın.

3. İş kullanıcıları sistemi ilk kez UAT sırasında görüyor

Sorunlar UAT sırasında ortaya çıkar ve onları bulmak için en pahalı yer burasıdır. Tasarım kilitlenmiştir ve konfigürasyon neredeyse bitmiştir.

Güneydoğu Asya'daki bir holding şirketinin finans dönüşümünde UAT güvenle başladı. Senaryolar hazırdı. Teknik kontroller geçilmişti. Sonra finans ekibi giriş yaptı. Çoğu için ekranları ilk kez görüyorlardı. Her gün kullandıkları alanlar yoktu. Adımlar açıklama yapılmadan ortaya çıkmıştı. İş akışları, teknik açıdan mantıklı, operasyonel açıdan hiç mantıklı olmayan biçimde yeniden kurulmuştu.

Kilit akışları gözden geçirmemiz gerekti ve bazı mantıkların yeniden kurulması şart oldu. Proje haftalar kaybetti.

Kullanıcılara tamamlanmamış ekranları erkenden gösterin. Bitmiş ekranları geç göstermekten her zaman daha ucuzdur.

4. Konfigürasyonun yeteceği yerde özel geliştirme

Özel kod daha hızlı ve daha kontrollü hissettirir. İstediğiniz şeyi tam olarak alırsınız. Zamanla test etmesi zor, değiştirmesi zor ve kırılgan hale gelir; S/4HANA'da her değişiklik yükseltme eforu ekler.

Bir keresinde altı ülkeyi kapsayan küresel bir implementasyonda çalıştım; vergi mantığı tamamen ABAP ile kurulmuştu: ülke kuralları, istisnalar, ürün bazlı oranlar. İşe yarıyordu. Ama standart SAP bunu koşul türleri, vergi prosedürleri ve ülke konfigürasyonuyla zaten karşılıyordu.

Bir ülke vergi oranını değiştirdiğinde iş birimi bir geliştirme talebi açmak, beklemek ve her şeyi yeniden test etmek zorundaydı. Başta verimli hissettiren şey, her vergi değişikliği için darboğaza dönüştü. Bu gibi durumlarda çözüm, özel tabloları emekliye ayırmak, mantığı standart konfigürasyona taşımak ve yalnızca gerçekten benzersiz kuralları küçük bir uzantıda tutmaktır.

Aynı örüntü başka yerlerde de çıkar. Konfigürasyonun zaten karşıladığı kayıt kuralları için özel doğrulamalar. Standart Fiori uygulamaları ya da CDS görünümleri varken yeniden yazılan raporlar. Değişikliğe yer bırakmayan, koda gömülmüş onay adımları. Her seferinde tek bir soru sorun: bu mantık nerede duruyor ve bir proje gerektirmeden bir sonraki yükseltmeden sağ çıkacak mı? Cevap “çekirdekte” ya da “kontrol etmedik” ise, onu konfigürasyona ya da BTP'ye taşıyın.

5. Kontrol edilmeyen entegrasyon noktaları

Test sırasında ekipler kendi modüllerine odaklanır. Sınırlar kontrol edilmeden kalır.

Bir üretim kurulumunda mal girişleri MM'de doğru işlendi. Envanter güncellendi. Lojistik şikâyet etmedi. FI'de bu girişler için hiçbir yevmiye kaydı yoktu.

Neden, hesap belirlemede eksik bir değerleme sınıfıydı. MM hatasız işledi ve hiçbir finansal kayıt oluşturmadı. Teşhis iki gün sürdü. Bu arada kaydedilenleri temizlemek birkaç gün daha aldı.

Gördüğüm benzer hatalar: hesap belirleme boşlukları yüzünden yanlış gelir hesaplarına kayıt atan SD faturalaması. PM'de Varlık Muhasebesi'ne hiç ulaşmayan varlık transferleri. MM ve FI ekiplerinin farklı anladığı GR/IR mantığı. MM ve SD test senaryolarını inceleyen tek bir finans lideri bunların çoğunu önler. Bir kaydın nasıl görünmesi gerektiğini finans bilir. Bir lojistik test uzmanı çoğu zaman bilmez.

6. Son sprint'te tasarlanan raporlama

Finansal bilgi üretmek için var olan bir modül için, projeler raporlamayı sona atmakta dikkat çekici bir tutarlılık gösterir. Önce işlemler kaydedilsin, raporlar sonra halledilir.

Canlıya geçiş sonrası aşamayı desteklediğim Avrupa'daki bir tüketim malları müşterisinde CO-PA kurulmuş, alanlar eşlenmiş ve türetmeler konfigüre edilmişti. İlk segment kâr ve zarar tablosunun başlıkları doğruydu, maliyetler ise dağınık ve parçalıydı. Gelir iyiydi. Bazı değer alanları hiç doldurulmamıştı.

Finans ekibi yine Excel'e döndü. Yeniden. Toparlamak için devreye girmem gerekti. Raporlamaya duyulan güven bir kez kaybolduğunda, nadiren kendiliğinden geri gelir.

İş için kanal bazında marj ya da proje bazında maliyet önemliyse, bu gereksinimin tasarım sırasında verinin nasıl yakalanacağını şekillendirmesi gerekir. 2026'daki olağan raporlama katmanı, Universal Journal'ı okuyan SAP Analytics Cloud'dur; bazı GROW ve RISE paketlerine dahildir, bazılarında ayrı satılır, bu yüzden sözleşmenizi kontrol edin. Temiz bir karlılık tasarımının üzerindeki Analytics Cloud işe yarar. Yarım konfigüre edilmiş birinin üzerindeki Analytics Cloud yaramaz. Daha fazlası SAP Analytics Cloud rehberimde.

7. Ekipler arasında kaybolan uç durumlar

Projeler haklı olarak yüksek hacimli süreçlere odaklanır. Bu, uç durumları ortaya çıkana kadar kenara iter.

Bir kurulumda müşterinin üç şirket kodu ve üç farklı mali yıl varyantı vardı: biri takvim yılı, biri Nisan'dan Mart'a, biri 4-4-5. Tasarımda kimse bunu işaretlemedi.

Şirketler arası mutabakatta ortaya çıktı. Dönemler örtüşmedi. Her şirket kodunun kesme tarihi farklı olduğu için finans zamanında kapanış yapamadı. Bu tek sorun konsolidasyonu iki hafta geriye attı.

Planda, her çalışma kolunun kendi alanındaki alışılmadık şeyleri listelediği bir saat ayırın. Üç soru sorun. Henüz modellenmemiş yasal ya da bölgesel kurallar var mı? Herhangi bir ekip SAP dışında elle çözümler yürütüyor mu? Avanslar, park edilmiş belgeler ya da şirketler arası netleştirme gibi özellikler kullanılıyor mu? Uç durumlar her zaman ortaya çıkar. Tek soru, bir tasarım oturumunda mı yoksa ay sonu kapanışında mı ortaya çıkacakları.

Bu listeyi UAT başlamadan iki hafta önce çalıştırın. Her “hayır”, bir sahibi ve bir tarihi olan, kayda geçirilecek bir risktir.

1. Ana veri sahibi belirlendi. Tek bir kişi hesap planını, maliyet merkezi hiyerarşisini, kâr merkezlerini ve tedarikçi ile müşteri ana kayıtlarını onaylar. Sahibi: finans direktörü.
2. Maliyet merkezi hiyerarşisi gerçek maliyet akışına karşı test edildi. Organizasyon şemasına karşı değil. Sahibi: finansal kontrolör.
3. Kontrolörler karlılık tasarımını inceledi. Özellikler, türetme kuralları ve segment kâr ve zarar tablosunun ilk taslağı. Sahibi: kontrol birimi başkanı.
4. Anahtar kullanıcılar ekranları gördü. UAT senaryoları yazılmadan önce süreç başına en az bir gösterim. Sahibi: finans süreç lideri.
5. Özel kod listesi gözden geçirildi. Her geliştirmenin, standart konfigürasyonun neden yapamadığına dair bir gerekçesi var. Sahibi: çözüm mimarı.
6. Hesap belirleme modüller arası test edildi. Bir mal girişi, bir tedarikçi faturası, bir müşteri faturası ve bir üretim siparişi uzlaştırması, beklenen yevmiye kayıtlarını üretir. Sahibi: MM, SD ve PP liderleriyle birlikte FICO lideri.
7. Yönetim raporları gerçek test verisinden kuruldu. Maketlerden değil. Sahibi: CFO ofisiyle birlikte raporlama lideri.
8. Mali yıl varyantları, para birimleri ve şirketler arası ayarlar şirket kodları arasında karşılaştırıldı. Sahibi: FICO lideri.
9. Uç durum oturumu yapıldı. Tahakkuklar, avanslar, park edilmiş belgeler, şirketler arası netleştirme, ülke vergi kuralları. Sahibi: program yöneticisi.

SAP FICO nedir ve her harf neyi ifade eder?

FI, Finansal Muhasebe; CO ise Kontrolling anlamına gelir. Birlikte SAP'nin temel finans modülleridir.

FI dış raporlamayı yönetir: Genel Muhasebe, Borç Hesapları, Alacak Hesapları, Varlık Muhasebesi ve Banka Muhasebesi. CO iç yönetim raporlamasını yönetir: maliyet merkezleri, iç siparişler, kâr merkezleri ve karlılık analizi.

Sıkı sıkıya bağlıdırlar. S/4HANA'da tek bir Universal Journal'ı paylaşırlar; dolayısıyla birini diğeri olmadan anlayamazsınız.

SAP FICO, SAP MM, SD ve PP ile nasıl entegre olur?

MM'den FI'ye: mal girişi otomatik olarak bir GR/IR kaydı atar. Tedarikçi faturası onu mahsup eder ve Borç Hesapları'na kayıt atar. Hesap belirleme doğru olmalıdır; yoksa MM işler ve hiçbir finansal kayıt görünmez.

SD'den FI'ye: faturalama geliri ve alacakları günceller. SD hesap belirlemesindeki boşluklar geliri yanlış hesaplara ya da hiçbir yere göndermez.

PP'den FI/CO'ya: üretim siparişleri malzeme, işçilik ve genel gider maliyetlerini toplar. CO, devam eden işi ve sapmaları uzlaştırır. Zayıf bir karlılık tasarımı, bu maliyetlerin marj raporlarına hiç ulaşmaması demektir.

Üçünün de çözümü aynı. Bir finans lideri, diğer çalışma kollarının yazdığı entegrasyon test senaryolarını incelemeli.

SAP HANA ile SAP FICO arasındaki fark nedir?

Farklı katmanlardır. SAP HANA bellek içi veritabanıdır. SAP FICO, muhasebecilerin ve kontrolörlerin kullandığı finans uygulamasıdır.

S/4HANA'da Universal Journal'ı pratik kılan HANA'dır: FI ve CO verisi tek tabloda, toplu mutabakat olmadan gerçek zamanlı raporlanır. Bir HANA performans sorunu FICO raporlarının ne kadar hızlı çalıştığını etkiler. Bir FICO konfigürasyon sorunu ise bu raporların neyi içerdiğini belirler.

SAP FICO, 2026'da S/4HANA ile hâlâ geçerli mi?

Evet. Temel beceriler aktarılır: hesap belirleme, maliyet merkezi tasarımı, karlılık kurulumu, dönem sonu kapanışı. Şirketlerin hâlâ işlemleri bilmenin yanı sıra finans süreçlerini de anlayan insanlara ihtiyacı var.

Değişen, talep gören profil. İşverenler Universal Journal'ı, Marj Analizi'ni, Group Reporting'i ve clean core uzantısını anlayan, ECC'den geçiş sırasında hangi özelleştirmelerin emekliye ayrılacağı konusunda danışmanlık verebilen FICO danışmanları istiyor. ECC ana akım bakımının 2027'de sona ermesiyle, geçiş işleri talebi yüksek tutuyor.

Bir FICO kariyer geçişi planlıyorsanız, SAPopedia'nın kariyer yolları becerileri role göre haritalıyor ve ERPCV kariyer paketi S/4HANA finans deneyiminizi bir CV'de sunmanıza yardımcı oluyor.

Joule, 2026'da SAP FICO implementasyonlarını nasıl değiştiriyor?

Pazarlamanın ima ettiğinden az, şüphecilerin varsaydığından fazla. SAP Joule for Consultants, konfigürasyon ve kod sorularını SAP'nin kendi Notları ve Activate içeriğinden yanıtlar; bu, standart kapsam üzerindeki araştırmayı hızlandırır. Sistemin içinde Joule, sabit kıymet ana verisi oluşturma ve banka ekstrelerini izleme gibi görevleri yürütür; SAP da vadesi geçmiş alacakların peşine düşen gibi finans ajanları yayımladı.

Hiçbiri çok ülkeli vergi, grup raporlama yapıları ya da gelir tanıma konusundaki tasarım yargısının yerini almaz. Ve yalnızca altındaki veri kadar iyi çalışır. Ortak tekliflerini incelerken, yapay zeka araçlarının efor tahminlerine nasıl yansıdığını sorun.

Yeni bir implementasyonda temel FICO konfigürasyon adımları nelerdir?

Temel yaklaşık şu sırayla konfigüre edilir:

1. Şirket kodları: finansal tabloları üreten tüzel kişilikler.
2. Mali yıl varyantları: takvim yılı, Nisan'dan Mart'a ya da 4-4-5. Birbiriyle ticaret yapan şirket kodları arasında tutarlı tutun.
3. Hesap planı: GL hesap listesi, mümkün olduğunda şirket kodları arasında paylaşılır. Bu kararlar sistemin ömrü boyunca her raporu etkiler.
4. Kayıt dönemi varyantları: hangi dönemlerin kayda açık olduğu.
5. Alan durumu varyantları: hangi alanların zorunlu, isteğe bağlı ya da gizli olduğu.
6. Vergi konfigürasyonu: vergi kodları, oranlar ve ülke eşlemesi. Yerelleştirme karmaşıklığının çoğu burada.
7. Kontrolling yapıları: kontrol alanı, maliyet merkezleri, kâr merkezleri, iç siparişler ve karlılık özellikleri; kontrolörlerle birlikte tasarlanır.
8. Hesap belirleme: MM, SD ve PP işlemlerinin FI kayıtlarına nasıl dönüştüğü. Canlıya geçişten önce uçtan uca entegrasyon testleriyle doğrulayın.