小村軟體有限公司
聯絡我們
選單

用 AI Builder 讀取 FAX 送達的訂購單 ── 減少手動輸入抄錄的務實設計與極限

· · Power Automate, AI Builder, FAX收單, OCR, SharePoint, 受發訂, 業務自動化, 技術諮詢

「四成的訂單現在還是靠 FAX。一邊看著複合機印出的訂購單，一邊一筆一筆打進銷售管理系統。」在製造業或批發業的諮詢中，這句話真的常常聽到。接著出現的往往是「跟客戶的關係還沒到能拜託對方改用網路下單的地步」、「規模愈大的客戶，對方的下單系統反而愈是以傳送 FAX 為前提，動不了」這類實情。

改善 FAX 收單大致有兩條路線。一條是轉移到網路收單或 CSV 匯入，「捨棄 FAX」；另一條則是維持接收 FAX 的現狀，把讀取與抄錄自動化，「與戒不掉的 FAX 共處」。前者已在另一篇文章「把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務」中處理過。這篇文章要談的是後者，也就是把 FAX 當成資料（PDF）接收，用 AI Builder 的文件處理來讀取，加入人工確認，再串接到收單台帳與核心系統的設計。

先說在前面：這套機制不會成為「全自動」，也不應該追求全自動。即便如此，如果能把每天 1～2 小時的抄錄作業，壓縮成「只需確認讀取結果」的數十分鐘，對許多公司來說仍然值得投資。這篇文章依據 Microsoft Learn 上可以確認的規格，整理出到底能自動化到什麼程度、極限又在哪裡。

1. 先講結論

  • FAX 讀取自動化的前提是以資料（PDF）而非紙本接收 FAX。從用複合機的 FAX 轉發功能或雲端 FAX 服務把收到的 FAX 檔案化、集中存到 SharePoint 開始做起。
  • AI Builder 的文件處理自訂模型，能從訂購單這類獨特版面的單據中擷取欄位與表格。訓練是以「同一版面的單據＝集合」為單位，每個集合至少需要 5 份（最多 20 份）範例。12
  • 兩種訓練類型（固定範本文件、一般文件）都支援日文，FAQ 明確寫著也支援手寫文字的擷取。不過 FAX 品質的實際單據能讀到什麼程度，一定要用自家的範例來驗證。32
  • 這套流程的關鍵在於用信心分數分流。擷取結果每個欄位都會附上 0～1 的分數，因此要設計高信心自動登錄台帳、低信心轉交人工確認的分支。不要放棄「全部由人看過」的前提，而是設計成「讓確認變輕鬆」。4
  • 不要嘗試讀取所有客戶的單據。由於機制上是依版面分別建立集合，只鎖定件數排名靠前的客戶的定型訂購單也能見效。低品質單據可將範例增加到 15～20 份，這是官方的建議做法。25
  • AI Builder 另外需要用量計費的點數。文件處理依頁數消耗，自訂模型的消耗速率比預先建置的模型高。隨著 2025 年 10 月發布的 AI Builder 點數階段性終止，體系正在移轉到 Copilot 點數。67
  • 讀取並非萬能。依件數、客戶數、單據的定型程度而定，有時網路收單轉移或 EDI 才是正道（詳見第 8 章的判斷表）。

2. 「捨棄」與「讀取」── 不要混用這兩條路線

在接受 FAX 收單的諮詢時，我最先確認的是「對方是不是能戒掉 FAX 的客戶」。

轉移到網路收單，是一項需要客戶改變行為的行動。如同分階段轉移那篇文章所寫，應該從件數多、系統可以配合的客戶開始依序轉移，在效果大的地方先減少手動輸入。但無論如何都動不了的客戶還是會留下來——對方的下單作業本來就以 FAX 為前提在運作、承辦人員年紀大了拜託不動網路輸入、或是自家原本就不是「能拜託對方」的關係——這類客戶的 FAX，現實上要當作會留存好幾年來看待。

於是「讀取」這條路線就派上用場了。重點是，這兩條路線並非互斥。

路線 對象 自家的改變 客戶端的改變
捨棄（轉移到網路收單・CSV 匯入） 願意配合的客戶 開發接收端、整備主檔 下單方式改變
讀取（本文） 戒不掉 FAX 的客戶 接收資料化與讀取流程 沒有

「讀取」路線最大的優點，就是完全不要求客戶做出任何改變。在分階段轉移的雙軌並行期間，它也能發揮降低 FAX 通道處理成本的作用。反過來說，極限也很明確：讀取準確度不會達到 100%，確認的工序會一直留存。若想讀取每個客戶版面都不同的單據，會被模型的維護消耗掉。正因如此，才要用「能轉移的就轉移，剩下的客戶就讀取其 FAX」這種組合來思考。

