運用 AI 自動處理申請表格：OCR、數據擷取及安全儲存

申請表格仍是許多業務流程的核心，涵蓋客戶開戶與註冊、保險申請、公共服務、金融服務申請、登記、理賠及內部審批等場景。然而，人工處理這些表格不僅耗時，容易出錯，也難以大規模擴展。

借助 elDoc Intelligent Document Processing，企業可將收到的申請表格轉化為結構化且經驗證的業務數據，並自動分流至相應的工作流程及文件儲存庫。

從申請表格到可直接用於業務的數據

申請表格很少會作為獨立文件處理。在大多數業務流程中，申請表只是一整套文件的起點，後續通常還包括身份證明文件、證書、聲明、證明材料、佐證記錄及往來文件。企業不僅需要讀取申請表內容，還必須判斷已提交哪些資料、哪些文件屬於同一宗申請、文件包含哪些資訊、所需資料是否完整，以及下一步應採取甚麼行動。

申請可透過網上入口、電郵、API、系統整合或紙本文件掃描件提交，格式涵蓋 PDF、JPG、PNG 及 TIFF 等。elDoc 提供端到端的申請處理方案，將 OCR、基於 LLM 的文件理解、AI 文件分類、數據擷取、驗證、工作流程啟動及安全文件儲存整合於同一流程中。

應用於不同業務流程的申請表格

根據申請類型不同，所需的佐證文件亦可能大相逕庭：

申請流程	申請表可能附帶的文件	需要處理的內容
公用服務接駁申請	身份證明、住址證明、物業所有權或租賃文件、場地平面圖、授權書、技術文件	識別申請人及服務地點，擷取接駁資料，分類佐證文件，核實資料完整性，並啟動相應的接駁流程
保險理賠申請	保單、照片、發票、收據、醫療文件、警方報告、維修報價及其他證明材料	擷取理賠資料，識別已提交的證明材料，提取金額及相關資訊，將佐證文件與理賠個案關聯，並將個案分流至評估流程
銀行／貸款申請	身份證明、住址證明、銀行結單、薪金記錄、在職證明、公司文件及財務報表	擷取申請人及財務資料，分類佐證記錄，驗證所需數據，並整理申請文件包以供審核及批核
政府／公共服務申請	身份證明、證書、聲明、牌照、許可證、官方記錄及佐證材料	識別不同文件類型，擷取申請資料，核查所需文件，並將個案分流至相關行政流程
物業／租賃申請	身份證明、收入證明、就業記錄、推薦資料、物業文件、租賃記錄及證書	擷取申請人及物業資料，整理佐證文件，識別相關日期及數據，並將申請分流至核實及批核流程

因此，申請處理並非只是對表格進行 OCR。完整的文件套件必須轉化為員工及後端業務系統可以直接使用的資訊。

從多份文件到一個完整關聯的申請個案

借助 elDoc，收到的申請表及其佐證文件可作為一個完整關聯的業務個案統一處理。

申請表格 + 佐證文件 → OCR 及 LLM 處理 → AI 分類 → 數據擷取 → 驗證及完整性檢查 → 啟動工作流程 → 審核／批核 → 安全文件儲存庫 → 歸檔

在每個階段，整套文件都會逐步轉化為更具結構化的資訊：

OCR 及 LLM 處理將掃描及數碼文件轉化為機器可讀的資訊，並讓 AI 理解文件內容及其上下文。

AI 分類識別收到的文件屬於申請表、身份證明文件、發票、證書、結單、佐證材料或其他文件類型，並將其關聯至相應的處理流程。

AI 數據擷取提取業務流程所需的資訊，包括申請人姓名、地址、參考編號、日期、金額、帳戶資料及申請專屬欄位，並將其轉化為結構化數據。

驗證及完整性檢查協助判斷擷取的資訊是否符合既定的信心度及業務規則，以及所需文件和資料是否已完整提交。需要人工核實的個案則可分流至 Human-in-the-Loop（HITL）人工審核。

