Restoran Tedarikçi Fatura Onayı ve İstisna Akışı Nasıl Kurulur?

Restoranda tedarikçi faturası onayı neden ayrı bir akıştır?

Restoran tedarikçi fatura onayı, gelen belgeyi yalnızca muhasebeye aktarmak değil; sipariş, teslimat, fiyat, miktar ve yetkili onayını aynı işlemde karşılaştırmaktır. Malzeme depoya girmiş olsa bile fatura üzerindeki birim, miktar veya fiyat beklenenden farklı olabilir. İyi tasarlanmış bir akış bu farkı ödeme aşamasına bırakmadan görünür kılar. Amaç her belgeyi otomatik kabul etmek değil, tekrar eden kontrolleri düzenli hale getirip istisnaları insan kararına taşımaktır.

Bu konu, reçete ve fire hesabından farklıdır. Fire takibi tüketilen malzemeyi anlamaya çalışırken tedarikçi fatura akışı satın alma taahhüdü ile gelen belgenin tutarlılığına odaklanır. Entegrasyon planının sınırlarını görmek için restoran stok ve fire otomasyonu yazımıza ayrıca bakabilirsiniz. Webinle'nin otomasyon yazılımı hizmeti, bu süreçlerin işletmenin kullandığı sistemlerle nasıl bağlanacağını değerlendirme alanıdır.

Önce belge akışının gerçekte nasıl işlediğini çizin

Bir restoranda tedarikçi faturası e-posta eki, basılı belge, portal çıktısı veya muhasebe programındaki kayıt olarak gelebilir. Her kaynağı aynı varsayımla işlemek hataya açıktır. İlk görüşmede belgenin kim tarafından alındığını, kimin teslimatı kontrol ettiğini, fiyat anlaşmasının nerede tutulduğunu ve son onayı kimin verdiğini yazın. Şube varsa hangi personelin hangi şube adına işlem yapabildiğini de belirtin.

Ardından bir işlem için gereken asgari alanları belirleyin: tedarikçi, belge tarihi, belge numarası, ürün veya hizmet satırı, miktar, birim, birim fiyat, toplam, teslimat referansı ve onay durumu. Vergi veya e-belge alanlarını ülkenin ve işletmenin muhasebe yükümlülüklerine göre uzmanla netleştirin; bu yazı mevzuat tavsiyesi değildir. Başlangıçta bütün alanları otomatik okumaya çalışmak yerine doğruluğu kritik alanları seçmek daha güvenlidir.

Sipariş, teslim ve faturayı nasıl karşılaştırmalı?

En pratik modelde satın alma talebi veya sipariş kaydı ilk referanstır. Teslim sırasında gelen miktar ve kabul edilen ürün ayrı kaydedilir. Fatura ise üçüncü kayıttır. Sistem, bu üç kaydın satırlarını mümkün olduğunca eşler; eşleyemediği satırları sessizce tamamlanmış saymaz. Örneğin siparişte koli, teslimde adet, faturada kilogram kullanılıyorsa birim dönüşümünün tanımı olmadan otomatik onay verilmemelidir.

Tedarikçi adı farklı yazılmış olabilir; ürün kodu değişmiş olabilir; kısmi teslimat yapılmış olabilir. Bu durumlar aynı “hata” kategorisine doldurulursa ekip gerçek sorunu göremez. Ayrı istisna nedenleri tanımlayın: eksik teslim, fiyat farkı, birim uyumsuzluğu, yinelenen belge, siparişsiz fatura ve belirsiz ürün eşlemesi. Personel her istisna için açıklama veya ek belge ekleyebilsin. Böylece onay veren kişi yalnızca kırmızı bir uyarı değil, kararın bağlamını görür.

Görsel okuma ve OCR tek başına onay değildir

Belge görselinden alan çıkarmak veri girişini kolaylaştırabilir; ancak okunmuş metin, doğrulanmış ticari işlem anlamına gelmez. Yazı karakterleri karışabilir, satırlar kayabilir veya birden fazla belge tek dosyada bulunabilir. Bu yüzden OCR çıktısı satır bazında kaynak görüntüyle ilişkilendirilmeli; düşük güvenli alanlar inceleme kuyruğuna alınmalıdır. “Otomatik yakalandı” ile “ödemeye uygun bulundu” ayrı durumlar olmalıdır.