另外，以電子郵件附件送達的 PDF 訂購單，已在「用 Power Automate 自動處理電子郵件送達的訂購單・請款單 PDF ── 儲存・分類・通知・讀取的設計」中處理過。若 FAX 是以電子郵件轉發的方式接收，接收之後的設計就會和這篇文章、以及電子郵件那篇文章匯流。

3. 前提：以「資料」接收 FAX ── 維持紙本狀態就無法開始

能傳給 AI Builder 的只有檔案。若運作方式是把複合機印出來的紙再重新掃描一次，只是把手工從抄錄換成掃描，稱不上自動化。第一步該做的，是打造一條收到的 FAX 不經人手、直接以檔案形式保存的路徑。現實中有兩個選項。

  • 複合機的 FAX 轉發功能。多數業務用複合機可以不列印，直接把收到的 FAX 存到指定資料夾（掃描到資料夾），或以電子郵件附件的形式轉發。設定方式要查機種手冊並與維護廠商確認。
  • 雲端 FAX 服務。把 FAX 號碼整個轉移到雲端服務，以電子郵件或 API 的形式接收成 PDF。不必更換複合機就能資料化，是否可攜碼、費用體系則需依服務逐一確認。

無論走哪條路徑，都建議把落地點統一到 SharePoint 文件庫。SharePoint 連接器有「當建立檔案時（僅限屬性）」觸發程序和「取得檔案內容」動作，能直接把保存動作當成後續讀取流程的起點。8 若以電子郵件轉發方式接收，可以在前段加入用共用信箱接收、把附件 PDF 存到 SharePoint 的流程（這個設計與電子郵件附件那篇文章的第 3～4 章完全相同）。

檔案格式有一點要注意。依複合機的轉發設定不同，FAX 有時會以 TIFF 格式保存。AI Builder 的文件處理訓練模型時只能使用 PDF、JPG、PNG，但在雲端流程中執行已訓練好的模型時，也能處理 TIFF。3 話雖如此，考量到範例的準備工作，轉發設定上乾脆選擇輸出 PDF 會比較單純。同時也要記住，可處理的檔案最大 20 MB，若是圖片則限制在 50×50～10,000×10,000 像素。3

4. AI Builder 的文件處理能做到什麼

自訂模型的訓練機制

AI Builder 的文件處理，是一種用範例單據來訓練「這份單據的哪個位置寫了什麼」的自訂 AI 模型。建立模型時首先要選擇文件類型。1

文件類型 適合的單據 特徵
固定範本文件 請款單、訂購單、送貨單等，項目位置依版面固定的單據 訓練速度快。只有這種類型支援準確度分數的評估功能5
一般文件 契約書、書信等沒有固定結構的文件 擷取能力強，但訓練較費時
請款單 想在預先建置的請款單處理模型上加入自訂欄位時 內建欄位＋額外訓練

若是客戶的定型訂購單，基本上就選固定範本文件。接著要定義想擷取的資訊：可以指定欄位（訂單編號、訂購日期、客戶名稱、送貨地點等）、表格（品項、數量、單價的明細列）以及核取方塊。1

訓練的單位是集合。集合指「同一版面的單據群組」，像客戶 A 的訂購單和 B 公司的訂購單這類版面不同的單據，要分到不同集合。每個集合要上傳至少 5 份範例文件，並標記欄位與表格的位置以進行訓練。每個集合最多可放 20 份範例，每個模型最多可建立 200 個集合。13 高品質文件通常 5 份就夠，但低品質掃描則建議使用 15～20 份，這是官方 FAQ 的建議。2

建立模型的步驟

訓練與測試都不消耗點數9，所以先實際做做看是最快的路徑。畫面上的操作順序如下（選單名稱依 Microsoft Learn 的表記）。1

  1. 登入 Power Apps（make.powerapps.com）或 Power Automate（make.powerautomate.com）。
  2. 開啟左側窗格的 … More（其他） > AI hub。常用的話釘選起來會比較方便。
  3. 從 Discover an AI capability 中選擇 AI models。
  4. 選擇 Extract custom information from documents（從文件擷取自訂資訊）。
  5. 選擇 Create custom model，就會啟動精靈。
  6. 在 Choose document type 選擇文件類型。若是客戶的定型訂購單，選 Fixed template documents（固定範本文件）。
  7. 在 Choose information to extract 中，用 +Add 定義想擷取的項目。可以加入文字、數字、日期、核取方塊、表格，數字的小數點符號（. 或 ,）、日期的年月日順序、表格的欄位結構都在這裡指定。
  8. 依版面建立集合，各自上傳5 份以上的範例（JPG、PNG、PDF）。若有兩家客戶樣式不同，就建立兩個集合。
  9. 在每份上傳的範例上，標記出對應到步驟 7 所定義項目的位置。
  10. 用 Train 進行訓練，再用 Quick test 試讀。確認讀取結果符合預期後就發佈（公開），使其能被流程呼叫。

