自由工作者怎樣開 USDT 收款發票？

USDT 收款發票不應只是聊天視窗裡的一串錢包地址。對自由工作者、海外接案者和跨境小商戶來說，一張可執行的發票，要把工作範圍、計價幣別、USDT 數量、網路、費用承擔方式、付款時限與付款證據連在一起。這樣才能避免「客戶付 100 美元」究竟是發票面額、USDT 數量，還是連全部費用在內的總預算等爭議。

直接答案： 先寫工作價值及計價幣別，再把 USDT 寫成結算資產；列明匯率來源與核對時間、完整網路名稱、已確認的收款地址、由誰負擔費用、實際必須到帳的數量與到期時間。收到款項後，另做收據或付款紀錄，加入 txid 與實際入帳數量。一般發票、報價單與收據不是同一文件；自行製作的 USDT 發票也不一定能取代所在地要求的電子稅務發票。

目錄

• 報價單、發票和收據有何分別
• 先決定計價幣別
• USDT 發票的 18 個欄位
• 匯率怎樣寫才可核對
• 網路、地址與費用
• 一個清楚標示的虛構範例
• 分期、少付和多付怎樣處理
• 付款後的收據與紀錄
• KES、TZS 與 Mobile Money 放在哪一層
• 稅務、私隱與常見錯誤
• 可複製的發票骨架
• 官方核對來源

報價單、發票和收據有何分別

報價單 是客戶確認工作之前的提案，通常包含服務範圍、價錢、有效期與修改條件。發票 是工作或里程碑達成後提出的付款要求。收據 則是已收到某一筆款項的紀錄。三者可以使用相近版面，但不能只改文件標題而不改狀態與證據。

例如，你先發出 USD 300 的網站設計報價，客戶接受後，再出具編號 INV-2026-014 的發票，並提供以 USDT 結算的選項。客戶付款後，不要靜默覆蓋原始發票。應保留原版本，記下 txid、實際入帳數量及時間，再出具收據或把發票狀態標為 paid。這條時間線能讓客戶、會計人員與你自己日後重建事件。

Microsoft 的官方說明指出，小型企業可利用 Word 或 Excel 的發票模板，再以 PDF 或紙本傳送。模板負責版面，不會自動解決 USDT 的網路、匯率與證據問題，也不代表符合任何特定國家的稅務規定。

Microsoft Excel 官方頁面截圖，核對於 2026 年 8 月。畫面只示範發票版面，不是實際交易或稅務發票。

先決定計價幣別

「收 100 USDT」可能代表三種完全不同的交易：

1. 服務定價為 USD 100 ，付款時按約定來源換算成 USDT；
2. 服務直接定價為 100 USDT ，不再按美元價格調整；
3. 客戶的全部預算是 USD 100 ，平台、提幣與網路費都要包含在內。

如果沒有先定義，客戶可能以為只需在提幣欄輸入 100，而收款人以為自己必須淨收 100。兩者中間若有 sender-side withdrawal fee，就會立刻出現短款。

發票可使用以下其中一種寫法：

服務價格：USD 300。以 USDT 結算。USDT 數量按雙方指定來源於某個帶時區的時間鎖定。

或：

服務價格及結算資產：300 USDT。若付款服務從發送數量扣除提幣或網路費，客戶須另加費用，確保收款地址淨入帳 300 USDT。

USDT 旨在參考美元價值，但 P2P 報價、交易所顯示價及你與客戶的合約價不一定完全相同。不要在永久模板中寫「1 USDT 永遠等於 1 USD」。發票需要的是一條雙方可以重新計算的規則，而不是無法保證的固定市場結論。

USDT 發票的 18 個欄位

發出 PDF 前逐項核對：

1. 文件類型： INVOICE／發票，付款前不要寫成已付款收據；
2. 唯一編號： 例如 INV-2026-014；
3. 發出時間： 使用日期、時間與時區；
4. 到期時間： 不要只寫「明天」；
5. 賣方資料： 依法需要的姓名、商號或識別資料；
6. 客戶資料： 與合約一致的姓名或公司；
7. 工作說明： 交付物、期間、數量或里程碑；
8. 計價幣別： USD、KES、TZS 或 USDT；
9. 小計、稅項與總額： 只在適用並有法律依據時填寫；
10. 結算資產： 明確寫 USDT；
11. 價格來源： 指定市場、頁面或雙方同意的公式；
12. 核價時間： 加入時區；
13. USDT 數量： 寫清小數位與四捨五入規則；
14. 網路： 例如 USDT-TRC20 或 USDT-ERC20；
15. 收款地址： 從收款方官方 App 的 deposit／receive 畫面複製；
16. Memo／Tag： 寫實際值，或清楚標明不需要；
17. 費用規則： 誰負擔平台、提幣、網路與後續付款費；
18. 付款證據： 付款後加入 txid、內部轉帳編號或訂單 reference。

