線上預約系統怎麼選？Calendly 類工具的時區、金流與台灣可用性

第一次因為時區把客戶約掉，是我自己算錯的。那時我還沒導入任何線上預約系統，跟一位美東的客戶用信件來回喬了七封信，最後敲定「台灣時間週四晚上九點」。我在行事曆上寫了「9PM TPE / 9AM EST」，還特別檢查過一次。問題出在那一週剛好是美國換鐘的那個週日，我腦袋裡那條「差 13 小時」的公式在那個週一之後就失效了。客戶九點上線，我十點才出現，開場白只能是道歉。

後來我把整條約時間的流程換成預約頁，那類錯誤就再也沒發生過——但換來的是另一組問題：收費預約要接哪個金流？台灣人到底能不能開 Stripe？客戶留下的姓名、電話、想諮詢的內容存到美國的伺服器，責任在誰身上？把預約元件嵌進自己的 WordPress 網站，會不會把好不容易調好的網站速度再次拖垮？

這篇文章就是把這些問題一次攤開。我實際去打開了六家工具的官方定價頁、兩部台灣現行法規、IANA 時區資料庫的發行紀錄，還親手 curl 量了嵌入腳本的實際位元組數。所有價格與費率都標明幣別、標明是月繳價還是年繳均攤價、標明查核日 2026 年 8 月 6 日；定價頁上那個預設停在「年繳」的切換鈕，我一家一家撥到月繳再抄一次。查不到可信數字的，我就直接說查不到，不會替它推估一個看起來很精確的數字。

預約系統解決的不是排時間，是來回確認的溝通成本

很多人把線上預約系統理解成「一個可以讓別人選時間的網頁」。這個描述沒錯，但它會讓你低估它真正省下的東西。你省下的不是「排時間」這個動作，而是為了排時間而產生的整串來回確認。

拆開來看，一次沒有預約系統的約會流程大概長這樣：你發信提三個時段；對方回信說三個都不行，提兩個新的；你查行事曆發現其中一個跟另一件事撞到，回信再提兩個；對方確認其中一個；你手動建立行事曆事件、貼會議連結、設提醒；會議前一天再發一封提醒信。六到八封信、跨兩到三天，中間你的注意力被切碎好幾次。

換成預約頁之後，這整串變成：你貼一個連結；對方點進去挑一個還亮著的時段、填完必要欄位、按送出；系統自動產生行事曆事件、自動發確認信、自動在會議前寄提醒。你從頭到尾只做了「貼連結」這一個動作。真正的效益不在於節省了幾分鐘，而在於你不需要為這件事保留任何「待辦中」的心智空間。

這也就解釋了為什麼有些人裝了覺得神、有些人裝了覺得沒差。差別在於你每個月要排幾場、以及對方是不是陌生人。如果你的會議大多是同一個長期客戶、用 Line 一句「明天下午三點？」就搞定，預約系統只是多一層儀式。但如果你要面對的是不熟的人、跨時區的人、或會不斷有新面孔進來的人，那來回確認的成本會是線性成長的，預約頁的價值也會跟著線性成長。

三種角色、三種用法

接案者的典型用法是「初談」。你在提案信、報價單、作品集網站上放一個 30 分鐘的初談連結，把「有沒有興趣聊聊」跟「什麼時候聊」這兩個決策合併成一次點擊。我在寫客戶提案簡報的跟進節奏時就提過，提案後最怕的就是「我再看看」這種懸而未決的狀態，一個可以立刻點下去的預約連結，能把懸念直接轉成日曆上的一格。

顧問與教練的用法是「售後排程」。學生買了六堂課，你不希望每一堂都重新喬一次。這時你需要的功能就從「單次預約」升級成「套票 / 週期預約 / 群組預約」，這是分辨工具等級的第一個分水嶺——不是每一家的免費版都做得到。

遠距工作者的用法是「對外窗口」。你可能不接案，但你有一個對外的角色：招募、合作洽談、社群諮詢。這種情境的重點不是效率，而是「不要讓對方覺得你很難約」。一個清楚標示了你所在時區、而且會自動換算成對方時區的預約頁，本身就是一種專業訊號。這一點跟我在遠距團隊管理實戰裡談的非同步規則是同一套邏輯：把需要協商的事情，先變成可以自助的事情。

什麼情況下不需要

我得誠實說：有三種情況你可以先不要裝。第一，你的客戶年齡層偏高或不習慣英文介面，預約頁的中文化程度會直接影響完成率，這時一通電話比較快。第二，你的服務本身需要先篩選（例如你只想跟預算到位的人聊），那你需要的是表單加人工排程，而不是任何人都能佔走你時段的公開連結。第三，你一個月真的只開三、四場會，那把時間花在調整緩衝設定上，投報率不會好看。

先確認你的問題是「排程摩擦」，再決定要不要買工具，這個順序不能顛倒。

時區才是核心價值，也是最容易出事的地方

如果只看功能清單，預約工具之間的差異其實不大。真正拉開差距的是時區模型做得夠不夠乾淨，以及它有沒有替你把日光節約時間這件麻煩事吞下去。

先搞懂一個觀念：時刻與顯示是兩件事

一場會議在資料庫裡其實只有一個東西——一個絕對時刻（可以想成 UTC 上的一個點）。你在台北看到的「晚上九點」跟客戶在紐約看到的「早上九點」，是同一個時刻在兩套規則下的兩種顯示。只要工具是把「絕對時刻」存起來、把「顯示」交給各自的時區規則去算，就不會錯；只要有任何一層是用「時差幾小時」硬算的，遲早會錯。

這就是為什麼手動在信裡寫「台灣時間 21:00＝美東時間 09:00」是一種高風險行為。那個「差 12 小時」只在美東實施日光節約時間的那半年成立；剩下半年是 13 小時。而且這兩個切換點，一個在三月、一個在十一月，完全不會提醒你。

Calendly 的時區模型：兩個你必須分清楚的設定

Calendly 官方的〈Time Zones overview〉說明文件寫得相當清楚，值得逐條看。它說每一組排程（schedule）都綁定單一時區，你應該用「你人會在的那個地方的當地時間」來填寫可預約時段；系統會偵測受邀者的時區，用對方的當地時間顯示你的空檔，受邀者也可以自己從預約頁的下拉選單改成別的時區。

關於日光節約時間，官方原文是「Calendly handles daylight saving time changes for you. If someone books before or after a time change, we adjust the times so meetings happen at the correct local time.」——也就是說，跨越換鐘日的預約，它會替你把時間調到正確的當地時間。這是好消息。