若自家的範例還沒準備好，只想先試試操作，也可以用 Microsoft 提供的範例資料來建立模型。1

除了步驟 6 選擇的文件類型之外，模型內部還有一個文件智慧（Document Intelligence）的版本（v4.0／v3.1），由最後編輯的時間點決定，可在 Settings > Published model version 中確認。表格與儲存格能取得信心分數的是 v4.0，較舊的模型只要重新編輯、重新訓練並重新發佈，就會升級到 v4.0。1

日文與手寫的支援情況

處理日文單據時該確認的重點，可以在 Microsoft Learn 上確認如下。

  • 無論固定範本文件還是一般文件哪種訓練類型，支援語言都包含日文。3
  • 官方 FAQ 明確寫著「文件處理能擷取印刷文字與手寫文字」。2

不過，這裡要老實說清楚。「支援」與「自家的 FAX 能以實用準確度讀取」之間是有距離的。FAX 解析度低，字跡模糊、糊掉、歪斜是家常便飯。手寫的數量訂正或潦草的備註能不能讀到，要看單據的書寫方式而定。文件處理的模型訓練與測試都是免費的9，所以在做導入決策之前，務必用實際收到的 FAX PDF 本身當範例來訓練、測試，看看在自家單據上的準確度。若用乾淨的原始 PDF 訓練，卻拿去用在 FAX 上運作，很容易變成測試與正式環境的畫質差太多、準確度出不來的失敗案例。

與預先建置的模型有何不同

AI Builder 也提供不需訓練的預先建置模型。代表性的是請款單處理模型，它能不經訓練就擷取請款單編號、請款日期、支付金額等共通欄位，支援語言也包含日文。10 若要處理請款單，先試試這個是最快的路徑。

另一方面，沒有針對訂購單的預先建置模型。訂購單、發包單、送貨單這類版面因公司而異的單據，官方 FAQ 也把它們列為固定範本文件自訂模型的典型例子2，本文主題的 FAX 訂購單正屬於自訂模型的範疇。

5. 流程整體設計 ── 加入人工確認

整體樣貌如下。關鍵在正中央的「人工確認」，省略這一步的全自動架構，理由詳見後述，並不推薦。

高信心低信心從客戶收到 FAX複合機的 FAX 轉發 / 雲端 FAX 服務以 PDF 存入資料夾・電子郵件存入 SharePoint 文件庫含接收日期時間的唯一檔名觸發雲端流程當建立檔案時AI Builder - 處理文件擷取訂單編號・客戶・交期・明細信心分數判定例如 - 主要欄位是否全部達 0.9 以上?記錄到收單台帳清單狀態 - 已自動讀取・未確定請承辦人員確認Teams 通知+原始 PDF 連結與原本核對後修正並確定狀態 - 已確認彙整清單確認後確定狀態 - 已確認輸入到核心系統 ── 僅狀態為「已確認」的資料列CSV 匯入 / Power Automate for desktop

讀取步驟

流程中會把訓練並已發佈的模型、以及從 SharePoint 取得的檔案內容，一起傳給「處理文件（Process documents）」動作（這個動作在 2025 年 5 月從「從文件擷取資訊」改名而來）。輸出內容包含所定義各欄位的值（{欄位} value）與信心分數（{欄位} confidence score）、以及表格中每個儲存格的值與分數。若是多頁文件，也可以指定要處理的頁面範圍以抑制消耗量。4

實作上要注意的是，擷取值一律以字串形式回傳。要把數量或金額放進台帳的數值欄位，必須用 int／float 運算式轉換，貨幣符號或空白則用 replace 運算式移除。日期也要用 formatDateTime 運算式統一格式。4 FAX 號碼或訂單編號的全形半形差異，若在這裡先做正規化，後續核對會輕鬆許多。

確認步驟 ── 這裡是關鍵