啟動工作流程將已處理的申請轉化為可執行的業務流程。elDoc 可根據文件類型、擷取資訊及預設規則，啟動相應工作流程、分配審核人員並建立後續工作。

安全儲存及歸檔讓原始申請、佐證文件、擷取的中繼資料及處理資訊在整個生命週期內保持關聯，並可隨時搜尋。

1. 從任何渠道接收申請表格

申請表格可透過多種渠道進入企業，包括經網上入口上載、透過電郵接收、經 API 傳送、由紙本掃描，或從其他企業系統提交。

elDoc 支援 PDF、JPG、PNG 及 TIFF 等常見業務文件格式，讓企業可在同一環境中統一處理數碼生成的表格及掃描文件。

企業亦可為申請人提供單一、專用的提交介面，建立更有結構且可自行完成的申請流程。入口不只是提供一般的檔案上載功能，還可逐步引導申請人完成提交，例如選擇申請類型、填寫基本資料，以及一併上載申請表格和所需佐證文件。

在正式接收申請前，提交流程可加入驗證及完整性檢查。視乎具體應用場景，當必填資料或文件缺失時，系統可即時提示申請人，有助減少不完整提交及後續反覆溝通。

例如，提交公用服務接駁申請時，系統可引導申請人在完成提交前提供申請表格、身份證明文件、住址證明及相關物業文件。同樣的方式亦可應用於保險理賠、貸款申請、政府服務及其他文件密集型流程。

這為企業提供兩種互補的方式：一是沿用現有渠道處理申請，無需改變客戶目前提交文件的方式；二是引入集中式、自助引導的申請入口，從源頭開始標準化整個提交流程。

無論採用哪種方式，文件均會進入相同的後端處理流程：

提交 → 初步驗證 → OCR 及 AI 處理 → 分類 → 數據擷取 → 驗證 → 工作流程

這樣既能建立集中且可控的申請處理入口，亦讓企業可靈活選擇申請人、客戶、合作夥伴及員工參與流程的方式。

2. 自動分類申請表格及佐證文件

申請很少會單獨提交，通常會附帶身份證明文件、證書、財務報表、合約、佐證材料及其他附件。elDoc 提供開箱即用的 AI 文件分類功能，可自動識別這些文件，並將其歸類至相應的文件類型，以進一步處理。

然而，文件分類並不只是識別文件屬於例如物業協議這類基本文件類型。

企業可能需要根據自身的業務背景、文件內容、代碼、專用術語或營運規則進一步分類文件。elDoc 允許客戶提供額外的 AI 提示詞及上下文指令，明確定義文件應如何分類。

例如，客戶可以設定以下分類規則：

申請／文件	提供給 AI 的額外上下文／指令	分類結果
公用服務申請	如果服務代碼 = NC01，分類為新接駁；如果服務代碼 = AC02，分類為帳戶變更。	新接駁申請／帳戶變更申請
保險理賠表格	如果理賠包含保單產品代碼 MV，分類為汽車保險理賠；如果產品代碼為 TR，則分類為旅遊保險理賠。	汽車保險理賠／旅遊保險理賠
銀行／貸款申請	年營業額低於指定門檻的企業申請應分類為中小企；其餘則分類為企業客戶。	中小企融資申請／企業融資申請
政府服務申請	如果申請人類型 = GOV，則分流至政府類別；如果申請人類型 = COM，則分類為商業類別，不受一般申請表格類型影響。	政府申請／商業申請
物業協議	文件外觀可能完全相同，但物業代碼 005 代表政府物業，而代碼 002 代表商業物業。	政府物業協議／商業物業協議

這使企業能夠進行多層次、符合自身業務需求的文件分類。AI 可先理解文件類型，再結合文件內容及企業設定的指令，判斷該文件在實際業務流程中應如何分類。

更重要的是，這些指令可透過自然語言 AI 提示詞及上下文進行設定，減少企業為不同業務場景開發複雜硬編碼分類邏輯的需要。

