Fatura yakalama, onay yönlendirme, ödeme durumu takibi, hatırlatmalar ve güvenli raporlama içeren tedarikçi fatura web uygulaması oluşturma adım adım planı.
Araçları seçmeden veya ekran çizmeden önce hangi problemi kimin için çözdüğünüzü netleştirin. Bir tedarikçi fatura uygulaması, günlük kimlerin kullandığına göre çok farklı ihtiyaçlara hizmet edebilir.
Öncelikle temel kullanıcı gruplarını adlandırın:
MVP'nizi genellikle AP + onaycılar etrafında tasarlayın; bu en küçük kullanıcı seti değeri açar.
En çok önem taşıyan üç sonucu seçin. Yaygın tercihler:
Bu hedefleri yazın; kabul kriterleriniz bunlar olacak.
Ekipler "ödendi" ile farklı şeyler kastedebilir. Resmi durumları erken belirleyin, örneğin:
Ayrıca bir durum değişikliğini neyin tetikleyeceğini tanımlayın (onay, muhasebeye dışa aktarma, banka teyidi vb.).
Bir MVP için hedef: fatura alımı, temel doğrulama, onay yönlendirmesi, durum takibi ve basit raporlama. Gelişmiş ögeleri (OCR, tedarikçi portalı, derin ERP senkronu, karmaşık istisnalar) "sonra" listesine açık bir gerekçe ile koyun.
Ekranları veya tabloları inşa etmeden önce, bir faturanın şirketinizde aldığı gerçek yolu yazın—geliş anından ödemenin doğrulanmasına kadar. Bu, uygulamanızın durumları, bildirimleri ve raporları için tek gerçek kaynağı olur.
Faturaların nereden girdiğini (e-posta gelen kutusu, tedarikçi portalı, kağıt tarama, çalışan yüklemesi) ve sonraki dokunma noktalarını kaydedin. AP ve en az bir onaycı ile görüşün; genellikle desteklenmesi veya bilerek kaldırılması gereken resmi olmayan adımlar (yan e-postalar, tablo kontrolleri) bulursunuz.
Çoğu fatura→ödeme akışında birkaç zorunlu kapı vardır:
Her kontrol noktasını bir durum değişikliği olarak yazın; açık bir sahibi ve giriş/çıkış tanımlayın. Örnek: “AP fatura kodlar → fatura ‘Onay için hazır’ olur → onaycı onaylar veya değişiklik ister.”
Mutlu yolu bozacak kenar durumlarını listeleyin:
Her adım için zaman beklentileri belirleyin (ör. onay 3 iş günü içinde, ödeme net vadeye uygun) ve kaçırıldığında ne olacak: hatırlatma, bir yöneticiyi bilgilendirme veya otomatik yeniden yönlendirme. Bu kurallar daha sonra bildirim ve raporlama tasarımınızı yönlendirir.
Açık bir veri modeli, faturalar yüklemeden ödemeye kadar hareket ederken uygulamanızın tutarlı kalmasını sağlar. Başlangıçta büyütebileceğiniz küçük bir varlık seti ile başlayın.
En azından bunları ayrı tablolar/collection'lar olarak modelleyin:
Para alanlarını yuvarlama hatalarını önlemek için tam sayılar (ör. kuruş) olarak tutun.
Gönderim için bunları zorunlu yapın: tedarikçi, fatura numarası, tarih, para birimi ve toplam. Süreciniz bağımlıysa vade tarihi, vergi ve PO numarası ekleyin.
Herkesin aynı gerçeği görmesi için faturada tek bir durum tanımlayın:
(vendor_id, invoice_number) üzerinde benzersiz kısıtlama ekleyin. Bu, çift girişe karşı en basit ve etkili korumadır—özellikle daha sonra fatura yükleme ve OCR eklediğinizde.
Erişim kontrolü, fatura uygulamalarının ya düzenli kalmasını ya da kaosa sürüklenmesini belirler. Küçük bir rol seti tanımlayarak ve her rolün neler yapabildiğini açıkça belirleyerek başlayın.
İzinleri ekran bazlı değil eylem bazlı tutun: view, create/upload, edit, approve, override, export, manage settings. Örneğin, birçok ekip AP Clerk'lerin başlık alanlarını (tedarikçi, tutar, vade) düzenlemesine izin verir ama banka detayları veya vergi kimliklerini düzenlemelerine izin vermez.
Birden fazla iş birimi aynı sistemi paylaşıyorsa, erişimi tedarikçi veya tedarikçi grubuna göre kısıtlayın. Tipik kurallar:
Bu, yanlış veri ifşasını önler ve gelen kutuların odaklı kalmasını sağlar.
Delegasyonu başlangıç/bitiş tarihleri ve bir denetim notu ile destekleyin ("X adına Delege tarafından onaylandı"). Kim kimin yerine baktığını gösteren basit bir sayfa ekleyin ve bu delegasyonların AP Admin'ler (veya yöneticiler) tarafından oluşturulmasını zorunlu kılın ki kötüye kullanım önlensin.
İyi bir AP uygulaması, birisi ilk açtığında sezgisel hissettirmeli. İnsanların nasıl çalıştığına uyan küçük bir ekran seti hedefleyin: faturaları bul, ne olduğunu anla, bekleyenleri onayla ve vadesi gelenleri gözden geçir.
Varsayılan görünümü, hızlı tarama ve hızlı kararlar için bir tablo yapın.
Durum, tedarikçi ve vade tarihi için filtreler; fatura numarası ve tutarla arama ekleyin. "Sahip ata", "Bilgi isteği" veya "Ödendi olarak işaretle" gibi toplu işlemler ekleyin (izin kontrolleri ile). Haftalık incelemeler için "7 gün içinde vadesi gelen" gibi kaydedilmiş filtre tutun.
Detay ekranı şu soruyu cevaplamalı: Bu fatura nedir, nerede takılmış ve sonraki adım nedir?
Açık bir zaman çizelgesi (alındı → doğrulandı → onaylandı → planlandı → ödendi), bağlam için bir notlar dizisi ve ekler (orijinal PDF, e-postalar, destekleyici belgeler) ekleyin. Birincil eylemleri (onayla, reddet, değişiklik iste) üstte koyun ki gizlenmesin.
Sadece işlem gerektirenleri gösteren özel bir kuyruk oluşturun. Yorumla onayla/reddet desteği, ayrıca ekstra tıklama gerektirmemek için hızlı "ana alanları görüntüle" paneli sağlayın. Yöneticilerin kısa aralıklarla çalışabilmesi için listeden geri dönüş kolay olsun.
"Ne vadesi geldi ve ne gecikti?" sorusuna odaklanan basitleştirilmiş bir görünüm sunun. Vade tarihine göre gruplayın (geçmiş, bu hafta, gelecek hafta) ve durumları görsel olarak ayırt edilebilir yapın. Her satırı takip için fatura detayına bağlayın.
Gezinmeyi tutarlı tutun: sol menüde Faturalar, Onaylar, Ödemeler ve Raporlar; detay sayfalarında breadcrumb'lar.
Fatura yakalama, dağınık gerçek dünya girdilerinin sisteme girdiği yerdir; insanlara hoşgörülü, ama veri kalitesine karşı sıkı olun. Birkaç güvenilir giriş yoluyla başlayın, sonra otomasyonu katmanlayın.
Uygulamaya fatura sokmak için birden fazla yol destekleyin:
İlk sürüm basit tutulsun: her giriş yöntemi aynı sonucu üretmeli — bir taslak fatura kaydı ve eklenmiş kaynak dosya.
En azından PDF ve yaygın görüntü formatlarını (JPG/PNG) kabul edin. Tedarikçiler yapılandırılmış dosyalar gönderiyorsa, ayrı bir akış olarak CSV içe aktarımı ekleyin; şablon ve açık hata mesajları sağlayın.
Orijinal dosyayı değiştirmeden saklayın ki finans her zaman kaynağa başvurabilsin.
Kaydetme ve onaya gönderme aşamasında doğrulayın:
OCR PDF'lerden/görsellerden alanlar önerse bile bunu bir öneri olarak ele alın. Güven seviyesi göstergeleri gösterin ve çıkarılan değerler onaylanmadan fatura ilerlemesin.
Onaylar, fatura takibini "bir liste" olmaktan gerçek bir AP sürecine dönüştürür. Amaç basit: doğru kişiler doğru faturaları inceler, kararlar kaydedilir ve onay sonrası değişiklikler kontrol altında tutulur.
Teknik olmayan kullanıcıların kolayca açıklayabileceği bir kural motoru ile başlayın. Yaygın yönlendirme kuralları:
İlk sürümü öngörülebilir tutun: adım başına birincil onaycı ve açık bir sonraki eylem.
Her kararın değiştirilemez bir log girişi oluşturmasını sağlayın: fatura ID, adım adı, aktör, eylem (onaylandı/reddedildi/gönderildi), zaman damgası ve yorum. Bu logu düzenlenebilir fatura alanlarından ayrı tutun ki "kim neyi ne zaman onayladı" her zaman cevaplanabilsin.
Faturalar genellikle düzeltme gerektirir (PO eksik, hatalı kodlama, çift kayıt). "AP'ye geri gönder" desteği sağlayın; yeniden işleme nedenleri zorunlu olsun ve opsiyonel ek dosya ekleme imkanı verin. Reddedilenler için standart nedenler (çift, yanlış tutar, uyumsuz) + serbest metin notu kaydedin.
Bir fatura onaylandıktan sonra düzenlemeler kısıtlanmalı. Pratik iki seçenek:
Bu, sessiz düzenlemeleri önler ve onayların anlamlı kalmasını sağlar.
Faturalar onaylandıktan sonra uygulama "kim imzalayacak?" yerine "ödeme gerçekliği nedir?" moduna geçmeli. Ödemeleri tek bir onay kutusu gibi değil, birinci sınıf kayıtlar olarak ele alın.
Her fatura için bir veya daha fazla ödeme girdisi saklayın:
Bu, serbest metin zorunluluğu olmadan denetim-dostu bir hikaye sağlar.
Ödemeleri birden çoğa ilişki olarak modelleyin: Invoice → Payments. Fatura toplamlarını şöyle hesaplayın:
Durum gerçeği yansıtmalı: Unpaid, Partially paid, Paid, Overpaid (nadir olsa da kredi veya çift ödeme durumları ortaya çıkar).
Planlanmış ödemeler için bir Scheduled durumu ekleyin (beklenen mutabakat tarihi opsiyonel). Para gerçekten çıkınca durumu Paid yapın ve nihai zaman damgası ve referans ID'yi kaydedin.
Ödemeleri harici kanıtlara bağlayabilecek eşleme iş akışları oluşturun:
Bildirimler düzenli bir kuyruk ile gecikmiş faturalar arasındaki farktır. Bunları bir eklenti değil iş akışı özelliği olarak ele alın.
Önce yaklaşan vadeler, sonra gecikmeler için iki tür hatırlatmayla başlayın. Basit bir varsayılan işe yarar (ör. vade 7 gün kala, 1 gün kala, sonra her 3 günde bir gecikme bildirimleri), ama şirket bazında yapılandırılabilir olsun.
Hatırlatmalar Paid, Canceled veya On Hold faturalarını atlamalı ve bir fatura uyuşmazlıkta ise duraklatılmalıdır.
Bir fatura onay kuyruğuna girdiğinde onaycılara ilk bildirim gönderin; tanımlı SLA içinde hala bekliyorsa yeniden hatırlatın.
Eskalasyonlar açık olmalı: örn. 48 saat içinde işlem yoksa bir sonraki onaycıya veya finans adminine bildirin ve faturayı UI'da görünür kılmak için Escalated olarak işaretleyin.
Kullanıcılara kontrol verin:
Uygulama içi uyarılar için bildirim merkezi ve rozet sayacı genellikle yeterlidir.
Özetler gürültüyü azaltır ama sorumluluğu tutar. Kısa bir özet ekleyin: kullanıcının bekleyen faturaları, vadesi yaklaşanlar ve eskale edilenler. Filtrelenmiş görünümlere doğrudan bağlantı verin (ör. Raporlar > Onay Bekleyenler, Vadesi Geçenler).
Son olarak, gönderilen her bildirimi (ve kullanıcının erteleme/abonelik iptali eylemlerini) loglayın ki sorun giderme ve denetimler mümkün olsun.
Entegrasyonlar zaman kazandırır ama karmaşıklık getirir (kimlik doğrulama, hız sınırları, karışık veriler). Çekirdeğiniz sağlam olana kadar bunları opsiyonel tutun. Temiz dışa aktarmalarla bile iyi bir MVP değer sağlayabilir.
İlk olarak güvenilir bir CSV dışa aktarma gönderin—tarih, tedarikçi, durum veya ödeme partisi ile filtrelenebilir. Yeniden dışa aktarımın başka bir sistemde tekrar yaratmaması için sabit ID'ler ekleyin.
Örnek alanlar: invoice_number, vendor_name, invoice_date, due_date, total_amount, currency, approval_status, payment_status, internal_invoice_id.
Zaten bir API'niz varsa, JSON dışa aktarma uç noktası hafif otomasyon için faydalıdır.
QuickBooks/Xero/NetSuite/SAP gibi bağlayıcılara geçmeden önce şunu yazın:
Küçük bir "Entegrasyon Ayarları" ekranı yardımcı olur: dış ID'leri, varsayılan hesapları, vergi işleyişini ve dışa aktarma kurallarını saklayın. Ayarlardan erişilebilir olsun.
İki yönlü senkron eklediğinizde kısmi hatalar bekleyin. Yeniden deneme kuyruğu kullanın ve insanlara ne olduğunu gösterin:
Her senkron denemesi için zaman damgası ve payload özeti ile log tutun ki finans tahmin yürütmek zorunda kalmasın.
Güvenlik, hesaplar ödenecek alanında "iyi olur" değil zorunludur. Faturalar banka detayları, vergi ID'leri, fiyatlandırma ve iç onay notları içerir—sızdırılırsa ciddi zarar verir.
Denetim günlüğünü hata ayıklama aracı değil bir birinci sınıf özellik olarak ele alın. Aşağıdaki anlar için değiştirilemez event'ler kaydedin: fatura gönderimi, OCR/ithalat sonuçları, alan düzenlemeleri, onay kararları, yeniden atamalar, açılan/çözülen istisnalar ve ödeme güncellemeleri.
Kullanışlı bir denetim girdisi genelde şunu içerir: kim yaptı, ne değişti (eski → yeni), ne zaman oldu ve nereden kaynaklandı (UI, API, entegrasyon). Append-only saklayın ki sonradan yeniden yazılamasın.
Tüm trafiğe TLS kullanın (iç servis çağrıları dahil). Hassas veriyi veritabanında ve obje depolamada (fatura PDF/görseller) şifreleyin. Banka detayları veya vergi kimlikleri saklıyorsanız alan düzeyinde şifreleme düşünün ki bir veritabanı snapshot'u ele geçse bile en kritik değerler korunmuş olsun.
Ayrıca kimlerin orijinal fatura dosyalarını indirebileceğini sınırlayın; genellikle dosya erişimine ihtiyacı olanlar, sadece durum görünürlüğüne ihtiyacı olanlardan daha azdır.
Güçlü kimlik doğrulama ile başlayın (e-posta/şifre güçlü hash, veya müşteri SSO beklentisi varsa SSO). Oturum kontrolleri: kısa ömürlü oturumlar, secure cookie, CSRF koruması ve admin'ler için opsiyonel MFA ekleyin.
Onaylanmış faturaları düzenleme, ödeme durumunu değiştirme veya veri dışa aktarma gibi işlemler için asgari ayrıcalık prensibini (least privilege) uygulayın.
Faturaları, logları ve ekleri ne kadar süreyle saklayacağınızı ve silme taleplerini nasıl işleyeceğinizi tanımlayın. Düzenli yedekler ve geri yükleme testleri yapın ki hatalar veya kesintiler sonrası kurtarma öngörülebilir olsun.
Raporlama, günlük fatura güncellemelerini finans için netliğe dönüştürür. Başlangıçta ay sonu kapanışı sırasında sorulan sorulara cevap verecek birkaç yüksek sinyal görünümü ile başlayın.
İlk aşamada 3–4 temel rapor yapın, sonra gerçek kullanım bazında genişletin:
"Bu hafta vadesi gelen", "$10k üstü onaysız" ve "PO eksik" gibi kaydedilmiş filtreler ekleyin. Her tablo CSV/XLSX dışa aktarılabilir olsun ve sütunlar tutarlı kalsın ki muhasebeciler her ay aynı şablonları kullanabilsin.
Grafikleri basit tutun: durum sayıları, yaklaşan vade toplamları ve küçük bir "riskte" paneli (vadesi geçmiş + yüksek değerde). Amaç hızlı triage, detaylı analitik değil.
Raporların rol tabanlı erişim kurallarına uymasını sağlayın: kullanıcılar sadece kendi departman/firma verilerini görmeli; dışa aktarmalar da aynı kuralları uygulamalı ki veri sızıntısı olmasın.
Bir tedarikçi fatura uygulaması güvenilir olmak için egzotik bir düzene gerekmez. Teslim hızına, sürdürülebilirliğe ve işe alıma öncelik verin—gerektikçe karmaşıklık ekleyin.
Ekibinizin destekleyebileceği, kutularıyla gelen popüler seçeneklerden birini tercih edin:
Bunların hiçbiri fatura yakalama, onaylar ve ödeme durum takibini rahatça yönetir.
Eğer ilk sürümü daha da hızlandırmak isterseniz, Koder.ai gibi sohbet destekli platformlar React tabanlı UI ve backend iş akışı kurmada hız kazandırır—sonra onay kuralları, roller ve raporlarla yineleyebilirsiniz. Hazır olduğunuzda kaynak kodu dışa aktarabilirsiniz.
Başlangıçta bir web uygulaması + bir veritabanı (ör. Postgres) ile başlayın. UI, API ve veritabanı arasında temiz ayrım yapın ama hepsini tek dağıtılabilir hizmette tutun. Gerçek ölçekleme baskıları çıkınca mikroservislere ayırın.
OCR, banka/ERP dosyası ithalatı, hatırlatıcı gönderimleri ve PDF üretimleri yavaş veya öngörülemez olabilir. Bunları iş kuyruğu (Sidekiq/Celery/BullMQ) üzerinden çalıştırın ki uygulama duyarlı kalsın ve hatalar güvenle yeniden denensin.
Faturalar ve fişler merkezi. Dosyaları bulut obje depolama (S3 uyumlu) içinde saklayın. Ek olarak:
Bu yaklaşım, sistemi aşırı mühendisleştirmeden güvenilir kılar.
Bir tedarikçi fatura uygulaması yalnızca "basit" hissediyorsa, bunun en hızlı yolu testi ve dağıtımı ürün özelliği gibi ele almaktır.
Sonuçları değiştiren kurallara odaklanın:
Gerçek iş akışını taklit eden birkaç uçtan uca test ekleyin: fatura yükle, onaya yönlendir, ödeme durumunu güncelle ve denetim izini doğrula.
Demo ve QA için örnek veri ve scriptler ekleyin: birkaç tedarikçi, farklı durumlarda faturalar ve birkaç “problemli” fatura (PO eksik, çift numara, tutar uyuşmazlığı). Bu, destek, satış ve QA'nın üretime dokunmadan sorunları yeniden üretmesini sağlar.
Dağıtımı baştan staging + production, environment variable'lar ve logging ile planlayın. Staging production ayarlarını yansıtmalı ki onay akışı sürüm öncesi aynı davranış göster
Staging ortamı üretim ile benzer olsun ki onay yönlendirmesi değişikliklerini güvenle test edebilesiniz.
Eğer Koder.ai gibi bir platform kullanıyorsanız, snapshot ve rollback özellikleri onay yönlendirmesi değişikliklerini güvenle test etmeye ve gerekirse hızlı geri almaya yardımcı olur.
Adım adım yayın yapın: önce bir MVP (yakalama, onaylar, ödeme durumu takibi) yayınlayın; sonra ERP/muhasebe entegrasyonları ve en sonunda hatırlatmalar ve eskalasyonlar gibi gelişmiş otomasyonları ekleyin. Her sürümü tek bir ölçülebilir iyileşmeye bağlayın (daha az geciken ödeme, daha az istisna, daha hızlı onaylar).
AP personeli ve onaycılar (AP staff + approvers) ile başlayın. Bu ikili temel döngüyü açar: faturalar yakalanır, doğrulanır, onaylanır ve ödemeye kadar izlenir.
İş akışı kararlı hale gelip benimsenme sağlandıktan sonra finans yöneticilerini, raporlama kullanıcılarını ve tedarikçi portalını ekleyin.
3 ölçülebilir çıktıyı seçin ve kabul kriteri olarak kullanın, örneğin:
Bir özellik bu hedeflerden birini geliştirmiyorsa, "sonra" listesine alın.
Tek resmi durum zinciri ve her değişikliği tetikleyen koşulu yazın, örneğin:
"İşlendi" gibi belirsiz durumlardan kaçının veya ne anlama geldiğini kesin olarak tanımlayın.
Pratikte en az şu tablolar/collection'lar olmalı:
Para alanlarını tam sayı (kuruş) olarak tutun (yuvarlama hatalarını önlemek için) ve orijinal fatura dosyasını değiştirmeden saklayın.
(vendor_id, invoice_number) üzerinde benzersiz kısıtlama uygulayın. Gerekirse, numaralandırmayı tekrar kullanan tedarikçiler için miktar/tarih penceresi gibi ikincil kontroller ekleyin.
UI'da "muhtemel kopya" uyarısı gösterin ve eşleşen faturaların bağlantılarını verin, böylece AP hızlıca çözebilir.
Küçük bir rol seti ve eylem bazlı izinler kullanın:
İzinleri view, edit, approve, export gibi fiillere bağlayın.
Delegasyonu şu şekilde destekleyin:
Ayrıca aktif delegasyonları gösteren basit bir sayfa sağlayın ki kapsama görünür olsun.
Doğrulamayı kaydetme ve gönderme aşamalarında kapı olarak ele alın:
Tüm giriş yöntemleri (manuel, yükleme, e-posta) aynı sonucu üretmeli: .
Ödemeleri birincil kayıtlar olarak saklayın:
Hesapla:
Bu, kısmi ödemeleri ve mutabakatı basitleştirir ve "onay kutusu muhasebesi"nin önüne geçer.
İlk entegrasyonlar için MVP-dostu yaklaşım:
İki yönlü senkronu, iç iş akışı güvenilir ve denetlenebilir hale geldikten sonra ekleyin.
