Pakistan 加密税务 2026：Binance 记录与申报边界

巴基斯坦 Binance 用户现在应如何准备税务记录？

截至 2026-08-09，本页能从 FBR 官方入口确认的是：Pakistan 仍以 Income Tax Ordinance、Finance Act、适用 income head、居民身份和 tax year 等一般框架处理应税事实；FBR 的 Finance Acts 目录已经列出 Finance Act 2026。本页核验的这些公开文件没有确认面向所有个人加密交易的统一专项税率。这不等于 crypto 免税，更不等于每个 Binance 用户都按同一方式申报。

实际可做的第一步不是猜税率，而是把一年的数字还原成可以复核的证据链：何时取得什么资产、付出什么、在哪个市场处置、收到多少 PKR 或其他资产、支付多少费用、资金最终流到哪里。Binance 记录导出能提供一部分底层字段，却不能替你完成收入分类、成本归集或 FBR return。

税务与 affiliate 披露： 本页不含 Binance 注册、referral 或优惠链接，也不因读者开户或交易获得报酬。内容是独立的记录整理指南，不构成税务、法律或投资意见。

FBR 文件能确认哪些税务边界？

FBR 的 Income Tax Basics 把 income broadly 分为 salary、property、business、capital gains 和 other sources 五个 head，并分别介绍 resident、non-resident、Pakistan-source 与 foreign-source 概念。这些栏目说明分类问题真实存在，但没有把“买卖 USDT”预先塞进某一个格子。相同的币种，在偶发处置、持续经营、收取服务费或其他事实下，可能需要问不同问题。

正常 tax year 是截至 6 月 30 日的十二个月，而不是简单照抄 Binance 的公历年度报告。用户若用 1 月至 12 月文件做工作底稿，应额外建立 7 月至次年 6 月的映射，避免年度切点错位。居民身份也不是仅凭 CNIC 或账户地区判断；FBR 页面列有停留天数等条件，跨境居留应单独核验。

记录保留方面，FBR 的 return 页面写明，有 taxable income 的人应保留 Income Tax Return records 六年。稳妥做法是从相关 tax year 结束后计算，并在存在 audit、notice、appeal 或其他未决程序时先咨询是否需要继续保存，而不是机械到期删除。

官方文件目前没有确认什么？

本轮没有在已核验 FBR 页面中找到一个名为“crypto tax”的统一个人税率表，也没有看到“只要走 P2P 就免税”的规则。Finance Bill 2026 是提案文本；Finance Act 2026 才是 FBR 目录列出的 Act。把 Bill、新闻标题、社交媒体解读或别国规则直接套到 Pakistan，会把法源层级和适用事实混在一起。

官方页面同样没有确认：USDT 永远等于美元；每一次钱包转移都是处置；充值一定是收入；提现一定是利润；P2P 银行入账金额就是应税所得；或 Binance 的 realized PNL 就是 Pakistan return 的最终数字。文章因此不提供一个“把成交额乘以 X%”的捷径。

如果有人只问“Rs 100,000 的 USDT 卖出要交多少税”，仍缺少至少四组事实：资产如何取得、取得成本是多少、卖出是否属于业务活动、以及用户在相关 tax year 的身份和其他收入。金额本身不能补齐这些变量。

Binance 记录应保存哪些字段？

先保存原始导出，再做清洗副本。原始文件应只读归档，记录下载日、平台页面、所选时间范围、文件名和校验值；任何分类或汇率列放在工作副本，不覆盖平台原字段。

记录层	最低字段	为什么需要
现货成交	symbol、side、price、qty、quoteQty、orderId、tradeId、timestamp	还原每次成交而非只看订单总额
费用	commission、commissionAsset、扣费时间	费用可能用 BNB 等另一资产支付，需独立换算
充值/提现	asset、amount、network、address、TxID、状态、时间	区分平台内部成交与外部钱包资金移动
P2P	order number、买卖方向、crypto 数量、广告价、PKR 金额、支付方式、完成/申诉状态	把平台订单与银行实际结算对应起来
银行侧	入账/出账日期、金额、参考号、账户持有人、退回或冻结状态	证明 PKR 是否真正结算，避免只信收据
人工作底稿	事件类型、税年、成本来源、PKR 换算、异常说明、复核人	让汇总可回到原证据

Binance Academy 的现货历史示例包含价格、数量、quote quantity、费用、费用资产和时间戳。这些字段适合构建账本，但还需结合充值提现、P2P 和外部钱包证据，才能解释完整资金路径。

现货、P2P、充值提现怎样对账？

把每一个事件分成“交易”和“资金移动”两类。现货 BTC/USDT 成交改变资产构成；从自己的外部钱包充入 Binance 可能只是位置变化；P2P 卖出则同时出现平台订单和银行 PKR 入账。三者不能只按同一列“收入”相加。

现货对账从 tradeId 汇总到 orderId，再检查成交总数量、quoteQty 和 commission。P2P 对账以 order number 为桥，把订单金额、完成时间、付款方式与银行 reference 对应。充值提现用 TxID 与链上/钱包记录配对，标注“自有钱包转移”“向第三方付款”或“来源待确认”，但不要在证据不足时强行分类。

一个实用的差额测试是：期初资产 + 全部流入 + 买入 - 卖出 - 全部流出 - 费用，是否能解释期末余额。若不能，先查 Earn、Convert、dust conversion、手续费资产、失败/退回交易或另一个账户，不要用一笔“balancing adjustment”把缺口抹掉。

