一張單據進來之後，系統做了什麼
抽取一張發票在 2026 年已經是商品化服務，一份大約幾美仙。 所以真正的產品不在「讀得懂」，在於讀完之後的三件事： 怎樣編碼、什麼時候該停手、以及怎樣證明給核數師看。
五個階段
-
收件
每間公司有一個專屬電郵地址；供應商直接寄，同事直接轉寄。手機拍照走一個網頁（不是要下載的 App）。平台（Stripe、Shopify、WooCommerce）用 webhook 自動進來。每一個檔案先做 SHA-256 內容雜湊——同一份檔案不會被處理兩次。
-
抽取
多模態模型按嚴格的 JSON schema 輸出，並且每一個欄位各自附上置信度。這一點很重要：發票號碼看不清而總額很清楚，是兩件不同的事，覆核的人需要知道分別。高金額或低置信的單據會再用第二個模型跑一次——兩家答案不一致，本身就是最強的訊號。
-
解析
供應商用名稱、稅號和銀行帳號做模糊比對。重複偵測是一條加權規則，不是單一欄位比較：同一供應商、金額相差 0.5% 以內、日期相差七天以內、發票號碼相似度高——四項一起看。新供應商一律轉人手，不猜。
-
編碼
不是用所有客戶的數據訓練一個通用模型。是把「供應商＋明細描述」向量化，在這一間公司自己的已編碼交易裡找最相近的紀錄，提議它過去用過的科目、稅項和成本中心。同一個供應商大約十五張單據之後就穩定，而且可以解釋——這比任何置信度數字都有說服力。
-
入帳或轉人手
通過閘門就寫入 Xero，帶 idempotency key、附上原始單據，並在寫入前先在本地檢查會計期間有沒有鎖上。不通過就進例外佇列，並且說明為什麼在那裡。
閘門為什麼要有兩個獨立條件
模型自報的置信度不是校準過的概率。單靠它去決定「要不要無人入帳」， 等於把一個會計後果押在一個沒有校準的數字上。 所以閘門的另一半必須是確定性的、可審計的、和模型完全無關的。
| 模型那一半 | 確定性那一半 |
|---|---|
| 關鍵欄位（供應商、總額、幣別、日期）的最低置信度高於門檻 | 金額低於該公司的自動入帳上限 |
| 若觸發交叉核對，兩個模型的答案一致 | 該供應商已有足夠歷史樣本（預設十五張） |
| — | 不是新供應商、不疑似重複 |
| — | 會計期間未鎖、政策檢查（預算、成本中心、審批人）通過 |
頭九十天，全部人手覆核
自動入帳上限設為零。系統照常運作、照常提議，但每一筆都由人確認——同時記錄它「本來會怎樣做」。只有在幾百張真實單據上量到錯誤率之後，才開始放寬。
永遠抽查一成
即使放寬了，已自動入帳的分錄長期抽查 10%，並把覆核紀錄寫進佐證。抽樣錯誤率超過門檻就自動收緊閘門。這是我們敢開自動入帳的唯一理由，也是說服核數師的關鍵。
佐證：這是產品真正的交付物
Xero 在每一筆 API 寫入的使用者欄位上，一律記錄為「System Generated」。 換句話說，從 Xero 裡面完全分不出一筆分錄是被人覆核過，還是凌晨三點無人入帳的。 Scalebook 存在的一半理由，就是補上這個分別。
- 逐筆的輸入——指向那一份原始檔案，不是一批的摘要
- 模型與提示版本——生成式輸出不可重現，所以記下「當時用了什麼」比記下「我們用 AI」有意義得多
- 輸出與置信度——連同當時的判斷依據（例如「歷史 47 次一致」）
- 覆核的人、時間、以及改了什麼——橡皮圖章式的批准不是佐證
- 不可竄改的版本歷史——修改以新紀錄出現，不覆蓋舊的；每一筆雜湊鏈接上一筆，事後回頭改動驗得出來
一條沒有例外的規則
已入帳的分錄沒有編輯功能。錯了就沖銷，再入正確的一筆，兩筆都留在帳上並附上原因。悄悄改掉一筆已入帳的分錄，正是會摧毀整個佐證體系的那個動作。
為什麼第一階段建在 Xero 之上，而不是一開始就自己做總賬
我們的方向是最終取代它（見先做層，再做賬）。但入口不能是總賬——三個理由。
時間
寫一個正確的總賬、稅務引擎、多幣種重估和審計軌跡是兩年工作，做完只是追上 2015 年的水準。那兩年應該先用在沒有人做過的部分——佐證層。
信任
核數師已經接受 Xero。這份信任在第一階段借得到；自己建卻要從零累積，而且要累積很多年。我們打算賺這份信任，但不是用一句宣傳語去賺。
覆蓋
Xero 在香港、新加坡、馬來西亞、澳紐都有。我們往區域走的時候，這一層不用重做。
一個我們不會迴避的限制
Xero 的文件明確寫著：透過 API 進行銀行對賬的那一下不支援，而且沒有計劃支援。所以我們的做法是：在銀行紀錄到達之前，先把編碼正確的帳單建立好，讓 Xero 自己的對賬畫面顯示為完全吻合的建議——一次過按確認。那一下永遠留在 Xero，我們不假裝可以拿走它。