簡短的答案： 絕對不要把已簽署的報價單重新打成帳單。重新打字正是項目內容悄悄跑掉、稅額被重新計算、客戶當初同意的金額和你最後開出的金額不知不覺出現落差的環節。改用轉換功能，項目、稅額和客戶資訊都會原封不動地帶過去，帳單才能真正對應到當初簽署的那份文件。
現在是週二晚上 9 點 40 分，你坐在廚房餐桌前開帳單。已簽署的報價單開在手機上，靠在一個咖啡杯旁邊，你正一行一行把它抄進帳單裡：同一個客戶、同一個地址、同樣的十四個項目、同樣的稅額。抄到第九行的時候，你把 1,840 美元打成了 1,480 美元。
沒有人發現這個錯誤。客戶二話不說就付了這張帳單，因為客戶不會抱怨金額算少了的帳單，於是 360 美元的利潤就這樣憑空蒸發，沒有人知道它曾經存在過。或者，錯誤方向反過來，客戶真的發現了，這下帳單上其他每一個數字都會被拿出來質疑——而在收到那封郵件之前，這個工程原本一切都很順利。
不管哪一種情況，這個錯誤都不是在 9 點 40 分那一刻造成的。它是在整套流程要求你把同樣的十四行內容打第二次的那一刻，就已經注定發生了。
為什麼重新打一次報價單會讓你賠錢？
把報價單抄進帳單裡，感覺就像是一件單純的文書工作，而這正是它危險的原因：它往往發生在你疲憊的時候，枯燥到讓人注意力渙散，而它出錯的方式又非常安靜，不會發出警訊。
少算的錯誤是無聲的。 兩個數字調換了位置、抄的時候漏掉了一筆 60 美元的項目、數量 12 被打成了 2。這些錯誤都不會主動跳出來告訴你。客戶依照帳單上的數字付款，工程結案，而你之後的工程成本核算會顯示出一個利潤問題，你很可能會誤以為那是定價出了問題。
多算的錯誤是很大聲的。 同樣的打字錯誤，如果方向相反，就會被發現，而代價不只是那 360 美元。真正的代價是，客戶從此開始逐項審查任何掛著你名字的東西。對帳單的信任是非有即無的，只要一個數字錯了，就會整個翻盤。
稅額這一項，本身就是另一個陷阱。 重新打字，意味著你要靠記憶重新套用稅務處理：哪些項目要課稅、稅率多少、課哪一部分。一旦弄錯，你不是得在申報時自己吞下差額，就是得寄一封誰都不想寫的更正郵件給客戶。
而且重新打字還有時間成本。 因為靠重新打字開帳單是件苦差事，你會一直等到某個清閒的夜晚才動手。旺季裡清閒的夜晚少之又少，結果已完工的工程就這樣拖了好幾天都沒開帳單。每拖一天，都等於你在無息幫客戶的工程墊款，而理由僅僅是因為資料輸入太麻煩了。
解決之道不是在晚上 9 點 40 分打字時更加小心。而是徹底消除那第二次打字的動作。
工作獲利分析計算機可以幫你確認一件已完工的工程，獲利是否達到你報價時預估的水準。
轉換功能：帳單是報價單升級而來的
在 Zeus 裡，已簽署的報價單可以直接轉換成帳單。所有項目會完全依照報價單原樣帶過去：說明、數量、單價，一應俱全，連帶稅務處理方式也會一起帶過去。客戶資訊和工程資訊也會一併帶過去，因為這張帳單就是在報價單所屬的同一個工程底下建立的，而不是一份需要你重新填寫收件人資訊的獨立文件。
原本要花掉一整個晚上的苦差事，現在變成工程結束前最後三十秒的動作。你可以就在車道上，趁卡車還沒開走之前，直接從客戶簽署的那份紀錄裡產生帳單。
這裡還藏著一個容易被忽略的第二個好處：客戶認得出這張帳單。 當一張帳單上的項目、用詞和總額，跟他們當初簽署的那份文件一模一樣，它讀起來就像是一次確認，而不是一份需要重新細看的新文件。客戶熟悉的帳單會很快被付清；陌生的帳單則會被仔細研究。一張重新打字的帳單，說明用詞不太一樣、項目順序也變了、總額看起來差不多卻又哪裡不對，即使每個數字都是對的，也會招來對方仔細核對。
使用轉換功能，不代表你就不能再編輯了。有時候帳單和報價單本來就該有差異：客戶在工程進行中取消了某個項目、換了一種材料。你可以在送出之前先調整。重點在於你的起點：你是從那份已簽署的文件開始，只修改真正有變動的地方，而不是從一張空白頁面開始，靠自己重新拼湊出整份內容。
變更單併入同一個工程
工程中途的變動，正是靠重建帳單內容出錯機率最高的地方。報價單上寫的是 8,400 美元。接著客戶加了一個插座、核准了一段圍籬工程，又取消了置物棚的層架，這一切都是在三次對話和一串簡訊裡談定的。到了開帳單的時候，靠重新打字的承包商，這時候就成了考古學家，得靠記憶和翻找訊息記錄，重新拼湊出最終的數字。
如果變動是以變更單的形式，寫進同一個工程裡（標價、簽署、和原始報價單一起歸檔），那麼最終的帳單就不再是一場事後重建。它就是已簽署的報價單，加上所有已核准的變更，而每一項變更，都是客戶已經簽過名的文件。帳單上不會有任何新的資訊。
這徹底改變了交付時的對話方式：
「這張帳單和你 4 號簽的那份報價單一致，再加上你核准的三項變動：11 號加的插座、15 號的圍籬工程，還有取消掉的置物棚層架。金額跟你手上已經有的那幾份文件完全一致，上面沒有任何新的東西。」
試著用一張手動拼湊出來的帳單，配上三次現場對話的記憶去講出這番話。兩者的差別不在於說話是否得體，而在於一個版本可以在十秒內拿簽名去核對，另一個版本則做不到。
帳單編號如果出現跳號，會發生什麼事？
有一件平常看起來很小、到了報稅季卻一點都不小的事：帳單編號。
手動編號的帳單很容易出亂子。你可能跳過某個號碼、重複用了同一個號碼，或是因為手機和筆電各自有自己的一套編號邏輯，而同時跑出兩套編號序列。這一切看起來都無傷大雅，直到某個以審查為職責的人（記帳士、年底時的會計師、稅務審查員）問起 1047 號帳單到底怎麼了。帳單序號出現斷層，看起來就像有一張帳單被刪掉了，而「我想我大概是跳過了吧」這種答案，絕對不是你想拿來解釋自己營收記錄的說法。
在 Zeus 裡，帳單編號由伺服器統一發放，對整間公司來說是一套沒有斷層的連續序列。你永遠不用自己挑編號，兩台裝置也永遠不會撞號，整套序列不會有任何需要解釋的空缺。這樣的設計還帶來一個實際上的結果：因為編號是由伺服器發放，一張在離線狀態下先寫好草稿的帳單，會在同步時才拿到正式編號。序列之所以能保持乾淨，正是因為不允許任何一台裝置自己去猜編號。
與此配套的規則是：出錯的帳單要作廢，而不是直接刪除。作廢的帳單依然留在紀錄裡，標記為作廢，讓整個序列保持完整，歷史紀錄也保持誠實。一套可以被悄悄刪除紀錄的開票系統，它產出的報表你就沒辦法完全信任——連你自己的都一樣。
用批次開票清掉週五累積的工程
就算有了轉換功能，真實的一週結束時，你手上還是可能堆著一疊工程：週一到現在完工了四個工程，一張帳單都還沒開，因為每收尾一個工程，下一個工程馬上又接著開始。
批次開票就是為了應付這種累積的工程而存在的。你不用一個一個處理已完工的工程，而是一次批次產生好幾個工程的帳單：每一張都根據各自的已簽署報價單和已核准的變更單建立，依序編號，隨時可以送出。週五累積的工程，原本是一個你不斷延後的夜晚，現在只要幾分鐘就能搞定。
這背後的經濟邏輯很枯燥，卻很真實：在工程結束當天就送出的帳單，能立刻啟動付款的計時器，而這個時候工程成果（以及你贏得的那份好感）在客戶心中還很新鮮。趁客戶還在欣賞成果的時候送出的帳單，得到的待遇會比兩週後才送到、像是陌生人寄來的帳單好得多。哪一種帳單會在客戶的收件匣裡躺得比較久，不需要統計數字也能猜到答案。
這個功能解決不了什麼
這一點值得說清楚，因為一個宣稱能解決所有問題的工具，通常什麼問題都解決不了。
除非你開口要它做，否則它不會替你去催款。 自動逾期提醒是有的——「催收逾期帳單」會在帳單到期後第 3、7、14 天寄郵件提醒客戶，之後就停止——但它預設關閉，要你親手打開才會運作，而多數承包商都讓它維持關閉。未付款的帳單會出現在「提醒」裡，也就是「需要處理」的待辦清單，並附上你的應收帳款帳齡狀況，讓你不會漏看任何一筆。但催款的電話或訊息，還是得由你自己開口。工程結束當天送出、附上付款資訊的帳單，能降低客戶付款的阻力；但它取代不了第十五天你親自打的那通電話。
它會忠實地複製一份錯誤的報價單。 轉換功能只是把已簽署的內容原樣帶過去。如果報價單一開始就把工程報得太便宜，帳單就會用一模一樣的格式，忠實地複製這個過低的價格。估價的紀律要從源頭去把關，沒有任何開票機制能事後幫你修正。
訂金改變的是餘額，不是開票的邏輯。 記錄在工程底下的訂金和部分付款，會反映在應付金額裡，讓客戶清楚看到自己已經付掉的部分確實有折抵進去。但這一切都必須建立在款項一入帳，你就真的把它記錄下來的前提上。這套系統反映的是你的記帳工作，不會替你完成記帳這件事。
Zeus 在這裡扮演的角色
九點四十分犯的那個錯不是打錯字，而是一套要求你把同樣十四行輸入兩次的流程；而第二次輸入，只有在帳單就建立在工程結束的地方時，才會消失。
一份已簽署的報價單，會在同一個工程上轉成帳單。品名、數量和單價都照報價的原樣帶過去。稅以稅率的形式儲存，並在文件開立時凍結在上面，所以客戶同意過的內容，事後不會悄悄漂移；金額以完整的分為單位保存，所以中途不會有任何四捨五入。掛在那個工程上、已簽署的變更單也會一起帶過來，這正是最後的總額不需要重新拼湊的原因。帳單號碼由伺服器發出，對這間公司而言是一條沒有缺口的連號。在沒有訊號的車道上建立帳單，它會先寫進手機，等訊號回來再取號，而這是把工程跑起來的一部分，不是晚上的雜務。
報價單、變更單、對著餘額記下的款項，以及一份工程紀錄還帶著的其他東西，全都放在同一個工程上。報價、開立帳單，以及每個地址的紀錄，一開始都不用花錢，而且不會用完，而更大的規模多加了些什麼，定價頁面上有寫。只要報價單住在你手機裡的這個應用程式，下一張帳單就可以從路邊寄出，而不是從餐桌上。
星期二早上九點四十分，馬克杯撐著手機。在那些項目從來不必輸入第二次的版本裡，帳單四點二十分就離開了車道，客戶認得上面的每一行，而那個晚上就只是一個晚上。
常見問題
如果最終價格和已簽署的報價單不一樣，該怎麼辦？
如果是因為工程範圍改變，答案就是在變動發生的當下就開一份變更單，標好價格、取得簽署，並附加在這個工程底下，這樣一來，帳單就會自動等於「報價單加上已核准的變更」。在轉換的當下編輯項目也是可行的，有時候也的確該這麼做（取消某個項目、更換某項材料），但每一次編輯，都是偏離了客戶當初簽署的內容，所以在你送出帳單時，值得附上一句說明，而不是讓對方自己發現一個沒人解釋過的差異。
可以在工程還沒完工之前，先開部分帳單嗎？
可以。對於規模較大的工程來說，訂金、部分付款和付款排程都是很常見的做法：一開始先收一筆款項，達成某個里程碑再收一筆，完工時收尾款。把每一筆款項都記錄在工程底下，能讓即時餘額保持準確，這樣一來，最後開帳單時要談的只是剩餘金額，而不是重新協商整個總金額。
為什麼我不能自己選帳單編號？
因為帳單序列的價值，恰恰就在於它枯燥無趣：單一序列、沒有斷層、沒有重複，不用向記帳士或稅務審查員解釋任何東西。由伺服器統一發放編號，才能在多台裝置、以及一個支援離線使用的應用程式裡，確保這個保證始終成立。而這裡的取捨（離線建立的帳單草稿要等到同步時才會拿到正式編號），正是讓整套序列無可挑剔的關鍵所在。
客戶已經付過訂金了，帳單上會顯示嗎？
會顯示，前提是訂金在收到的當下就有被記錄下來。已記錄的款項會計入工程的餘額，讓客戶能看到原始金額、已經付了多少，以及還剩多少——這正是一張能自己回答問題的帳單，和一張會讓客戶打電話來問問題的帳單之間的差別。
ZEUS