讀取結果的確認，有以下兩種容易組成的方式。

  1. 用台帳清單的狀態欄位來輪替確認。收單台帳以 SharePoint 清單管理，讀取結果先以「待確認」狀態登錄，由承辦人員在清單上對照原始 PDF（附件或連結）進行修正，再把狀態改為「已確認」。以改為已確認為觸發，啟動後續處理。把台帳從 Excel 換成 SharePoint 清單的設計，在「將 Excel 台帳置換為 SharePoint 清單」中有詳細說明。
  2. 用 Teams 的核准來輪替確認。使用核准（Approvals）連接器的「開始並等待核准」動作，搭配自訂回應，讓承辦人員從「就這樣登錄」「需要修正」之類的選項做判斷。核准的建立方式與回應的處理方式，在「用 Power Automate 建立核准流程 ── 將紙本與電子郵件的簽呈・申請電子化」中有詳細說明。11

無論哪種方式，通知都應集中到 Teams 頻道，並且務必附上原始 FAX PDF 的連結。12 確認作業的本質是「讀取結果與原本的核對」，若打開原本很費工夫，確認就會流於形式。

從台帳到核心系統

把已確認的資料放進核心系統的方法，取決於核心系統端的輸入口。若有 CSV 匯入功能，把已確認資料整理成 CSV 匯入是穩妥的做法。若沒有匯入功能、只能靠畫面輸入，則可以選擇用 Power Automate for desktop 進行畫面操作的自動抄錄。這種設計在「用 Power Automate for desktop 將登錄至核心系統的作業自動化」中有處理。整個流程的錯誤處理（讀取失敗時的通知、重新執行）則可直接套用「Power Automate 的錯誤處理與重試設計」的思路。

6. 與準確度共處 ── 即使無法全部讀取也能見效

用信心分數分流

只要以「讀取有可能出錯」為前提，設計的核心就會落在信心分數的用法上。分數介於 0～1，愈接近 1 表示擷取值正確的可能性愈高。4 實務上，可以這樣分流：

  • 訂單編號、客戶、交期、明細等主要欄位全部達到門檻（例如 0.9）以上 → 以「已自動讀取」登錄到台帳。承辦人員只需彙整清單確認，做一次確定操作即可
  • 只要有一項未達門檻 → 以「待確認」轉交承辦人員。在通知中明確列出分數偏低的欄位，讓承辦人員與原本核對後修正

實作只需要一個「條件」動作即可完成。在「處理文件」之後放一個條件，從動態內容清單中選擇 {欄位名稱} confidence score 與門檻值比較。若要一次判定所有主要欄位，可將條件切換成詳細模式（運算式），用 and 串接。以下 <...> 依 Microsoft Learn 的範例表示「從動態內容插入的位置」。4

and(
  greaterOrEquals(<訂單編號 confidence score>, 0.9),
  greaterOrEquals(<客戶名稱 confidence score>, 0.9),
  greaterOrEquals(<交期 confidence score>, 0.9)
)

寫運算式時有兩個重點。

  • 值與分數的型別不同。 {欄位} value 是字串，而 {欄位} confidence score 則以 0～1 的 float 回傳，因此分數可以直接做數值比較。只有在把金額或數量本身用於條件判斷時，才需要用 float() 或 int() 轉換。4
  • 明細表格的儲存格也附有分數（{表格名稱}{欄位名稱} confidence score）。不過，一旦參照了表格的欄位，該動作就會自動進入「Apply to each」之中。若想一次判定整個明細，可以準備一個變數（例如把 minScore 初始化為 1.0），在迴圈內比較每一列的分數並保留最小值，等迴圈結束後再與門檻值比較一次，這種做法比較好處理。4 另外，只有文件智慧 v4.0 的模型才能取得表格與儲存格的信心分數。1

只要在條件的「是」那一側把資料登錄到收單台帳為「已自動讀取」，「否」那一側分流到 Teams 通知與待確認登錄，這一章談的分流就直接變成了流程本身。

要注意的是，高信心的一側並不代表可以省略確認本身。分數只是表示「正確的可能性高」，不是正確性的保證。即使高信心，讀取錯誤仍可能發生，因此只把人做過確定操作、狀態為「已確認」的資料列送進核心系統這道關卡，不論分數高低都必須維持。分數能改變的是確認的輕重（要一次彙整確定，還是要一筆一筆修正），而不是有沒有確認。

門檻值一開始不要定死，應該在正式運作後，一邊觀察「被判定為自動處理、結果其實是錯的件數」一邊調整。重要的是，錯誤的成本是不對稱的。就算判定過度傾向待確認，頂多只是稍微增加一點確認的工夫；但若讓誤讀自動放行，就可能演變成出貨錯誤。猶豫的話，門檻值就設高一點。