但真正的坑在下一段：官方明白寫著「Changing your Account time zone does not automatically update your booking page time zone.」你的「帳號時區」控制的是會議在你 Calendly 帳號介面裡怎麼呈現，而「預約頁時區」是由可預約時段（Availability）與活動類型（Event type）的排程設定控制的。你飛到里斯本住三個月，把帳號時區改成葡萄牙，以為一切搞定，結果預約頁還在用台北時間放時段——這種錯誤不會有任何警告，你只會在某天早上發現有人約在你的凌晨四點。

這個對台灣接案者尤其致命，因為我們常常是「人在台灣、客戶在歐美」，而不是整組搬過去。我在跨時區協作實戰指南裡整理過重疊工時的算法，那套算法的前提就是你的預約頁時區跟你的實際所在地是一致的；不一致的話，後面全錯。

日光節約時間不是抽象問題，它有明確的法源與日期

很多人把日光節約時間當成一個模糊的「國外的事」。其實它的規則是白紙黑字寫在法律裡的，而且各地不一樣：

歐盟依 Directive 2000/84/EC，夏令時間在「三月最後一個星期日格林威治時間凌晨 1 時」開始、在「十月最後一個星期日格林威治時間凌晨 1 時」結束（該指令第 2 條與第 3 條）。注意它用的基準是 GMT，所以歐盟境內所有會員國是同一個瞬間一起換，不是各自的當地凌晨。

美國依 15 U.S.C. §260a，日光節約時間自「三月第二個星期日當地時間凌晨 2 時」開始、至「十一月第一個星期日當地時間凌晨 2 時」結束，且各州可以選擇不實施。所以美國與歐盟的換鐘日差了大約兩到三週——在那個空窗期，台北與紐約、台北與倫敦的時差各自處於不同狀態，這是每年最容易約錯的兩段時間。

台灣則是全年 UTC+8、不實施日光節約時間。這件事的實務意義是：對台灣人來說，時差不是常數，是一個一年會變動四次的變數（美國兩次、歐洲兩次）。你腦中那條公式一年有四次會失效。

時區規則本身就在變：IANA 資料庫是活的

更少人知道的是，全世界的軟體算時區靠的是同一份資料——IANA 的 Time Zone Database（tz／zoneinfo）。它會因為各國政府修改規則而持續改版。查核日 2026 年 8 月 6 日的最新版本是 2026c，發行日 2026-07-08。

光是 2026 年就已經發了三版，而且改的都不是冷門地方：

• 2026b（2026-04-22）：英屬哥倫比亞省在 2026-03-08 那次春季調快之後，就不再變動時間，改為固定 UTC−7。
• 2026c（2026-07-08）：亞伯達省同樣在 2026-03-08 那次調快後停止換鐘，於 2026-06-18 起改為固定 UTC−6；摩洛哥（連同西撒哈拉）預定 2026-09-20 凌晨 2 時起改為固定 UTC+0，不再有日光節約時間切換。發行說明中也提到西北地區預期會跟進，但因為法律程序尚未完成，目前只以註解形式存在。

如果你想看什麼叫「政府臨時改規則」的極端案例，IANA 的發行紀錄裡有一段很有名：2023b（2023-03-23）為了配合黎巴嫩宣布當年改成 4 月 20/21 日才換鐘而更新了資料；五天後的 2023c（2023-03-28）就把它改回去，發行說明直接用了「Model Lebanon’s DST chaos by reverting data to tzdb 2023a」這句話。短短五天內，全世界依賴這份資料的軟體被要求改兩次。

這件事對你的決策有一個很具體的影響：如果你選擇自架，時區資料的更新就變成你的責任。用 SaaS，這件事是廠商的事；自架一套跑在你自己主機上的預約系統，作業系統或執行環境裡的 tzdata 沒跟上，你的預約頁就會在某個地區顯示錯誤的時間，而且不會有任何錯誤訊息。

七條我自己在跑的時區實務守則

1. 信件裡永遠不要手寫換算後的對方時間。只寫你的當地時間加時區代號，換算交給預約頁或行事曆邀請去做。
2. 設定可預約時段時，填的是「你人會在的地方」的當地時間，不是客戶的時間，也不是你公司登記地的時間。
3. 人一移動，第一件事是檢查預約頁時區（不是帳號時區）。兩個都要看，而且要在預約頁前台實際看一次。
4. 三月與十一月（美國）、三月與十月（歐盟）換鐘的前後各一週，跨區會議一律在會議前 24 小時再確認一次。
5. 不要在換鐘當天當地時間凌晨 1 時到 3 時之間排任何東西。那一小時在春季根本不存在、在秋季會出現兩次。
6. 長期系列課程（例如每週同一時間、連續十二週）跨越換鐘日時要主動通知學員——因為工具會維持「當地時間不變」，所以對另一邊的人來說，時間就是變了。
7. 行事曆邀請一律由工具產生，不要自己手動建再轉寄。手動建的事件很容易用到你當下的裝置時區。

行事曆雙向同步與衝突偵測：讀與寫是兩件事

「行事曆同步」這四個字被廠商講得像是一個開關，實際上它是兩個方向、可以分別失敗的功能。

「讀」是防雙訂：系統要能看到你行事曆上既有的事件，才能把那些時段從預約頁上拿掉。「寫」是產生事件：有人預約成功後，系統要在你指定的那本行事曆上建立一筆事件。很多工具的免費版只有寫、沒有讀，或者只讀一本行事曆——這就是為什麼有人裝了預約系統之後反而被雙重預約：他的私人行事曆沒有被納入衝突檢查。

以 Calendly 官方定價頁（查核日 2026-08-06）為例，免費方案的「連接行事曆」數量是 1 本，Standard、Teams、Enterprise 則是 6 本。這個數字看起來很多，但你算一下：Google 個人帳號、Google 工作帳號、Outlook 公司帳號、家人共用的家庭行事曆、某個客戶共享給你的專案行事曆——很快就用完了。

五個實際會發生的同步失敗模式

• 授權過期：OAuth 權杖有生命週期，改密碼、開啟兩步驟驗證、公司 IT 調整政策都可能讓它失效。失效後預約頁不會壞掉，它只會開始把已經有事的時段顯示成有空。這是最陰險的一種壞法。
• 共享行事曆的權限層級不足：對方只給你「查看忙碌／空閒」時，有些工具讀不到細節；給了「查看所有詳細資訊」才算數。
• 全天事件：「休假」這種全天事件在不同工具裡的處理不一致，有的會擋掉整天，有的完全不擋。裝好之後請務必自己建一筆全天事件測一次。
• 暫定（tentative）狀態：你按了「或許」的邀請，在有些工具眼中不算佔用。
• 同步延遲：絕大多數工具是靠推播通知加輪詢，不是即時。你在手機上剛建的事件，可能要幾十秒到幾分鐘才會反映在預約頁上。所以「先在行事曆上卡位、再貼預約連結」這個順序，中間要留一點時間。

