Dijital Makbuzlar ve Harcamalar İçin Mobil Uygulama Nasıl Yapılır

Hedefi ve Uygulamanın Kimler İçin Olduğunu Tanımlayın

Ö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.

Temel problemle başlayın

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.

Birincil kullanıcıları ve farklı ihtiyaçlarını belirleyin

Çoğu dijital makbuz uygulaması birden fazla kitleye hizmet eder:

• Çalışanlar hızlı yakalama, minimum yazma ve geri ödemelerin gecikmeyeceği konusunda güven ister.
• Serbest çalışanlar vergi için hazır düzenleme, geçmiş satın alımların aranması ve kişisel ile iş harcamalarını ayırmayı önemser.
• Finans ekipleri politika uyumu, daha az geri-gönderi ve muhasebe araçlarına temiz aktarma ister.

İ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.

Yapılacak ana işler (jobs-to-be-done) tanımlayın

İlk sürümü küçük bir sonuç kümesine odaklayın:

• Yakalama: fotoğraf çekme (veya e-posta yönlendirme).
• Otomatik doldurma: mümkün olduğunda tüccar, tarih, toplam, para birimi, vergi ve ödeme yöntemi.
• Gönderme: tek dokunuşla gider raporuna veya müşteri projesine gönderme.
• Geri ödeme: kullanıcıların sürecin nerede olduğunu bilmesi için durum güncellemeleri.

Ölçülebilir başarı metrikleri belirleyin

Gerçek değeri yansıtan birkaç metrik üzerinde anlaşın:

• Yakalamadan gönderime geçen süre (ör. medyan < 60–90 saniye)
• OCR/otomatik doldurma doğruluğu (alan düzeyinde doğruluk)
• Benimseme oranı (haftalık aktif kullanıcılar / davet edilenler)

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.

Makbuz → Gider İş Akışını Haritalayın

Ö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.

Temel akış (kanıttan ödemeye)

En azından tam yolu haritalayın:

• Makbuz yakalandı → veri çıkarıldı → kategorize edildi → gönderildi
• Gönderildi → incelendi/onaylandı (veya sebep ile reddedildi)
• Onaylandı → bordroya/muhasebeye aktarıldı ve denetim için saklandı

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).

İş akışının nerede başladığı

Ana giriş noktalarını belirleyin; çünkü bunlar UI’yi ve backend varsayımlarınızı şekillendirir:

• Kamera yakalama (en yaygın): satın alma anında hızlı tarama
• Gelen kutusu/e-posta ile yönlendirme: “makbuzları şuna gönder: receipts@…” ve otomatik içe aktarma
• Cüzdan geçidi / e-makbuzlar: bir sağlayıcı veya tüccardan içe aktarma
• Dosya yükleme: PDF’ler (ör. taksi, uçak, rezervasyon araçları)

MVP’niz için bir “varsayılan başlangıç” seçin, sonra diğer yolları ikincil olarak destekleyin.

Roller, izinler ve devirler

Kim ne yapabilir netleştirin:

• Çalışan: gider oluşturur, alanları düzenler, gönderir
• Yönetici/onaycı: onaylar/reddeder, değişiklik ister, takım toplamlarını görür
• Yönetici/finans: kategorileri, politikaları, dışa aktarma hedeflerini, saklama kurallarını yapılandırır

Devir kurallarını erken tasarlayın (ör. bir gider ne zaman salt okunur olur, kim üzerine yazabilir ve değişiklikler nasıl kaydedilir).

Önden ele alınması gereken kenar durumlar

İş 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ı.

Veri Modelinizi Planlayın: Makbuzlar, Giderler ve Meta Veriler

İ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.

Makbuz vs. Gider: iki bağlı kayıt

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.

• Makbuz: yakalama kaynağı, ham dosya konumu, OCR çıktısı, güven skorları.
• Gider: tutar, kategori, proje/müşteri, geri ödeme durumu, onay durumu.

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.

Başlangıçtan itibaren desteklenecek yakalama yöntemleri

Büyüme için capture_method alanı planlayın:

• fotoğraf yakalama
• PDF yükleme
• e-posta içe aktarma (yönlendirilen makbuzlar)
• e-makbuz API’leri (varsa)

Bu alan aynı zamanda kalite sorunlarını gidermenize ve OCR/parsing ayarlarını zamanla iyileştirmenize yardımcı olur.

Minimum normalize edilmiş alanlar (ve neden önemli oldukları)

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)

Depolama ve arama

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:

• tüccar
• tarih aralığı
• tutar aralığı
• kategori ve proje

Bu alanları erken indeksleyin; bu, “sonsuz kaydırma” ile “anında cevap” arasındaki farktır.

Saklama ve silme kuralları

Şemaya saklama kontrollerini dahil edin, sonradan eklemeyin:

• kullanıcı tarafından başlatılan silme
• şirket saklama politikaları (ör. N yıl sonra kilitle/sil)
• dışa aktarma/yedekleme takibi (ne dışa aktarıldı, ne zaman, kim tarafından)

Bu parçalarla uygulamanız kişisel yakalamadan şirket çapında uyuma kadar büyüyebilir.

Makbuz Yakalama ve OCR: Görselden Yapılandırılmış Veriye

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.

Otomatik hissettiren kamera UX’i

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.

OCR öncesi görüntü ön işlemeleri

Biraz ön işlem genellikle OCR motoru değiştirmekten daha fazla doğruluk artırır:

• Deskew ve perspektif düzeltme, metin satırlarını yatay hale getirir.
• Gürültü azaltma ve kontrast arttırma, soluk mürekkebi arka plandan ayırır.
• Aydınlatmayı normalize etme (özellikle kırışık makbuzlarda) ve mümkünse hareket bulanıklığını azaltma.

Bu ön işlem hattını tutarlı çalıştırın ki OCR öngörülebilir giriş görsün.

OCR stratejisi: cihazda, bulutta veya hibrit

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:

• Önce cihazda deneyin.
• Güven düşükse, makbuz uzun veya satır öğesi ayrıştırması isteniyorsa buluta düşürün.

Yüklemeyi tetikleyen durumlar hakkında şeffaf olun ve kullanıcılara kontrol verin.

Alan çıkarımı ve güven skorları

İ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”).

İnsan-in-the-loop incelemesi (hızlı)

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.

Kategorilendirme, Kurallar ve Çoğaltma Önleme

İ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.

Kategorilendirme: önce kurallar, sonra akıllı öneriler

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.

Takımların gerçekten harcadığı yere uygun özel alanlar

Ç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ünmüş giderleri zahmetsiz yapın

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.

Politika kontrolleri + çoğaltma tespiti

Kaydetme ve gönderme anında politika kontrolleri çalıştırın:

• Gerekliyse eksik makbuz
• Limit aşımı
• Hafta sonu harcaması uyarıları
• Muhtemel çoğaltmalar

Çoğaltma için birden çok sinyali birleştirin:

• Tüccar + tarih + tutar benzerliği
• Görüntü hash’i (aynı fotoğraf iki kez yüklendi)
• İşlem eşleştirmesi (kart akışları bağlıysa)

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.

Güvenilir Bir Mobil Deneyim İçin Mimari Seçimler

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 platform stratejinizi seçin

MVP için teslim hızını mı yoksa sınıfının en iyisi yerel deneyimi mi hedeflediğinize karar verin.

• Sadece iOS veya sadece Android hızlı çıkış sağlar eğer kullanıcı tabanınız açıkça eğilimliyse.
• Çapraz platform (React Native, Flutter) genellikle ilk sürüm için “bir kez yayınla” yolunu verirken sık yakalama iş akışları için yeterli UI sunar.
• Tam yerel kamera performansı, arka plan işleme veya OS-özgü entegrasyonlar gerektiğinde mantıklıdır; ama genelde lansman daha yavaştır.

Backend olsa bile offline-first olun

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).

Backend sorumluluklarını net tanımlayın

Çoğu ekip backend gerektirir:

• Kimlik doğrulama ve kullanıcı/organizasyon üyeliği
• Makbuz görüntüleri ve oluşturulan PDF’ler için güvenli depolama
• Bir OCR hattı (yükle → işle → çıkarılan alanları döndür)
• Denetim günlükleri (kim neyi, ne zaman değiştirdi) finans iş akışları için
• Dışa aktarmalar (CSV, muhasebe formatları) ve web panelleri

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.

Aramaya ve raporlamaya uygun veritabanı tasarlayın

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.

Güncellemeleri planlayın: senkronizasyon + bildirimler

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.

Teslimatı hızlandırırken kontrolü elden bırakmayı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.

Güvenlik, Gizlilik ve Erişim Kontrolü

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.

Kullanıcılara uygun kimlik doğrulama

Uygulamanın dağıtım şekline uygun bir giriş yöntemi seçin:

• E-posta + sihirli bağlantı yüklenici ve BYOD kullanıcılar için iyi çalışır ve zayıf parolalardan kaçınır.
• SSO (SAML/OIDC) orta ve büyük ölçekli takımlar için ideal; merkezi offboarding ve politika kontrolü sağlar.
• Cihaz tabanlı giriş (yönetilen cihazlar, biyometrik) saha dağıtımlarını kolaylaştırabilir; fakat kayıp cihazlar ve yeniden kayıt için plan yapın.

Veri iletiminde ve dinlenmede koruma

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.

En az ayrıcalık prensibiyle erişim kontrolü

Rolleri erken tanımlayın ve izinleri açık tutun:

• Gönderenler kendi giderlerini oluşturup düzenleyebilir.
• Onaycılar atanan kapsam içinde inceleyip yorum yapabilir, onaylayıp reddedebilir.
• Yöneticiler politikaları, entegrasyonları ve kullanıcı erişimini yönetir.

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.

Gizlilik-odaklı tasarım ve kullanıcı rızası

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.

Güvenilir denetim kaydı

Ö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.

Manuel Çalışmayı Azaltan UX ve UI Kalıpları

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.

Temel ekranlar (döngüyü sıkı tutun)

Çoğu ekip gerçek kullanımın %90’ını altı ekranla karşılayabilir:

• Yakalama (kamera + galeri içe aktarma)
• İnceleme (çıkarılanlar, hızlı düzeltmeler)
• Gider listesi (taslaklar, gönderilenler, geri ödenenler)
• Gönder (politika kontrolleri, toplamlar, notlar)
• Durum (onay, geri ödeme zaman çizelgesi)
• Ayarlar (profil, para birimleri, entegrasyonlar)

Bu ekranları tek bir akış olarak tasarlayın: yakala → incele → otomatik kaydet → hazır olduğunda gönder.

Hız için tasarım: daha az dokunuş, daha az yazma

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.

Güven sinyalleri: yapılan işleri gösterin

Kullanıcılar otomasyonu anlamadan kabul etmez. Çıkarılan alanları (tüccar, tarih, toplam) vurgulayın ve önerilerin nedenini kısa gösterin:

• “Kategori önerildi: tüccar Starbucks’a göre.”
• “Vergi satır öğelerinden tespit edildi.”

Düşük güvenli alanları görsel olarak işaretleyin (örn. Dikkat Gerekiyor) ki kullanıcılar nereye bakacaklarını bilsin.

Hata yönetimi akışı bozmadan

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.

Erişilebilirlik temelleri herkesin işine yarar

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.

Onaylar, Raporlama ve Muhasebe Entegrasyonları

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.

Fazladan iş yaratmayan onay akışı

İş akışını basit, öngörülebilir ve görünür tutun. Tipik döngü:

• Çalışan gideri (veya birden çok gider içeren raporu) gönderir
• Yönetici inceler, yorum ekler, onaylar veya reddeder
• Reddedilirse çalışan düzenler ve yeniden gönderir (denetim iziyle)

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.

Hemen teslim edilebilen raporlama formatları

Kullanıcıların raporları elle tekrar oluşturmasına gerek kalmayacak yaygın dışa aktarmaları destekleyin:

• CSV (tablolar ve özel içe aktarmalar için)
• PDF paket: bir özet sayfası + makbuz görüntüleri (denetimler için kullanışlı)
• Muhasebe-dostu eşlemeler: hesap planı kodları, vergi/KDV alanları ve “müşteriye/projeye faturalandırılabilir” meta verileri

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.

Muhasebe sistemleriyle entegrasyonlar (ve bir yedek)

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.

Geri ödeme durumu: döngüyü kapatın

Kullanıcılar en çok “ne zaman ödenecek?”i önemser. Ödemeler bordroda olsa bile uygulamanız geri ödeme durumunu takip edebilir:

• Gönderildi → Onaylandı → Bordroya/muhasebeye gönderildi → Ödendi

“Ö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.

MVP Oluşturma ve Gerçek Kullanıcılarla Doğrulama

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.

MVP döngüsünü tanımlayın (en küçük faydalı set)

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.

Aşamalı yol haritası oluşturun (MVP → v1 → v2)

Henüz inşa etmeyeceğiniz şeyleri açıkça yazın:

• MVP: makbuz yakalama, OCR çıkarımı, temel kategoriler, manuel düzenlemeler, basit dışa aktarma
• v1: satır öğeleri, daha iyi tüccar ayrıştırma, çoklu para birimi, çevrimdışı iyileştirmeler
• v2: kart akışları, politika motoru, gelişmiş kurallar, onaylar

Net bir yol haritası kapsam kaymasını önler ve kullanıcı geri bildirimlerini önceliklendirmeyi kolaylaştırır.

Kullanıcı değeri ile eşleşen analitiği kurun

Yakalamadan gönderime kadar olan huniyi takip edin:

• % başarıyla çıkarılan makbuzlar
• yakalama ile “göndermeye hazır” arasındaki süre
• düşüş noktaları (yakalamadan sonra, OCR’dan sonra, kategorilendirmeden sonra)

Bunu, başarısızlık anında “Bu makbuzda ne zorlayıcıydı?” gibi hafif uygulama içi anketlerle eşleştirin.

OCR’ı gerçek makbuz test setiyle doğrulayın

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.

Odaklı bir beta pilotu yürütün

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.

MVP geliştirmeleri için pratik bir kestirme

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.

Yaygın Tuzaklar ve Kaçınma Yolları

İyi tasarlanmış gider uygulamaları bile belirli hatalara takılabilir. Bu sorunları erken planlamak haftalarca yeniden çalışmayı ve çok sayıda destek talebini önler.

1) OCR, gerçek makbuzlar yüzünden başarısız olur

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.

2) Yerelleştirme sonra eklenir

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.

3) Büyük görüntüler ve zayıf ağlar performans sorunları yaratır

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.

4) Dolandırıcılık ve kötüye kullanım “kenar durum” değildir

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.

5) Operasyonel hazırbulunuşluk unutulur

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.

Zaman İçinde Lansman, İzleme ve İyileştirme

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.

SLA’ları belirleyin—ve UI’da gösterin

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.

Tükenmeyi öngören sağlık metriklerini izleyin

Gurup churn’ını erken gösteren birkaç göstergeyi takip edin:

• Çökme oranı (cihaz modeli ve OS sürümüne göre)
• Senkronizasyon hataları ve yeniden deneme sayıları
• OCR güveni trendleri (genel ve tüccara göre)
• İlk gidere kadar geçen süre (kurulumdan ilk başarılı yakalamaya kadar)

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.

Sürekli iyileştirme döngüsü kurun

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.

Çekirdeği dağıtmadan genişlemeyi planlayın

Yakalama ve arama stabil hale gelince şunları düşünebilirsiniz:

• E-makbuz ortaklıkları (e-posta yönlendirme, tüccar portalları)
• Tutar doğrulamak ve çoğaltmaları azaltmak için kart işlem eşleştirmesi
• Taslak vs. kaydedilmiş durumları destekleyen muhasebe entegrasyonları

Kullanıcıyı gerçekten daha az iş yüküne sokan onboarding

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.