USDT 收款記錄怎樣匯出 CSV？

收取 USDT、把部分資產以 P2P 換成 KES 或 TZS，再由 Mobile Money 收到法幣，通常會留下四套分散記錄：發票在電郵，鏈上交易在 explorer，訂單及聊天在 P2P 平台，最後付款在 M-PESA 或其他 wallet。若沒有一張索引表把它們串起來，很容易重複扣費、混淆報價，或無法解釋最後實收為何與發票不同。

直接答案： 建立一個 CSV，以一列代表一個經濟事件或訂單，用 record_id 與 case_id 連結發票、USDT 交易、P2P 訂單及 Mobile Money 交易編號。每列保存原始輸入與結果，包括報價、發出和收到的 USDT、網路、地址、txid、P2P 價格、各層費用及最後實收。時間統一使用包含時區的 RFC3339，文字採 UTF-8。

更新日期： 2026-08-09。這份 CSV 是個人或商戶的內部工作記錄，不是銀行結單、Mobile Money 官方結單、稅務發票或法律意見。保存年期、報稅及會計分類要按所在地規定向專業人士核實。

目錄

• CSV 要解決甚麼問題
• 一列應代表甚麼
• 基本識別欄位
• USDT、地址與網路欄位
• P2P、KES、TZS 與 Mobile Money 欄位
• 費用與最後實收怎樣計
• 日期與時區怎樣保存
• CSV 格式與安全風險
• 教學用 CSV 範例
• 在 Excel 匯出與重新匯入
• 每星期或每月怎樣對帳
• 隱私、備份與證據連結
• 常見錯誤
• 儲存前核對清單
• 核對資料

CSV 要解決甚麼問題

CSV 的角色是跨系統索引，不是取代原始證據。 它應能回答：哪張發票對應哪筆鏈上 transaction、哪張 P2P 訂單處理了多少 USDT、哪個 Mobile Money transaction ID 完成了付款，以及每一層扣了甚麼費用。

自由工作者或跨境小商戶不能只記「收到多少 USDT」。完整路徑至少分為：

• 發票金額與報價幣別；
• 客戶實際送出的 USDT；
• 收款端入帳的 USDT；
• 使用的 TRC20、BEP20 或 ERC20 網路及 txid；
• P2P 訂單賣出的 USDT；
• 該訂單的 KES 或 TZS 單價；
• 平台費、價差與 Mobile Money 費用；
• 最後可以使用的淨額。

CSV 可以排序、篩選及加總上述資料，但不能代替 invoice、explorer 記錄、訂單詳情、聊天、付款憑證或官方結單。Safaricom 的 M-PESA Statement 條款說明，服務可顯示收付款與提供不同期間的完整結單，並區分一般結單與 certified copy。這正好提醒使用者：自己製作的表格有整理價值，但不應冒充官方文件。

一列應代表甚麼

開始前要選定一種規則：一列代表一個經濟事件，或一列代表一張訂單。 同一個檔案不可中途改變列的含義。

較適合多步驟收款的做法，是一列一個事件：

1. invoice_issued：發票建立；
2. usdt_received：USDT 入帳；
3. p2p_sale：部分或全部 USDT 透過 P2P 賣出；
4. mobile_money_received：法幣進入 Mobile Money；
5. adjustment：有原因及證據的更正。

每個事件有獨立 record_id，同一收款路徑則共用 case_id 或 invoice_id。這樣能處理客戶分批付款、一筆入金拆成多張訂單，或只兌換部分 USDT，而不需要把多個時間點塞進一個儲存格。

較簡單的做法，是一列代表一張 P2P 訂單。若每張發票只收一次、所有 USDT 只賣一次，這種模式容易閱讀；但收到 USDT、建立訂單與 Mobile Money 入帳實際發生於不同時間，之後對帳會較難。

在 data dictionary 頂部寫清楚規則，例如：「每列代表一個事件；同一 case_id 的列組成一條收款路徑。」這能避免使用者把 invoice 列及 payment 列同時計作兩次收入。

基本識別欄位

每列需要不會改變的內部編號，以及可以返回原始資料的參考。 建議欄位包括：

欄位	用途	格式示例
record_id	每列唯一編號	REC-2026-0001
case_id	連結完整收款路徑	CASE-2026-0042
invoice_id	發票編號	INV-2026-017
client_alias	不直接暴露身份的內部別名	CLIENT-K
event_type	事件類型	p2p_sale
direction	資金流入或流出	in
status	pending／completed／reversed／disputed	completed
notes	簡短而可核實的備註	受控文字

不要以電話、電郵或全名作 record_id。唯一編號應在客戶更改聯絡方式後仍保持不變。若業務需要保存法定姓名，可以用另一份權限更嚴格的客戶名冊，把 client_alias 映射到真實身份。

