GST fatura veri modeli: HSN ve siparişler için minimum alanlar

GST faturalarında genelde ne yanlış gidiyor

Çoğu GST fatura problemi “karmaşık vergi” sorunu değildir. Eksik veya tutarsız veri sorunlarıdır. Bir denetim, fatura satılanla, kime, nerede sağlandığı ve verginin nasıl hesaplandığıyla net şekilde bağlanamadığında başarısız olur.

Yaygın tetikleyicilerden biri HSN’in eksik, güncel olmayan veya yanlış seviyede uygulanmış olmasıdır. Ekipler HSN’i ürüne ekleyebilir, ancak fatura satırı farklı bir SKU adı veya varyantından oluşturulduğunda HSN nihai belgeye hiç yansımayabilir. Diğer sık sorun, vergi bölmesinin yanlış yapılmasıdır: "yer teslimi" nakliye adresinden tahmin edilip gerekli durum kodları saklanmadığı için IGST yerine CGST+SGST (veya tam tersi) alınması gibi.

Finans ekipleri bunu hemen hisseder. Mutabakat günlük bir temizlik işine dönüşür: fatura toplamları siparişle eşleşmez, sipariş ödeme ağ geçidi mutabakatıyla eşleşmez ve iadeler manuel not zincirine dönüşür. Satır kalemleri arasındaki küçük yuvarlama farkları bile fatura PDF’i, GST raporları ve defterler arasında uyumsuzluk yaratabilir.

En çok uyuşmazlık yaratan desenler şunlardır:

• Ürün ve fatura satırları aynı HSN, GST oranı ve vergilendirilebilir değer alanlarını paylaşmıyor.
• Vergi birden fazla yerde hesaplanıyor (sepet vs fatura) ve sonuçlar farklı.
• Toplamlar sadece “genel toplam” olarak saklanıyor; vergilendirilebilir değer ve her vergi bileşeni için ayrıntı yok.
• Fatura numaralandırması düzenlenebilir veya seri içinde çoğaltılmış.
• İadeler, doğru kredi notu yerine negatif siparişler olarak kaydediliyor.

GST fatura veri modelinin amacı basittir: her sayının daha sonra yeniden üretilebilmesi ve açıklanabilmesi için sipariş, ürün, taraf, vergi, fatura ve kredi notu alanlarının minimum setini saklayın. Küçük tutun, ama vergi türünü, oranını ve raporlamayı belirleyen yasal öneme sahip alanları atmayın.

Gerekli en küçük kayıt seti

GST faturalarının kolay oluşturulması ve sonradan mutabakatının kolay olması için küçük bir nesne setiyle başlayın ve her birinin tek bir iş yapmasını sağlayın. Temiz bir GST fatura veri modeli çok sayıda tabloya sahip olmaktan daha çok, gerçeklerin zaman içinde sabit tutulmasıyla ilgilidir.

Çoğu ekip için ilk günde gereken temel kayıtlar şunlardır:

• Müşteri: satın alan kişi (isim, telefon/e-posta, B2B ise GSTIN)
• Adres: sevkiyat ve fatura adresleri, ayrıca eyalet ve yer teslimi sinyalleri
• Ürün (veya Hizmet): satılan şey, birim, temel fiyat ve varsayılan HSN/SAC
• Sipariş: ticari olay (sepet, indirimler, kargo ücretleri, durum)
• Ödeme: paranın nasıl hareket ettiği (gateway referansı, yöntem, alınan tutar, tarih)

Bir Fatura Siparişten ayrı olmalıdır. Siparişler değişebilir (adres düzenlenir, ürünler iptal edilir, kısmi teslimat). Faturalar değişmemeli. Numaralandırma, tarih ve toplamlar sabit olmalı; birileri siparişi sonradan güncellediği için “kayma” yaşamamalıdır.

Vergi doğruluğu için kilit nokta Satır Kalemleridir. Her sipariş satırı (ve sonrasında her fatura satırı) o belirli ürün için tam miktar, birim fiyatı, indirim ve vergi dökümünü tutmalıdır. HSN/SAC ve GST oranları burada uygulanır.

Finans ekiplerinin işini kolaylaştıran bir ayrıntı: anlık görüntüleri saklayın. Fatura oluşturduğunuzda ürün açıklamasını, HSN/SAC, vergi oranını ve fiyatlamayı fatura satırlarına kopyalayın. Güncel ürün ana kaynağına güvenmeyin; oranlar ve isimler değişir.