完成分類後，系統即可據此決定下一步處理方式：

收到文件 → AI 識別文件類型 → 業務專屬 AI 分類 → 相應數據擷取 → 驗證 → 工作流程分流

對申請處理而言，這意味著 elDoc 不僅能判斷已提交哪些文件，還能識別文件所屬的業務類別及應採用的處理路徑。這為企業提供靈活的基礎，讓系統可自動套用相應的數據擷取要求、驗證規則、工作流程、負責團隊及儲存結構。

3. OCR、AI 文件理解及數據擷取

收到申請後，OCR 會將掃描或影像格式的文件轉換為機器可讀的文字，為後續自動化處理奠定基礎。

然而，OCR 本身主要負責識別字元及文字。elDoc 將 OCR 與 AI 及 LLM 驅動的文件理解能力結合，進一步解析文件中的結構、上下文及資訊含義。企業因此可以處理不同版面及結構的表格，而無需完全依賴固定模板或欄位座標。

精確定義需要擷取的數據

企業可以針對每種文件類型定義需要擷取的欄位，讓不同文件類型各自採用相應的數據擷取要求。

例如：

文件類型	需要擷取的欄位示例
公用服務接駁申請	申請人姓名、服務地址、電錶號碼、接駁類型、要求接駁日期
保險理賠表格	保單號碼、索償人姓名、事故日期、理賠類型、索償金額
貸款申請	申請人姓名、公司名稱、申請金額、貸款用途、年收入
政府申請	申請人姓名、申請類型、參考編號、提交日期、牌照／許可證類型
物業／租賃申請	租戶姓名、物業地址、每月租金、租約開始日期、租約結束日期

為 AI 提供欄位理解所需的上下文

更重要的是，企業可以針對個別欄位提供 AI 提示詞及上下文指令。

這一點尤其重要，因為同一個詞語、數字或短語，在不同文件、流程或企業術語中可能具有不同的業務含義。企業不必只是要求 AI 尋找某個特定標籤下的數值，而是可以進一步說明欄位代表甚麼、可能出現在哪裡、應如何理解，以及當文件中存在多個可能值時應選取哪一個。

例如：

欄位	AI 上下文／指令示例
申請人姓名	擷取申請服務一方的法定名稱。不要使用授權代表或聯絡人的姓名。
索償金額	擷取保單持有人提出索償的總金額，而非維修報價、自付額或保單保障限額。
生效日期	擷取協議依法生效的日期，而非文件簽署日期或提交日期。
物業地址	擷取本申請所涉及物業的地址，而非申請人的通訊地址或註冊地址。
客戶參考編號	使用企業的客戶參考編號。不要填入申請編號、發票編號或外部參考編號。

這些額外上下文有助 AI 區分文件中多個看似都符合條件、但實際業務含義各不相同的數值。

例如，一份保險理賠文件套件可能同時包含索償金額、維修報價、保單限額及自付額。OCR 可以識別這四個數值，但欄位層級的 AI 指令會告訴模型，哪一個金額才是企業需要擷取為「索償金額」的數值。

從文件文字到可直接應用於業務的數據

這套方法整合三項關鍵能力：

OCR 識別內容 → AI 理解文件 → 客戶自訂提示詞明確定義需要擷取的業務資訊。

擷取後的資訊會轉化為結構化欄位及中繼資料，可進行驗證及搜尋，用於啟動工作流程，與文件一併儲存，或透過 API 傳送至下游 ERP、CRM、核心業務系統及其他企業系統。

因此，數據擷取不再局限於預先定義的 OCR 欄位或固定文件模板，而是能夠針對不同文件、理解業務上下文，並按照企業自身的術語及要求靈活配置。

4. 檢查申請完整性及佐證文件

在申請進入驗證或批核流程之前，elDoc 可協助判斷是否已收到完整的申請文件套件。