FAX 畫質這個宿命

文件處理的規格要求寫著「從紙本掃描而來的應為高品質影像」、「內嵌文字的 PDF（文字型 PDF）比較理想，不會有亂碼或位置偏移」。35 FAX 正處於這個理想的對立面。即便如此，仍有一些能做的事。

  • 把訓練範例換成實際的 FAX。如前所述，用與正式運作時相同的畫質來訓練是第一步。低品質影像官方建議把範例增加到 10～15 份以上。5
  • 向傳送端爭取品質。對主要客戶，有時可以拜託對方「用高畫質（精細）模式傳送」。雖然大方向是不要求客戶改變，但只是傳送鍵旁邊的一項設定，屬於比較容易開口的部分。
  • 不要勉強讀取讀不了的單據。字跡嚴重模糊、幾乎全是手寫這類單據，往往會常態性地落入待確認。這時也需要判斷把該客戶排除在讀取對象之外，維持原本的手動輸入。

版面因客戶而異的問題

訂購單的版面有多少客戶就有多少種。文件處理的設計是用集合來吸收這個差異，可以依版面分別建立集合，彙整成一個模型（最多 200 個）。3 不過集合愈多，範例收集與標記、準確度驗證、追蹤版面變更等維護成本就愈高。只要客戶改了訂購單樣式，那個集合就得重新訓練。

正因如此，起步方式不是「全部讀取」，而是「只讀取件數排名靠前的客戶的定型訂購單」。假設 FAX 收單每月 600 件，前三大客戶就占了 350 件，那麼用 3 個集合（各 5～20 份範例）建成的模型，就能覆蓋將近六成的抄錄工作。剩下的維持手動輸入即可。這正是分階段轉移文章中「從效果最大的地方依序著手」原則的讀取版，網路轉移時用的客戶分類（A／B／C）也能直接沿用。先在試點打造模式、測量效果之後再增加集合，這樣的推進方式能避免模型維護被消耗殆盡。

也要確認一些細節限制。目前不支援跨頁的欄位，以及跨頁換行的明細列。3 若有很多客戶的訂購單常常跨多頁，明細的設計就要多加留意。

7. 授權與費用概念 ── 點數這種消耗模式

AI Builder 的動作與 Power Automate 的授權是分開的，每次執行都會消耗一種用量計費的容量。不知道這一點就開始建置，正式上線後很容易撞上 NoCapacity 系列的錯誤。9

機制是這樣的：文件處理會依處理的頁數消耗點數（即使頁面上沒有想擷取的資料也一樣消耗）。2 消耗速率依功能而異，官方的速率表中，自訂模型的文件處理是每頁 100 個 AI Builder 點數，預先建置的請款單處理等則是每頁 32 點數，在 Copilot 點數體系下，內容處理則定義為每頁 8 個 Copilot 點數。6

點數的取得途徑，過去主要有以下兩種。9

  • AI Builder 容量附加元件：每個附加元件 100 萬點數
  • Premium 授權內含的起始點數：每張 Power Automate Premium 授權附帶 5,000 點數

點數以租用戶為單位統一管理，由管理員分配到各環境使用。試算一下，Premium 內含的 5,000 點數，相當於自訂模型文件處理的 50 頁份。若單頁訂購單每月不到 50 件，內含的份額就夠用；若每月 600 件，就需要購買附加元件或 Copilot 點數，大致是這種規模感。

消耗量的概算

金額會因時間點與合約而異，本文不涉及，但消耗的點數量可以自己用公開的速率表算出來。自訂模型的文件處理是每頁 100 個 AI Builder 點數，在 Copilot 點數體系下，內容處理則是每頁 8 個 Copilot 點數。6 只要乘上每月的讀取頁數即可。

每月讀取頁數 AI Builder 點數 Copilot 點數 大致情況
50 頁 5,000 400 剛好落在 Power Automate Premium 1 張內含的起始點數（5,000）範圍內
600 頁 60,000 4,800 內含份額不夠。約消耗容量附加元件（100 萬點數）的 6%
3,000 頁 300,000 24,000 消耗容量附加元件 1 個的三成

計算方式與 Microsoft FAQ 中的範例相同（收據處理 32,000 件×32 點數＝1,024,000 點數 → 用 1 個附加元件＋5 張 Premium 補足）。9 實際支付金額，是把這個消耗量乘上自家合約單價（附加元件或 Copilot 點數的價格、匯率與折扣的適用情況）算出來的。Power Platform 授權指南（PDF）中有速率卡，估算時請務必參照該處與最新的價格資訊。9