Erken eklemeye değer olan seçenekler arasında İadeler, Geri Ödemeler ve Kredi Notları ayrı kayıtlar olarak yer alır. Örnek: iki öğelik bir siparişten bir öğe iade edilirse, orijinal fatura satırına referans veren bir kredi notu istersiniz; ödeme iadesi kaydı ise gateway işlemine referans verir. Bunları açık nesneler olarak tutmak ay sonu “manuel düzeltmeleri” önler.

Bunu Koder.ai içinde inşa ediyorsanız, her nesneyi önce basit bir ekran (oluştur, görüntüle, düzenle) olarak ele alın; sonra anlık görüntüler ve satır düzeyi alanlar hazır olduktan sonra fatura üretimini ekleyin.

HSN ve SAC: modelde nereye oturur

HSN (mal için) ve SAC (hizmet için) sadece “fatura-detayı” değildir. Ürün veya hizmet tanımında başlar ve fatura düzenlenirken her fatura satırına kopyalanır. Bu, karışık sepetleri doğru tutar ve denetimleri kolaylaştırır çünkü her satır kendi başına açıklanabilir olur.

Pratik minimum veri modeli şöyle olabilir:

• Ürün: id, ad, SKU, birim (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (manuel satırlar için opsiyonel), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

HSN/SAC’i Ürün üzerine koymak yönetim ekibinizin bunu tek bir yerden sürdürmesini sağlar. Fatura satırına kopyalamak geçmiş faturaları kararlı kılar. Ürün daha sonra değişse bile fatura satış anında doğru olanı gösterir. Bu, mutabakatta kırılmayan bir GST fatura veri modelinin özü.

HSN depolaması için basit tutun: kod gerekli, açıklama isteğe bağlı, ve bir effective_from tarihi değişiklik geçmişi istiyorsanız isteğe bağlıdır. Çoğu ekip her satırda açıklamaya ihtiyaç duymaz, fakat istisnaları kontrol ederken finans için yardımcı olabilir.

Karışık sepetler normaldir: bir faturada birden fazla satır ve dolayısıyla birden fazla HSN/SAC kodu olabilir. Bir faturaya tek bir kod zorlamayın. Toplamlar fatura düzeyinde toplanır, sınıflandırma satır düzeyinde kalır.

Değişiklik yönetimi insanların başını ağrıtır. Küçük bir kural seti kullanın:

• İhraç edilmiş fatura satırlarında HSN/SAC’i asla üzerine yazmayın.
• Bir ürünün HSN/SAC’i değişirse, sadece gelecekteki siparişler için Ürünü güncelleyin.
• Geçmiş tutuluyorsa, eski kaydı düzenlemek yerine yeni bir effective_from kaydı ekleyin.

Yönetim ekranı açısından, Ürün vergi alanlarını düzenlemek için tek bir yere ihtiyaç vardır; faturada yakalandığını doğrulamak için fatura satırlarında salt okunur bir görünüm yeterlidir. Eğer bu ekranları hızla kuruyorsanız, Koder.ai gibi araçlar bu modelden temel CRUD sayfaları ve veri tablolarını minimal eforla üretebilir.

Taraf detayları: GSTIN, adresler ve yer teslimi

Bir GST fatura veri modeli en sık taraf detaylarında başarısız olur. Alıcı veya satıcının kimliği biraz bile yanlışsa, faturanız kağıt üzerinde geçerli olsa bile iadeler ve mutabakat sırasında sorun olur.

"Satıcı", "alıcı" ve "teslimat adresi"ni ayrı taraflar olarak ele alarak başlayın, bunlar aynı kişi olsa bile. Bu, müşteri farklı bir teslimat adresi eklediğinde veya birden fazla GST kaydı ile satış yaptığınızda sonradan yapılan geçici çözümleri önler.

Saklanması gereken minimum alanlar (alıcı ve satıcı)

Sıkıcı ve açık alanlar tutun. Genelde faturada ve raporlarda ihtiyaç duyulanlar şunlardır:

• Yasal isim (faturada görüneceği şekilde)
• Ticari isim (opsiyonel, ama faydalı)
• GSTIN (satıcı için gerekli; alıcı için boş olabilir)
• Telefon/e-posta (destek için faydalı)
• Adres satırları, şehir, eyalet, ülke, PIN/posta kodu

Eyaleti hem insan okunur isim hem de eyalet kodu olarak saklayın; çünkü raporlama ve yer teslimi kuralları genellikle koda dayanır.

Fatura vs gönderim ve yer teslimi

Siparişte hem fatura hem gönderim adresini yakalayın; sadece müşteri profiline bağlı kalmayın. Profiller değişir; faturalar değişmemeli.

Yer teslimini faturada (fatura oluşturma anında) belirli bir eyalet kodu olarak saklayın. Sonradan "yeniden hesaplama" yapmayın. Kuralınız "gönderim adresi" ise, o sonucu ve kararı verirken kullanılan eyaleti saklayın. Bu denetimleri ve anlaşmazlıkları kolaylaştırır.

B2B vs B2C: GSTIN ne zaman zorunlu

B2B için alıcı GSTIN genelde zorunludur ve girişte uzunluk ve format doğrulanmalıdır. B2C için GSTIN boş kalabilir, ancak CGST/SGST veya IGST uygulanıp uygulanmayacağını belirlemek için tam bir adres ve eyalet gerekir.

Çoğu sistem için işe yarayan basit kural: alıcı GSTIN girildiyse B2B, yoksa B2C olarak değerlendirin. İstisnalar gerekiyorsa, açık bir customer_type alanı saklayın.

Çoklu varlık satıcılar (birden fazla GSTIN)

Birden fazla GST kaydı olan şube veya birimleriniz varsa, "Satıcı Varlığı"nı kendi kaydı olarak modelleyin; her birinin kendi GSTIN ve adresi olsun. Her sipariş kesinlikle bir satıcı varlığına referans vermeli ve her fatura bu detayları kopyalamalı; böylece geçmiş faturalar satıcı adresi sonradan değişse bile doğru kalır.

Koder.ai gibi araçlar bu kayıtlar için yönetim formlarını hızlıca üretebilir; kilit yapı: ayrı satıcı varlığı, fatura oluşturma zamanında anlık görüntüler ve açık bir yer teslimi eyalet kodu.

Saklamanız gereken vergi hesaplama alanları

En yaygın ayrım basittir: eğer yer teslimi tedarikçiyle aynı eyaletteyse vergi CGST + SGST’dir. Farklı eyalet ise IGST uygulanır. Sisteminiz "sonradan toplamdan yeniden hesaplamamalı" çünkü küçük farklar (yuvarlama, indirim, kargo) uyuşmazlıklara yol açar.

En azından vergi rakamlarını fatura satır düzeyinde saklayın, sadece fatura başlığı değil. Böylece faturadaki her kuru açıklayabilir ve ürüne, HSN’e ve gelire geri eşleyebilirsiniz.

Bir fatura satırı için pratik minimum alanlar:

• taxable_value (satır düzeyinde ayrılan indirim sonrası)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (kullanılan bölümle birlikte saklayın)
• cgst_amount, sgst_amount, igst_amount (hesaplanmış tutarları saklayın)
• line_total (taxable_value + vergi tutarları)

İndirimler sistemleri karıştıran yerdir. Tek bir kural belirleyin ve net saklayın. İndirimler vergiden önce fiyatı azaltıyorsa (ürün indirimleri ve kuponlar için tipik), orijinal brüt tutarı, indirim tutarını ve ortaya çıkan vergilendirilebilir değeri saklayın. Sipariş düzeyi kupon varsa, genelde her satıra oransal olarak paylaştırın ve her satırın ayrılmış indirimini saklayın ki vergi hesabı açıklanabilir olsun.

Yuvarlama tutarlı olmalı ve kaydedilmelidir. Satır düzeyinde mi yoksa sadece fatura düzeyinde mi yuvarlama yapacağınıza karar verin, sonra basılı olan yuvarlanmış sonuçları saklayın. Birçok ekip vergiyi satır başına hesaplar, 2 ondalığa yuvarlar, toplar ve sonra tam ödenecek tutarı yakalamak için invoice_rounding_adjustment alanı uygular.

Kargo ve elleçleme gizli eklemeler olmamalı. Bunları kendi HSN/hizmet kodu ve vergi oranı kuralları olan ayrı bir fatura satırı olarak ele alın. Örneğin, iki ürün ve bir kargo ücreti olan bir sipariş üç satır olur; her biri saklanmış vergilendirilebilir değere ve vergi bileşen tutarına sahip olur; bu finans mutabakatını kolaylaştırır.

Fatura doküman verileri: numaralandırma, tarihler, toplamlar, durum

Vergi hesaplandıktan sonra fatura halen geçerli, denetlenebilir ve sonradan mutabakatı kolay olacak "belge" alanlarına ihtiyaç duyar. GST fatura veri modelinde fatura başlığını yasal bir kayıt gibi ele alın: ürün veya müşteri verileri gelecekte değişse bile sabit olmalıdır.

Başlangıç olarak başlık temelleri: fatura numarası, düzenleme tarihi (faturadaki tarih), fatura türü (vergi faturası, ihracat, B2B, B2C vb.) ve para birimi. Çoğunlukla INR ile fatura kesilse bile para birimini saklamak ihracat veya çoklu para birimli pazar yerleri için karmaşıklıkları önler.

Numaralandırma takımı insanları yakar. Bir seri veya önek saklayın (örneğin “FY25-INV-”), mali yılı saklayın ve veritabanı seviyesinde benzersizliği zorunlu kılın. Yönetimde seri başına "sonraki numara" kontrollerini saklayın ki iki yönetici aynı numarayı aynı anda veremesin.

Toplamlar açıkça saklanmalı, sadece türetilmiş olmamalı. Ara toplam (vergilendirilebilir değer), toplam vergi, genel toplam ve ayrı bir round-off miktarı saklayın. Satır öğelerinden sonradan yeniden hesaplarsanız, küçük bir kural değişikliği eski faturaların dosyalanan beyannamesiyle eşleşmeyi durdurabilir.

Durumlar gerçek yaşam döngüsünü yansıtmalı ve gerektiğinde kaydı kilitlemeli:

• Taslak (düzenlenebilir)
• Düzenlendi (numara atandı, PDF oluşturuldu)
• İptal edildi (denetim için saklanır, silinmez)
• İade edildi (ödeme geri alındı, kredi notu gerekebilir)
• Kredi notu düzenlendi (ilişkili kredi notu verildi)

Son olarak oluşturulmuş artefakt metadata’sını saklayın: PDF şablon versiyonu, oluşturma zaman damgası ve dosya kimliği. Bir hash isteğe bağlıdır ama PDF’in değiştirilmediğini kanıtlamanız gerektiğinde faydalıdır.

Örnek: bir destek görevlisi bir şablon güncellemesinden sonra PDF’i yeniden oluşturursa, fatura toplamları ve numarası aynı kalmalı; ancak saklanan şablon versiyonu PDF düzeninin neden farklı göründüğünü açıklar.

Ürünler, vergiler ve müşteri detayları için yönetim ekranları

Temiz GST faturası istiyorsanız, fatura ekranında başlamayın. Onu besleyen yönetim sayfalarıyla başlayın. İyi bir GST fatura veri modeli, bu girdiler kontrol altında ve tutarlı olduğunda küçük kalır.

Ürün ana kaydı (SKU'dan HSN/SAC'e)

Ürün ana kaydı çoğu gelecekteki uyuşmazlığın başladığı yerdir, bu yüzden katı tutun. Her SKU’nun tam olarak bir varsayılan HSN (hizmetler için SAC), ayrıca bir varsayılan GST oranı ve yalnızca belirli tarihler için geçerli istisnaları olmalıdır.

Pratik bir ürün ekranı genelde şunları ister:

• SKU ve ürün adı (basılı görünmesini istediğiniz haliyle)
• HSN/SAC kodu, GST oranı ve varsa vergi kategorisi
• Aktif olma tarihleri (değişiklikler eski faturaları yeniden yazmasın diye)
• Fiyat geçersiz kılmaları (özellikle MRP veya kanal bazlı fiyatlar)
• Durum (aktif/pasif) ve devre dışı bırakma nedeni

Vergi ayarları (oranlar ve iç/dış eyalet girişleri)

Bir "hesap makinesi" UI’sinden kaçının. Bunun yerine sisteminizin tutarlı uygulayabileceği girdileri saklayın: oran tabloları, uyguladığınız yer teslimi kuralları ve intra-state vs inter-state kararını nasıl verdiğiniz (genelde tedarikçi eyaleti ile gönderim eyaletinin karşılaştırılmasıyla).

Vergi ekranını: kategori/HSN grubuna göre vergi oranları, geçerli tarihleri ve alıcı geçerli bir GSTIN sağladığında ne yapılacağı gibi girdilere odaklı tutun.

Müşteri ve şirket profili (faturada kim görünecek)

Müşteri ekranı GSTIN ve doğrulama durumunu, ayrıca varsayılan fatura ve gönderim adreslerini yakalamalı. Kullanıcıların serbest metin eyalet girmesine izin vermeyin; "KA" ile "Karnataka"nın iki farklı değer olmaması için kontrollü bir liste kullanın.

Şirket profil ekranınız da aynı derecede önemli: yasal isim, GSTIN, kayıtlı adres ve fatura serisi ayarları (önek, sonraki numara ve mali yıl sınırları). Bunları izinlerle kilitleyin çünkü değişiklikler gelecekteki tüm belgeleri etkiler.

Denetim kaydı temelleri (güven ve izlenebilirlik)

Karmaşık bir sisteme ihtiyacınız yok ama bir iz olmalı. HSN/SAC, GST oranları, fatura serisi veya şirket GSTIN değişikliklerini kim değiştirdiğini, eski ve yeni değeri, zaman damgasını ve nedeniyle birlikte kaydedin.

Koder.ai gibi araçlarla bu ekranları kurarken denetim kaydı ve geçerli tarihleri ilk gün birinci sınıf alanlar olarak ele alın. Erken eklenmesi az maliyetlidir ve finans incelemelerinde saatler kazandırır.

Adım adım: siparişten uyumlu faturaya

Uyumlu bir fatura süslü formatlardan daha çok, doğru anlarda doğru gerçekleri dondurmaktır. GST fatura veri modelinizi bu akış etrafında tasarlarsanız, finans işi basit bir eşleşme olur, haftalık bir soruşturmaya dönüşmez.

1) Müşterinin gerçekten ne satın aldığını dondurun

