बैंक स्टेटमेंट OCR क्यों विफल है

आप एक बैंक स्टेटमेंट स्कैन करते हैं, उसे OCR टूल से चलाते हैं, और परिणाम गलत आते हैं। लेनदेन की राशियां कॉलम बदल जाती हैं, दुकान के नाम पंक्तियों के बीच टूट जाते हैं, और डेबिट को क्रेडिट के रूप में पढ़ा जाता है। अगर आपने बैंक स्टेटमेंट पर सामान्य OCR आजमाया है, तो आप इस निराशा को जानते हैं: 70% की गलती की दर कोई अतिशयोक्ति नहीं है।

समस्या OCR में नहीं है। समस्या यह है कि बैंक स्टेटमेंट मशीन-पढ़ने योग्य नहीं हैं। अलग-अलग बैंक अलग-अलग लेआउट का उपयोग करते हैं, स्कैन की गई छवियां गुणवत्ता की समस्याएं पैदा करती हैं, और बहु-पंक्ति लेनदेन सादे पाठ पृष्ठों के लिए बनाए गए पैटर्न-मिलान इंजन को भ्रमित करते हैं। यहां देखते हैं कि मानक OCR स्टेटमेंट पर क्यों विफल होता है, लोग कौन से समाधान आजमाते हैं, और वास्तव में क्या विश्वसनीय डेटा देता है जिसे आप सामंजस्य कर सकते हैं।

सामान्य OCR टूल बैंक स्टेटमेंट को क्यों छोड़ते हैं

Tesseract जैसे सामान्य OCR इंजन या Adobe Acrobat में बने-बनाए रीडर एक पृष्ठ स्कैन करते हैं, पाठ के टुकड़े पहचानते हैं, और स्ट्रिंग आउटपुट करते हैं। ये टाइप किए गए पत्रों या निश्चित फ़ील्ड वाले फॉर्म के लिए अच्छे काम करते हैं। बैंक स्टेटमेंट इस मॉडल को तीन विशिष्ट तरीकों से तोड़ते हैं।

पहला, लेनदेन तालिकाओं की कोई निश्चित कॉलम चौड़ाई नहीं होती। एक दुकान का नाम 40 वर्ण हो सकता है; अगला 8 हो सकता है। OCR पाठ का एक समूह देखता है और अनुमान लगाता है कि एक फ़ील्ड कहां समाप्त होती है और अगली शुरू होती है। जब कोई विवरण दूसरी पंक्ति में जाता है, तो इंजन अक्सर दूसरी पंक्ति को एक अलग लेनदेन मानता है या इसे गलत कॉलम में जोड़ता है। आप राशि के फ़ील्ड में तारीखें और विवरण में राशियां देखते हैं।

दूसरा, स्कैन की गई और फोटोकॉपी की गई स्टेटमेंट में शोर आता है। एक प्रिंटआउट की फोटोकॉपी कंट्रास्ट खो देती है; डेस्क पर स्टेटमेंट की फोन फोटो में छाया और दृष्टिकोण विकृति होती है। OCR की सटीकता गिरती है, और इंजन संख्या 8 को 3 के रूप में पढ़ना शुरू कर देता है, या फीके पाठ को बिल्कुल छोड़ देता है। ऑनलाइन बैंकिंग से आने वाली डिजिटल PDFs इससे बचती हैं, लेकिन जैसे ही स्टेटमेंट स्कैनर या फैक्स मशीन से गुजरता है, सटीकता गिर जाती है।

तीसरा, हर बैंक स्टेटमेंट को अलग तरीके से फॉर्मेट करता है। Chase तारीख को पहले कॉलम में रखता है; Bank of America लेनदेन के प्रकार से शुरू कर सकता है। एक DD/MM/YYYY का उपयोग करता है, दूसरा MM-DD-YY का उपयोग करता है। सामान्य OCR को बैंक स्टेटमेंट की कोई अवधारणा नहीं है, इसलिए यह संरचना को लागू नहीं कर सकता। यह पढ़ने के क्रम में पाठ को डंप करता है, और आप को आउटपुट को हाथ से पार्स करना पड़ता है।

लोग कौन से समाधान आजमाते हैं (और वे क्यों अधूरे हैं)

जब सामान्य OCR विफल हो जाता है, तो सहज प्रतिक्रिया प्रक्रिया को ठीक करना है। तीन समाधान बार-बार फोरम और सहायता धागों में दिखाई देते हैं, प्रत्येक का अपना टूटने वाला बिंदु है।

OCR के बाद मैनुअल पुनः-प्रविष्टि