要注意的是，消耗量以月為單位重置，用剩的點數不會結轉到下個月。9 若配合旺季高峰多準備一些，淡季用不完的份額就會浪費掉。用頁面範圍指定來減少無謂的讀取、把讀取對象限縮在件數排名靠前的客戶，這類設計層面的節省，會直接反映在費用上。

點數用盡時的因應方式

若流程因 NoCapacity、EntitlementNotAvailable、QuotaExceeded、No capacity was found、Credit usage exceeds allocation 之類的錯誤而失敗，要先確認環境的點數分配。流程設計工具會出現「All AI Builder credits in this environment have been consumed（此環境的 AI Builder 點數已全數用盡）」的修復面板。9

確認與因應的步驟如下。9

  1. 在 Power Platform 管理中心 開啟 Licensing（授權） > Capacity add-ons（容量附加元件） > Summary 分頁，確認已購買、已分配、已消耗的點數數量。
  2. 各環境的消耗量可在 AI Builder 消耗報表中確認。把當月的量加總，就是該環境的月消耗量。
  3. 若不足，就從同一畫面的 Add-ons 分頁，用 Assign to an environment 重新分配到該環境（可以把整個租用戶或其他環境的餘量調過來）。
  4. 若還是不夠，就要考慮加購容量附加元件（僅限既有客戶，可購買至 2026 年 11 月 1 日）或購買 Copilot 點數・允許用量計費。

這裡有一項規格需要特別留意。一旦為某個環境分配了點數，該環境就不會自動使用租用戶尚未分配的點數。9 「明明整個租用戶還有剩，卻只有這個環境停住了」這種事故，不知道這項規格的話就找不到原因。反過來說，沒有進行過分配的環境，會使用租用戶未分配的份額。在正式運作前，請先與管理員確認要放讀取流程的環境屬於哪一種狀態。

不過，這套體系現在正處於轉換期。2025 年 10 月，Microsoft 宣布了AI Builder 點數的階段性終止。自 2025 年 11 月 1 日起，新客戶將無法購買 AI Builder 容量附加元件，且預定於2026 年 11 月 1 日終止附加元件的續購，並廢除 Premium 授權內含的起始點數。AI Builder 的功能本身不會消失，仍可透過 Copilot 點數繼續使用。轉換期間的優先順序是：先消耗 AI Builder 點數，用盡後改消耗 Copilot 點數，兩者都沒有時執行就會被封鎖。7

簡而言之，「讀取需要依執行量支付額外成本，而這個貨幣正在轉換中」。這篇文章不會列出具體金額，但請用每月的 FAX 件數×頁數，對照速率表估算消耗量，並搭配最新的價格資訊確認。Power Automate 端的授權（標準／進階連接器的分界）已在「Power Automate 的授權與標準/進階連接器的分界」中整理過。

8. 該選哪一條路 ── 判斷表

FAX 訂購單的因應方式，並不是只有 AI Builder 讀取這個答案。以件數、客戶數、單據的定型程度來畫線，大致會呈現以下樣貌。

狀況 現實的選擇
FAX 收單每月數十件，客戶也不多 維持手動輸入。讀取的建置與維護成本往往超過效果。光是把接收自動化為 PDF 並保存下來，就有其價值
件數多，但集中在少數客戶的定型訂購單上 AI Builder 讀取的理想戰場。從排名靠前的客戶的集合開始，搭配確認流程運作
件數多，客戶也願意配合（能以資料形式建立訂單） 轉移到網路收單・CSV 匯入才是正道。可以直接消除讀取這道工序本身，轉移期間殘留的 FAX 則併用讀取
以手寫為主・每次版面都不同・畫質不佳 讀取準確度不穩定。可以維持手動輸入，同時把交涉的重點放在網路、電話等接收方式本身的變更上
特定產業交易量大，存在標準格式 可考慮EDI。若有業界標準，長期來看會比自製讀取更便宜（參見「什麼是 EDI？如何讓企業間收發訂單更輕鬆」）
想同時推動轉移與 EDI，但投資餘力是課題 有時可利用省力化投資的補助制度（參見「省力化投資補助金能讓 FAX 收單網路化嗎」）

判斷的感覺上，數一數「同一版面的單據每月會送來幾張」是最快的方法。若這個數字很大的客戶有好幾家，讀取就能發揮效果。若每種版面的張數不多、客戶數卻很多，讀取模型的維護就划不來，這時網路轉移、EDI，或維持手動輸入反而更合理。