P2P 事件另加 platform_name、order_id，有需要時加入 ad_id。聊天及付款截圖放在獨立證據資料夾，CSV 只保存 evidence_ref 或受控路徑，不要把整段聊天塞進 notes。Binance Academy 提醒交易者保存付款確認，因為申訴可能需要查看；訂單編號及時間線就是 CSV 與證據包之間的橋樑。

USDT、地址與網路欄位

若發出、收到及賣出的 USDT 可能不同，就不應只有一個 usdt_amount。 建議分開記錄：

• asset：固定寫 USDT；
• usdt_quoted：發票或合約約定數量；
• usdt_sent：付款端實際發出；
• usdt_received：收款端實際入帳；
• usdt_sold：P2P 訂單實際賣出；
• network：按畫面寫 TRC20、BEP20 或 ERC20；
• address：完整收款地址，分享版本可另作遮罩；
• txid：完整 transaction hash；
• network_fee_asset：費用使用的資產；
• network_fee_amount：費用數量；
• deposit_status：pending、credited 或 rejected。

network 與 address 必須成對保存。只有 0x 地址，不能告訴核對者該交易走 ERC20 還是 BEP20；TRON 地址即使以 T 開頭，也應明確寫 TRC20，不能讓人由外觀猜測。

公開 explorer 可用來核對 txid、狀態、地址及 token 合約。Ethereum 官方文件說明 transaction hash 及交易生命週期；TRON 文件說明帳戶與 TRC20。可是，explorer 不知道你的發票內容，也不能證明 Mobile Money 已收款，因此 txid 只是整條證據鏈的一部分。

P2P、KES、TZS 與 Mobile Money 欄位

P2P 記錄要保存該張訂單的真實價格與數量，不要日後用「市場價」倒推。 訂單價才是該筆交易的資料。

可使用以下欄位：

• p2p_platform；
• order_id；
• trade_side：由自己的角度寫 sell 或 buy；
• fiat_currency：KES 或 TZS；
• p2p_price_per_usdt；
• p2p_usdt_amount；
• gross_fiat；
• platform_fee_fiat 或 platform_fee_usdt；
• counterparty_alias：只保存必要識別；
• payment_method：例如 M-PESA；
• mobile_money_transaction_id；
• mobile_money_gross_received；
• mobile_money_fee；
• net_received；
• payment_received_at；
• order_completed_at；
• chat_evidence_ref 與 payment_evidence_ref。

Binance 的 P2P 說明把 ad、order limit、payment window 及 appeal 分開定義；可用價格與付款方法依地區及廣告變化。因此，模板不應預先寫死匯率，p2p_price_per_usdt 必須來自該張訂單詳情。

在肯亞，可用自己的 M-PESA statement 核對 transaction ID、金額與時間；在坦尚尼亞，Vodacom 的 M-PESA 條款說明交易查詢及結單安排。核實收款時應查看自己帳戶的餘額與結單，不可只看對方傳來的付款截圖。

費用與最後實收怎樣計

保留所有輸入值及計算結果，不要只留下公式。 CSV 在不同軟體之間不會可靠保存 workbook 公式、驗證規則及多個工作表；日後若公式改變，舊結果亦可能跟着變。

以一張賣出 USDT 的 P2P 訂單為例：

gross_fiat = p2p_usdt_amount × p2p_price_per_usdt
net_received = gross_fiat - platform_fee_fiat - mobile_money_fee - other_direct_fee

若網路費在 USDT 入帳前已從發送端或提領額扣除，應在相應資產與階段保存，不要在 gross_fiat 再扣一次。建議加 fee_stage，使用 sender、network、p2p 或 mobile_money 等值，讓核對者知道費用在哪一步發生。

若要計算成本比例，需保存分子與分母。不可把 USD 發票、USDT 數量及 KES 收款額混在同一個百分比而不記錄轉換依據。能由原始欄位重算的結果，比只有一個無法解釋的 formula cell 更可靠。

日期與時區怎樣保存

統一使用包含 UTC offset 的 RFC3339，例如 2026-08-09T14:30:00+03:00。 沒有時區的深夜交易，可能在客戶、P2P 平台與 Mobile Money 結單分屬不同日期，令對帳出現假差異。

時間欄位可包括：

• quoted_at；
• invoice_issued_at；
• usdt_sent_at；
• usdt_credited_at；
• p2p_order_opened_at；
• payment_received_at；
• order_completed_at；
• record_updated_at。

RFC 3339 規定日期、時間及 Z 或數字 offset 的表示。肯亞與坦尚尼亞一般採 +03:00，但 CSV 應記錄事件實際顯示的時區，不要把不明時間自行猜成當地時間。若來源是 UTC，可用 Z。