如果你像我一樣同時經營自己的網站與客戶專案，帳號與授權的管理本身就是一件要建流程的事。我在密碼管理器與客戶帳密交接那篇裡提過，第三方應用程式的授權清單要定期回頭盤點；預約系統因為串了行事曆，權限範圍其實不小，離場時記得撤銷。

緩衝時間、每日上限、提前預約期：四個設定的實務判準

裝好之後最需要花時間的不是外觀，是這四個設定。它們決定了你的預約頁是幫你保護時間，還是幫別人把你的一天切碎。

一、前後緩衝時間（Buffer）

會議結束後你需要時間寫紀錄、寄後續信、把腦袋切回原本的工作。會議開始前你需要時間看一下對方是誰、上次聊到哪。沒有設緩衝時間，等於允許陌生人替你排出一個背靠背的一天。我自己的做法是會前 10 分鐘、會後 15 分鐘；如果是需要交付成果的諮詢，會後拉到 30 分鐘。

二、最短預約通知期（Minimum scheduling notice）

這個設定決定「最快多久之後的時段才能被預約」。設 0 代表有人可以在五分鐘後把你約走。我的判準是：你需要多久準備，就設多久，再加一個晚上。初談設 12 小時、需要看資料的正式諮詢設 48 小時。這個數字設得太小，你會不斷處於被打斷的狀態；設得太大，會流失掉「現在就想聊」的高意願客戶。

三、每日場次上限（Daily limit）

這是四個設定裡最容易被忽略、但影響最大的一個。開會這件事的邊際成本是遞增的：第一場你精神很好，第四場你只是在把嘴巴打開。設一個你能維持品質的上限，然後把它當成硬規則。我自己是每天最多三場對外會議。

四、可預約日期範圍（Date range / rolling window）

兩種模式：滾動式（例如「未來 30 個日曆日內」）與固定區間（例如「即日起到 12 月 31 日」）。接案者通常用滾動式，因為你不希望有人在四個月後的某天卡一個位子，那時你的接案狀況根本還不確定。滾動視窗要用「工作日」還是「日曆日」也要看清楚，兩者在含連假的月份差很多。

設定項目	接案初談	付費諮詢／教練	對外窗口（招募／合作）
單場長度	20–30 分鐘	50–60 分鐘	15–20 分鐘
會前緩衝	5–10 分鐘	10–15 分鐘	0–5 分鐘
會後緩衝	15 分鐘	30 分鐘	10 分鐘
最短通知期	12 小時	48 小時	24 小時
每日上限	3 場	2 場	4 場
可預約範圍	滾動 30 日	滾動 45 日	滾動 14 日

上表為筆者自身作業慣例的建議值，非任何廠商的官方建議或研究數據，請依你的實際交付節奏調整。

六款工具的定價與能力比較（查核日 2026-08-06）

先講一個所有比較文章都應該先講、但幾乎沒人講的事：這類 SaaS 的定價頁預設顯示的幾乎都是「年繳均攤到每月」的價格，不是你按月付的價格。兩者可以差 16% 到 25%。而且切換鈕的預設位置就在年繳那一邊——Calendly、Cal.com、SavvyCal 三家我實際在瀏覽器裡把切換鈕撥到月繳，數字全都跳了一級。以下每一格我都同時列出月繳價與年繳均攤價，並標明哪個是哪個；查不到可信數字的（例如 Amelia），我就直接說查不到，不替它回推一個看起來很精確的數字。

各家官方定價（美元，查核日 2026-08-06）

工具	免費方案	入門付費方案	進階方案	計價方式備註
Calendly	永久免費；1 個活動類型、1 本連接行事曆	Standard：月繳 US$12／席／月；年繳均攤 US$10（頁面標示 Save 16%）	Teams：月繳 US$20／席／月；年繳均攤 US$16（Save 20%）；Enterprise 自 US$15,000／年起	定價頁預設顯示的是年繳均攤價，要把切換鈕切到「Billed monthly」才會看到月繳價。Teams 年繳有席次級距：1–30 席每席 $16、31–50 席 $14.50、51–100 席 $14.00、101–200 席 $13.50、201–300 席 $13.00、301 席以上 $12.00
Cal.com	US$0，1 人；不限活動類型與行事曆	Teams：月繳 US$16／人／月；年繳均攤 US$12（Save 25%）	Organizations：月繳 US$37／人／月；年繳均攤 US$28（Save 25%）；Enterprise 洽談	定價頁預設落在 YEARLY，要切到 MONTHLY 才看得到月繳價。14 天試用。原始碼採 MIT 授權，可自架
Acuity Scheduling（Squarespace）	無免費方案，7 天試用	Starter：年繳 US$16／月、月繳 US$20／月；1 本行事曆	Standard：年繳 US$27／月、月繳 US$34／月（至多 6 本）；Premium：年繳 US$49／月、月繳 US$61／月（至多 36 本）	官方頁同時列出月繳與年繳兩種價格，年繳約省 20%。Premium 含 HIPAA BAA、多員工時區、自訂 API／CSS
SavvyCal	無免費方案	Basic：月繳 US$12／人／月；年繳均攤 US$10	Premium：月繳 US$20／人／月；年繳均攤 US$17；含自訂網域、代理人排程、付費預約	定價頁預設就停在 Annual，$10／$17 是年繳均攤價，切到 Monthly 才會變成 $12／$20；年繳另標示「省兩個月」
TidyCal	US$0；不限預約次數與預約類型，含付費預約	Individual Lifetime：US$29 一次性買斷；10 個行事曆連接	Agency Lifetime：US$79 一次性；Pro：US$12／月或 US$99／年（年繳均攤約 US$8.25／月）	付費預約另外向預約者加收 1% 平台費，Stripe 手續費另計
Google 日曆「預約時段」	隨 Google 帳號提供	付費預約屬進階功能，需符合資格的 Google Workspace 訂閱	—	付費預約必須連接 Stripe，付款與退款全由 Stripe 處理；Google 官方說明表示自己不收平台費

自架型：WordPress 預約外掛

如果你已經有一個自架 WordPress 網站，另一條路是直接裝外掛，把預約留在自己的網域與資料庫裡。以 Simply Schedule Appointments 官方定價頁（查核日 2026-08-06）為例：

