OpenClaw ile Belge İşleme Otomasyonu
Her iş belgelerle çalışır. Faturalar, sözleşmeler, satın alma siparişleri, teslimat makbuzları, uyumluluk raporları, masraf talepleri; hacim asla azalmaz ve bunların manuel olarak işlenmesinin maliyeti çok yüksektir. İhtiyatlı tahminler, manuel fatura işlemenin ortalama maliyetinin belge başına 12 ila 16 ABD Doları arasında olduğunu ve hata oranlarının %3 ile %5 arasında olduğunu ortaya koyuyor. Bunu ayda binlerce belgeyle çarptığınızda otomasyonun durumu kendiliğinden ortaya çıkar.
OpenClaw'ın belge işleme aracıları OCR'yi, yapılandırılmış veri ayıklamayı, doğrulama kurallarını ve ERP entegrasyonunu tek bir özerk işlem hattında birleştirir. Sonuç, bir belgeyi alan, türünü ve içeriğini anlayan, verileri iş kurallarınıza göre doğrulayan ve çıkarılan bilgileri, belgelerin çoğu için insan müdahalesi olmadan doğru hedefe yönlendiren bir sistemdir.
Önemli Çıkarımlar
- OpenClaw belge aracıları PDF'leri, taranmış görüntüleri, ekleri olan e-postaları ve yapılandırılmış dosya formatlarını (CSV, XML, EDI) birleşik bir işlem hattı aracılığıyla yönetir.
- OCR kalitesinde puanlama kapıları AI çıkarma—düşük kaliteli taramalar, işleme devam etmeden önce yeniden tarama isteğini tetikler.
- Çıkarma katmanı, belge formatlarında maksimum doğruluk için düzen analizi, adlandırılmış varlık tanıma ve LLM tabanlı ayrıştırmanın bir kombinasyonunu kullanır.
- Doğrulama becerileri, herhangi bir veri ERP'nize ulaşmadan önce ayıklanan verileri tedarikçi ana kayıtlarına, PO numaralarına, vergi kodlarına ve iş kurallarına göre kontrol eder.
- İstisna işleme yalnızca gerçekten belirsiz belgeleri insanlara yönlendirir; aracı, en iyi tahminini içeren önceden doldurulmuş bir form sağlar, böylece insan yeniden girmek yerine yalnızca onaylar.
- İşlem hattı, kutudan çıktığı gibi 300'den fazla belge türünü yönetir; özel şablonlar düşük kodlu bir şema düzenleyici aracılığıyla eklenebilir.
- Belge alımından ERP girişine kadar uçtan uca gecikme süresi, temiz belgeler için ortalama 90 saniyenin altındadır.
- ECOSIRE, Odoo, SAP, QuickBooks ve özel ERP'lerle entegre OpenClaw belge işleme hatları oluşturur ve yönetir.
Belge İşleme Mimarisine Genel Bakış
Bir üretim OpenClaw belge işleme hattı, her biri bir veya daha fazla beceri olarak uygulanan altı aşamadan oluşur:
Document Ingestion
↓
[ Classifier Agent ] — document type detection, routing
↓
[ Extraction Agent ] — OCR + structured data extraction
↓
[ Validation Agent ] — business rule validation, master data lookup
↓
[ Enrichment Agent ] — GL coding, cost center assignment, approver lookup
↓
[ Integration Agent ] — ERP/downstream system write
↓
[ Exception Agent ] — handles ambiguous documents, requests human review
Her aracı bağımsız olarak çalışır ve görev veriyolu aracılığıyla iletişim kurar. Herhangi bir aşamada başarısız olan belgeler, yukarı akış aşamalarında tamamlanmış olan işi kaybetmeden İstisna Aracısına yönlendirilir.
Belge Besleme: Her Formatı Kabul Etme
Belgeler birden fazla kanaldan gelir: e-posta ekleri, dosya sistemi kesintileri, API yüklemeleri, fakstan e-postaya ağ geçitleri ve satıcı portalları. Besleme katmanı tüm bunları standart bir belge görevinde normalleştirir.
export const DocumentIngester = defineSkill({
name: "document-ingester",
tools: ["email", "storage", "queue"],
async run({ input, tools }) {
let rawFile: Buffer;
let mimeType: string;
if (input.source === "email") {
const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
rawFile = attachment.buffer;
mimeType = attachment.mimeType;
} else if (input.source === "storage") {
rawFile = await tools.storage.get(input.storageKey);
mimeType = detectMimeType(rawFile);
}
// Normalize to PDF for consistent downstream processing
const normalizedPdf = mimeType === "application/pdf"
? rawFile
: await convertToPdf(rawFile, mimeType);
const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
await tools.storage.put(storageKey, normalizedPdf);
return {
storageKey,
originalSource: input.source,
originalMimeType: mimeType,
pagCount: await getPdfPageCount(normalizedPdf),
};
},
});
Normalleştirme adımı, Word belgelerini, Excel dosyalarını, görüntü dosyalarını (JPEG, PNG, TIFF) ve e-posta HTML gövdelerini aşağıya aktarmadan önce PDF'ye dönüştürür. Aşağı akış temsilcileri yalnızca PDF'leri alır; bu, OCR'yi ve düzen analizini önemli ölçüde basitleştirir.
Belge Sınıflandırması: Neye Sahip Olduğunuzu Bilmek
Çıkarma başlamadan önce, Sınıflandırıcı Aracısı belge türünü tanımlar. Sınıflandırma önemlidir çünkü farklı belge türleri farklı ayıklama şablonları gerektirir; bir fatura, teslimat makbuzuna hiç benzemez.
Sınıflandırıcı iki aşamalı bir yaklaşım kullanır:
1. Aşama — Düzen Analizi: Belgenin görsel yapısı (tablo konumları, başlık blokları, alt bilgi desenleri, logo yerleşimi), belge kategorisini küçük bir aday grubuna daraltmak için analiz edilir.
2. Aşama — İçerik Sınıflandırması: Metindeki anahtar ifadeler ve yapısal modeller, belirli belge türünü doğrular. Sınıflandırıcı bir tür etiketi ve bir güven puanı üretir.
export const ClassifyDocument = defineSkill({
name: "classify-document",
tools: ["storage", "classification-model"],
async run({ input, tools }) {
const pdfBuffer = await tools.storage.get(input.storageKey);
const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
const textContent = await performOcr(pdfBuffer, { mode: "fast" });
const classification = await tools.classificationModel.classify({
layoutFeatures,
textContent: textContent.slice(0, 2000), // First 2000 chars for speed
});
if (classification.confidence < 0.70) {
return {
type: "unknown",
confidence: classification.confidence,
requiresManualClassification: true,
};
}
return {
type: classification.label,
confidence: classification.confidence,
requiresManualClassification: false,
extractionTemplate: TEMPLATE_MAP[classification.label],
};
},
});
Yaygın belge türleri ve bunların çıkarma şablonları önceden oluşturulmuştur: satıcı faturaları, kredi notları, satın alma siparişleri, teslimat notları, banka ekstreleri, sözleşmeler, gider raporları ve gümrük beyannameleri. Şablon düzenleyici aracılığıyla kod değişikliği yapılmadan yeni belge türleri eklenebilir.
OCR ve Çıkarma: Verileri Doğru Şekilde Çıkarma
Ekstraksiyon Aracısı, teknik karmaşıklığın çoğunun yaşandığı yerdir. Yapılandırılmamış belgelerden yapılandırılmış veriler üretmek için OCR çıktısını düzen analizi ve LLM tabanlı ayrıştırmayla birleştirir.
OCR kalitesi, AI çıkarma işlemi başlamadan önce değerlendirilir. OCR'den gelen ortalama karakter güvenirliği 0,80'in altındaysa (bulanık bir taramayı, düşük çözünürlüğü veya çarpık sayfayı gösterir), aracı, güvenilmez metinle devam etmek yerine belgeyi yeniden tarama için işaretler.
OCR kalite kontrollerini geçen belgeler için çıkarma işlemi üç geçişte gerçekleştirilir:
Pass 1 — Şablon Eşleştirme: Bilinen satıcılar ve belge formatları için çıkarma şablonu, alan konumlarını (koordinatlar veya normal ifade bağlantıları) sağlar. Bilinen kaynaklardan gelen yapılandırılmış belgeler için şablon eşleştirme hızlı ve doğrudur.
Pass 2 — Adlandırılmış Varlık Tanıma: NER, şablon eşleştirmesinin kaçırıldığı tutarları, tarihleri, adresleri, tanımlayıcıları (fatura numaraları, PO numaraları, KDV numaraları) ve satır öğesi sınırlarını tanımlar.
Pass 3 — LLM Muhakeme: Belirsiz alanlar için veya ilk iki geçiş düşük güvenirlik değerleri ürettiğinde, LLM doğru değeri çıkarmak için çevreleyen metin içeriğini ayrıştırır.
export const ExtractInvoiceData = defineSkill({
name: "extract-invoice-data",
tools: ["storage", "ocr-service", "llm"],
async run({ input, tools, memory }) {
const buffer = await tools.storage.get(input.storageKey);
const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });
if (ocrResult.averageConfidence < 0.80) {
return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
}
// Pass 1: Template matching
const templateFields = applyTemplate(ocrResult, input.extractionTemplate);
// Pass 2: NER for missing fields
const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });
// Pass 3: LLM for remaining low-confidence fields
const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
const llmFields = lowConfidenceFields.length > 0
? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
: {};
const extracted = mergeExtractions(templateFields, nerFields, llmFields);
await memory.working.set("extractedData", extracted);
return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
},
});
Doğrulama: Hataları ERP'nize Ulaşmadan Yakalamak
Ham olarak çıkarılan veriler hiçbir zaman doğrudan ERP'nize yazılmaz. Doğrulama Aracısı, herhangi bir şey gönderilmeden önce her alanı iş kurallarınıza ve ana verilerinize göre kontrol eder.
Satıcı faturasına yönelik doğrulama kontrolleri şunları içerir:
- Satıcı mevcut: Tedarikçi adı ve KDV numarası satıcı ana dosyasındaki bir kayıtla eşleşiyor.
- PO eşleşmesi: Faturadaki PO numarası açık bir PO ile eşleşir ve tutarlar tolerans dahilindedir (faturalama esnekliği için genellikle ±%5).
- Yinelenen algılama: Bu satıcının fatura numarası son 180 gün içinde işlenmemiştir.
- Vergi hesaplaması: Satır öğesi toplamları artı vergi, yuvarlama toleransı dahilinde fatura toplamına eşittir.
- Para birimi ve döviz kuru: Dövizli faturalar, fatura tarihindeki döviz kuruna göre doğrulanır.
- GL dönemi: Fatura tarihi açık bir hesap dönemine denk gelir.
export const ValidateInvoice = defineSkill({
name: "validate-invoice",
tools: ["erp", "vendor-master"],
async run({ input, tools }) {
const errors: ValidationError[] = [];
// Vendor validation
const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });
// PO match
if (input.data.poNumber) {
const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
}
}
// Duplicate check
const isDuplicate = await tools.erp.invoiceExists({
vendorId: vendor?.id,
invoiceNumber: input.data.invoiceNumber,
});
if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });
return {
valid: errors.length === 0,
errors,
validatedData: errors.length === 0 ? input.data : null,
};
},
});
Doğrulama hataları, belgeyi sessizce bırakmak yerine İstisna Aracısına yönlendirilir. İstisna Aracısı, çıkarılan verilerle ve belirli doğrulama hatalarıyla önceden doldurulmuş bir inceleme görevi oluşturur, böylece bir insan yalnızca işaretlenen alanları düzeltebilir.
Zenginleştirme: İş İçeriği Ekleme
Temiz, doğrulanmış verilerin bir ERP'ye gönderilmeden önce hâlâ iş bağlamına ihtiyacı vardır. Zenginleştirme Aracısı, belgelerin içermediği bilgileri ekler: GL hesap kodları, maliyet merkezi atamaları, vergi muamele kodları, onay iş akışı atamaları ve ödeme koşulları.
Zenginleştirme kuralları bir politika deposunda tanımlanır ve satıcı niteliklerine, satır öğesi açıklamalarına, departmana, proje kodlarına ve miktar eşiklerine referans verebilir. Zenginleştirme kurallarının çoğu deterministik aramalardır; Belirsiz durumlar için (birden fazla GL hesabıyla eşleşebilecek açıklamalara sahip satır öğeleri), LLM açıklamalarla birlikte sıralanmış bir öneri listesi sağlar.
ERP Entegrasyonu: Verileri İlk Kez Doğru Yazma
Entegrasyon Aracısı doğrulanmış, zenginleştirilmiş verileri ERP'nize gönderir. Orijinal belgenin karmasından türetilen bir korelasyon kimliğine sahip bağımsız API çağrıları kullanır; ERP yazma işlemi yeniden denenirse (ağ zaman aşımı nedeniyle), yinelenen kayıtlar önlenir.
export const PostToErp = defineSkill({
name: "post-to-erp",
tools: ["erp"],
async run({ input, tools }) {
const correlationId = hashDocument(input.storageKey);
const result = await tools.erp.createVendorBill({
correlationId, // ERP uses this for idempotency
vendorId: input.enrichedData.vendorId,
invoiceNumber: input.enrichedData.invoiceNumber,
invoiceDate: input.enrichedData.invoiceDate,
lineItems: input.enrichedData.lineItems,
taxLines: input.enrichedData.taxLines,
paymentTerms: input.enrichedData.paymentTerms,
glCodes: input.enrichedData.glCodes,
});
return {
erpRecordId: result.id,
erpRecordUrl: result.url,
posted: true,
};
},
});
Orijinal belge gönderildikten sonra ERP kaydına bağlanır ve belge yönetim sisteminizde tam meta verilerle birlikte arşivlenir. Denetim takibi tamamlanmıştır: e-posta ekinden veya dosya gönderiminden, her işlem aşamasına ve son ERP girişine kadar.
İstisna İşleme: Önemli Olduğunda Döngüdeki İnsan
Her belge temiz bir şekilde işlenmez. İstisna Aracısı dört istisna kategorisini işler:
- Sınıflandırma hataları: Belge türü yeterli güvenle belirlenemedi.
- Çıkarma hataları: Kritik alanlar (toplam tutar, satıcı kimliği, fatura numarası) çıkarılamadı.
- Doğrulama hataları: Çıkarılan veriler iş kuralı kontrollerinden geçemez.
- Entegrasyon hataları: ERP gönderimi reddetti (ör. kapalı hesap dönemi, hesap kilitlendi).
Her istisna için temsilci, yardım masanızda veya iş akışı sisteminizde, aracının en iyi girişimini ve belirli hatayı gösteren önceden doldurulmuş bir form içeren bir inceleme görevi oluşturur. İnsan yalnızca hatalı alanları düzeltir ve onaylar; temsilci yeniden gönderimi gerçekleştirir.
Sıkça Sorulan Sorular
Doğru OCR için hangi belge çözünürlüğü gereklidir?
Basılı belgelerde kabul edilebilir OCR sonuçları için minimum 150 DPI'dır; Güvenilir çıkarma için 300 DPI önerilir. El yazısıyla yazılan belgeler veya çok küçük yazı boyutlarına sahip belgeler için 400 DPI veya üzeri tercih edilir. OCR kalite değerlendirme becerisi, çıkarma işlemi başlamadan önce belgeleri eşiğin altında işaretler ve otomatik olarak yeniden tarama isteğini tetikler.
Sistem çok sayfalı belgeleri nasıl işler?
Çok sayfalı belgeler sayfa sınırı algılamayla işlenir. Faturalar için aracı, başlık sayfasını, satır öğesi sayfalarını ve devam sayfalarını tanımlar. Sayfa sonlarını kapsayan satır öğeleri, düzen analizi katmanı tarafından doğru şekilde yeniden oluşturulur. Diğer belge türleri için (sözleşmeler, raporlar), aracı tüm sayfaları işler ve her sayfadan çıkarılan alanları birleştirir.
Sistem insanlar tarafından yapılan düzeltmelerden öğrenebilir mi?
Evet. Bir insan bir istisna belgesini düzelttiğinde, düzeltme Bilgi Aracısına geri gönderilir. Aynı düzeltme modeli üç defadan fazla görünüyorsa (örneğin, yeni bir satıcının faturasını her zaman standart olmayan bir şekilde biçimlendirmesi), sistem o satıcı için otomatik olarak yeni bir çıkarma şablonu önerir. Bir yönetici önerilen şablonu inceleyip onaylar ve sistem bu noktadan itibaren satıcının insan incelemesine gerek kalmadan şablonu uygular.
El yazısı belgeler nasıl işlenir?
El yazısı belgeler en zorlu kategoridir. OCR katmanı, bu belgeler için özel bir el yazısı tanıma modeli kullanır ve yapay zeka ayıklamaya geçiş için güven eşiği daha yüksektir (basılı belgeler için 0,90'a karşı 0,80). Uygulamada çoğu kurumsal belge iş akışı, süreç değişiklikleri (elektronik gönderim portalları, dijital imza iş akışları) aracılığıyla elle yazılan belgeleri ortadan kaldırabilir. ECOSIRE, el yazısı belgeleri işlemesi gereken kuruluşlar için, el yazısı ağırlıklı belgeler için insan incelemesine sahip hibrit bir yaklaşım önerir.
Çıkartma için hangi diller destekleniyor?
OpenClaw'ın belge işleme özelliği, OCR için 40'tan fazla dili destekler; İngilizce, Almanca, Fransızca, İspanyolca, Arapça, Çince (Basitleştirilmiş ve Geleneksel), Japonca ve Portekizce dillerinde başlıca iş belgesi formatları için doğrulanmış çıkarma şablonları bulunur. Diğer dillerde OCR çalışır ancak çıkartma şablonunun kalitesi belge örnek kümenize bağlıdır. Yüksek Lisans muhakeme katmanı birçok dili yerel olarak yönetir.
Belge gizliliği nasıl korunur?
Belgeler aktarım sırasında (TLS 1.3) ve beklemedeyken (AES-256) şifrelenir. Her belge izole bir bağlamda işlenir; hiçbir belge içeriği kuruluşlar arasında paylaşılmaz. Son derece hassas belgeler için (yasal sözleşmeler, mali tablolar), işlem hattını muhakeme katmanı için şirket içi bir LLM kullanacak şekilde yapılandırabilir ve belge içeriğini tamamen ağınızın sınırları içinde tutabilirsiniz.
Fatura işlemede tipik doğruluk oranı nedir?
Bilinen satıcılardan şablon eşleştirmeli yapılandırılmış faturalar için alan düzeyinde doğruluk, şablon kalibrasyonundan sonra genellikle %99,5'i aşar. Yeni satıcılardan gelen yapılandırılmamış faturalarda doğruluk genellikle ilk denemede %95-98'dir ve sistem satıcının formatını öğrendikçe bu oran artar. İzlenecek temel ölçüm istisna oranıdır; iyi yapılandırılmış ardışık düzenlerde istisna oranları toplam belge hacminin %5'inin altındadır.
Sonraki Adımlar
Manuel belge işleme, rekabet açısından hiçbir değer katmayan bir maliyet merkezidir. OpenClaw belge işleme otomasyonu, onu yoğun personel gerektiren bir işlemden, belge hacminizin %95'inden fazlasını insan müdahalesi olmadan işleyen otomatik bir boru hattına dönüştürür.
ECOSIRE'ın OpenClaw uygulama ekibi Odoo, SAP, QuickBooks ve özel ERP'lerle entegre belge işleme hatları oluşturma konusunda uzmanlaşmıştır. Belge sınıflandırma şablonu tasarımını, OCR kalibrasyonunu, doğrulama kuralı yapılandırmasını, ERP entegrasyonunu ve istisna iş akışı kurulumunu gerçekleştirerek altı ila sekiz hafta içinde üretime hazır bir sistem teslim ediyoruz.
Mevcut operasyonunuzun belge işleme denetimiyle başlamak için ECOSIRE ile iletişime geçin.
Yazan
ECOSIRE Research and Development Team
ECOSIRE'da kurumsal düzeyde dijital ürünler geliştiriyor. Odoo entegrasyonları, e-ticaret otomasyonu ve yapay zeka destekli iş çözümleri hakkında içgörüler paylaşıyor.
İlgili Makaleler
Case Study: AI Customer Support with OpenClaw Agents
How a SaaS company used OpenClaw AI agents to handle 84% of support tickets autonomously, cutting support costs by 61% while improving CSAT scores.
Testing and Monitoring AI Agents in Production
A complete guide to testing and monitoring AI agents in production environments. Covers evaluation frameworks, observability, drift detection, and incident response for OpenClaw deployments.
Building Custom AI Agents with OpenClaw: Developer Guide
Complete developer guide for building custom AI agents with OpenClaw. Architecture patterns, skill definitions, deployment strategies, and integration blueprints.