還有一點不能忘記，就是確認工序的定位。讀取自動化的效果並不是「抄錄歸零」，而是「抄錄變成確認」。做效果評估時，請用同一把尺，比較導入前的輸入時間與導入後的確認・修正時間。同時追蹤待確認率（未達門檻、轉交人工的比例）與被判定為自動處理但其實誤讀的件數，能作為調整門檻值與新增集合的判斷依據。

9. 總結

FAX 送達的訂購單自動化，可以設計成與「捨棄 FAX」不同的另一條路線。整理如下。

首先，用複合機的轉發功能或雲端 FAX 服務把收到的 FAX 轉成 PDF，集中存到 SharePoint。維持紙本狀態什麼都無法開始。接著，把 AI Builder 的文件處理自訂模型，鎖定在件數排名靠前的客戶的定型訂購單上進行訓練。每個集合至少 5 份，FAX 品質的話範例要多一些，訓練要用實際收到的 FAX。然後，用信心分數把自動與待確認分流，加入人工確認之後，才流向台帳與核心系統。不追求全自動，反而能讓導入更快、運作更穩定。

在費用方面，估算用量計費的點數消耗，以及確認從 AI Builder 點數轉移到 Copilot 點數的時程，都是必要的功課。而且，讀取終究只是「與戒不掉的 FAX 共處」的手段。願意配合的客戶轉移到網路收單或 CSV 匯入，剩下的 FAX 用讀取來減輕負擔。把這兩條路線組合起來，手動輸入的總量才會降到最低。

從 FAX 收單的 PDF 化，到讀取流程的設計、確認步驟與核心系統串接的建置，再到與網路轉移的組合方式，若想一邊驗證自家單據能做到什麼程度一邊推進，歡迎從下方的相關諮詢領域與我們聯繫。

相關文章

相關諮詢領域

合同會社小村軟體可就 FAX、電子郵件送達單據的讀取自動化設計、確認流程的建置，到與既有銷售管理系統・核心系統的串接，提供諮詢服務。

參考連結

  1. Microsoft Learn, Create a document processing custom model。關於模型建立精靈的操作順序（AI hub > AI models > Extract custom information from documents > Create custom model > 選擇文件類型 > Choose information to extract > 建立集合並上傳範例 > Train > Quick test）、3 種文件類型（固定範本文件／一般文件／請款單）、欄位・表格・核取方塊的定義與數字的小數點符號・日期順序指定、可用範例資料建立模型、集合為「同一版面單據的群組」、每個集合至少需要 5 份範例（JPG／PNG／PDF）且最多可建立 200 個集合、文件智慧 v4.0 與 v3.1 的差異（v4.0 支援表格・儲存格的信心分數與簽名偵測）及在 Settings > Published model version 中確認的方式。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, FAQ for document processing。關於固定範本文件適合請款單、訂購單、送貨單、能同時擷取印刷文字與手寫文字、高品質文件 5 份即足夠而低品質掃描建議使用 15～20 份、每個集合最少 5 份・最多 20 份的最佳實務，以及即使頁面上沒有擷取對象也會依頁數消耗點數。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft Learn, Requirements and limitations for a document processing model。關於固定範本文件・一般文件兩種類型皆支援日文、支援格式（PDF／JPG／PNG，建議使用文字型 PDF）、TIFF 無法用於訓練但已訓練模型的雲端流程執行可處理、最大 20 MB・圖片 50×50～10,000×10,000 像素的限制、紙本掃描應為高品質影像、每個模型最多 200 個集合、跨頁欄位・明細列不受支援。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  4. Microsoft Learn, Use a document processing model in Power Automate。關於「處理文件（Process documents）」動作（2025 年 5 月由「從文件擷取資訊」改名而來）、輸出每個欄位・表格儲存格的值與 0～1 的信心分數、可用頁面範圍指定抑制消耗量、擷取值一律以字串回傳需用 int／float／replace／formatDateTime 運算式轉換、以 Is Inline 條件排除簽名影像。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. Microsoft Learn, Improve the performance of your document processing model。關於低品質影像應使用 10～15 份以上等更多範例、文字型 PDF 比影像型文件更理想且掃描 PDF 會被當成影像處理、準確度分數只有固定範本文件類型的模型才能取得、版面不同的文件應分到不同集合。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Overview of licensing (AI Builder capability rate table)。關於自訂文件處理每頁 100 個 AI Builder 點數、請款單・收據等分析每頁 32 點數、在 Copilot 點數體系下內容處理為每頁 8 個 Copilot 點數，這類依功能而異的消耗速率。 ↩ ↩2 ↩3

  7. Microsoft Learn, End of AI Builder credits。關於 2025 年 10 月宣布的 AI Builder 點數階段性終止、2025 年 11 月 1 日起停止向新客戶銷售附加元件、2026 年 11 月 1 日終止附加元件續購並廢除起始點數、AI Builder 功能本身可透過 Copilot 點數繼續使用、AI Builder 點數→Copilot 點數的消耗優先順序，以及兩者皆無時的封鎖機制。 ↩ ↩2

  8. Microsoft Learn, Microsoft SharePoint Connector in Power Automate。關於「當建立檔案時（僅限屬性）」觸發程序、「取得檔案內容」「建立檔案」等動作，以及可以文件庫的保存動作為起點組成流程。 ↩

  9. Microsoft Learn, Licensing and AI Builder credits。關於 AI Builder 容量附加元件為 100 萬點數、Power Automate Premium 授權內含 5,000 點數、點數以租用戶為單位彙整並分配到環境使用、容量不足時會出現 NoCapacity／EntitlementNotAvailable／QuotaExceeded 等錯誤而遭封鎖，流程設計工具會顯示修復面板、Power Platform 管理中心的 Licensing > Capacity add-ons（在 Summary 分頁確認消耗、在 Add-ons 分頁的 Assign to an environment 進行環境分配）、以消耗報表確認各環境的消耗量、分配到環境後不會自動切換使用租用戶未分配的份額、消耗量每月 1 日重置且用剩不會結轉、模型的訓練與測試免費、起始點數將於 2026 年 11 月 1 日刪除、估算的思路（收據 32,000 件×32 點數的範例）與授權指南 PDF 中的速率卡。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  10. Microsoft Learn, Invoice processing prebuilt AI model。關於預先建置的請款單處理模型能不經訓練擷取請款單編號、請款日期、支付金額等共通項目、支援語言包含日文（日本）、輸入格式（JPEG／PNG／PDF，20 MB 以下）。 ↩

  11. Microsoft Learn, Get started with approvals。關於「開始並等待核准」動作，以及可自行定義回應選項的自訂回應等核准類型。 ↩

  12. Microsoft Learn, Send a message in Teams using Power Automate。關於結合 SharePoint 的「當建立檔案時（僅限屬性）」觸發程序與 Teams 的「在聊天或頻道中張貼訊息」動作所組成的通知流程。 ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

