如何製作總額精準的收據

收據是一段簡短的書面紀錄，用以確認購買商品或服務的款項已經付清，內容列出購買項目、收費金額以及找零金額，而製作收據最可靠的方法，就是立即在使用者本機的工具中擷取這筆交易，並由該工具依據您所輸入的數值計算出每一個金額。最快產出整潔、逐項列出的收據的方式，就是輸入商家名稱、付款日期、收據編號、貨幣，以及每一筆明細項目的數量與單價；加入任何固定折扣、百分比稅額與小費；輸入顧客實際交付的金額；接著讓計算機根據這些確切的數字產生小計、稅額、總計與找零。由於收據是用以確認一筆已完成的付款，而不是用來請求付款，因此一個良好的工作流程，會在顧客交付的現金少於計算總計時，拒絕列印任何標示為已付款的內容。本指南所介紹的工具 Lizely Receipt Maker 遵循這項規則，所有的運算都在您的瀏覽器中於本機執行，並可讓您列印結果，或將其另存為可稍後重新開啟的獨立 HTML 檔案。

每張收據都必須包含的內容

無論由誰開立，每一張可用的收據都帶有相同的六大類資料，以便這份文件在數個月後仍可由顧客、記帳人員或稅務機關閱讀。抬頭部分識別商家、付款日期，以及一個唯一的收據編號，使該文件可從分類帳中被調出。內文將每一筆已付款的品項或服務列為獨立的一行，包含數量、單價以及計算後的金額。頁面中段顯示財務調整項目：從小計中扣減的任何固定折扣、套用於折扣後小計的百分比稅額，以及任何固定小費。頁尾則列出最終總計、顧客交付的金額，以及找回的零錢。僅填寫這些類別中的某一部分，會使整份文件變成一張手寫便條而非收據，這就是為什麼一個能同時提示使用者填寫每一類欄位的工具，能讓多筆交易之間的結構保持一致。

Receipt Maker 為何能解決這個問題

手動製作收據的挑戰在於每個金額都必須在心算中計算，而只要出現一次算術失誤，就會讓一張已付款的收據變成顧客的爭議。浮點數計算機常常會顯示令人意外的尾數：$0.10 加上 $0.20 可能顯示為 $0.30000000000000004，因為其底層的二進位表示法無法精確表示這些小數。一個在整數最小貨幣單位中執行所有金額運算的工具——在加總前先把 $1.00 轉換為 100 分——就能完全消除這一類錯誤。Receipt Maker 將這種作法套用於整張收據，包括每一筆明細項目，其中的單價會與通過驗證的數量相乘，並只有在乘法運算完成後才四捨五入到最近的最小貨幣單位。對於空白、負數、非數值或超出支援範圍的輸入，會予以拒絕而非以零靜默取代，因此一個誤打的按鍵不會悄悄使總計失效。再加上要求交付金額必須等於或大於計算總計的產生防護機制，最終得到的收據，其金額與實際交付的現金完全一致。若想親自體驗，請在瀏覽器中開啟 Receipt Maker；所有資料都不會離開您的裝置，因此您可以用測試資料自由操作。

分三個階段建立收據

整個工作流程可分為三個階段，每個階段涵蓋表單上一組相關的欄位。第一個階段確立收款對象與時間：商家名稱、付款日期、收據編號，以及該筆交易所使用的顯示貨幣。第二個階段記錄購買內容與付款方式：每一筆明細項目的數量與單價，接著是固定折扣、百分比稅額、固定小費，以及顧客交付的金額。第三個階段是驗證：仔細閱讀預覽內容，確認每一個總計與顯示的找零金額，接著列印收據或將其另存為獨立 HTML 檔案以供留存。完整流程如下：

輸入商家名稱、付款日期、收據編號，並選擇該筆交易所使用的顯示貨幣。
將每一筆已付款項目以獨立一列加入，填入其數量與單價，接著輸入固定折扣、百分比稅額、固定小費，以及顧客交付的金額。
產生收據，預覽中確認每一筆金額與顯示的找零，接著列印此頁面或下載獨立 HTML 檔案。

在進行任何編輯後，先前產生的結果會自動清除，因此下一次預覽永遠反映最新的輸入內容，不會與較早輸入所產生的結果混淆。每張收據最多支援 100 筆明細項目，任何未通過驗證的數值都會被回報而非自動取代，以便在產生收據前先修正根本問題。固定折扣不得超過其欲扣減的小計，而超出支援金額範圍的總計也會被標記，以便重新檢視計算結果。

運算如何保持精確

Receipt Maker 透過在進行任何加法或減法之前，先將每一個兩位小數的金額輸入轉換為整數最小貨幣單位，來避免浮點數尾數的產生。對於以兩位小數顯示的貨幣而言，一個主單位會變成 100 個最小單位，因此 $0.10 會變成 10，$0.20 會變成 20，而 10 加上 20 會精準地回傳 30 個最小單位，再由渲染端格式化為 $0.30。單價最多接受兩位小數，數量最多接受三位，而明細金額只有在通過驗證的數量乘上整數單價之後，才會四捨五入到最近的最小貨幣單位。計算順序是明確的，並與預覽中顯示的規則一致：