方案	首年優惠價（年繳，美元）	續約價（年繳，美元）	關鍵功能
Basic	免費	免費	1 站；不限預約類型、Email 通知、頁面編輯器整合
Plus	US$99／年	US$129／年	Google 日曆同步、Zoom／Google Meet、群組預約
Professional	US$199／年	US$249／年	Stripe 與 PayPal 收款、簡訊通知、Webhook
Business	US$399／年	US$499／年	團隊成員排程、資源管理、優先支援

請特別注意「首年優惠價」與「續約價」的落差——這是自架外掛市場的通則，不是特例。Professional 從 US$199 跳到 US$249，等於第二年多 25%。另一款常見的 Amelia 我在查核日當天無法取得可信的定價：它的官方定價頁掛著一個倒數計時的限時促銷，而且金額會依你所在地區換成當地幣別顯示（我從台灣連線時看到的是新台幣，不是美元），用 curl 直接抓則只會拿到尚未被 JavaScript 填值的佔位符。所以這裡不列 Amelia 的具體數字——如果你要評估它，請自己打開定價頁並一路點到結帳頁，以結帳頁當下顯示的幣別與金額為準。這種續約漲價的模式，跟我在WordPress 主機的續約陷阱裡寫的完全是同一套劇本：把三年的總持有成本算完再決定，不要只看第一年。

收費預約與台灣金流：這裡是台灣使用者最大的斷點

前面談的都是「怎麼把時間排好」。一旦你想在預約時就收錢——不管是為了過濾不認真的人，還是因為你賣的本來就是諮詢時數——台灣使用者會撞上一道很硬的牆。我把整條因果鏈拆給你看。

第一層：這些工具的收款，本質上是 Stripe 或 PayPal 的代理

Calendly 官方說明文件寫得很明白：Stripe 整合「Available to all users on Standard, Professional, Teams, and Enterprise plans」，而它支援的幣別只有五種——AUD 澳幣、CAD 加幣、EUR 歐元、GBP 英鎊、USD 美元。PayPal 整合的說明頁列的是同一組五種幣別，並註明「A Business PayPal account is required to accept payments」。兩份官方文件裡都沒有 TWD 新台幣。

Google 日曆的付費預約也一樣：官方說明頁寫「To require payments, you need to connect Google Calendar to a Stripe account」，而且「all payments and refunds are handled by Stripe」，幣別由 Stripe 提供。

第二層：Stripe 官方全球可用清單上，沒有台灣

我在 2026-08-06 打開 Stripe 官方的全球可用性頁面逐一比對：完整支援的是 44 個國家／地區，其中亞洲包含香港、日本、馬來西亞、新加坡、泰國；另有標示為「Preview」的印度與印尼，以及透過 Paystack 提供的「Extended network」五個非洲國家（象牙海岸、迦納、肯亞、奈及利亞、南非）。台灣沒有出現在這份清單的任何一層——不在完整支援、不在 Preview、也不在 Extended network。

換句話說，以台灣公司或台灣個人身分直接開立 Stripe 帳戶收款這條路，在官方公開清單上是走不通的。這裡要小心區分兩種完全不同的「變通做法」：一種是拿別人的地址、填不實的營運地資訊去申請，這違反服務條款，帳戶隨時可能被凍結、款項被扣留，我不會建議把營收綁在上面；另一種是真的在受支援的國家設立法律實體（Stripe 自己就有 Atlas 這項在美國設立公司的服務，官方頁面寫著「Startups in over 140 countries have chosen Atlas to start their business」），這在合規上站得住腳，但你換來的是一間真的美國公司，以及隨之而來的稅務申報、年度規費與會計成本。後者是一個要認真評估的商業決定，不是一個繞過去的小技巧。要注意的是，Stripe 官方頁面並沒有正面說明「台灣不支援」這句話，我能查到的只有台灣未列在可用清單上這個事實。

第三層：這不只是廠商的商業選擇，背後有法規

台灣的《電子支付機構管理條例》（現行版本修正日期為民國 112 年 1 月 19 日）第 15 條第 1 項與第 2 項規定得非常直接：

（第 1 項）「境外機構非依本條例申請許可設立電子支付機構，不得於我國境內經營第四條第一項業務。」

（第 2 項前段）「有與境外機構合作或協助其於我國境內從事第四條第一項業務之相關行為者，應經主管機關核准。」

而該條例第 4 條第 1 項所列的業務包括「代理收付實質交易款項」「收受儲值款項」「辦理國內外小額匯兌」等。「代理收付實質交易款項」正是第三方支付的核心動作。境外業者要在台灣境內做這件事，必須依法取得許可；與境外機構合作或協助其在境內從事這些業務，也要經主管機關核准。

這條規定的實務結果，可以直接從 PayPal 自己的費率頁上讀出來。我在 2026-08-06 打開 PayPal 台灣的「商業交易手續費」頁（適用市場／地區明列「台灣 (TW)」），它在開頭同時定義了「國內」與「跨國」兩種交易，但接下來的「商業交易費率」章節只有「接收跨國交易」一張表（付款人所在地為「台灣外 (TW)」，費率 4.40% ＋ 固定費用），完全沒有任何一列是台灣帳戶適用的國內交易費率。換句話說，這不是我推論出來的，是官方費率表自己把國內那一格留白。這與 2017 年起媒體報導的「PayPal 停止台灣境內收付、只保留跨境」是一致的；不過我要說清楚，我沒有找到 PayPal 官方的公告頁面正面說明這件事，能查證的只有費率表上的這個缺口。

那台灣人到底能怎麼收費預約？三條可行路線

路線 A：以外幣收款，走 PayPal Business

如果你的客戶本來就在海外、本來就以美元或歐元報價，這條路最短：開 PayPal 商業帳戶，在 Calendly、Cal.com、SavvyCal（Premium）或 TidyCal 裡接上去，用 USD 標價。代價是費用不低，以下是 PayPal 台灣官方「商業交易手續費」頁面（查核日 2026-08-06，該頁標示最近更新日期為 2026 年 5 月 28 日）逐格對照後列出的數字：

項目	PayPal 台灣官方費率
跨境商業交易收款	4.40% ＋ 固定費用（以 TWD 計價時固定費用為 NT$10.00）
收款／退款時的貨幣轉換	基準匯率外加 4.00%
提領至本地銀行且涉及貨幣轉換	基準匯率外加 2.50%
提領至玉山全球通帳戶（新台幣，無貨幣轉換）	免費
提領至美國銀行帳戶（無貨幣轉換）	2.50%
糾紛申訴手續費（官方分「標準」／「高額」兩級）	NT$250.00／NT$500.00
交易退單手續費（即一般說的 chargeback）	NT$330.00