कुछ लोग OCR चलाते हैं, 70% सटीकता प्राप्त करते हैं, और फिर हर त्रुटि को मैनुअल रूप से सुधारते हैं। यह स्वचालन का उद्देश्य ही विफल करता है। अगर आप 30 मिनट लेनदेन को अदल-बदल करने और दुकान के नामों को फिर से टाइप करने में लगा रहे हैं, तो आप शुरुआत से ही डेटा दर्ज कर सकते हैं। समय बचत गायब हो जाता है, और नई टाइपिंग गलतियों की जोखिम बढ़ती है क्योंकि आप अब एक त्रुटिपूर्ण आधार के विरुद्ध प्रूफरीड कर रहे हैं।

लेनदेन डेटा को टेक्स्ट के रूप में डाउनलोड करना

जब संभव हो, ऑनलाइन बैंकिंग में लॉगिन करना और CSV या OFX के रूप में लेनदेन डाउनलोड करना OCR को पूरी तरह से छोड़ देता है। यह पूरी तरह से काम करता है जब आपका बैंक इसे प्रदान करता है और जब निर्यात उस अवधि को कवर करता है जिसकी आपको आवश्यकता है। समस्या: कई बैंक डाउनलोड को 90 दिन तक सीमित करते हैं, कुछ ऐतिहासिक डेटा के लिए शुल्क लेते हैं, और अगर आप किसी ग्राहक की स्टेटमेंट सामंजस्य कर रहे हैं या बंद खातों के साथ काम कर रहे हैं, तो अक्सर आपके पास केवल PDF है। पाठ डाउनलोड पर निर्भर रहना आदर्श पथ है, लेकिन यह हमेशा उपलब्ध नहीं है।

कई OCR टूल आजमाना और सर्वश्रेष्ठ परिणाम चुनना

एक ही स्टेटमेंट को तीन विभिन्न OCR इंजनों के माध्यम से चलाना और आउटपुट की तुलना करना पूरी तरह से ध्वनि है। व्यवहार में, सभी तीन अलग-अलग तरीकों से विफल हो सकते हैं। एक डेबिट और क्रेडिट को स्वैप करता है, दूसरा तारीखों को खराब करता है, तीसरा आधे लेनदेन को छोड़ देता है। आपको अभी भी पंक्ति-दर-पंक्ति सत्यापन की आवश्यकता है, और आपने अब प्रसंस्करण समय को तिगुना कर दिया है। यह दृष्टिकोण मौलिक समस्या को भी हल नहीं करता: इनमें से कोई भी उपकरण स्टेटमेंट संरचना को नहीं समझता।

वास्तव में क्या काम करता है: संरचना-जागरूक निष्कर्षण

विश्वसनीय निष्कर्षण के लिए एक ऐसे इंजन की आवश्यकता है जो जानता है कि बैंक स्टेटमेंट क्या है। इसे लेनदेन तालिकाओं को पहचानना है, कॉलम सीमाएं लागू करनी हैं, बहु-पंक्ति विवरण को संभालना है, और यह सत्यापित करना है कि निकाला गया डेटा मुद्रित खुली और बंद शेष के विरुद्ध सामंजस्य करता है। सामान्य OCR इसे नहीं कर सकता क्योंकि यह हर दस्तावेज को सादे पाठ के रूप में मानता है। वित्तीय दस्तावेजों के लिए उद्देश्य-निर्मित उपकरण कर सकते हैं।

संरचना-जागरूक सिस्टम विभिन्न संस्थानों से हजारों वास्तविक बैंक स्टेटमेंट पर प्रशिक्षित मशीन लर्निंग मॉडल का उपयोग करते हैं। वे सीखते हैं कि सबसे बाईं ओर की कॉलम लगभग हमेशा एक तारीख है, राशियां दाईं ओर संरेखित होती हैं, और बिना तारीख की पंक्ति संभवतः पिछले लेनदेन की निरंतरता है। जब वे स्कैन की गई या फोटोकॉपी की गई स्टेटमेंट का सामना करते हैं, तो वे OCR से पहले छवि प्री-प्रोसेसिंग लागू करते हैं - विकृति को हटाना, कंट्रास्ट बढ़ाना, शोर कम करना - जो वर्ण मान्यता सटीकता में नाटकीय रूप से सुधार करता है।

अधिक महत्वपूर्ण रूप से, ये उपकरण आउटपुट को सत्यापित करते हैं। लेनदेन निकालने के बाद, सिस्टम खुली शेष से आगे चलने वाली शेष की गणना करता है और जांचता है कि क्या यह मुद्रित बंद शेष से मेल खाता है। यदि यह नहीं है, तो निष्कर्षण कहीं विफल हुआ, और उपकरण विसंगति को फ़्लैग करता है। यह एकल सत्यापन कदम स्वैप किए गए डेबिट, छोड़े गए लेनदेन, और गलत पढ़ी गई राशियों को पकड़ता है जो सामान्य OCR से गुजर जाते हैं।