Vergiyi hesaplamadan önce bir sipariş anlık görüntüsü kilitleyin: ürünler, miktarlar, birim fiyatlar, indirimler, kargo/elleçleme ücretleri, müşteri GSTIN (varsa), fatura ve gönderim adresleri ve yer teslimi sinyalleri. Bu anlık görüntüü ürün fiyatı veya HSN eşleştirmesi sonradan değişse bile değişmemeli.

2) Anlık görüntüyü vergi özellikleri kopyalanmış fatura satırlarına dönüştürün

Vergileri hesaplayın ve anlık görüntüden fatura satırları oluşturun. Her fatura satırı HSN/SAC, vergi oranı(ları), vergilendirilebilir değer ve o anda kullanılan vergi tutarlarını kopyalamalı; sonradan canlı arama yapmasın.

3) Faturayı düzenleyin ve değiştirilemez hale getirin

Fatura numarasını ve düzenleme tarihini atayın, sonra faturayı düzenlenmiş olarak işaretleyin. Bu noktadan sonra fatura kaydında fiyat, vergi oranları, HSN kodları ve adresler gibi finansal alanlarda düzenlemeleri engelleyin. İzin verilecekse, sadece finansal olmayan notlar ve iç etiketlere sınırlayın.

4) Nihai belgeyi üretin ve toplamları saklayın