把 4.40% 的收款費加上 4.00% 的匯率加價，一筆 US$150 的諮詢實際落袋大約會少掉 8% 以上。如果你是以外幣接案，請把這個數字先算進報價裡，而不是事後才發現利潤被吃掉。關於跨境收款各家的實際差異，我在跨境收款工具比較裡有更完整的拆解，報價前值得先看過。

路線 B：預約用 SaaS、收款走台灣金流，兩件事分開

這是我認為對「客戶主要在台灣」的人最務實的做法：預約頁只負責排時間與收集資訊，付款用台灣本地的金流服務另外處理。以綠界科技官方服務費率表（查核日 2026-08-06，一般賣家）為例：

收款方式	費率（未稅）	備註
信用卡一次付清（國內）	2.75%，每筆最低收取 5 元	另有每筆 1 元訂單處理費
Apple Pay	2.75%，每筆最低收取 5 元	—
ATM 虛擬帳號	1%，每筆最低收取 15 元	—
超商代碼	每筆 31 元	—
超商條碼	每筆 16 元	—

該費率表另外註明：線上金流每筆費用最終結算需加收 5% 營業稅；一般賣家的金流代收款項於付款後 10 日內撥款；跨行提領酌收手續費 15 元；一般賣家 30 日收款額度為個人 20 萬元、商務 50 萬元。若要走「特約賣家」拿到議定費率（國內信用卡 1.85%～2.75%、海外信用卡 3.5%～3.8%），官方頁列出的是設立費 5,000 元、年費 13,000 元／1 年起。

路線 B 的缺點是流程斷成兩截：客戶先在預約頁選時段，再收到一封付款連結。好處是費率明顯低於跨境方案、可以開新台幣、而且金流留在台灣體系內比較好對帳與報稅。

路線 C：自架 WordPress，把預約與金流都收進自己的網站

如果你已經有網站，這是最完整、也最花工的做法：裝一支預約外掛，串接台灣金流。要注意的是，多數國際預約外掛（含前面提到的 Simply Schedule Appointments）內建的金流也是 Stripe 與 PayPal，台灣金流通常需要另外購買串接外掛或自行開發。如果你原本就在跑 WooCommerce，把預約當成一種商品來賣反而比較單純，這條路的完整設定我在WooCommerce 開店完整流程裡從安裝談到金流都寫過。

收了錢之後：發票怎麼開

這一段常被略過，但它是「收費預約」真正的下半場。

《加值型及非加值型營業稅法》第 32 條第 1 項規定：「營業人銷售貨物或勞務，應依本法營業人開立銷售憑證時限表規定之時限，開立統一發票交付買受人。但營業性質特殊之營業人及小規模營業人，得掣發普通收據，免用統一發票。」

那什麼時候你會變成「營業人」？財政部依營業稅法第 26 條發布的〈小規模營業人營業稅起徵點〉（最新修正民國 113 年 12 月 12 日，自民國 114 年 1 月 1 日生效）把起徵點調高為：銷售貨物業別每月銷售額 新臺幣 10 萬元、銷售勞務業別每月銷售額 新臺幣 5 萬元（原為 8 萬元與 4 萬元）。線上諮詢、教練、設計服務這類屬於銷售勞務。

白話講：如果你的預約收費每個月穩定超過新台幣 5 萬元，你就要面對稅籍登記的問題。綠界官方費率頁也在同一頁引用了台財稅字第 10904512340 號令，提醒自民國 112 年 1 月 1 日起，個人以營利為目的透過網路平台銷售達一定金額時，應辦理稅籍登記及商業登記。

要開電子發票的話，是另一筆成本。綠界的電子發票加值服務在查核日當天列出的是：新戶優惠首年 0 元可開立 20,000 張；之後 5,000 張 3,600 元、20,000 張 6,000 元、120,000 張 12,000 元（另加 5% 營業稅）。這條線該不該跨、跨了之後獨資行號跟一人有限公司怎麼選，我在稅籍登記與起徵點判斷與一人公司登記的三方比較兩篇裡各寫了一次。

嵌入自架 WordPress：三種方式與實測的效能代價

把預約頁嵌進自己的網站有三種常見形式，效能代價差很多：

• 行內嵌入（inline embed）：頁面一載入就把預約介面整個顯示出來。體驗最順，代價最高。
• 彈出視窗（popup widget）：頁面角落放一顆按鈕，點了才開。腳本還是會在載入時就進來，但主要內容延後。
• 彈出文字連結（popup text）：把某段文字變成觸發器。與上一種類似。

我實際量到的數字

2026 年 8 月 6 日我用 curl 直接抓了各家的嵌入載入腳本，未壓縮的實際大小如下：

資源	未壓縮大小	觀察
Calendly widget.js	11,933 位元組	回應標頭為 cache-control: public, max-age=300
Calendly widget.css	2,461 位元組	同上，快取期 300 秒
Cal.com embed.js	90,219 位元組	回應標頭為 public, max-age=0, must-revalidate

但這些數字會嚴重低估真實成本，原因有兩個。

第一，這幾支只是「載入器」。它們的工作是在你的頁面上插入一個指向第三方網域的 iframe，而那個 iframe 裡跑的是一整套前端應用程式——框架、樣式、字型、日曆邏輯、時區資料，全部另外下載。載入器只有 12 KB，不代表使用者只下載了 12 KB。

第二，那個 max-age=300 很關鍵。五分鐘的快取期意味著回訪的使用者幾乎每次都要重新驗證這支腳本，你沒辦法像對待自己的靜態資源那樣把它快取一年。這是使用第三方嵌入的固有成本，不是設定沒調好。

四個把傷害降到最低的做法

1. 只在需要的那一頁載入。不要用「全站頁尾」的方式塞進去。WordPress 可以用條件判斷只在特定頁面 enqueue，或者乾脆做一個獨立的 /booking 頁面。
2. 優先選彈出式而非行內嵌入。再進一步，可以自己寫一小段程式，在使用者第一次捲動或滑鼠移到按鈕上時才動態插入腳本。
3. 替 iframe 保留固定高度。不預留空間的話，元件載入完成的瞬間會把下面的內容推開，直接反映在 CLS（累積版面配置位移）上。
4. 嵌入前後各量一次。裝完就上線不量，等於不知道自己付了多少代價。量測方法與三項 Core Web Vitals 的修法，我整理在WordPress 網站速度優化實戰裡。

如果你走的是外掛路線而不是嵌入路線，效能問題會換一種形式出現：預約外掛通常會在前台額外載入自己的 JS 與 CSS，而且不少會在每一頁載入。我在把網站精簡到 11 支外掛的取捨清單裡寫過同樣的問題，判準是一樣的：看它有沒有提供「只在指定頁面載入資源」的設定，沒有的話就要自己用外掛管理器擋。

