Biçimler çok çeşitli
Fatura, irsaliye, kantar fişi ve yakıt fişi; her birinin alanları ve her satıcının şablonu farklı. Şablona bağlı bir okuyucu yetmezdi.
Fatura, irsaliye, kantar fişi ve yakıt fişi gibi belgelerin her biri bambaşka alanlar taşıyor; hepsini elle muhasebeye geçirmek gerekiyordu. Doksan9'u, belgeyi fotoğraflayınca alanlarını çıkaran ve her sonucu onaya sunan bir sistem olarak kurduk.
Fatura, irsaliye ve kantar fişi aynı işin farklı belgeleri; her birinin alanları bambaşka — biri tutar ve KDV, biri plaka ve malın cinsi, biri dara ve net ağırlık ister. Hepsi aynı anda muhasebeye elle giriliyordu.
Fatura, irsaliye, kantar fişi ve yakıt fişi; her birinin alanları ve her satıcının şablonu farklı. Şablona bağlı bir okuyucu yetmezdi.
Görsel-dil modeli her zaman doğru okumaz; bu yüzden hiçbir sonuç otomatik kaydedilmez. Hepsi önce insana gösterilir, düzeltilip onaylanmadan hiçbir belge muhasebeye girmez.
Faturalar ad, adres, vergi numarası ve araç plakası gibi kişisel veri taşıyor; bu veri, alan çıkarımı için görüntü olarak doğrudan bir bulut görsel-dil modeline gönderiliyor.
Kullanıcı belgeyi telefonla fotoğraflar ya da galeriden seçer; görsel bir kuyruğa alınır. Çok-modlu bir görsel-dil modeli görüntüden doğrudan yapılandırılmış alanlar çıkarır — ayrı bir metin tanıma adımı yok. Her sonuç onay bekler durumuna düşer; kullanıcı alanları gözden geçirip onaylar, o zaman kayda ve arşive girer.
{ "total": "1845.60", "date": "14/03/2026", "vat": "307.60", "description": "ABC Market", "companyId": "5f2e0c1a-....-....-....-............", "operation": true}{ "total": "1845.60", "date": "14/03/2026", "vat": "307.60", "description": "ABC Market" }
İlk sürümde görsel analizi Azure OpenAI'ın GPT-4 Vision modeliyle yapıyorduk. Sonra Google'ın Gemini 2.0 Flash modeline geçtik; belge akışı ve onay adımı aynı kaldı, yalnız görüntüyü okuyan model değişti.