İhraç edilmiş faturadan PDF/print görünümünü oluşturun, sonra raporlayacağınız nihai toplamları saklayın: vergilendirilebilir toplam, CGST/SGST/IGST toplamları, yuvarlama ve genel toplam. Ek güvenlik isterseniz belge versiyonu veya checksum saklayın ki basılı çıktı saklanan sayılarla eşleştiğini kanıtlayabilesiniz.

5) Değişiklikleri yasal yolla yönetin

İhraç sonrası değişiklikler kurallara göre olmalı, düzeltme yoluyla değil:

• Müşteri fiyat düzeltmesi istiyorsa: orijinal faturaya referans veren bir kredi notu çıkarın (veya debit note).
• Sipariş iptal edildiyse: fatura iptal edilebilir; değilse kredi notu düzenleyin.
• Müşteri adresini düzenlediyse: faturayı yeniden yazmayın; uygun belgeyle düzeltin ve denetim kaydını tutun.
• Kısmi iade: sadece iade edilen satırlar/miktarlar için kredi notu.
• Değişim gönderimi: yeni sipariş/fatura, sessiz düzenleme değil.

Bu akışı yönetim ekranlarınıza (Koder.ai tarzı Planlama Modu, inşa etmeden önce adımları haritalamak için faydalıdır) entegre ederseniz, ekibiniz faturaları hızla oluştururken mutabakatı bozmamış olur.