由於申請表格及佐證文件已完成分類，系統可以按照不同文件類型的要求，判斷特定申請所需提交的文件。所需文件清單亦可根據申請中所包含的資訊動態調整。

例如，公用服務接駁申請可能需要身份證明及住址證明；如果申請由租戶提交，還可能需要租約或物業擁有人的授權文件。保險理賠申請所需的佐證材料亦可能有所不同，視乎屬於汽車、旅遊、醫療還是物業理賠。

因此，系統可以檢查：

• 是否已提交所有必需文件；
• 是否已提供必填的申請欄位及資料；
• 已提交的文件是否符合預期的文件類型；
• 是否需要根據申請內容補充其他文件；
• 個案應否自動繼續處理，還是分流至進一步審核。

企業因此可以在申請進入耗時的審核及批核流程之前識別不完整的申請，減少人工核查，以及申請人與處理團隊之間不必要的往返溝通。

5. 在啟動工作流程前進行驗證

自動化數據擷取並不代表可以毫無保留地信任 AI 產生的每一項數值。在使用擷取資訊啟動工作流程、更新業務系統或支援決策之前，企業可以加入多層驗證及控制機制。

elDoc 可針對擷取的資訊應用 AI 信心評分、可配置的驗證規則及 Human-in-the-Loop（HITL）人工核實。

驗證可以細化至個別欄位層級。例如，企業可以規定保單號碼、申請人 ID 或銀行帳戶號碼必須符合特定格式；申請日期必須落在指定範圍內；或索償金額超過既定門檻時必須進一步審核。

AI 信心度可提供另一層控制。當擷取數值的信心度低於企業設定的門檻時，系統可自動將該欄位提交予獲授權的員工核實。

驗證結果決定下一步

驗證結果	處理路徑
AI 高信心度 + 驗證通過	→ 自動繼續下一個工作流程步驟
AI 低信心度	→ 將指定欄位分流至 Human-in-the-Loop 人工核實
驗證規則未通過	→ 建立例外個案，進行審核或修正
關鍵業務欄位	→ 無論信心度高低，均須進行強制人工核實
缺少必需資料	→ 暫停處理申請或要求補充資料

在信心度及規則允許的情況下自動化；在業務控制要求下進行人工核實。

這在直通式處理與 Human-in-the-Loop 人工審核之間建立受控的平衡，讓企業能夠自動化處理常規申請，同時對例外情況及關鍵業務資訊維持更嚴格的控制。

6. 自動啟動申請工作流程

完成申請分類、所需文件識別、數據擷取及驗證後，elDoc 可自動啟動相應的申請工作流程。

不同申請無需採用相同的工作流程。系統可根據申請類型、文件分類、擷取數據、驗證結果或企業專屬業務規則動態選擇相應流程。

例如，符合所有要求的標準申請可直接交由負責的處理團隊；超過指定金額的申請則可要求額外一級審批。不完整或存在例外情況的申請，則可分流至專門的審核隊列。

視乎具體流程，elDoc 工作流程可支援任務分派、審核及批核步驟、通知、升級處理、例外管理，以及與外部企業系統整合。

典型流程如下：

收到申請 → 文件分類 → 數據擷取 → 完整性檢查 → 數據驗證 → 選擇工作流程 → 分派審核人員 → 批核 → 儲存

從申請中擷取的結構化資訊亦可透過系統整合傳送至下游系統，減少員工重複手動輸入相同資料的需要。

這使申請處理從單純的 OCR 及數據擷取工作，轉變為端到端、可實際執行的業務流程。

7. 安全儲存、搜尋申請表格及透過 Agentic RAG 進行 AI 搜尋

完成處理後，申請表格及其佐證文件可連同擷取的中繼資料、分類結果及相關處理資訊，一併安全儲存於 elDoc 文件儲存庫。

企業不必只保留掃描 PDF 或一組互不關聯的附件，而是可以建立結構化的申請記錄，將原始申請、佐證文件及擷取的業務數據在同一申請脈絡下關聯起來。