另外一個常被忽略的細節：如果你的網站做了多語系，預約元件的語系通常是獨立設定的，不會跟著你的 WordPress 語系走。訪客在中文頁面上點開一個全英文的預約視窗，完成率會掉。這類語系與網址結構的搭配問題，可以參考網站多語系的取捨與 hreflang 實作。

資料落地與個資：蒐集者是你，不是工具

這一段是我認為最多人搞錯責任歸屬的地方。當客戶在你的預約頁上填下姓名、Email、電話、以及「想討論的主題」，法律上蒐集這些個人資料的人是你，不是 Calendly。工具只是你委外處理的廠商。

Calendly 自己怎麼說

Calendly 的隱私權聲明寫著，你的個人資料「may be transferred to, processed, and stored in the United States or another jurisdiction」，並說明它是依 EU-U.S. Data Privacy Framework、標準契約條款（SCC）與英國附錄（UK Addendum）作為跨境傳輸的合法基礎。關於受邀者的資料，它蒐集的包括姓名、Email、電話、線上會議錄影／逐字稿／摘要等；而且明確表示由客戶（也就是你）控制蒐集哪些資訊，並由客戶負責提供適當告知與取得同意。

換句話說，廠商已經在合約層面把告知與同意的責任推回給你了。這不是壞事，是常態——但你要知道它推過來了。

台灣《個人資料保護法》要你做的四件事

先講一個重要前提：全國法規資料庫上《個人資料保護法》最新一次修正日期為民國 114 年 11 月 11 日，但該頁面同時標示「本法規部分或全部條文尚未生效，最後生效日期：未定」，修正條文的施行日期由行政院定之。因此以下引用的是查核日 2026 年 8 月 6 日的現行有效版本（修正日期民國 112 年 5 月 31 日）。

一、告知義務（第 8 條）。向當事人蒐集個人資料時，應明確告知：機關名稱、蒐集之目的、個人資料之類別、個人資料利用之期間／地區／對象及方式、當事人得行使之權利及方式、以及不提供個人資料將對其權益之影響。注意「利用之地區」這一款——如果你的預約資料會存到美國的伺服器，這件事本身就在告知範圍內。實務做法是在預約表單旁放一段隱私權說明並附上連結，不是把它藏在網站頁尾。

二、特種個資的紅線（第 6 條）。該條第 1 項明定：「有關病歷、醫療、基因、性生活、健康檢查及犯罪前科之個人資料，不得蒐集、處理或利用」，除非符合但書所列六款情形之一（包括「法律明文規定」「經當事人書面同意」等，且書面同意還有「逾越特定目的之必要範圍……不在此限」的限制）。

這條對某些行業是致命的。如果你是心理諮商、物理治療、營養諮詢、醫美相關，預約表單上那個「請簡述您的狀況」的自由填答欄，很可能就在蒐集病歷或健康檢查資料。而這些資料會被送到境外的第三方伺服器上。我的建議很直接：這類欄位不要放在境外 SaaS 的預約表單裡，改成預約成功後另外用符合規範的管道收集，或者乾脆自架。

三、行銷的退出機制（第 20 條第 2、3 項）。條文寫的是：「非公務機關依前項規定利用個人資料行銷者，當事人表示拒絕接受行銷時，應即停止利用其個人資料行銷。非公務機關於首次行銷時，應提供當事人表示拒絕接受行銷之方式，並支付所需費用。」「首次行銷時」與「支付所需費用」這兩個要件常被忽略——不是等對方抗議才處理，而是第一次行銷就要主動提供退出方式，而且退出的成本要你負擔。把預約來的名單直接倒進電子報系統之前，請先確認這件事。相關的名單經營做法我在電子報訂閱名單從 0 到 1000 有整理。

四、安全維護與事故通知（現行有效之第 27 條、第 12 條）。現行第 27 條第 1 項：「非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。」現行第 12 條：「公務機關或非公務機關違反本法規定，致個人資料被竊取、洩漏、竄改或其他侵害者，應查明後以適當方式通知當事人。」

另外第 21 條規定，非公務機關為國際傳輸個人資料，在四種情形下中央目的事業主管機關「得限制之」，包括「接受國對於個人資料之保護未有完善之法規，致有損當事人權益之虞」。目前對美國並沒有一般性的限制令，但這條保留了政策空間，是選擇境外服務時要放在心上的風險。

五個我自己在遵守的實務規則

• 表單欄位最小化。初談只需要姓名與 Email，電話等到成交再要。少一個欄位，少一份責任，而且完成率還會上升。
• 自由填答欄改成選項。把「請描述您的狀況」換成幾個預設分類，可以大幅降低對方無意間留下敏感資料的機率。
• 預約表單旁一定要有隱私權說明的連結，內容涵蓋第 8 條各款，尤其是資料會存到境外這一點。
• 錄影與逐字稿要另外取得同意。會議錄影本身就是個資，AI 摘要功能會把它再複製一份到另一個系統。
• 定期清理。沒成交的初談名單留半年就夠了。留著不用的資料只是風險，不是資產。

如果你想把預約來的名單接進後續的跟進流程，我在接案者的客戶管理與個資責任那篇裡把「最小可用 CRM」的欄位設計寫得比較細，可以搭配著看。

自架與 SaaS 的取捨：把隱形成本也算進去

談到這裡，自架的吸引力應該已經很明顯了：資料留在你的網域、可以串台灣金流、沒有月費、沒有幣別限制。但我必須把帳算完整。

面向	SaaS（Calendly／Acuity 等）	WordPress 預約外掛	自架 Cal.com
上線時間	15 分鐘	1–3 小時	半天到數天
年度直接成本	約 US$120–600（依方案與席次）	US$0–499／年（見前表）	授權 US$0，但需負擔主機與網域
台灣金流	不可行（僅 Stripe／PayPal、無 TWD）	可，但通常需另購串接	可，需自行開發或找社群方案
資料位置	境外（Calendly 明示為美國或其他國家）	你的主機	你的主機
時區資料更新	廠商負責	取決於主機的 PHP／系統 tzdata	你自己負責
信件送達率	廠商的寄信基礎建設	需自行設定 SMTP 與 SPF／DKIM	需自行設定
壞掉時誰修	廠商	你	你

Cal.com 的原始碼在 GitHub 上採 MIT 授權（我在 2026-08-06 直接讀取了主分支的 LICENSE 檔確認），自架版本以 Cal.diy 名義提供，官方安裝文件列出的需求是 PostgreSQL 資料庫、Node.js（文件建議 18）、Yarn 與 Git，並需要產生 NEXTAUTH_SECRET 等環境變數。MIT 是相當寬鬆的授權，這對想長期自架的人是好消息。