अपने विकल्पों की तुलना करना

यहां बताया गया है कि जब आपको PDF बैंक स्टेटमेंट से डेटा की आवश्यकता हो तो सामान्य दृष्टिकोण कैसे तुलना करते हैं:

अगर आपकी स्टेटमेंट साफ डिजिटल PDF हैं जिनमें चयन योग्य पाठ है और आपके पास केवल कुछ पृष्ठ हैं, तो Tabula या Adobe की निर्यात सुविधा जैसे मुफ्त उपकरण पर्याप्त हो सकते हैं। जैसे ही आप स्कैन की गई छवियों, फोटोकॉपी, या कुछ पृष्ठों से लंबी स्टेटमेंट पेश करते हैं, आपको किसी ऐसी चीज की आवश्यकता होती है जो दस्तावेज संरचना को समझे।

जब आपको एक उद्देश्य-निर्मित कन्वर्टर का उपयोग करना चाहिए

तीन परिस्थितियां एक विशेष उपकरण को सामान्य OCR या मैनुअल विधियों पर व्यावहारिक विकल्प बनाती हैं।

आपके पास स्कैन की गई या फोटोग्राफ की गई स्टेटमेंट हैं। एक ग्राहक आपको फोटोकॉपी की गई स्टेटमेंट का एक ढेर देता है, या आपने ऑडिट के दौरान डेस्क पर कागज की स्टेटमेंट की फोन फोटो ली हैं। सामान्य OCR पृष्ठों की गड़बड़ाहट का पाठ उत्पन्न करेगा। एक कन्वर्टर जो छवि प्री-प्रोसेसिंग लागू करता है और स्टेटमेंट लेआउट जानता है, साफ डेटा निकालेगा।

आपको एक बार में कई स्टेटमेंट को बैच-प्रसंस्करण करने की आवश्यकता है। माह के अंत में पांच बैंक खातों के लिए सामंजस्य का अर्थ है 10 से 15 स्टेटमेंट फ़ाइलें। उन सभी को एक बैच में अपलोड करना और एक एकीकृत CSV या प्रति स्टेटमेंट अलग फ़ाइलें वापस पाना प्रत्येक को अलग-अलग संभालने की तुलना में घंटों बचाता है।

आपको निकाले गए डेटा को मुद्रित कुल के विरुद्ध सामंजस्य करना होगा। अगर खुली शेष $4,832.15 है और बंद शेष $6,201.48 है, तो निकाले गए लेनदेन को चलती कुल की गणना करते समय वह सटीक बंद आंकड़ा देना होगा। मैनुअल स्पॉट-जांच स्पष्ट त्रुटियों को पकड़ता है; स्वचालित शेष सत्यापन सब कुछ पकड़ता है। अपनी स्टेटमेंट पर इसे आजमाएं और अंतर देखें जब उपकरण आपको आगे बताता है कि डेटा सामंजस्य करता है या नहीं।

गोपनीयता और स्थानीय प्रसंस्करण

बैंक स्टेटमेंट को वेब सेवा में अपलोड करना स्पष्ट सवाल उठाता है: फ़ाइल कहां जाती है? अगर आप ग्राहकों के लिए स्टेटमेंट परिवर्तित कर रहे हैं या संवेदनशील खातों को संभाल रहे हैं, तो आपको आश्वासन की आवश्यकता है कि डेटा किसी और के सर्वर पर अनिश्चित काल तक नहीं रहता है या उपकरण के अगले संस्करण को प्रशिक्षित करने के लिए उपयोग नहीं किया जाता है।

BankStmtConverter प्रसंस्करण के बाद अपलोड की गई फ़ाइलों को हटाता है। निष्कर्षण होता है, आप आउटपुट डाउनलोड करते हैं, और PDF सर्वर से साफ कर दिया जाता है। उच्च-संवेदनशीलता वर्कफ़्लो के लिए, डेस्कटॉप संस्करण स्टेटमेंट को पूरी तरह से आपकी स्थानीय मशीन पर प्रसंस्करण करता है। फ़ाइल कभी आपके कंप्यूटर से नहीं जाती, जो अपलोड जोखिम को पूरी तरह से हटा देता है और आपको कोई आवर्ती सदस्यता के साथ एक बार की खरीद देता है। यह विकल्प बुककीपरों और एकाउंटेंटों के अनुकूल है जो ग्राहक डेटा को क्लाउड में जोखिम में नहीं डाल सकते।