匯入 spreadsheet 時把這些欄位指定為文字，避免軟體依地區設定改寫日期並刪除 offset。若為閱讀方便需要另一個本地日期欄位，可以另行產生，但 source timestamp 應保持不變。

CSV 格式與安全風險

CSV 是純文字格式，必須處理 delimiter、引號與 spreadsheet 公式風險。 RFC 4180 記錄常見做法：每列一筆 record、欄位以逗號分隔；含逗號、雙引號或換行的欄位以雙引號包圍，而欄位中的雙引號要重複一次。

可採用以下一致規則：

• 編碼使用 UTF-8；
• 第一列是固定 header；
• decimal separator 統一為小數點；
• 金額與幣別分欄，不把 KES 1000 當成一個 amount；
• 空值保持空白，只有真實零值才寫 0；
• notes 內的逗號、引號與換行要正確 escape；
• 每個檔案或 data dictionary 保存 schema_version。

OWASP 說明 CSV／formula injection：spreadsheet 可能把以 =、+、- 或 @ 開頭的儲存格當成公式。客戶別名、notes、聊天摘要等外來文字不可未經檢查便匯出。對人手查看的檔案，可以把相關欄位匯入為文字並按實際軟體處理危險開頭；不要啟用來源不明的外部內容或連結。

沒有一種清理方法能保證適用於所有 spreadsheet 及後續程式。較安全的設計，是減少不受控自由文字、把狀態改為固定選項，並把詳細 notes 放在受控證據檔案。收到別人提供的 CSV 時，先用 import preview 檢查 delimiter、編碼及欄位類型。

教學用 CSV 範例

以下資料只用來示範欄位，不是真實交易、目前匯率或付款證據。

schema_version,record_id,case_id,event_type,invoice_id,client_alias,asset,usdt_sent,usdt_received,usdt_sold,network,address,txid,p2p_platform,order_id,fiat_currency,p2p_price_per_usdt,gross_fiat,network_fee_amount,platform_fee_fiat,mobile_money_fee,net_received,mobile_money_transaction_id,status,quoted_at,received_at,evidence_ref,notes
1,REC-2026-0001,CASE-2026-0042,usdt_received,INV-2026-017,CLIENT-K,USDT,100.00,99.00,,TRC20,TExampleAddressForSchemaOnly,TXID-EXAMPLE,,,,,,,,,,completed,2026-08-09T09:00:00+03:00,2026-08-09T10:15:00+03:00,EVID-0042-A,"欄位示例，不是真實地址或 txid"
1,REC-2026-0002,CASE-2026-0042,p2p_sale,INV-2026-017,CLIENT-K,USDT,,,50.00,TRC20,,,ExamplePlatform,ORDER-EXAMPLE,KES,EXAMPLE_RATE,EXAMPLE_GROSS,,0.00,EXAMPLE_FEE,EXAMPLE_NET,MM-EXAMPLE,completed,2026-08-09T10:20:00+03:00,2026-08-09T10:40:00+03:00,EVID-0042-B,"按自己的訂單詳情替換 EXAMPLE 值"

不要把 TExampleAddressForSchemaOnly、TXID-EXAMPLE 或示例 rate 複製到真實記錄。這個範例只展示同一 case_id 如何連結入金與 P2P 訂單，並把 address、network、order 及 Mobile Money reference 分開。

在 Excel 匯出與重新匯入

Excel 可透過 Save As 選擇 CSV，但 CSV 只保存目前工作表的資料，部分 workbook 功能會遺失。 Microsoft Support 亦說明，直接開啟 CSV 時，Excel 會依目前預設格式解讀欄位；使用 Data > From Text/CSV 匯入，可以在載入前控制 delimiter 及 data type。

Microsoft Support 頁面截圖，2026 年 8 月。不同 Excel 版本的選單可能不同，請使用適用於自己版本的官方步驟。

匯出時：

1. 檢查 header 與 schema version。
2. 若 workbook 有公式、驗證規則或多個工作表，先保存原始 .xlsx。
3. 選擇 Save As；版本支援時使用 CSV UTF-8。
4. 閱讀「只保存目前工作表」及功能遺失提示。
5. 關閉檔案後，以匯入方式重新打開 CSV，檢查前導零、時間與 delimiter。
6. 比較列數、總額及數個抽樣 record。

匯入時不要直接雙擊來源不明的檔案。先開啟 preview，選 UTF-8 及正確 delimiter，並把 order_id、mobile_money_transaction_id、address、txid 及 timestamp 指定為文字。這可減少科學記號、前導零消失及日期被靜默改寫。

每星期或每月怎樣對帳

對帳的目的，是確認每筆數量都有可返回的來源與去向。 按 case_id 逐項檢查：