但請務必把三筆隱形成本放進試算：

第一，寄信。預約確認信與提醒信如果進了垃圾郵件匣，整套系統的價值就歸零。自架代表你要自己處理 SMTP、SPF、DKIM、DMARC，而且要持續監控送達率。這件事的難度比很多人想像的高。

第二，維運。備份、升級、安全性修補。我在WordPress 網站安全基本功裡寫過的那套流程，在你的網站開始承載客戶個資之後，重要性會直接翻倍——因為一旦出事，適用的就不只是「網站掛掉」，而是前面提到的第 12 條通知義務。

第三，時區資料。回到前面 IANA 那一段。SaaS 廠商每年會跟著 tzdata 更新好幾次，你不會有感覺；自架的話，這變成你維運清單上的一項。2026 年到 8 月為止已經改了三次，而且都涉及實際會有客戶的地區。

我的建議是：先用 SaaS 免費版跑三個月，把流程與設定磨順，確定你真的需要收費預約或資料落地之後，再評估要不要自架。反過來做——先花兩天自架，結果發現一個月只用三次——是很常見的沉沒成本。

三種角色的組合建議

把前面所有條件合在一起，我會這樣建議：

客戶主要在海外、以外幣報價的接案者：Calendly 免費版或 Standard，收款走 PayPal Business，報價時把 4.40% 加 4.00% 的成本內含進去。如果你需要多個活動類型（初談／正式諮詢／專案檢視各一個），免費版的 1 個活動類型會馬上不夠用，這是你升級的觸發點。報價策略可以參考五種定價模型與台灣行情。

客戶主要在台灣、要收新台幣的顧問或教練：預約用 TidyCal（US$29 一次性買斷，成本壓力最小）或 Cal.com 免費版，收款用綠界或藍新另外處理。等到月營收穩定超過新台幣 5 萬元，就把稅籍登記與電子發票一起處理掉。

已經有自架 WordPress 網站、且服務涉及敏感資料的人：直接走外掛路線。多付的授權費換到的是資料落地與台灣金流的可能性，這在合規上的價值遠高於一年幾千塊。

只是想要一個不讓人覺得難約的對外窗口：Google 日曆的「預約時段」就夠了，不用另外付錢，也不用另外接一套系統。等到你開始需要緩衝時間、每日上限這些設定，再考慮升級。

不管選哪一個，設定完成之後請務必用另一台裝置、另一個瀏覽器的無痕視窗，親自把自己的預約流程走一遍，最好切換到一個不同的時區再走一次。工具的後台顯示永遠是對的；會出錯的是前台。

常見問題

台灣人真的完全不能用 Stripe 收款嗎？

先講精確一點：我在 2026 年 8 月 6 日逐一比對了 Stripe 官方全球可用性頁面，台灣沒有出現在完整支援的 44 個國家／地區、Preview（印度、印尼）或 Extended network 任何一層。但我也要誠實說，Stripe 官方文件裡沒有一句話正面寫「台灣不支援」，我查到的是「未列於公開支援清單」這個事實，而不是 Stripe 的否定聲明；台灣的《電子支付機構管理條例》第 15 條對境外機構在我國境內經營代理收付業務的規範，則提供了一個合理的背景解釋。實務上的結論是：以台灣身分直接申請這條路走不通。至於變通做法，填不實營運地資訊違反服務條款、我不建議；真的到受支援國家設立公司（例如 Stripe 自家的 Atlas）則是合規的，但要一併承擔該國的稅務與申報義務。

Calendly 可以用新台幣收費嗎？

不行。Calendly 的 Stripe 與 PayPal 兩份官方整合說明頁列出的支援幣別都是 AUD、CAD、EUR、GBP、USD 五種，沒有 TWD。若你要收新台幣，只能把付款流程拉到 Calendly 之外處理。

預約系統會自動處理日光節約時間嗎？我還需要做什麼？

主流工具會處理。Calendly 官方明確表示會替你調整跨越換鐘日的預約時間，讓會議發生在正確的當地時間。你仍然需要做兩件事：一是確認你的「預約頁時區」正確（官方說明指出改帳號時區不會自動更新預約頁時區），二是對跨越換鐘日的長期系列課程主動通知對方——因為對他們來說，鐘面上的時間確實變了。

免費方案夠用嗎？什麼時候該付費？

三個觸發點：需要第二個活動類型（Calendly 免費版只有 1 個）、需要連接第二本行事曆做衝突偵測（免費版只有 1 本）、需要在預約時收款。在這三件事發生之前，免費版通常真的夠用。Cal.com 的免費方案在活動類型與行事曆數量上比較寬鬆，是另一個選項。

把預約元件嵌到網站上會不會拖慢速度？

會，而且比看到的數字更多。我實測 Calendly 的載入腳本為 11,933 位元組、Cal.com 為 90,219 位元組（2026-08-06，未壓縮），但這些只是載入器；真正的預約介面是在第三方 iframe 裡另外載入一整套前端應用程式。做法上建議只在需要的頁面載入、優先使用彈出式而非行內嵌入、並替 iframe 預留固定高度以避免版面位移。

預約表單可以問客戶的健康狀況或病史嗎？

要非常小心。《個人資料保護法》第 6 條第 1 項明定病歷、醫療、基因、性生活、健康檢查及犯罪前科之個人資料原則上不得蒐集、處理或利用，僅在但書所列六款情形下例外。若你的服務涉及這類資訊，我的建議是不要透過境外 SaaS 的預約表單收集，改用其他符合規範的管道，或評估自架方案。具體適用情形請諮詢專業人士。

資料來源