Mutabakatı zahmetsizleştirin: ödemeler, iadeler ve kayıtlar

Ödemeler siparişte tek bir "ödenmiş/ödenmemiş" bayrağı olarak işlendiğinde mutabakat karışır. Ödemeleri ve iadeleri sipariş ve faturaya işaret eden ayrı kayıtlar olarak tutun ki finans banka mutabakatlarını tarihi değiştirmeden eşleyebilsin.

Ödeme ve iade kayıtlarını ayrı tutun (faturayı düzenlemeyin)

Bir fatura düzenlendikten sonra sabit kalmalıdır. Müşteri kısmen öder veya sonradan iade olursa, bu hareketi ödeme veya iade girişi olarak kaydedin; faturanın toplamını değiştirmeyin.

Mutabakatı kolay yapan minimum alanlar:

• Ödeme: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Tahsilat (opsiyonel): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• İade: refund_id, order_id, invoice_id, payment_id, credit_note_id (verildiyse), gateway_refund_id, amount, reason, refunded_at, status
• Mutabakat anahtarları: order_id, invoice_id, payment_id, refund_id, credit_note_id tekrar kullanılmamalı

Müşteri bir ürünü iade ederse faturayı "azaltmayın." Orijinal faturaya bağlantılı bir kredi notu düzenleyin. Fatura sicili temiz kalır ve iade ödemesi kredi notuna bağlanır.