1. 發票總額是否等於雙方約定？
2. usdt_sent 與 usdt_received 的差額是否有費用或其他解釋？
3. txid 的 token、network 與 address 是否正確？
4. 同一 case 的 usdt_sold 總和有否超過可用 USDT？
5. 每個 order_id 是否有訂單詳情、聊天及付款確認？
6. gross_fiat 能否由訂單數量與價格重算？
7. Mobile Money transaction ID 是否出現在自己的結單？
8. 每項費用是否只在正確 stage 扣除一次？
9. net_received 是否與可用餘額或結單一致？
10. pending、disputed、reversed 是否與 completed 分開？

不要為了讓總額吻合而靜默修改舊列。新增 adjustment 事件，保存理由、時間及證據 reference，才能保留 history。若舊資料確實輸入錯誤，可用 supersedes_record_id 指向被替代記錄，而不是刪除痕跡。

分批付款應共用一個 invoice 或 case，建立多個 payment event。多張 P2P 訂單則各自保留 order_id。最後加總 completed events，既能得到 case 總額，也不會失去每一批的細節。

隱私、備份與證據連結

包含地址、txid、訂單與 Mobile Money ID 的 CSV 屬敏感資料，即使部分鏈上內容公開。 把公開地址與客戶身份、收入及付款習慣連結後，隱私風險會明顯增加。

最低措施包括：

• 法定姓名另存於權限更嚴格的檔案；
• 工作表只用 client alias；
• 絕不保存 PIN、OTP、密碼、seed phrase、private key 或 Cookie；
• 加密保存裝置或 archive；
• 至少保留兩份分離備份，並實際測試 restore；
• 證據資料夾不可使用公開分享連結；
• 申訴或交給會計人員時，只提供必要 subset；
• 分享截圖前遮蓋無關餘額、其他交易與私人聯絡資料。

evidence_ref 最好是內部 identifier，例如 2026/CASE-0042/EVID-0042-B，真正檔案由 storage 權限保護。若需要檢查檔案是否被改動，可以保存 hash；但 hash 只說明位元是否一致，不能在缺少原始來源時證明內容真實。

保存年期應按法律、合約及爭議風險決定。不要無目的地永久保存每張截圖，也不要自行猜測稅務記錄何時可以刪除；向所在地的會計或法律專業人士核實。

常見錯誤

多數問題來自欄位定義含糊，而不是計算本身。 常見錯誤有：

• 只有一個 amount，沒有 currency、asset 或 stage；
• 由地址外觀猜 ERC20、BEP20 或 TRC20；
• 缺少 order／訂單編號、聊天及付款證據 reference；
• 以買方截圖代替自己帳戶的結單；
• 把報價價格當成實際 order price；
• 同一 network fee 扣兩次；
• 日期沒有時區；
• transaction ID 被 spreadsheet 轉成科學記號；
• 匯出未檢查的外來文字或公式；
• 直接改舊記錄，不建立 adjustment trail；
• 把 CSV 稱為官方 receipt 或 tax return；
• 把證據路徑設成任何人可開啟的公開連結。

儲存前核對清單

以下任何一項未通過，都應先修正來源檔案，再使用 export 做對帳。

• Header 與 data dictionary、schema version 一致。
• 每列有 record_id、case_id、event type 及 status。
• 金額有明確 currency／asset 及 stage。
• USDT 記錄包含 network、address/reference 及 txid。
• P2P 記錄包含 order／訂單編號、價格、數量及法幣。
• Chat、付款憑證及 Mobile Money 結單有 evidence reference。
• KES／TZS 金額與 Mobile Money fee 分欄。
• 所有時間均為含時區的 RFC3339。
• 逗號、引號及換行已正確 escape。
• 外來文字已檢查 formula injection。
• 檔案以 UTF-8 儲存，並成功重新匯入測試。
• 列數、總額及抽樣 record 已與原始來源比較。
• 沒有 PIN、OTP、seed phrase、private key 或 Cookie。
• 備份可以打開，證據連結沒有公開。

核對資料

以下資料於 2026-08-09 核對；實際操作請按目前軟體版本與服務條款：

1. IETF RFC 4180：CSV 常見格式及 MIME type
2. RFC Editor：RFC 3339 timestamps
3. Microsoft Support：Import or export text and CSV files
4. OWASP：CSV Injection
5. Safaricom：M-PESA Statement Service terms
6. Vodacom Tanzania：M-PESA services and important documents
7. Vodacom Tanzania：M-PESA terms and statements
8. Binance Academy：What is Binance P2P and how to use it
9. Ethereum.org：Transactions and transaction hash
10. TRON Developer Hub：Accounts

本站不保存使用者記錄、不收取 USDT，也不執行兌換。這份欄位設計只協助人手整理資料；來源真確性、存取權限、會計分類及所在地合規仍由使用者自行核實。