• Calendly 官方定價頁——證明頁面預設顯示年繳均攤價（Standard US$10、Teams US$16，標示 Save 16%／20%），切到「Billed monthly」後為 Standard US$12、Teams US$20；Enterprise 自 US$15,000／年起；免費版 1 個活動類型、連接 1 本行事曆，付費方案「Connect up to 6 calendars per user」。查核日 2026-08-06。
• Calendly 說明中心：選擇適合團隊的方案——證明 Teams 年繳方案的席次級距定價（1–30 席每席 US$16 至 301 席以上 US$12）。
• Calendly 說明中心：Time Zones overview——證明排程綁定單一時區、自動偵測受邀者時區、自動處理日光節約時間，以及「更改帳號時區不會自動更新預約頁時區」。
• Calendly 說明中心：Calendly + Stripe——證明支援幣別僅 AUD／CAD／EUR／GBP／USD，且適用於 Standard 以上方案。
• Calendly 說明中心：Calendly + PayPal——證明 PayPal 整合同樣僅支援上述五種幣別，且需要 PayPal 商業帳戶。
• Calendly 隱私權聲明——證明個人資料「may be transferred to, processed, and stored in the United States or another jurisdiction」，跨境傳輸依據為「EU-U.S. Data Privacy Framework, Standard Contractual Clauses and the UK Addendum」，以及「Each customer controls and is responsible for the information they process using our Services and for complying with any regulations or laws that require providing notice, disclosure, and/or obtaining consent prior to transferring Personal Data to Calendly.」
• Cal.com 官方定價頁——證明 Teams US$12／人／月、Organizations US$28／人／月為 YEARLY 計價（Save 25%），切到 MONTHLY 後為 US$16 與 US$37；免費版 1 人、活動類型與行事曆連接皆不限；Teams 14 天試用。
• Cal.com 自架版（cal.diy）GitHub 主分支 LICENSE——證明原始碼採 MIT 授權（查核日 2026-08-06 直接讀取主分支 LICENSE 檔，開頭即為「MIT License / Copyright (c) 2020-present Cal.com, Inc.」）。
• Cal.diy 自架安裝文件——證明自架需求為 PostgreSQL、Node.js 18、Yarn 與 Git。
• Acuity Scheduling 官方方案頁——證明各方案同時標示月繳與年繳價（Starter US$20／US$16、Standard US$34／US$27、Premium US$61／US$49）。
• SavvyCal 官方定價頁——證明計費切換鈕預設停在 Annual（該按鈕 aria-pressed="true"），此時顯示的 Basic US$10、Premium US$17 為年繳均攤價；切到 Monthly 後為 Basic US$12、Premium US$20，年繳另標示「Save 2 months」。查核日 2026-08-06。
• TidyCal 官方定價頁——證明 Individual Lifetime US$29 一次性、Agency Lifetime US$79、Pro US$12／月或 US$99／年，以及付費預約另收 1% 平台費。
• Simply Schedule Appointments 官方定價頁——證明首年優惠價與續約價的差距（Professional US$199 對 US$249）。
• Google 日曆說明：Require payments for appointments——證明付費預約必須連接 Stripe，付款與退款皆由 Stripe 處理，Google 不收平台費。
• Stripe 官方全球可用性頁面——證明完整支援為 44 個國家／地區、Preview 為印度與印尼、Extended network 為經 Paystack 提供的五個非洲國家，且台灣未列於其中任何一層。該頁並未出現任何否定台灣的敘述，本文依據的是「未列於公開支援清單」這個事實，而非 Stripe 的官方否定聲明。查核日 2026-08-06。
• PayPal 台灣官方「商業交易手續費」頁面（商業帳戶）——證明適用市場為「台灣 (TW)」，商業交易費率章節僅列「接收跨國交易」（台灣外 4.40% ＋ 固定費用，新台幣固定費用 10.00 TWD）而未列任何國內交易費率；付款或退款時貨幣轉換加價 4.00%、當地銀行提領轉換 2.50%、提領至玉山全球通新台幣帳戶免手續費、提領至美國帳戶 2.50%、標準／高額糾紛申訴手續費 250.00／500.00 TWD、交易退單手續費 330.00 TWD。該頁標示最近更新日期 2026 年 5 月 28 日。
• 綠界科技官方服務費率表——證明一般賣家信用卡 2.75%（每筆最低 5 元）、ATM 1%（最低 15 元）、超商代碼 31 元、超商條碼 16 元、每筆訂單處理費 1 元、需加收 5% 營業稅、付款後 10 日內撥款，以及電子發票加值服務的張數費用。
• 全國法規資料庫：電子支付機構管理條例——證明第 15 條第 1 項（境外機構非依本條例許可，不得於我國境內經營第 4 條第 1 項業務）與第 2 項（與境外機構合作或協助其於境內從事該等業務應經主管機關核准），以及第 4 條第 1 項所列「代理收付實質交易款項」等業務項目。現行版本修正日期民國 112 年 1 月 19 日，該頁無條文未生效之標示。
• 全國法規資料庫：個人資料保護法——該頁標示「本法規部分或全部條文尚未生效，最後生效日期：未定」，並載明民國 114 年 11 月 11 日修正第 1-1、12、18、21、22～26、41、47～49、52、53、55 條，刪除第 27 條，施行日期由行政院定之。因此本文所有條文均改引同站歷史法規頁的現行有效版本（修正日期民國 112 年 5 月 31 日）逐字比對：第 6 條特種個資限制與六款但書、第 8 條告知事項六款、第 12 條事故通知、第 20 條第 2、3 項行銷退出機制、第 21 條中央目的事業主管機關得限制國際傳輸之四款情形、第 27 條第 1 項安全維護義務。
• 全國法規資料庫：加值型及非加值型營業稅法第 32 條——證明營業人銷售貨物或勞務應開立統一發票，小規模營業人得掣發普通收據免用統一發票。
• 財政部主管法規共用系統：小規模營業人營業稅起徵點——證明銷售貨物業別起徵點為每月銷售額新臺幣 10 萬元、銷售勞務業別為 5 萬元，最新修正民國 113 年 12 月 12 日，自民國 114 年 1 月 1 日生效。
• EUR-Lex：Directive 2000/84/EC——證明歐盟夏令時間自三月最後一個星期日 GMT 凌晨 1 時起、至十月最後一個星期日 GMT 凌晨 1 時止。
• 美國聯邦法典 15 U.S.C. §260a——證明美國日光節約時間自三月第二個星期日凌晨 2 時起、至十一月第一個星期日凌晨 2 時止，各州可選擇不實施。
• IANA Time Zone Database與官方發行說明（NEWS）——證明最新版本為 2026c（2026-07-08）、2026 年已發行三個版本、英屬哥倫比亞省與亞伯達省改為固定時間、摩洛哥預定 2026-09-20 改為固定 UTC+0，以及 2023b／2023c 五天內來回修改黎巴嫩資料的紀錄。

本文涉及台灣稅務與個人資料保護法規的部分，僅為依查核日 2026 年 8 月 6 日之公開官方資料所做的整理，不構成法律、稅務或財務意見。法規與廠商定價都可能變動，實際適用情形因個案而異；涉及稅籍登記、發票開立、特種個人資料處理等事項，請向會計師、律師或主管機關確認後再行決定。文中所有價格與費率均以各官方頁面於 2026 年 8 月 6 日之顯示為準，且已標明幣別與計價方式（月繳或年繳均攤）。