AI Builder 能讀取日文的 FAX 訂購單嗎？
有相當高的可能性可以讀取。AI Builder 的文件處理自訂模型，無論是固定範本文件還是一般文件哪種訓練類型，都支援日文，官方 FAQ 也明確寫著支援手寫文字的擷取。不過 FAX 的解析度低，容易出現字跡模糊與歪斜，實際能讀到什麼程度要看單據與線路品質而定。在做導入決策之前，強烈建議先用實際收到的 FAX PDF 當作範例來訓練模型，確認在自家單據上的準確度。
訓練模型需要多少張範例單據？
同一版面的單據匯集而成的「集合」，每個至少需要 5 份範例文件。每個集合最多可登錄 20 份，高品質文件通常 5 份就夠，但像 FAX 這種低品質掃描，官方建議使用 15～20 份。若不同客戶的訂購單版面不同，就要依版面分別建立集合（每個模型最多 200 個集合），先從件數最多的客戶的定型訂購單開始，是比較務實的做法。
讀取結果可以直接登錄到核心系統嗎？
不建議在無人監督下直接流入系統。AI Builder 的擷取結果每個欄位都會附上 0～1 的信心分數，因此務必加入一個分流：分數高的自動記錄到收單台帳，分數低的則通知承辦人員，讓他們與原始 FAX 影像核對後再確認、修正。只把已確認的資料送進核心系統的輸入作業（CSV 匯入或用 Power Automate for desktop 抄錄），才能避免讀取錯誤直接演變成出貨錯誤的事故。
使用 AI Builder 需要什麼費用？
AI Builder 的動作每次執行都會消耗一種用量計費的點數。文件處理依讀取的頁數消耗，自訂模型的消耗速率比預先建置的模型更高。過去是以 AI Builder 點數（容量附加元件或 Power Automate Premium 內含的 5,000 點數）來支應，但 2025 年 10 月宣布了 AI Builder 點數的階段性終止，正逐步移轉到 Copilot 點數。Premium 內含的起始點數將於 2026 年 11 月 1 日終止，新導入時務必確認最新的授權體系。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