可以加入聯絡方法處理錯誤，但發票不應包含 seed phrase、private key、PIN、OTP、密碼或 Cookie。收款地址可公開給付款人；控制錢包的祕密資料不能出現在發票、電郵或客服聊天中。

匯率怎樣寫才可核對

如果服務以 USD 定價、以 USDT 結算，可以使用透明公式：

基礎 USDT 數量 = 發票的 USD 總額 ÷ 每 1 USDT 的 USD 價格

假設一張教育用途的虛構發票是 USD 300，而雙方指定來源在鎖價時顯示 1 USDT = USD 0.998，示例計算便是 300 ÷ 0.998。這只是示範公式，不是目前價格，也不能直接複製到真實發票。真正付款前應把當時來源、讀數、時間和時區寫入新版本。

還要指定價格有效窗口。例如，報價只在發票送出後 30 分鐘有效。超時便重新核價，建立 revision 2，保留舊版與修改原因。不要在客戶付款後改掉原始 PDF，否則日後無法證明付款時究竟採用哪一個數字。

如果服務直接以 300 USDT 定價，就寫清不按美元再換算。如果要求收款人淨收 300 USDT，就不要只寫「請發送 300」，還要寫 sender-side fee 由付款人額外承擔。這一行通常比任何複雜公式更能避免短款。

網路、地址與費用

Tether 在多條區塊鏈上發行代幣，因此「USDT」不是完整付款路線。付款端的 withdrawal network、收款端的 deposit network，以及雙方服務當下支援的 token/network 組合必須一致。

安全流程如下：

1. 收款人登入自己的官方服務，選擇 Deposit／Receive > USDT > Network；
2. 把 token、完整網路名稱與地址放在同一則訊息或同一張發票；
3. 付款人在自己的提幣頁確認同一個網路標籤；
4. 雙方比較地址開頭、結尾，再完整核對全部字元；
5. 查清 minimum deposit、confirmations 與 memo/tag；
6. 大額或新路線先決定是否小額測試；
7. 實際送出前重新查看平台當下顯示的提幣與網路費。

TRON 官方文件說明，常見 Base58Check 地址以 T 開頭；Ethereum 交易則包含收款 to 地址。地址外觀只能幫助發現部分錯誤，不能代替網路支援檢查。即使兩條 EVM 相容網路的地址形式看起來相似，也不代表把 ERC20 發到 BEP20 deposit 一定會自動入帳。

費用可用三種方式約定：

• 淨額到帳： 收款人必須實收指定 USDT，付款人另加 sender-side fee；
• 總額發送： 客戶只輸入指定 USDT，任何被扣費用會令到帳較少；
• 分擔： 每一方負擔自己階段的費用，並接受預先列明的差額。

不要籠統寫「零手續費」。即使 P2P 訂單沒有獨立 trading fee，廣告價仍可能包含價差；Mobile Money、提幣或鏈上轉帳也可能另有費用。把費用按層分開，才知道客戶預算與你最終到帳的差異來自哪裡。

一個清楚標示的虛構範例

以下資料完全虛構，只用來展示欄位，不代表真實客戶、價格或地址：

模板中不要放一個「看起來真的」虛構地址，避免將來誤發。可先放醒目的 [貼上已確認收款地址]，最後由兩人或兩個獨立畫面核對後才匯出 PDF。

分期、少付和多付怎樣處理

三個工作里程碑可以使用一張發票列出三期，也可以每個里程碑另開發票。無論哪種方式，每一期都要有計價金額、鎖定的 USDT 數量、網路、地址、到期時間、重複費用與付款後餘額。

若客戶因提幣費被扣而少付，不應把整張發票標成 paid。記錄：

• 客戶下單或輸入的數量；
• 收款端實際 credited amount；
• txid 或 internal transfer ID；
• 未付差額；
• 雙方同意現在補付，還是加到下一期。

如果多付，也不要立刻按聊天中出現的新地址退款。退款是另一筆交易，會產生新的網路、身份與費用風險。先核對平台規則、對方身份、原付款來源與 refund address，建立 credit note 或 adjustment，再保存新 txid。原發票本身不能證明某個新地址屬於付款人。

分期還會重複產生提幣、網路、P2P 與 Mobile Money 成本。發票應寫清每期由誰負擔，並在簽約前比較一次收款和分批收款，而不是付款後才爭論。

付款後的收據與紀錄

USDT 收據需要把發票與真實付款連起來，至少記錄：

• invoice number 與 revision；
• 原應付數量；
• 付款端發送數量（如可見）；
• 收款端 credited amount；
• token 與 network；
• 完整 txid；
• 帶時區的日期與時間；
• confirmations 或 credited status；
• 顯示出的差額與費用；
• 最終狀態：paid、partial、overpaid、refunded 或 disputed。