步驟	動作	產生的數值
1	加總每一筆通過驗證的明細金額	小計
2	扣減固定折扣（不得超過小計）	折扣後小計
3	將稅率百分比套用於折扣後小計，並四捨五入至最近的最小貨幣單位	稅額
4	加入固定小費	總計
5	將顧客交付金額與總計進行比較	找零 = 交付金額 − 總計，否則停止產生

一個完整的範例可從頭到尾展示計算順序。購買了兩項商品：1 × $12.50 以及 3 × $4.00。明細金額分別為 $12.50 與 $12.00，因此小計為 $24.50。$2.00 的折扣使折扣後小計變為 $22.50。對 $22.50 課徵 8% 的稅額，精準得到 $1.80，因為 $22.50 × 0.08 = $1.80，無需四捨五入。$3.00 的小費使總計變為 $27.30，計算方式為 $22.50 + $1.80 + $3.00。若顧客交付 $30.00，則找零為 $2.70，計算方式為 $30.00 − $27.30。收據產生成功；反之，若僅交付 $25.00，產生程序將會停止，不會輸出任何已付款的收據。

收據與發票的功能性差異

這類文件最容易令人混淆之處，在於收據與發票之間的差異。發票是向顧客請求付款：它記載到期日、列出應付金額，且可能在任何款項實際流動之前就已開立。收據則是確認一筆已經發生的付款，記錄顧客交付的金額，並顯示找回的零錢。將兩者混淆，會使一份禮貌的付款請求變成誤導性的已付款紀錄，而這正是 Receipt Maker 設計上要避免的失敗情境。兩者的功能區分整理如下：

面向	收據	發票
用途	確認一筆已完成的付款	向顧客請求付款
產生防護機制	若交付金額低於總計，則拒絕列印	可針對任何請求金額產生，包含未來的到期日
必填欄位	顧客交付金額、應找零金額	到期日、應付餘額
典型後續步驟	顧客保留文件以供存查	顧客於到期日前安排付款
處理此任務的合適工具	Receipt Maker（本指南介紹）	Invoice Generator

若您需要記錄部分付款、設定到期日，或顯示未結清餘額，請使用 Invoice Generator 或支援付款分攤與稽核紀錄的記帳系統；Receipt Maker 的設計刻意限定於單筆已完成的付款，並不維護顧客帳戶、連續分類帳、庫存、退款、作廢或支付處理商紀錄。

本機處理與隱私界線

每一次運算、每一次預覽渲染、每一張列印頁面，以及每一個下載的 HTML 檔案，都是在當前的瀏覽器中產生。商家名稱、明細項目、價格、備註、稅率、小費以及任何付款數值都保留在裝置上；在您輸入或產生收據的過程中，不會有任何數值被上傳至 Lizely。這種純本機的設計帶來兩個實際影響。第一，您可以在店裡的筆電上使用此工具，無須擔心顧客資料被傳送給第三方服務。第二，由於下載或列印的 HTML 頁面可由日後開啟它的任何人進行編輯，因此它無法被視為獨立的防詐騙證據。具備權威性的付款證據——支付處理商紀錄、收銀機日誌、銀行紀錄或簽署過的合約——仍應與任何列印的收據一併保存。

列印或儲存完成的收據

當預覽中的每個總計都確認無誤後，可使用兩種輸出方式。「列印收據」動作會開啟瀏覽器的列印對話框，您可以將頁面傳送至紙本印表機，或在作業系統支援此選項時，另存為 PDF。此對話框與 MDN Window.print 參考文件中所描述的介面相同，因此各現代瀏覽器的操作體驗一致。「下載 HTML」動作則會儲存一份獨立檔案，內容包含預覽中所見的通過驗證的數值，並附加一份合規免責聲明，其格式可供任何一般瀏覽器稍後重新開啟並列印。由於該檔案僅為 HTML，可與其他記帳文件一同歸檔保存，無需原始工具即可重新開啟；它採用的是 MDN Blob 參考文件中所記錄的同一種 Blob 基礎下載方式。

What the Tool Will Not Replace

It is worth being explicit about what the Receipt Maker does not do, because the limits are part of what makes the result trustworthy. The tool does not contain tax tables, product exemptions, jurisdiction-specific rounding mandates, sequential ledger numbering rules, or any authentication of the merchant or the payment. It does not create a tamper-evident signature, a fiscal receipt, or an archived compliance record, and it does not integrate with a payment processor, a cash register, or a point-of-sale system. Treat the produced page as a readable convenience document for one completed payment; keep the payment processor statement, the signed agreement, or the cash register journal as the authoritative evidence for any dispute, reimbursement, warranty, insurance, or regulated recordkeeping need, and consult a qualified professional when a receipt must meet a specific legal or tax standard.