PKR 与外币应怎样换算并留档？

平台记录常以 USDT 或交易对报价资产表示，银行侧却以 PKR 结算。每次换算都应保留五件事：来源、日期时间、时区、采用的价格类型和计算公式。P2P 实际结算可以记录实际 PKR；现货或链上事件若需估值，应记录使用的市场数据来源及为什么适合该事件。

不要混用“参考中间价”“P2P 可成交价”和“银行实际到账价”而不做标签。对于费用币种，先保留原始数量，再在同一方法下换成 PKR。对跨午夜或 tax year 边界的交易，要把 Binance UTC 时间与 Pakistan Standard Time 的转换写入字段，防止同一成交落入不同日期。

汇率方法一旦选定，应在同一资料包中保持一致。若某日数据缺失或价格异常，在例外日志写明替代来源、选择理由和影响金额，留给税务专业人士复核。

费用与成本依据应怎样保存？

“买入总额”不自动等于可扣成本，“交易手续费”也不应只看页面显示的百分比。保存实际 commission 和 commissionAsset；若费用用 BNB 支付，还要保留该 BNB 的来源及费用发生时的 PKR 换算。提现 network fee、P2P 价格点差和银行费用则是不同证据项目，不要合并成一个无法追踪的数字。

成本批次方法、内部转移、空投、奖励、赠与、挖矿或业务库存可能需要不同判断。本站不指定 FIFO、加权平均或其他方法，也不宣布某种费用必然可扣。工作底稿的任务是把候选成本和来源证据分开列出，让专业人士在一致政策下决定。

缺失记录怎么补？

先从 Binance 网页或应用导出。官方现货历史页说明，六个月内可直接导出，单次最多 10,000 个数据点；全历史生成需要等待，且下载链接只保留七天。收到文件后立即下载、备份并记录范围，避免月底才发现某段没有覆盖。

若网页范围不足，API 可以作为补充，但应优先使用只读、最小权限、独立创建且用后撤销的 key。不要把带交易或提币权限的 API secret 发给所谓“报税助手”。API 仍可能只覆盖特定市场；P2P、Convert、Earn、钱包和银行侧需要各自证据。

缺口无法补回时，不要伪造精确数字。建立 exception log：缺哪一段、尝试过什么、能从银行/钱包/邮件恢复什么、剩余不确定金额是多少。透明的不确定性比无来源的“精确”更可审计。

年度资料包应包含什么？

建议每个 tax year 单独建只读资料包：01-original-exports 保存原文件，02-bank-and-wallet 保存银行流水与 TxID，03-pkr-method 记录换算来源，04-reconciliation 放对账表，05-exceptions 放缺口，06-adviser-notes 保存专业意见与采用理由。文件名使用日期、来源和范围，避免 final-final-2.csv。

汇总页至少列：期初/期末资产、按事件类型的流入流出、已实现与未分类项目、费用币种、PKR 换算方法、重大例外以及与 return 数字的桥接。完成后将公式表导出为不可编辑版本，同时保留可计算副本和版本记录。

按照 FBR 公布的六年记录要求设保留提醒，但如有未决程序、修订申报或专业人士给出更长建议，以更严格期限为准。加密平台可能限制旧数据生成次数，年度下载比几年后集中追溯可靠得多。

什么时候需要专业意见？

出现以下任一情况时，不宜只靠通用文章：大量高频或系统化交易；替他人撮合或收款；以 crypto 收取商品/服务报酬；跨境居留或外国税；多个自托管钱包但成本断裂；长期持有与业务库存混合；衍生品、借贷、质押或奖励；金额与银行流水明显不一致；收到 FBR notice；或需要修改既往 return。

向税务师交付的不是几百张无序截图，而是一份有索引的资料包和待决问题表。例如：“这 12 笔是自有钱包转移还是处置？”“BNB 手续费如何进入成本？”“P2P 业务频率是否改变 income head？”这样才能让专业判断建立在事实之上。

哪些变化会触发本文更新？

以下事件发生时，本页需要重新核验：FBR 发布新的 Income Tax Ordinance 合订本、Finance Act 修订或 crypto 专项通知；PVARA 最终法规涉及税务报告或记录接口；Binance 改变现货/P2P/钱包导出字段、范围或次数；Pakistan 的居民身份或 tax year 规则变化；或官方申报表新增 virtual asset 栏目。

读者在实际申报前应重新打开 FBR 原页和自己的 Binance 界面。本文的日期是证据快照，不是把 2026-08-09 的页面状态永久冻结。

常见问题

页面底部六个结构化问答集中处理统一税率、P2P、截图、平台导出、历史 PKR 价格和专业意见。核心原则只有一个：先保留能复核的事实，再决定分类；不要从交易通道名称反推税务结论。

来源

• FBR Income Tax Ordinance 更新目录：确认当日法源版本入口。
• FBR Finance Acts：区分 Finance Act 2026 与预算阶段文件。
• FBR Income Tax Basics：income heads、居民身份与 tax year 基础。
• FBR Finance Bill 2026：仅作 Bill 边界核验，不作为最终 Act 替代品。
• FBR File Income Tax Return：六年记录保存说明。
• Binance Academy：Account Trade History via API：成交字段和网页/API 范围。
• Binance Support：Download Spot Trading Transaction History：导出步骤与限制。
• Binance Developer Docs：Spot REST API：USER_DATA 与 key 安全边界。