例如，一份申請記錄可以包括原始申請表格、身份證明文件、佐證材料、申請人資料、申請／參考編號、文件分類、擷取的中繼資料及相關工作流程資訊。

傳統搜尋及基於中繼資料的檢索

由於擷取的欄位會轉化為可搜尋的中繼資料，員工可以直接利用實際業務資訊查找申請，而不必只依賴檔案名稱或資料夾結構。

申請可根據申請人姓名、客戶編號、申請參考編號、物業地址、保單號碼、文件類型、提交日期、申請狀態或其他擷取欄位等屬性進行搜尋。

即使企業需要管理大量文件，這種方式亦能提供結構化的檢索機制，快速定位個別申請及其佐證文件。

透過 Agentic RAG 跨申請進行 AI 搜尋

除傳統搜尋外，企業還可利用 elDoc Agentic RAG，以自然語言提問並與申請文件互動。

獲授權的員工無需逐一搜尋文件、開啟多份附件及閱讀其內容，而是可以直接向 AI 提問，查詢其獲授權存取的資訊。

例如：

使用者問題	AI 搜尋可協助擷取的資訊
「找出 ABC 公司的申請，並摘要其申請內容。」	相關申請及佐證文件，並提供精簡摘要
「這項物業申請的接駁容量是多少？」	公用服務申請及相關佐證文件中的資訊
「這宗保險理賠提交了哪些證明材料？」	理賠表格及相關證明材料，例如發票、報告及照片
「申請的貸款金額及用途是甚麼？」	從申請及相關財務文件中擷取的資訊
「這宗物業申請涉及哪些重要日期及義務？」	從整套申請文件中識別出的相關日期及條款

基於存取權限的 AI 搜尋

更重要的是，AI 搜尋不應成為繞過文件存取權限的新途徑。

elDoc Agentic RAG 可在企業所設定的使用者、角色及文件存取權限範圍內運作，因此 AI 搜尋所提供的資訊只會涵蓋使用者獲授權存取的內容。

使用者不會因向 AI 提問而獲得更廣泛的存取權限。Agentic RAG 只會在使用者獲授權的資訊範圍內進行搜尋及回答。

這對申請處理尤其重要，因為相關文件可能包含個人、財務、合約或其他敏感資訊。

透過結合安全文件儲存、結構化中繼資料搜尋及具權限感知能力的 Agentic RAG，elDoc 可將文件儲存庫由被動的檔案庫轉變為主動的企業知識來源，讓獲授權的使用者不僅可以查找申請記錄，還能以自然語言提問，從中取得相關資訊。

8. 保存及長期歸檔

申請獲批、被拒或完成處理後，其生命週期未必就此結束。許多企業仍需基於營運、合約、法規或內部管治要求，保存申請記錄及相關佐證文件。

完成處理後，文件可進入受控的保存及長期歸檔流程。

企業可根據文件類型及業務要求設定保存規則，以管理已完成申請記錄在整個保存期間的維護方式。更重要的是，申請進入長期儲存後，其完整業務脈絡仍可保留。

企業可以持續保留原始申請、佐證文件、擷取的中繼資料及相關處理資訊之間的關聯，完整保存可追溯的申請生命週期記錄。

對於每年處理數千甚至數百萬宗申請的企業而言，這提供了一套結構化方式管理持續增長的文件量，同時從收到申請直至最終歸檔，維持可搜尋性、受控存取、可追溯性及生命週期管理。

準備好自動化您的申請表格處理流程了嗎？

每個申請流程各有不同：申請表格、佐證文件、需要擷取的數據、驗證要求及批核流程均取決於企業及具體應用場景。

與 elDoc 專家交流，了解如何優化現有申請流程，從文件提交及 OCR 開始，延伸至 AI 驅動的數據擷取、驗證、工作流程自動化、安全儲存及 Agentic RAG。

與我們分享您的申請表格及處理要求，我們可以協助您找出 AI 及文件自動化在整個申請生命週期中最能創造價值的環節。