21 Haz 2025·8 dk
Dijital Makbuzlar ve Harcamalar İçin Mobil Uygulama Nasıl Yapılır
Makbuzları yakalayan, OCR ile verileri çıkaran, giderleri kategorize eden ve muhasebe araçlarına dışa aktaran bir mobil uygulama oluşturmak için pratik rehber.
Makbuzları yakalayan, OCR ile verileri çıkaran, giderleri kategorize eden ve muhasebe araçlarına dışa aktaran bir mobil uygulama oluşturmak için pratik rehber.
Özellikleri veya ekran tasarımlarını seçmeden önce çözdüğünüz sorunu netleştirin. “Giderleri takip etme” çok genel; gerçek acı genelde kaybolan makbuzlar, yorucu elle giriş ve yavaş geri ödeme süreçleri şeklindedir.
Her kararda test edebileceğiniz tek cümlelik bir problem açıklaması yazın:
“Kullanıcıların saniyeler içinde makbuz yakalamasına, bunu otomatik olarak eksiksiz bir harcamaya dönüştürmesine ve eksik detaylar için peşinde koşmadan gönderme yapmasına yardım edin.”
Bu, kapsamı kontrol altında tutar ve uygulamanızın genel bir finans aracına dönüşmesini engeller.
Çoğu dijital makbuz uygulaması birden fazla kitleye hizmet eder:
İlk olarak birincil kullanıcıyı seçin (genellikle çalışanlar veya serbest çalışanlar) ve finans-ekibi deneyimini temel iş akışı yerine bir “inceleme katmanı” olarak tasarlayın.
İlk sürümü küçük bir sonuç kümesine odaklayın:
Gerçek değeri yansıtan birkaç metrik üzerinde anlaşın:
Hedef, kullanıcılar, işler ve metrikler net olduğunda, geri kalan yapım kararları tahmin yerine kontrol edilebilir ticaret-off’lara dönüşür.
Özellikleri veya ekranları seçmeden önce uygulamanızın desteklemesi gereken uçtan uca yolu yazın. Açık bir iş akışı “makbuz tarama”nın bağlantısız araç yığını olmasını engeller.
En azından tam yolu haritalayın:
Her adım için, kullanıcının ne gördüğünü, hangi verinin oluşturulduğunu ve nelerin otomatik yapılması gerektiğini not edin (ör. toplamların hesaplanması, para biriminin normalize edilmesi, vergilerin tespiti).
Ana giriş noktalarını belirleyin; çünkü bunlar UI’yi ve backend varsayımlarınızı şekillendirir:
MVP’niz için bir “varsayılan başlangıç” seçin, sonra diğer yolları ikincil olarak destekleyin.
Kim ne yapabilir netleştirin:
Devir kurallarını erken tasarlayın (ör. bir gider ne zaman salt okunur olur, kim üzerine yazabilir ve değişiklikler nasıl kaydedilir).
İş akışınız kullanıcıları tıkamayan net yollar içermeli: iade/geri ödeme, bölünmüş faturalar, çoklu para birimi, bahşişler, eksik makbuzlar ve günlük ödenekler gibi durumları belgeleyin. Bu özellikleri v1’de otomatikleştirmeseniz bile, bloke etmeyecek açık bir yol olmalı.
İyi bir veri modeli her şeyi kolaylaştırır: daha hızlı arama, daha az manuel düzenleme ve muhasebe için temiz dışa aktarmalar. Ana fikir, kullanıcının yakaladığı (orijinal makbuz dosyası) ile uygulamanızın anladığı (filtreleyip raporlayabileceğiniz normalize alanlar) şeyleri ayırmaktır.
Makbuzu delil olarak (dosya + çıkarım sonuçları) ve Gideri ise geri ödeme, politika kontrolleri ve raporlama için kullanılan iş kaydı olarak ele alın.
Tek bir gider bir makbuza, birden fazla makbuza (bölünmüş ödemeler) veya hiçbir makbuza (manuel giriş) sahip olabilir; bu esnek ilişkiyi modelleyin.
Büyüme için capture_method alanı planlayın:
Bu alan aynı zamanda kalite sorunlarını gidermenize ve OCR/parsing ayarlarını zamanla iyileştirmenize yardımcı olur.
En azından Gider üzerinde şu alanları saklayın (OCR’den gelse bile): tüccar, tarih, toplam, vergi, para birimi, ödeme yöntemi. Hem ham metni hem de normalize edilmiş değerleri (ör. ISO para birimi kodları, ayrıştırılmış tarihler) saklayın ki düzenlemeler geri alınabilir ve açıklanabilir olsun.
Ayrıca şu meta verileri saklayın:
merchant_normalized (tutarlı arama için)transaction_last4 veya tokenize edilmiş kart referansı (çoğaltmaları önlemek için)timezone ve locale (tarih/vergileri doğru ayrıştırmak için)Ham görüntü/PDF’yi, çıkarılmış/normalize edilmiş veriden ayrı tutun. Bu, daha iyi OCR için yeniden işlemeye izin verirken orijinali kaybetmemenizi sağlar.
Kullanıcıların gerçekten sordukları sorulara göre arama tasarlayın:
Bu alanları erken indeksleyin; bu, “sonsuz kaydırma” ile “anında cevap” arasındaki farktır.
Şemaya saklama kontrollerini dahil edin, sonradan eklemeyin:
Bu parçalarla uygulamanız kişisel yakalamadan şirket çapında uyuma kadar büyüyebilir.
Makbuz yakalama, kullanıcıların uygulamanızın zahmetsiz mi yoksa sinir bozucu mu olduğuna karar verdiği andır. Kamerayı bir “fotoğraf aracı” değil, bir “tarayıcı” gibi ele alın: varsayılan yol hızlı, kılavuzlu ve hoşgörülü olsun.
Canlı kenar algılama ve otomatik kırpma kullanın; kullanıcıların mükemmel şekilde çerçevelemesine gerek kalmasın. İnce, eylem odaklı ipuçları ekleyin (“Daha yakınlaşın”, “Gölgeden kaçının”, “Sabit tutun”) ve parlama olduğunda uyarı gösterin.
Otel faturaları ve uzun madde listeleri için çok sayfalı yakalama önemlidir. Kullanıcıların tek bir akışta sayfa eklemeye devam etmesine izin verin, sonra bir kez onaylasınlar.
Biraz ön işlem genellikle OCR motoru değiştirmekten daha fazla doğruluk artırır:
Bu ön işlem hattını tutarlı çalıştırın ki OCR öngörülebilir giriş görsün.
Cihazda OCR hız, çevrimdışı kullanım ve gizlilik için iyidir. Bulut OCR ise kötü görüntüler ve karmaşık düzenler için daha iyi olabilir. Pratik yaklaşım hibrittir:
Yüklemeyi tetikleyen durumlar hakkında şeffaf olun ve kullanıcılara kontrol verin.
İlk olarak yüksek değerli alanlara odaklanın: tüccar, tarih, para birimi, toplam, vergi ve bahşiş. Satır öğeleri faydalı ama çok daha zordur—bunları bir geliştirme olarak görün.
Her alan için bir güven skoru saklayın, sadece makbuz düzeyinde değil. Bu, yalnızca dikkat gerektirenleri vurgulamanıza izin verir (ör. “Toplam belirsiz”).
Taradıktan sonra, tek dokunuşla düzeltmeler yapabilecekleri hızlı bir inceleme ekranı gösterin (toplamı düzenle, tarihi ayarla, tüccarı değiştir). Yapılan düzeltmeleri eğitim sinyalleri olarak kaydedin: kullanıcılar sıkça düzeltme yapıyorsa çıkarım zamanla iyileşir.
İyi yakalama işin yarısıdır. Giderlerin temiz kalması (ve geri-gönderi azaltılması) için uygulamanızın hızlı kategorilendirme, esnek meta alanlar ve güçlü çoğaltma karşıtı önlemler sunması gerekir.
Kullanıcıların anlayabileceği belirleyici kurallarla başlayın. Örnekler: “Uber → Ulaşım”, “Starbucks → Yemek”, “USD + havalimanı tüccar kodları → Seyahat.” Kurallar öngörülebilir, denetlenebilir ve çevrimdışı çalışabilir.
Bunun üzerine ML tabanlı öneriler ekleyin (isteğe bağlı) ama kontrolü kullanıcıya bırakın. UI net olsun: önerilen kategoriyi, neden önerildiğini gösterin (örn. “tüccara göre”) ve kullanıcıların tek dokunuşla geçersiz kılmasına izin verin.
Bir diğer hızlandırıcı kullanıcı favorileri: tüccar başına son kullanılan kategoriler, sabitlenen kategoriler ve “bu proje için son kullanılan.” Gerçek dünyada bunlar sıklıkla “AI”dan daha çok işe yarar.
Çoğu organizasyon kategori dışında fazlasına ihtiyaç duyar. Proje, maliyet merkezi, müşteri ve politika etiketi (örn. “faturalandırılabilir”, “kişisel”, “tekrarlı”) gibi özel alanlar oluşturun. Workspace başına yapılandırılabilir ve politika gereksinimine göre zorunlu/opsiyonel yapılabilir.
Bölünmeler yaygındır: bir otel faturası projelere bölünür veya grup yemeği katılımcılara göre paylaşılır.
Bir gideri farklı kategoriler, projeler veya katılımcılarla birden çok satıra bölme desteği verin. Ortak ödemeler için “ödeyen”i işaretleme ve payları tahsis etme imkanı sağlayın—tek bir temel makbuzu korurken.
Kaydetme ve gönderme anında politika kontrolleri çalıştırın:
Çoğaltma için birden çok sinyali birleştirin:
Olası çoğaltma tespit ettiğinizde hemen engellemeyin—yan yana karşılaştırma ve “Her ikisini de tut” gibi güvenli bir seçenek sunun.
Bir makbuz-gider uygulamasının başarısı/gündelik hissi güvenilirliğe dayanır: insanlar bodrum kafe’sinde bile makbuz yakalayabiliyor mu, kaybolmadan saklanıyor mu ve finans istediğinde bulunabiliyor mu? Erken yapılan mimari kararlar günlük hisse yön verir.
MVP için teslim hızını mı yoksa sınıfının en iyisi yerel deneyimi mi hedeflediğinize karar verin.
Yakalama bağlantının zayıf olduğu yerlerde gerçekleşir. Telefonu verinin ilk kaydedildiği yer olarak kabul edin.
Yerel kuyruk kullanın: kullanıcı bir makbuz gönderdiğinde, görüntü + taslak gideri yerelde saklayın, “beklemede” olarak işaretleyin ve sonra senkronize edin. Yeniden denemeler (üstel geri çekilme) planlayın ve senkron çakışlarını nasıl yöneteceğinizi tanımlayın (örn. “sunucu kazanır”, “en yeni kazanır” veya nadir durumlarda kullanıcıya sor).
Çoğu ekip backend gerektirir:
Bu servisleri modüler tutmak, OCR sağlayıcılarını değiştirmeyi veya parsing’i iyileştirmeyi uygulamayı yeniden yazmadan yapmanızı sağlar.
Kullanıcılar “Uber”i aradığında veya “Mart’taki Yemekler”i filtrelediğinde indeksler önemlidir. Normalize tüccar adları, tarihler, toplamlar, para birimleri, kategoriler ve etiketleri saklayın. Yaygın sorgular için indeksler ekleyin (tarih aralığı, tüccar, kategori, durum) ve eğer “makbuz depolama ve arama” temel sözünüzse hafif bir arama katmanı düşünün.
Desteklenen yerlerde arka plan senkronizasyonu kullanın ama buna bağlı kalmayın. Uygulama içi senkron durumunu açık gösterin ve “OCR hazır”, “makbuz reddedildi” veya “gider onaylandı” gibi olaylar için push bildirimleri düşünün ki kullanıcılar sürekli uygulamayı açmak zorunda kalmasın.
Akışı (yakalama → OCR → inceleme → gönderim) hızlıca doğrulamak istiyorsanız, tam özel bir yapı kurmadan önce bir prototip/araç kullanmak faydalı olabilir: örneğin Koder.ai hızlı prototipleme, web paneli ve backend hizmetlerini chat odaklı bir yaklaşımla oluşturmak için yardımcı olabilir. Bu özellikle React yönetici paneli ve Go + PostgreSQL API gibi destekleyici bileşenleri hızla test ederken kodunuzu sahiplenmenize yardımcı olur.
Makbuzlar ve giderler hassas kişisel ve şirket bilgileri içerir: isimler, kart parçaları, adresler, seyahat desenleri ve bazen vergi kimlikleri. Güvenlik ve gizliliği ürün özelliği olarak ele alın.
Uygulamanın dağıtım şekline uygun bir giriş yöntemi seçin:
Tüm ağ çağruları için TLS kullanın ve hassas verileri sunucuda şifreleyin. Makbuzlar genelde görüntü/PDF olarak saklandığından, medya depolamayı veritabanından ayrı ve güvenli tutun (özel bucket’lar, kısa ömürlü imzalı URL’ler ve katı erişim politikaları).
Cihazda mümkün olduğunca az önbellek tutun. Çevrimdışı saklama gerekiyorsa, yerel dosyaları şifreleyin ve erişimi OS seviyesinde güvenlik (biyometri/şifre) ile koruyun.
Rolleri erken tanımlayın ve izinleri açık tutun:
Denetim erişimi için “sadece görüntüleme” ve hassas kategoriler (ör. tıbbi) için kısıtlı görünürlük gibi koruyucu önlemler ekleyin.
Yalnızca ihtiyaç duyduğunuz verileri toplayın. Tam kart numaralarına veya kesin konumlara ihtiyacınız yoksa saklamayın. Çıkardığınız bilgilerin ne olduğu, ne kadar süre saklandığı ve kullanıcıların nasıl silebileceği konusunda açık olun.
Önemli işlemler için kim, ne zaman ve neden değiştirdiğini gösteren denetim günlükleri tutun (tutar, kategori ve onay düzenlemeleri dahil). Bu anlaşmazlık çözümü, uyum incelemeleri ve entegrasyon hatalarının araştırılması için gereklidir.
Harika bir makbuz-gider uygulaması kısayol gibi hissettirir: kullanıcılar saniyeler içinde yakalar, dakikalarca düzeltmez. Amaç “ödedim”i “göndermeye hazır” hale birkaç dokunuşa indirmektir.
Çoğu ekip gerçek kullanımın %90’ını altı ekranla karşılayabilir:
Bu ekranları tek bir akış olarak tasarlayın: yakala → incele → otomatik kaydet → hazır olduğunda gönder.
Tek el kullanımı önceliği verin: büyük deklanşör düğmesi, ulaşılabilir kontroller ve net “Tamam” eylemi. Tekrarlı veri girişi azaltmak için akıllı varsayılanlar kullanın—para birimi, ödeme yöntemi, proje/müşteri ve sık kullanılan kategorileri doldurun.
İnceleme ekranında “çipler” ve hızlı eylemler (örn. Kategori değiştir, Böl, Katılımcı ekle) uzun formlardan iyidir. Satır içi düzenleme, kullanıcıları ayrı düzenleme sayfalarına göndermekten daha etkilidir.
Kullanıcılar otomasyonu anlamadan kabul etmez. Çıkarılan alanları (tüccar, tarih, toplam) vurgulayın ve önerilerin nedenini kısa gösterin:
Düşük güvenli alanları görsel olarak işaretleyin (örn. Dikkat Gerekiyor) ki kullanıcılar nereye bakacaklarını bilsin.
Yakalama kalitesi düşükse sadece hata vermeyin. Spesifik rehberlik gösterin: “Makbuz bulanık—daha yakınlaşın” veya “Çok karanlık—flaş açın.” OCR başarısız olursa yeniden deneme durumları ve yalnızca eksik alanlar için hızlı manuel yol sağlayın.
Okunabilir tipografi, güçlü kontrast ve büyük dokunma hedefleri kullanın. Notlar ve katılımcılar için sesle girişi destekleyin ve hata mesajlarının ekran okuyucularla duyurulduğundan emin olun. Erişilebilirlik ekstra değil—herkesin işini kolaylaştırır.
Makbuz yakalama uygulaması, giderleri inceleme, geri ödeme ve muhasebeye mümkün olduğunca az el ile aktardığında gerçek değer kazanır. Bu, net onay adımları, kullanıcıların hemen teslim edebileceği rapor formatları ve finans ekiplerinin zaten kullandığı araçlarla entegrasyon anlamına gelir.
İş akışını basit, öngörülebilir ve görünür tutun. Tipik döngü:
Detaylar önemlidir: “son gönderimden bu yana ne değişti” gösterin, belirli satır öğesine satır içi yorum eklemeye izin verin ve her durum geçişini saklayın (Gönderildi → Onaylandı → Dışa Aktarıldı vb.). Ayrıca onayların gider başına mı yoksa rapor bazlı mı olacağını erken kararlaştırın.
Kullanıcıların raporları elle tekrar oluşturmasına gerek kalmayacak yaygın dışa aktarmaları destekleyin:
PDF paketi sunuyorsanız, özet sayfasını finansın beklediği şekilde hazırlayın: kategori, para birimi, vergi ve politika bayraklarına göre toplamlar.
QuickBooks, Xero, NetSuite gibi popüler platformlar için entegrasyon genelde: gider/fatura oluşturma, makbuz dosyalarını ekleme ve alanları doğru eşleme (satıcı/tüccar, tarih, tutar, kategori/hesap, vergi). İlk anda yerel entegrasyonlar göndermiyorsanız bile, takımların uygulamanızı iş akışlarına bağlaması için genel webhook/API sağlayın.
Destek yükünü azaltmak için eşlemeleri yapılandırılabilir yapın: bir yönetici kategorilerinizi kendi hesaplarına eşlesin ve takım/proje/tüccar bazında varsayılanlar belirlesin.
Kullanıcılar en çok “ne zaman ödenecek?”i önemser. Ödemeler bordroda olsa bile uygulamanız geri ödeme durumunu takip edebilir:
“Ödendi” bilgisini otomatik doğrulayamazsanız manuel bir devretme adımı veya bordro içe aktarımı ile durumları mutabıklaştırma imkanı verin.
Muhasebe entegrasyonları ve planlama için hangi işlevlerin hangi pakette olduğunu netleştirmek faydalıdır—bunu kullanıcı beklentilerini net tutmak için fiyatlandırma bilgileriyle birlikte dokümante edin.
Bir gider uygulaması, en uzun özellik listesine sahip olduğunda değil, iş yoğunluğunu azalttığında başarılı olur. En küçük faydalı döngüyle başlayın ve gerçek kullanıcılarla bunun işe yaradığını kanıtlayın.
Tamamlamak için gereken en az şeyi inşa edin: yakala → çıkar → kategorize et → dışa aktar.
Bu, bir kullanıcının makbuz çekip ana alanların (tüccar, tarih, toplam) otomatik dolduğunu görmesi, kategori seçmesi veya onaylaması ve bir gider raporu dışa aktarabilmesi (CSV, PDF veya kısa e-posta özeti) anlamına gelir. Kullanıcı bu döngüyü hızlı tamamlayamıyorsa, ekstra özellikler sorunu çözmez.
Henüz inşa etmeyeceğiniz şeyleri açıkça yazın:
Net bir yol haritası kapsam kaymasını önler ve kullanıcı geri bildirimlerini önceliklendirmeyi kolaylaştırır.
Yakalamadan gönderime kadar olan huniyi takip edin:
Bunu, başarısızlık anında “Bu makbuzda ne zorlayıcıydı?” gibi hafif uygulama içi anketlerle eşleştirin.
Farklı tüccarlar, yazı tipleri, diller, kırışık fotoğraflar içeren küçük, çeşitli bir gerçek makbuz seti oluşturun. Bunları değerlendirme ve regresyon testleri için kullanın ki OCR kalitesi sessizce düşmesin.
1–2 gider döngüsü için küçük bir ekip ile pilot yapın. Kullanıcılardan çıkarılan alanları düzeltmelerini ve makbuzları kategorize etmelerini isteyin; bu düzeltmeleri etiketli eğitim/veri olarak değerlendirin. Amaç mükemmellik değil—iş akışının tutarlı şekilde zaman kazandırdığını kanıtlamaktır.
Hızlı bir beta hedefiniz varsa, destekleyici parçaları (yönetici konsolu, dışa aktarmalar, OCR iş panosu, temel API) hızlı oluşturmak için Koder.ai gibi araçlar kullanmayı düşünebilirsiniz. Kaynak kod dışa aktarımı, dağıtım/host ve geri alma anlık görüntüleri ile çalışmak iterasyonu hızlandırırken kodun size ait kalmasını sağlar.
İyi tasarlanmış gider uygulamaları bile belirli hatalara takılabilir. Bu sorunları erken planlamak haftalarca yeniden çalışmayı ve çok sayıda destek talebini önler.
Gerçek makbuzlar stüdyo fotoğrafları değildir. Kırışık kağıt, soluk mürekkep ve özellikle termal kağıt kısmi veya bozuk metin üretebilir.
Başarısızlıkları azaltmak için yakalama anında kullanıcıyı yönlendirin (otomatik kırpma, parlama algılama, “daha yakın” uyarıları) ve orijinal görüntüyü saklayın ki yeniden tarama yaparken her şeyi yeniden girmesinler. OCR’ı “en iyi çaba” olarak gösterin: çıkarılan alanları güven göstergeleriyle gösterin ve düzenlemeyi hızlı yapın. Düşük güvenli taramalar için (yüksek değerli makbuzlarda) manuel giriş veya insan incelemesi gibi yedek yollar düşünün.
Tarihler, para birimleri ve vergiler büyük farklılık gösterir. “03/04/25” farklı anlamlara gelebilir ve KDV/GST kuralları hangi toplamların saklanacağını etkiler.
Formatları sabitlemekten kaçının. Tutarları sayı + para birimi kodu olarak saklayın, tarihleri ISO zaman damgası olarak tutun ve denetim için ham metni saklayın. Vergi alanlarını kapsayıcı/ayırt edici vergiler ve birden çok vergi satırı için hazırlayın. Çok dilli genişleme planlıyorsanız tüccar adlarını orijinal formda bırakın ama UI etiketleri ve kategori isimlerini yerelleştirin.
Yüksek çözünürlüklü görüntüler ağırdır ve mobil veride yükleme yavaş olabilir—pil tüketir ve kullanıcıyı sinirlendirir.
Cihazda sıkıştırma ve yeniden boyutlandırma yapın, arka planda yükleme ile yeniden deneme uygulayın ve makbuzların “kaybolmaması” için bir kuyruk kullanın. Son makbuzlar ve küçük resimler için önbellek tutun. Eski telefonlarda çökme önlemek için bellek kullanımına sıkı sınırlar koyun.
Değiştirilmiş toplamlar, çoğaltılmış gönderimler ve sahte makbuzlar gerçek dağıtımlarda çabuk ortaya çıkar.
Çoğaltma tespiti (aynı tüccar/tutar/tarih, benzer OCR metni, görüntü parmak izi) ekleyin ve şüpheli düzenlemeleri (örn. OCR sonrası toplam değişikliği) denetim izine kaydedin. Politika hassas alanlarda manuel geçersiz kılma için gerekçe isteyin.
Kullanıcılar dışa aktarma, silme ve eksik makbuz kurtarma ister.
Temel destek araçlarını hazırlayın: kullanıcı/makbuz ID’ye göre arama, işlem durumunu görüntüleme, OCR’ı yeniden çalıştırma ve istek üzerine veri dışa aktarma. Olay müdahalesi tanımlayın: OCR çalışmazsa veya yüklemeler başarısız olursa ne yapılacak? Net çalışma kitapları ve basit bir durum sayfası operasyonu yönetilebilir hale getirir.
Başarılı bir lansman sadece “app store’a gönderme” değildir. Beklentileri belirlemek, gerçek davranışı izlemek ve kullanıcı deneyimi ile ekip düzeltmeleri arasındaki döngüyü sıkılaştırmaktır.
Kullanıcıların en çok önem verdiği iki an için açık SLA’lar tanımlayın: makbuz işleme (OCR) ve cihazlar arası senkronizasyon.
Örneğin, OCR genellikle 10–30 saniye sürüyorsa bunu doğrudan söyleyin: “Makbuz işleniyor… genelde 30 saniyeden kısa sürer.” Senkron gecikebiliyorsa, “Yerel olarak kaydedildi • Senkronize ediliyor” gibi hafif bir durum gösterin ve yeniden deneme seçeneği sunun. Bu küçük ipuçları destek taleplerini azaltır.
Gurup churn’ını erken gösteren birkaç göstergeyi takip edin:
Ani yükselişlere alarm verin ve trendleri haftalık gözden geçirin. OCR güvenindeki düşüş genellikle bir sağlayıcı değişikliği, kamera güncellemesi veya yeni makbuz formatı sinyalidir.
Makbuz detay ekranına yakın bir yerde uygulama içi geri bildirim düğmesi ekleyin; sorun yaşanan yerde geri bildirim almak en değerlisidir. Düzeltmeleri kolaylaştırın, sonra toplu “düzeltme günlüklerini” değerlendirerek yaygın ayrıştırma hatalarını (tarihler, toplamlar, vergiler, bahşişler) tespit edin. Bu listeyi model/kurallar güncellemeleri için önceliklendirin.
Yakalama ve arama stabil hale gelince şunları düşünebilirsiniz:
60 saniyelik bir tanıtım, kullanıcıların düzenleyebileceği örnek bir makbuz ve “en iyi sonuç” ipuçları (iyi aydınlatma, düz yüzey) sunun. Ayrıntılı yardım için yardım sayfasına bağlantı verin.
Start with a narrow, testable problem statement (e.g., “capture a receipt in seconds, auto-create an expense, submit without missing details”). Then choose a primary user (employees or freelancers) and define 2–4 measurable success metrics like:
These constraints prevent scope creep into a generic finance app.
A practical MVP loop is: capture → extract → categorize → export/submit.
In v1, prioritize:
Defer line items, card feeds, advanced policies, and deep integrations until the loop reliably saves time.
Map the full path from “proof” to “payable”:
For each step, specify what’s automatic, what the user sees, and what data is created. This prevents building disconnected tools that don’t complete the reimbursement journey.
Pick one default start for your MVP (usually camera capture) and add others as secondary paths:
Your choice affects UI and backend assumptions (e.g., image preprocessing vs. parsing PDFs/email HTML). Track this with a capture_method field so you can debug accuracy and conversion by source.
Model Receipt and Expense as separate but linked records:
Keep relationships flexible: one expense can have multiple receipts (split payments) or none (manual entry). Store both raw OCR text and normalized fields so edits are explainable and reversible.
Use a camera experience that behaves like a scanner:
Before OCR, run consistent preprocessing (deskew, perspective correction, denoise, contrast/lighting normalization). Often this improves accuracy more than switching OCR vendors.
A hybrid approach is often most practical:
Whichever you choose, store confidence per field (not just per receipt) and build a fast review screen that highlights only what needs attention (e.g., “Total unclear”). Be transparent about what triggers uploads and give users control.
Start with rules users can understand, then layer suggestions:
Also support custom fields like project, cost center, and client so categorization matches real workflows.
Combine multiple signals and avoid hard-blocking:
When you detect a likely duplicate, show a side-by-side review and allow “Keep both.” Also log suspicious changes (e.g., total edited after OCR) in an audit trail for finance review.
Build offline-first reliability into the core flow:
Show clear states like “Saved locally • Syncing” and use notifications for key events (OCR ready, rejected, approved). This is what makes the app trustworthy in poor connectivity.