保存發票 PDF、收據 PDF 與 CSV 紀錄。檔名可使用 2026-08-09_INV-014_CLIENT-ALIAS_USDT.pdf，共享副本使用客戶代號，不要把完整電話、身份證或 Mobile Money 餘額暴露給不相關的人。

不要只依賴截圖。截圖適合保存當時的操作狀態，但 txid、平台 export、訂單編號與結構化 CSV 才方便搜尋和核對。如果是同一交易所內部轉帳，未必有鏈上 txid；此時應保存平台提供的 internal transfer ID、發送與入帳狀態，不能自行虛構鏈上雜湊。

KES、TZS 與 Mobile Money 放在哪一層

客戶若直接用 USDT 付發票，你之後把 USDT 賣成 KES／TZS，再收進 Mobile Money，通常是收款人的資金管理步驟，不必自動放進客戶發票。把兩件事分開，客戶便不會無意承擔你未事先約定的 P2P 價差或末端費用。

只有當合約明確要求收款人最終取得指定 KES 或 TZS 時，才需要把 P2P 價格來源、核價窗口、Mobile Money 費用、最低／最高限額與價差承擔者寫進付款條款。不要把今天的價格硬編碼到永久模板；每次交易都要手動填入當時的匯率、平台費、網路費和服務限額。

若要把 Mobile Money 付款與發票關聯，可保存 transaction ID 及 statement 中相應項目。對外分享前遮住不必要的電話、餘額和其他交易。即使對方自稱客服，也不要提供 PIN 或 OTP。

稅務、私隱與常見錯誤

一般商業發票與 tax invoice 在不同司法管轄區有不同要求。KRA 的官方資料指出，肯尼亞涉及的 tax invoice 由註冊人士出具，並須按適用規則由 eTIMS 產生。換言之，自製 USDT PDF 可以說明付款，但不一定能代替 eTIMS。坦桑尼亞或其他地區的用戶，應查看本地主管機關的現行規定，不能直接複製肯尼亞要求。

常見錯誤包括：

• 未具適當資格或法律依據卻在發票顯示稅項；
• 付款前把 quotation 寫成 receipt；
• 只寫 USDT，不寫 network；
• 使用上一次的地址而沒有重新核對；
• 沒說明費用在哪一端扣除；
• 在所有句子把 USD 與 USDT 當作完全相同；
• 只傳可編輯文件，沒有保存鎖定 PDF；
• 覆蓋舊 revision，破壞時間線；
• 在發票放 seed phrase、private key、PIN 或 OTP；
• 沒有鎖定價格和時間，卻承諾固定 KES／TZS 到帳。

有關 VAT、withholding、電子發票、保存期限及入帳匯率，應向所在地的會計師或稅務專業人士查詢。本文只提供付款操作結構，不是法律、稅務或投資建議。

可複製的發票骨架

INVOICE NO:
ISSUED AT (timezone):
DUE AT (timezone):
SELLER:
CLIENT:
SERVICE / MILESTONE:

QUOTE CURRENCY:
SUBTOTAL:
TAX (only if legally applicable):
TOTAL:

SETTLEMENT ASSET: USDT
PRICING SOURCE AND CHECKED TIME:
USDT AMOUNT:
NETWORK:
RECEIVING ADDRESS:
MEMO/TAG:
WHO PAYS SENDER/WITHDRAWAL/NETWORK FEES:
AMOUNT THAT MUST ARRIVE:
PAYMENT WINDOW:
TEST TRANSFER: required / not required

AFTER PAYMENT
TXID OR INTERNAL TRANSFER ID:
CREDITED AMOUNT:
CREDITED AT (timezone):
STATUS: paid / partial / overpaid / disputed

發出前最好做雙重確認：一人把發票與合約逐項比較，另一人從官方 App 重新核對 token、network、address、memo/tag 與 minimum deposit。如果只有一人，也應在不同時間或不同畫面獨立核對兩次，避免只看被惡意程式替換後的剪貼簿內容。

官方核對來源

以下頁面於 2026-08-09 核對。網路支援、平台規則與法律會變更，每次新發票仍應重新打開官方來源。

1. Microsoft Support：建立估價與發票
2. Microsoft Excel：發票模板
3. Kenya Revenue Authority：VAT
4. Kenya Revenue Authority：eTIMS
5. KRA：Buyer Initiated Invoicing
6. Tether：支援的協議
7. Tether：運作方式
8. TRON Developer Hub：帳戶與地址
9. Ethereum.org：交易
10. Safaricom：M-PESA Statement 條款

服務邊界： 本站不兌換 USDT、不代收款、不保管資金，也不保證匯率、平台可用性或轉帳結果。計算與模板只協助你整理決策；真實付款須使用你已核實的官方服務與當下資料。