在「把 FAX 收單搬到網路上」一文中,我們整理了將 FAX 收單網路化設計為「減少需要人工輸入的訂單件數」而非「廢除 FAX」的分階段轉移實務做法。
本文是它在費用層面的續篇。主題是:這項投資能否使用補助金。
FAX 收單的網路化・自動匯入,就性質而言是「把原本由人工進行的輸入作業替換為系統」的投資。這與以因應人手不足為目的的中小企業省力化投資補助金理念方向一致,其中尤其是可以將訂製系統作為對象的一般型,會成為值得考慮的候選。
不過,「成為候選」與「獲得採選」之間是有距離的。本文將從承接開發的立場出發,整理目錄訂購型與一般型的差異、收發訂單系統的開發在省力化投資中該如何定位,以及申請前應確認的要件與注意事項。
制度的要件・金額・時程會因每次公募而異。本文係根據2026 年 7 月時點的公開資訊撰寫,實際申請時請務必在官方網站確認最新的公募要領。
1. 先講結論
- FAX 收單的網路化・CSV 自動匯入,只要能定量展示人工輸入工時的削減效果,就有可能成為省力化投資補助金(一般型)的檢討對象
- 但前提是必須依規定基準證明自身現處於人手不足的狀態。沒有人手不足實際情況、只是「單純提升效率」的案件不屬於對象
- 投資規模也有下限。必須是包含單價 50 萬日圓(未稅)以上機械裝置・系統建置費用的設備投資,僅進行小額改造或導入工具的案件無法申請(金額標準請以公募要領為準)
- 與既有銷售管理系統對接的訂製開發屬於一般型。若現成的登記產品就足夠,則屬於目錄訂購型
- 審查的基礎在於「哪項作業、每月幾小時、如何減少」的逐項累積。轉移計畫中的現狀整理可以直接沿用
- 勞動生產力・加薪等要件與返還條款屬於經營層面的承諾。應在申請前檢討其可達成性
- 核准決定前下單不屬於補助對象・補助金為事後撥付這項通用規則,在本制度中同樣適用
- 無論是否使用補助金,分階段轉移的設計(雙軌並行期、主檔整備)都不能省略
2. 目錄訂購型與一般型 ── 先分清楚在討論哪一種
中小企業省力化投資補助金分為兩種類型,性質差異相當大。在討論收發訂單系統之前,先把這一點區分清楚。
| 目錄訂購型 | 一般型 | |
|---|---|---|
| 對象 | 事務局登記的現成省力化產品(自動售票機、自動倉儲、送餐機器人等) | 訂製設備・系統,多項設備的組合 |
| 自由度 | 從登記產品中選擇 | 可依自身業務進行配置 |
| 手續 | 相對簡易(與銷售事業者共同申請) | 包含擬定事業計畫在內的正式申請 |
| 與收發訂單系統開發的適配度 | 若有符合的登記產品 | 與既有系統對接・因應自身特有流程的開發屬於這一類 |
FAX 收單網路化在現實中真正需要的,正如「把 FAX 收單搬到網路上」一文中所整理的那樣,與其說是網路收單畫面本身,不如說是CSV 匯入、與既有銷售管理系統的對接、與商品・客戶主檔的整合這類貼合自身現狀的客製化開發。由於這個性質,很難套用從現成產品目錄中選擇的方式,檢討的重心會落在一般型上。
反之,若自身的需求用登記產品中的收發訂單產品或 OCR 產品就能直接滿足,那麼手續較輕的目錄訂購型,或數位化・AI 導入補助金(以導入事務局登記的現成 IT 工具・雲端服務為對象的制度)就已足夠。把這三種制度的使用場景歸納成一句話,如下所示。
- 只需導入登記的現成省力化產品(機器・設備) → 省力化投資補助金的目錄訂購型
- 只需導入登記的現成IT 工具・雲端服務 → 數位化・AI 導入補助金
- 需要因應既有系統對接或自身特有業務流程的客製化開發(訂製) → 省力化投資補助金的一般型
訂製開發應先確認現成產品是否足夠,這個順序即便在使用補助金時也不會改變。整體制度的運用場景劃分,已在「外包系統開發能否使用補助金」中整理過。
3. FAX 收單網路化可以說明為「省力化投資」
省力化投資補助金的目的,是為因應人手不足,透過運用數位技術的設備・系統來減少原本由人工進行的作業。FAX 收單的人工輸入,正好完全符合這個框架。
- 對照訂購單進行的抄錄輸入 → 替換為透過 CSV 匯入・網路收單完成的自動登錄
- 誤讀・輸入錯誤的確認與更正 → 替換為機械式的驗證(代碼比對、數量檢查)
- 應對「是否已收到」的確認電話 → 替換為訂單確認的自動回覆
重要的是,不要用定性的「提升效率」來說明,而要用時間的累積來展示。
現狀: 每筆訂單的輸入・確認時間 平均 8 分鐘 × 月 1,200 筆 = 月 160 小時
計畫: 將主要客戶(佔件數的 7 成)轉移到 CSV 匯入・網路
效果: 月 160 小時 × 0.7 = 每月削減 112 小時的人工輸入作業
(剩餘 3 成的 FAX 部分 月 48 小時暫時繼續維持)
※以上數字為說明用範例。
在代入自身數值時,只需填寫以下空格,就能得到同樣形式的累積計算。
【現狀】
每筆訂單的輸入・確認時間 ______分鐘
× 月間訂單件數 ______件
= 現狀的人工輸入工時 ______小時/月
【轉移率】
轉移到網路收單・CSV 匯入的客戶訂單件數占比 ______%
(依客戶的訂單件數由多到少排列,決定轉移到第幾家為止)
【效果】
現狀的人工輸入工時 ______小時/月 × 轉移率 ______%
= 可削減的人工輸入工時 ______小時/月
剩餘的人工輸入工時 ______小時/月,暫時繼續維持 FAX・電話方式
「每筆的時間」請不要憑感覺估算,哪怕只有幾天份的數據,也請實際測量。這一個數字支撐著整個事業計畫的依據,無論是在審查中還是在公司內部凝聚共識時,都是最會被追問的部分。
構成這個累積計算的素材,正是轉移計畫文章中提到的第0階段現狀整理(依客戶列出訂單件數・管道・輸入時間的清單)本身。也就是說,無論是否使用補助金都需要進行的現狀整理,可以直接作為事業計畫的依據資料。與其說是為了補助金特別製作資料,不如說是只要把轉移計畫做扎實,申請所需的材料自然就齊備了,兩者是這樣的關係。
此時,還要注意讓計畫與分階段轉移的設計不相矛盾。如果以「所有客戶一齊轉移到網路」為前提的「理想值」來誇大削減效果,不僅計畫的可行性會受到質疑,還會給自己背上無法達成的目標。應以仍保留雙軌並行期為前提,用實際可行的削減量來擬定計畫。
4. 申請前應確認的要件 ── 加薪不是「書面上的記載事項」
在進入要件的話題之前,先掌握與投資判斷直接相關的補助率與補助上限金額的大致標準。官方制度說明中所列出的數值如下。
| 分類 | 補助率 |
|---|---|
| 中小企業 | 1/2 |
| 小規模企業者・小規模經營者、重整企業 | 2/3 |
| 員工人數 | 補助上限額 | 大幅加薪的情況 |
|---|---|---|
| 5 人以下 | 750 萬日圓 | 1,000 萬日圓 |
| 6~20 人 | 1,500 萬日圓 | 2,000 萬日圓 |
| 21~50 人 | 3,000 萬日圓 | 4,000 萬日圓 |
| 51~100 人 | 5,000 萬日圓 | 6,500 萬日圓 |
| 101 人以上 | 8,000 萬日圓 | 1 億日圓 |
這個金額會因每次公募而變動。以上為 2026 年 7 月時點官方網站所刊載的數值,實際申請時請務必以最新的公募要領為準進行確認。「大幅加薪的情況」是指在加薪的基本要件(同一頁面所述為每人平均薪資總額的年平均成長率 +3.5%)之上再加碼,合計達成 +6.0% 以上的情況。上限額會因此提高,但相對地達成義務也會隨之加重。
若是在保留既有銷售管理系統的基礎上只新增收單入口的架構,投資額幾乎不會達到上限。也就是說,對這個規模的案件真正發揮作用的,與其說是上限額,不如說是補助率。若中小企業適用 1/2 的補助率,被認定為補助對象的經費中剩餘的一半,將作為永久性的自付部分留下;而被判定為補助對象外的經費,則要在此之外全額自付。請以此為前提進行投資判斷。
一般型不僅要求省力化的效果,對整個事業還設有基本要件。根據官方制度說明及公募要領所示的框架,會要求以下內容(數值・細節會因每次公募而變動,請務必以最新的公募要領為準進行確認)。
- 申請人現處於人手不足的狀態(以加班時間狀況、發布求才卻招募不到人的狀況、員工人數減少等公募要領所規定的基準來證明)
- 屬於包含單價 50 萬日圓(未稅)以上機械裝置・系統建置費用的設備投資(僅進行小規模改造或導入小額工具,無法滿足投資規模的標準)
- 以一定的年平均成長率提升勞動生產力的事業計畫
- 加薪相關目標(依公募回次不同,所使用的指標・數值也不同,例如薪資總額或每人平均薪資總額的增加率。若申請時設定的目標未能達成,設有依達成程度返還補助金的條款。另設有天災等情況下的豁免規定)
- 關於事業場內最低薪資水準的要件
第一項「處於人手不足的狀態」,是與省力化效果的定量化互相獨立的入口要件。即便能夠展示人工輸入工時的削減,如果人手充足(在招募或加班方面無法證明人手不足的實際情況),也無法作為本制度的對象事業成立。這種情況下,就需要考慮目的相近的其他制度或地方政府的補助金。
需要注意的是,加薪目標附有返還條款這一點。使用哪種指標會因每次公募而不同,但無論哪種情況,都會針對申請時自身設定・表明的目標進行是否達成的判定。這並非「在申請書上寫上就好」那種事項,而是要在數年間切實執行加薪的經營承諾。由於制度的設計理念是把省力化帶來的餘力用於加薪,方向上是自然的,但能否在自身的獲利計畫中實際達成,需要在申請前冷靜檢討。
這方面的判斷不屬於開發廠商的職責範圍。請透過商工會議所、萬事支援據點(よろず支援拠点)、中小企業診斷士等支援機構・專家,或Mirasapo plus等公開資訊進行確認。Mirasapo plus 是由中小企業廳營運的中小企業・小規模事業者支援資訊網站,彙整了補助金・扶助金的概要以及支援機構的查詢方式。
5. 時程安排與開發的推展方式
即便是省力化投資補助金,補助金通用的規則同樣適用。
- 核准決定前簽約・下單所產生的費用不屬於補助對象
- 補助金採核實撥款(事後撥付)方式,開發費須全額墊付
- 需在事業實施期間的期限之前完成驗收・付款,並提出成果報告
依時間順序排列,各環節的位置關係如下。
flowchart TD
A["申請準備<br/>現狀整理・取得報價・擬定事業計畫"] --> B["公募截止・審查"]
B --> C["入選公布"]
C --> D["核准申請"]
D --> E["核准決定<br/>從此可以下單"]
E --> F["簽約・下單"]
F --> G["開發"]
G --> H["驗收・付款<br/>需在事業實施期限前完成"]
H --> I["成果報告"]
I --> J["核實撥款<br/>補助金入帳在此"]
需要留意的重點有兩個。第一,若在核准決定之前的環節就簽約・下單,該筆費用就不屬於補助對象。入選公布只是「事業計畫已獲選」的通知,此時還不能下單。第二,補助金入帳排在最後。開發費的支付發生在驗收之後不久,因此從那時到入帳為止的這段期間,需要由自家公司全額墊付。
因此,開發時程不應從期望上線日開始推算,而應以核准決定日(可下單日)與事業實施期限(驗收・付款的完成期限)這兩點為基準逆向推算來安排。關於逆向推算的具體思路,以及核准決定前可以進行的準備工作(需求整理・取得報價・擬定事業計畫),已在「使用補助金進行系統開發的推展方式」中詳細整理。
若要舉出 FAX 收單網路化特有的一個注意點,那就是如何劃定要在補助事業期間內完成的範圍。分階段轉移本來就是以年為單位、按試點→推展→落實推進的工作。而補助事業則有實施期間的期限。因此,
- 補助事業的範圍:建置 CSV 匯入・網路收單機制、與銷售管理系統對接、直到在試點客戶處上線運作為止
- 補助事業之後:客戶的依序轉移、依管道測量件數、縮減 FAX 占比
像這樣把「機制的完成與初期上線」劃定為補助事業,將客戶推展作為之後的營運來規劃,是比較實際的切分方式。事業計畫上的效果測量(依管道的訂單件數、人工輸入時間)可以直接使用與轉移計畫相同的測量項目,因此只要在開發階段就把記錄件數・時間的機制內建進去,就能用同一份資料完成補助事業的效果報告與轉移的進度管理。
6. 常見的誤解與注意事項
| 誤解・容易踩的坑 | 實際情況 |
|---|---|
| 「有補助金了,乾脆全面翻新吧」 | 扣除補助率後的自付部分,以及上線後的維護費用仍然存在。只新增收單入口的架構(保留既有系統的思路)在投資與轉移風險上往往都更小 |
| 「申請了就會通過」 | 一般型是伴隨事業計畫審查的競爭性制度。會根據省力化效果的依據以及要件達成的可行性來評估 |
| 「已經入選了,那就開始開發」 | 原則上要在核准決定之後才能下單。搶跑下單不屬於補助對象 |
| 「加薪要件只是書面上的事」 | 存在未達成時的返還條款,應作為數年間的經營承諾來判斷 |
| 「效果寫成『提升效率』就好」 | 需要「哪項作業每月減少多少小時」的逐項累積,應從測量現狀的作業時間開始 |
| 「補助金能省下這部分錢,可以做得便宜一點」 | 補助金為事後撥付。開發費須全額墊付,因此資金週轉計畫應按沒有補助金的情況來擬定 |
總結
- FAX 收單的網路化・CSV 自動匯入,只要能定量展示削減人工輸入工時這項省力化效果,就有可能成為省力化投資補助金(一般型)的檢討對象
- 若現成產品足夠,就考慮目錄訂購型或數位化・AI 導入補助金;若需要伴隨既有系統對接的訂製開發,則考慮一般型,按這樣的順序進行檢討
- 事業計畫的依據,可以直接沿用轉移計畫第0階段(依客戶整理件數・管道・輸入時間)的成果
- 勞動生產力・加薪的要件與返還條款屬於經營層面的承諾。由於指標・數值會因每次公募而異,應在最新的公募要領中確認後,於申請前檢討其可達成性
- 核准決定前下單不屬於補助對象・補助金為事後撥付。時程與資金週轉應以逆向推算來安排
- 作為補助事業劃定範圍的,是到「機制的完成與試點上線」為止。客戶推展則作為後續營運持續進行
補助金是能為應該進行的投資提供助力的制度,但並不會替代投資判斷本身。健全的順序應該是:先透過分階段轉移的設計,確認 FAX 收單網路化對自身而言是否是必要的投資,若該計畫與制度相符,再加以運用。
給正在考慮收發訂單系統省力化投資的您
合同會社小村軟體承接活用既有銷售管理系統或 Windows 業務應用程式的 CSV 匯入・網路收單對接之設計與實作。若您正在考慮使用補助金,我們可以協助製作申請所需的報價單・系統構成圖・工時削減試算等依據資料,並在核准決定之後,提出以事業實施期限為基準逆向推算出的開發計畫。
我們不提供申請代辦或入選與否的判斷,但「究竟應該開發到什麼程度」「能否保留既有系統」這類投資範圍的整理,正是開發端諮詢的範圍所在。歡迎您從盤點現有收單管道開始,隨時與我們聯繫。
相關文章
共用相同標籤的最新文章。能以相近的主題延伸理解。
把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務
說明將 FAX 收單轉移到網路收單或 CSV 匯入的實務作法。整理一次性全面網路化容易失敗的原因、FAX 與網路雙軌並行期的設計、商品與客戶主檔的整備、CSV 匯入這種中間形態,以及如何讓客戶配合的分階段轉移步驟。
系統開發外包能否使用補助金 ── 依目的分類的制度地圖與發包前應了解的陷阱(2026年度版)
系統開發外包能否使用補助金?本文從發包方的角度,整理「IT導入補助金無法用於客製化開發」的原因、以ものづくり補助金為代表依目的分類的制度地圖,以及核准決定前禁止發包這項陷阱。
使用補助金的系統開發推進方式 ── 從核准決定回推的時程與事業計畫書製作實務
使用補助金的系統開發,推進方式與一般開發有所不同。本文從實務角度解說以核准決定日為起點的回推時程、獲選與核准決定的差異、為核銷撥款做準備的資金周轉,以及事業計畫書製作的分工。
什麼是數位發票(Digital Invoice)?──與「把請款單 PDF 寄送 email」有何不同
數位發票是指將請款資訊從賣方系統直接以資料形式傳遞給買方系統、無需人工介入的機制。本文將淺顯解說它與 PDF 請款單的差異、與日本發票制度(Invoice 制度)的關係、Peppol・JP PINT 的運作方式、與電子帳簿保存法的關聯,以及中小企業的入門方法。
什麼是 EDI?如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動
EDI 是一種讓訂購單、請款單等交易資料能在企業之間的系統中直接交換的機制。本文將淺顯易懂地說明 EDI 與傳真、電子郵件的差異、如何減少手動輸入與抄錄錯誤,以及將接單、庫存、出貨、請款串連起來的優點。
相關主題
與本文相近的主題頁面。以本文為起點,可進一步連到相關服務與其他文章。
Windows 技術主題
彙整 KomuraSoft LLC 關於 Windows 開發、故障調查與既有資產活用文章的主題中心。
與本主題相關的服務
本文連結到以下服務頁面,歡迎從最接近的入口查看。
Windows 應用程式開發
與既有銷售管理系統對接的網路收單・CSV 自動匯入之設計與實作,屬於業務應用程式開發的諮詢範圍,我們也能協助製作申請補助金所需的報價單・系統構成圖・工時削減試算等依據資料。
Windows 軟體維護 & 現代化
不重做銷售管理系統、只新增收單入口以減少人工輸入的架構,可以作為既有 Windows 軟體的改造與維護來規劃。
技術諮詢 & 設計審查
省力化效果的試算方法、包含雙軌並行期在內的轉移計畫,以及確認開發範圍是否因遷就補助金而被過度擴大,都屬於伴隨設計審查的技術諮詢範圍。
常見問題
整理諮詢這個主題時常見的問題。
- FAX 收單的網路化屬於省力化投資補助金的對象嗎?
- 只要能依循制度「因應人手不足」的宗旨,定量地展示人工輸入工時的削減效果,就有可能成為一般型的檢討對象。但前提是申請人須依規定基準證明自身現處於人手不足的狀態,實際能否成為對象,取決於整體事業計畫與公募要領所列要求(人手不足的狀態・勞動生產力・加薪等)的符合程度。這並不保證一定能獲選,請務必確認公募要領,並視需要向支援機構諮詢。
- 目錄訂購型與一般型應該選擇哪一種?
- 目錄訂購型是從事務局登記的現成省力化產品中選擇並導入的方式,手續相對簡單。一般型則可以將符合自身業務的訂製設備・系統作為對象,需要與既有銷售管理系統對接的收發訂單系統開發,正是這一類的候選。按「現成產品足夠就選目錄訂購型,需要與既有系統對接或因應自身特有業務流程才選一般型」這樣的順序來考慮,是比較自然的做法。
- 擔心無法滿足加薪要件,還是應該申請嗎?
- 省力化投資補助金(一般型)除了要求提升勞動生產力,還要求設定加薪相關的目標,若申請時設定的目標未能達成,有可能被要求返還部分補助金。加薪目標所使用的指標(薪資總額、每人平均薪資總額等)及數值會因公募回次而異。這是經營層面的承諾,而不僅僅是申請文件上的記載事項。請務必在最新的公募要領中確認要件細節與返還條件,並在申請前結合自身的獲利計畫評估是否能實際達成。若難以判斷,建議向商工會議所或中小企業診斷士等專家諮詢。
- 使用補助金時,開發可以從什麼時候開始?
- 原則上,在核准決定日之前簽約・下單所產生的費用不屬於補助對象。入選公布與核准決定是兩道不同的手續,只有在核准決定之後才能下單。不過,需求整理、業務流程盤點、取得報價、擬定事業計畫等工作,都可以在核准決定之前進行。反而是申請前把這部分工作做得越扎實,計畫的說服力以及核准決定後的啟動速度就會越好。