Finans görünümü ve dışa aktarımlar

Finansa şu soruyu cevaplayan tek bir ekran verin: ne düzenlendi, ne ödendi, ne açık kalıyor ve ne iptal edildi. Yaşlandırma (0-7, 8-30, 31-60, 60+ gün) ve ilgili ödeme/iadelere drill-down içermeli.

Her ay çoğu ekibin ihtiyaç duyduğu dışa aktarımlar:

• Fatura sicili (düzenlenen, iptal edilen, kredi notu düzenlenen)
• Oran ve HSN/SAC bazında vergi özeti (GST fatura veri modelinizi destekler)
• Ödeme vs fatura mutabakatı (invoice_id, ödeme toplamları, bakiye)
• İade ve kredi notu kaydı
• Gateway tahsilat raporu (payout_id ile fatura/ödeme eşlemesi)

Örnek: bir sipariş Rs 10,000 ise, bugün Rs 6,000 ödenmiş ve gelecek hafta Rs 4,000 ödenecek. Fatura Rs 10,000 olarak kalır. Finans görünümü bakiye olarak Rs 4,000 gösterir; ikinci tahsilat gelene kadar açık görünür, sonra tamamen ödenmiş olarak işaretlenir; ihraç edilmiş belge değiştirilmez.

Uyum ve uyuşmazlığa yol açan yaygın tuzaklar

Çoğu GST fatura sorunu “vergi mantığı” değil; kayıt tutma sorunudur: PDF üzerindeki sayılar finans dışa aktarımlarıyla eşleşmez veya fatura aylar sonra açıklanamaz.

İlk tuzak sadece görüntüleme anında GST hesaplamaktır. Her seferinde CGST/SGST/IGST hesaplıyorsanız, bir oran değişikliği, yuvarlama kuralı değişikliği veya hata düzeltmesi sonrası farklı sonuçlar alırsınız. Fatura düzenlenirken kullanılan hesaplanmış vergi dökümünü saklayın; girdileri de saklasanız bile.

İkinci tuzak düzenlenmiş faturaya düzenlemeye izin vermektir. Bir fatura kesinleştiğinde değişiklikler kredi notu veya yeniden düzenleme akışı ile olmalı; aksi halde "müşteri PDF’i ile defterler neden farklı?" tartışmaları çıkar.

GST fatura veri modelinde en sık görülen uyuşmazlık desenleri:

• Yer teslimi eksik veya eyalet kodu yanlış; bu nedenle IGST yerine CGST+SGST uygulanıyor (veya tam tersi).
• Ürün HSN/SAC veya vergi oranı güncellenmiş ve eski siparişler yeni değer kullanılarak yeniden hesaplanmış.
• Vergi saklanmış, ama yuvarlama kuralları UI, PDF üretimi ve CSV dışa aktarımları arasında farklı.
• İndirimler bir yerde vergiden sonra, başka yerde vergiden önce uygulanmış.
• İadeler orijinal faturaya açık bağlantı olmadan negatif satırlar olarak kaydedilmiş.

Hızlı bir örnek: Karnataka’daki bir müşteriye satıyorsunuz, ancak gönderim adresi Maharashtra. Sisteminiz fatura için yer teslimini fatura eyaletinden yanlışlıkla alırsa CGST+SGST tahsil edebilir; ayrıca vergiyi canlı yeniden hesaplarsanız, bu hata sessizce "düzelir" ve finans elinizdeki düzenlenmiş belge ile kayıtların farklı olmasına neden olur.

Yönetim ekranlarını (özel veya Koder.ai gibi bir platformla) oluştururken küçük koruma önlemleri ekleyin: düzenlenmiş faturaları kilitleyin, hesaplanan vergi türünün yanında yer teslimi girdilerini gösterin ve düzenleme anında kullanılan HSN, oran ve yuvarlamanın değişmez bir anlık görüntüsünü tutun.

Hızlı kontrol listesi ve sonraki adımlar

Bir faturayı müşteriye göndermeden veya "düzenlendi" olarak işaretlemeden önce hızlı bir dizi kontrol çalıştırın. Küçük hataların daha sonra büyük mutabakat baş ağrılarına dönüşmesinin yeri burasıdır. GST fatura veri modelinizi inşa ediyorsanız, bu kontrolleri hem doğrulama kurallarınıza hem de yönetim UI’sine yerleştirmek faydalıdır.

Fatura bazlı kontroller (düzenlemeden önce)

• HSN/SAC her satırda mevcut ve gerçekte satılan ürün/hizmetle eşleşiyor.
• GSTIN kuralları doğru uygulanmış (B2B vs B2C) ve fatura ile gönderim detayları çelişmiyor.
• Yer teslimi saklanmış ve vergi bölmesi mantıklı (CGST/SGST vs IGST).
• Toplamlar tam olarak toplanıyor: vergilendirilebilir değer, her vergi bileşeni, yuvarlama ve genel toplam.
• Düzenlendikten sonra fatura kilitleniyor (sessiz düzenleme yok). Düzeltmeler kredi notu veya iptal akışıyla yapılmalı; tarihçe yeniden yazılmamalı.

Basit bir örnek: müşteri ödeme sonrası gönderim adresini güncelliyor ve eyalet değişiyor. Aynı fatura numarasıyla yeni vergiyle tekrar düzenlerseniz, sicil ve ödeme kayıtları artık eşleşmez. Daha güvenli yaklaşım orijinal faturayı değişmez tutmak ve ayarlama belgesi üretmektir.

Veri + iş akışı kontrolleri (finansı temiz tutmak için)

• Fatura numaralandırması benzersiz, politikanıza uygun ardışık ve sadece "düzenleme" anında üretiliyor.
• Kullandığınız hesaplanmış vergi tutarlarını saklayın, sadece vergi oranlarını değil; böylece oranlar sonradan değişse bile raporlar sabit kalır.
• Net durum adımları: taslak -> düzenlendi -> iptal edildi (ve ayrı kredi notu belgeleri).
• Döneme göre mutabakat: fatura sicili toplamları yakalanmış ödemeler, işlenmiş iadeler ve açık alacaklarla tutarlı olmalı.
• Denetim alanları her zaman mevcut: oluşturandı, düzenlendi tarihi ve iptal/kredi notu sebepleri.

Sonraki adımlar: önce ekranları ve doğrulamaları uygulayın, sonra yinelemeye gidin. Koder.ai’de Planlama Modu ile kayıtları ve yönetim ekranlarını (HSN/SAC eşleştirmesiyle ürünler, müşteri/GSTIN detayları, vergi kuralları ve faturalar) çizin. Uygulamayı üretin, birkaç gerçek siparişi uçtan uca test edin, sonra anlık görüntüler ve rollback ile iş akışını güvenli şekilde rafine edin. Daha derin özelleştirme veya inceleme gerektiğinde, kaynak kodu dışa aktarın ve normal geliştirme sürecinizle ilerleyin.