[更新] Schwab NEC退稅試算表 v4.30b——處理到期的債券ETF稅務資料須補充Cash Liquidation Distr.

• Schwab NEC退稅試算表 v4.30 檔案連結
• 更新內容：
1. 支援目標到期債券基金 (defined-maturity bond funds)
2. 有些原來用無預扣稅判定為Muni的偷懶作法，也統一改用稅務資料 (AV欄) 做判斷，才能與現金清算配息區分
3. 改正BA1和報表1042-S核對部分的一些瑕疵，包括隱藏不需要的比對項目，預扣稅附註*號
4. 稅務資料查詢算式加上Value函式，以包容稅務資料貼入格式問題
• 其他版本及相關說明

和一般永遠不會到期的的債券基金不同，有一種目標到期債券基金 (defined-maturity bond funds) 是會到期的，如Invesco的BulletShares、iShare的iBonds，這類基金到期時會返還大量本金，其稅務性質和一般基金的現金清算 (Cash Liquidation) 類似 (對此類基金有興趣可參考綠角大的初步介紹，或可研讀Vanguard Research深入的研究報告)。

最近有網友提供他2019年在嘉信到期的BSCJ紀錄，從而有這個版本誕生。由於是僅僅根據這份唯一的資料所做的設計，適用性還待觀察，而且涉及新的免稅收入和預扣稅計算方式改變，變數較多，所以這個版本不會直接取代舊的v4.2x，而是先併行提供，確認無虞後再替換。

嘉信對於到期債券ETF的交易紀錄Action (行動)欄位標示為Final Cash Liquid，沒有預扣稅，1042-S的分類是Income Code 37。如果遇到這種情形，除了必須使用此一版本外才能正確處理之外，還需要取得每股現金清算配息金額Cash Liquidation Distr.，貼入稅務資料的L欄 (僅貼上值)。此資料抽取試算表也有提供，但因為欄位分布問題須要分開複製。而且QII和FSI%因為日期重複無法正確抽取，需自行到原始資料處 (NRA及Secondary工作表) 複製：

雖然試算表提示要整併，但因為這裡確實是分為兩筆屬性不同的配息，所以千萬不要整併。這種情形僅適用於其中一筆是普通配息、一筆是基金到期或清算的場合。至於這兩筆稅務資料如何區分，後續退稅試算表會自動處理，也會在報表的附註加上相關的稅務說明和核對算式。

不過，由於嘉信對這兩筆同樣日期配息的再分類出現技術性錯誤，而且難以簡單解釋 (有興趣可參考後面的說明)，所以就算用了更新版本，還是無法完美的對上1042-S的收入分類，只能在報表中簡單說明，除了1042-S分類與基金公司的稅務資料不相符之外，其他計算結果均相符。

以下為開發過程的技術說明，一般使用者可以忽略。

v4.30更新說明

嘉信將現金清算配息歸入Income Code 37，但沒有預扣稅，有獨立的交易分類，這和嘉信現行的各種配息都不相同。最直接的想法就是為開一個新的配息分類來處理，但很快就發現，有許多算式都是根據配息分類做不同的處理，要全面調整的話，工程實在不小 (已經忘記當初的辛苦)。此法也沒有解決兩筆同一天的配息該如何抓取稅務資料的問題，只能手動修改錯開日期做區分。而現金清算配息另成一類孤立於該ETF的其他配息之外，呈現方式也不太理想。既然又麻煩效果又差，於是果斷放棄。

由於嘉信將清算配息分類於Income Code 37，比較簡單的方法就是直接把現金清算配息當成ROC，將Cash Liquidation Distribution與ROC和併計算，即可直接套用大部分原來的ROC算式，大幅簡化修改程序。最初是讓使用者手動將現金清算金額併入ROC，然後並調整交易紀錄兩筆配息日期錯開。但這樣完成的配息列表就無法辨識現金清算紀錄的特殊性，只能將預扣稅的計算提前到在為交易紀錄分類的階段，才能做到無預扣稅，且後續也無法針對現金清算自動補充報表的相關說明。雖然很快就完成修改，但完成度實在不高。

最傷腦筋的地方是：如何正確將同一日期的兩筆交易，對應到正確的稅務資料，以減少手動調整的麻煩，也能維持資料的正確性。

後來想到一招，在稅務資料新闢Cash Liquidation Distri.欄位，然後將該筆現金清算配息的交易代碼末尾加上特別標記【-LQ】，然後在做配息分類時將Final Cash Liquid交易紀錄的基金代碼做上同樣的標記，這樣就可以用代碼直接辨識現金清算紀錄，要免除預扣稅、要自動增加附註說明都很容易，也可以維持原有的配息排序。

這個方法其實很類似Firstrade版本將Exempt Interest Dividend與QII合併計算的方式，於是報表的修改也可以依樣畫葫蘆，移植修改套用少去很多思考的功夫，完成度也令人滿意。

最後，在修改過程中陸續凸顯了BA1提示和報表1042-S核對部分的一些瑕疵，包括隱藏不需要的比對項目，預扣稅附註*號標示沒有自動調整。此外，修改後因為現金清算配息也沒有預扣稅，有些原來用無預扣稅判定為Muni的偷懶作法，也統一改用稅務資料 (AV欄) 做判斷，才能與現金清算配息區分。

稅務資料貼入格式問題造成的計算問題很難完全杜絕，這次也在稅務資料查詢算式加上Value函式直接給予包容。其實早期Google試算表演算效率欠佳，當初甚至因為計算延遲導致部分計算結果需要設法強迫計算才能正常更新，所以很多最早發展的算式都設法精簡以減少負擔。目前已經沒有這個問題了。

嘉信1042-S對BSCJ的再分類到底出了甚麼問題?

剛開始完全看不出1042-S到底是怎麼分類的，後來在嘗試各種解決方案的過程中，修改到某個階段，明明還是未完成狀態，卻意外發現當時應該是不正確的計算結果居然與1042-S正好相符。分析當時的修改狀態，可以確認嘉信是對那筆同日入帳的普通配息也套用了清算紀錄的每股現金清算配息金額做再分類，才造成Income Code 01和06減少、37增加的結果。顯然券商的資訊系統也因為這兩筆同日期的配息而抓錯稅務資料。

其實，雖然兩筆配息是同時入帳，但普通配息的除息日和登記日都比清算配息早，券商又不像我們只有交易紀錄的日期，基金公司是有提供配息的全部資料的，不應該無法區分才對。

讓問題變得更複雜的是，原本到期後配發的金額應該是100%現金清算配息，但基金公司的稅務資料又做了再分類修正，其中少部分配息被再分類為應稅股息和QII，使得錯誤狀況更難直接解讀出來。就算券商沒有前述錯誤，計算結果還是會與1042-S分類有差異，只是差異比較小而已。

雖然這次券商有錯沒錯對結局影響不大，不過還是期待以後券商可以正確再分類。畢竟，清算配息的再分類修改應該是例外的狀況，否則券商就不會直接不予預扣稅。當基金公司和券商都正確處理現金清算配息時，1042-S和計算結果應該會是相符的。