Restoran yazılım sağlayıcısı Toast'un 2026'da güncellenen ürün açıklaması, fatura satırlarının muhasebe verisi ve maliyet görünürlüğüyle ilişkilendirilebildiğini gösteriyor. Bu, Webinle'nin Toast ile entegrasyonu olduğu anlamına gelmez; yalnızca sektörde belgelerin satır düzeyinde ele alınmasının güncel bir örneğidir. Her işletmede kullanılacak ürün ve entegrasyon, mevcut altyapıya göre ayrıca seçilmelidir.

Onay yetkisi ve görev ayrımı nasıl kurulmalı?

Belgeyi sisteme yükleyen, teslimatı doğrulayan ve ödemeyi onaylayan rollerin aynı kişide toplanması her işletme için uygun olmayabilir. Küçük ekipte görevler birleşse bile işlem geçmişi kaybolmamalıdır. Onay kuralı tutar, ürün grubu, şube veya istisna türüne göre farklılaşabilir; ancak eşik değerleri rastgele bir şablondan kopyalanmamalıdır. İşletmenin kendi risk ve yetki politikasından türetilmelidir.

Bir fatura düzeltildiğinde eski değer, yeni değer, değiştiren kişi ve gerekçe kayıtlı kalmalıdır. Onay geri çekilebiliyorsa bunun da izlenebilir olması gerekir. Görev bir çalışandan diğerine devredildiğinde bekleyen fatura görünmez hale gelmemelidir. Bu yüzden yönetim ekranında “bekliyor”, “bilgi istendi”, “fark çözüldü”, “onaylandı” ve “reddedildi” gibi durumlardan hangilerinin kullanılacağı baştan belirlenir.

Muhasebe ve stok entegrasyonunda sınır nerede?

Fatura onayı tamamlandığında muhasebe sistemine aktarılan kayıt ile stok artışı aynı olay olmayabilir. Mal fiziksel olarak teslim edilmeden yalnızca fatura geldi diye stok eklemek yanlış tablo oluşturur. Kısmi teslimatta fatura tamamı için kesilmişse bekleyen miktar ayrıca izlenmelidir. Depo, satın alma ve muhasebe sistemleri arasında tek bir “kaynak doğru” belirlemek yerine her verinin sahibi açık olmalıdır.

Entegrasyon tasarımında başarısız gönderim ve tekrar gönderim senaryolarını da yazın. Ağ kesildiğinde aynı fatura iki kez açılmamalı; muhasebe sisteminin belgeyi reddetme nedeni görülebilmelidir. Bu noktada mevcut webhook yeniden deneme rehberimiz teknik altyapının neden işlem kimliğine ihtiyaç duyduğunu açıklar. Her entegrasyona webhook gerekmez, ama mükerrer kayıt riski her yöntemde düşünülmelidir.

Pilot kurulumda neyi ölçmek anlamlı?

İlk pilot için tek şube veya sınırlı tedarikçi grubu seçin. Eski işleyişte bir faturanın hangi adımlardan geçtiğini belgeleyin; yeni akışta aynı adımları izleyin. Ölçülecek şey yalnızca hızlı onay sayısı değil, açıklamasız bekleyen belge, yanlış eşleme, tekrar işlenen fatura ve çözülmemiş fiyat farkıdır. Daha fazla otomasyon her zaman daha doğru kontrol anlamına gelmez.

Personelden hangi ekranın eksik bilgi yarattığına dair geri bildirim alın. İstisna kuyruğu büyüyorsa kuralı gevşetmeden önce veri kaynağını ve ürün eşlemesini düzeltin. Tedarikçi fatura biçimini değiştirdiğinde okuma ve eşleme testlerini yeniden yapın. Böylece pilot, yalnızca güzel bir panel denemesi değil, gerçek karar akışının sınaması olur.

Sonuç: otomatik kayıt ile insan onayını dengede tutun

Restoran tedarikçi fatura onayı için iyi sistem, bütün belgeleri sessizce geçiren sistem değildir. Sipariş, teslim ve faturayı ortak bağlamda gösterir; uyuşmazlığı ilgili kişiye taşır ve verilen kararı izlenebilir kılar. İşletmenizde belgelerin nerede kaybolduğunu veya beklediğini anlamak istiyorsanız önce mevcut akışı çıkarın. Ardından Webinle ile görüşerek mevcut POS, stok ve muhasebe araçlarınıza uygun bir otomasyon kapsamı belirleyebilirsiniz.