अकाउंटिंग-तैयार आउटपुट प्रारूप

लेनदेन निकालना चरण एक है। चरण दो वह डेटा बिना पुनः-कुंजीपटन के अपने अकाउंटिंग सॉफ़्टवेयर में लाना है। CSV Excel के लिए काम करता है, लेकिन QuickBooks और Xero QBO या OFX फ़ाइलें पसंद करते हैं जो सीधे उनके आयात वर्कफ़्लो से जुड़ती हैं। एक अच्छा कन्वर्टर तीनों आउटपुट करता है, इसलिए आप Excel में सामंजस्य कर सकते हैं और फिर एक क्लिक के साथ अपनी अकाउंटिंग सिस्टम में समान डेटा आयात कर सकते हैं।

CSV में मानक कॉलम शामिल होने चाहिए: तारीख, विवरण, डेबिट, क्रेडिट, और शेष। कुछ उपकरण एक लेनदेन प्रकार कॉलम या एक श्रेणी फ़ील्ड जोड़ते हैं जिसे आप खातों के चार्ट कोड में मैप कर सकते हैं। संरचना जितनी अधिक होगी, आयात के बाद उतनी ही कम सफाई करनी पड़ेगी। जांचें कि उपकरण प्रति-संस्थान टेम्पलेट की आवश्यकता के बिना किसी भी बैंक और किसी भी लेआउट को संभालता है। समर्थित बैंक यहां देखें - सूची में सैकड़ों संस्थान हैं क्योंकि निष्कर्षण इंजन संरचना सीखता है, निश्चित टेम्पलेट नहीं।

चरण-दर-चरण: स्कैन की गई स्टेटमेंट को रूपांतरित करना

यहां वर्तमान कार्यप्रवाह है जब आपके पास स्कैन की गई या फोटोकॉपी की गई स्टेटमेंट है और विश्वसनीय डेटा की आवश्यकता है।

1. स्कैन की गई स्टेटमेंट को PDF के रूप में सहेजें। अगर आपके पास कागज की स्टेटमेंट का एक ढेर है, तो उन सभी को एक बहु-पृष्ठ PDF में या प्रति स्टेटमेंट अलग PDFs में स्कैन करें।
2. फ़ाइल को एक संरचना-जागरूक कन्वर्टर में अपलोड करें। अगर आप कई स्टेटमेंट प्रसंस्करण कर रहे हैं, तो समय बचाने के लिए उन सभी को एक बार में अपलोड करें।
3. निष्कर्षण के लिए प्रतीक्षा करें। उपकरण प्री-प्रोसेसिंग के साथ OCR चलाता है, लेनदेन तालिकाओं की पहचान करता है, और प्रत्येक पंक्ति को तारीख, विवरण, डेबिट, क्रेडिट, और शेष कॉलम में पार्स करता है।
4. आउटपुट डाउनलोड करें। Excel के लिए CSV, QuickBooks के लिए QBO, या अन्य अकाउंटिंग सॉफ़्टवेयर के लिए OFX चुनें। फ़ाइल सभी लेनदेन के साथ सही कॉलम में साफ रूप से खुलनी चाहिए।
5. बंद शेष की पुष्टि करें। CSV को Excel में खोलें और खुली शेष से डेबिट और क्रेडिट का योग करें। यदि गणना की गई बंद शेष मुद्रित स्टेटमेंट से मेल खाती है, तो निष्कर्षण सफल हुआ। यदि नहीं, तो छोड़े गए या डुप्लिकेट लेनदेन के लिए जांचें।

अगर आप अकाउंटिंग सॉफ़्टवेयर में डेटा सामंजस्य कर रहे हैं, तो QBO या OFX फ़ाइल आयात करें और लेनदेन को अपने बैंक फीड या मैनुअल प्रविष्टियों के विरुद्ध मिलाएं। कन्वर्टर में शेष सत्यापन कदम का अर्थ है कि आप आयात से पहले त्रुटियों को पकड़ते हैं, आयात के बाद नहीं जब आप पहले से ही अपनी बहीखाता को लेनदेन पोस्ट कर चुके हों।

किनारे के मामले जो अधिकांश उपकरणों को तोड़ते हैं

यहां तक कि उद्देश्य-निर्मित कन्वर्टर को भी सीमाओं का सामना करना पड़ता है। तीन किनारे के मामले सबसे अधिक समस्या पैदा करते हैं।

हाथ से लिखी गई नोट्स या स्टांप वाली स्टेटमेंट। एक स्कैन की गई स्टेटमेंट जिसमें हाथ से लिखी नोट्स या लाल स्टांप हैं।