授权链路用的是 ISO 8583:1987 系列的 0xxx MTI——0100 授权请求、0110 应答、0400 冲正。清算走 Mastercard 的 IPM 格式，MTI 是 1993 系列的 1xxx——1240 First Presentment（首次提交）、1442 退单、1740 费用收取。这是两份独立的规范、两套独立的字段字典。Mastercard 的规则文件里同一条要求经常要写两遍，一边一套：授权侧写「in DE x of Authorization Request/0100 messages」，清算侧写「in PDS xxxx of First Presentment/1240 messages」。
所以从解析授权报文转去读清算文件（或者做两边的对账）时，你背熟的那张字段表就失效了。下面是公开文档里能查到的对照关系。
最容易迷路的，是两个报文族里都存在、但定义变了的 DE 号。
授权里 DE22 叫 POS Entry Mode，子域 1 是 PAN 输入方式。清算里 DE22 叫 Point of Service Data Code，子域 1 变成了终端能力，真正的输入方式挪到了子域 7。连同一件事实的取值都不一样。以非接交易为例，Mastercard 的交易标识表要求：
| 事实 | 授权 0100/0200 | First Presentment/1240 |
|---|---|---|
| 非接 M/Chip（EMV）读卡 | DE22 子域 1（POS Terminal PAN Entry Mode）= 07 | DE22 子域 1（Terminal Data: Card Data Capability）= M，且子域 7（Card Data: Input Mode）= M |
| 非接磁条读卡 | DE22 子域 1 = 91 | DE22 子域 1 = A，且子域 7 = A |
同一笔交易、同一个 DE 号，子域布局不同，一边是数字码一边是字母。解析器（以及对账任务）需要按报文族各配一套 DE22 解码逻辑——本站的 DE22 速查工具覆盖的是授权侧取值。
商户类别码在授权报文里放 DE18（Merchant Type），在清算报文里放 DE26（Acceptor Business Code）。而 1987 字典里的 DE26 是另一个东西（POS PIN 采集码）——拿着清算记录去查授权字段表里的「DE26」，会被引到完全错误的方向。码值本身可以用 MCC 查询工具查。
授权报文里，Mastercard 把私有数据装进 DE48 的子元素；清算报文里，等价的事实以 PDS（Private Data Subelement）标签传递。公开规则里点名给出的对应有：
| 业务事实 | 授权 0100/0200 | First Presentment/1240 |
|---|---|---|
| Transaction Type Identifier（TTI，用于 Payment/Funding 等交易） | DE48 子元素 77 | PDS 0043 |
| 交通项目数据（子域 1 为 Transit Transaction Type Indicator） | DE48 子元素 64 | PDS 0210 |
| 商户注册国（Home Country ID） | DE48 子元素 37 子域 4 | PDS 0213 |
| MPOS 受理设备类型 | DE48 子元素 21（Acceptance Data）子域 1 | PDS 0018（Acceptance Data）子域 1 |
有两点值得注意。第一，编号之间没有任何规律——子元素 77 对应 PDS 0043，DE48 子元素号推不出 PDS 标签号。第二，DE48 里有些东西在公开规则中根本没有清算侧的对应物：Transaction Category Code（TCC），DE48 子域 1 里的一个字母，取值如 P（Payment Transaction）、X（航空及其他交通运输）、U（博彩），规则里只在授权侧引用它。
有些事实不只是改名，而是整个搬去了结构完全不同的位置。公开文档里记载的几个例子：
| 事实 | 授权 0100/0200 | First Presentment/1240 |
|---|---|---|
| 交易发生在 MPOS 终端 | DE61（Point-of-Service Data）子域 10（Cardholder-Activated Terminal Level）= 9 | PDS 0023（Terminal Type）= CT9 |
| 仅芯片（Chip-only）MPOS 终端 | DE61 子域 11（POS Card Data Terminal Input Capability Indicator）= 9 | DE22 子域 1 = E |
| 把报文关联回原授权的 Trace ID | DE48 子元素 63（Trace ID） | DE63（Transaction Life Cycle ID）子域 2（Trace ID） |
授权侧这些事实躺在 DE61 的定长子域网格或 DE48 的子元素里；清算侧则变成一个 PDS 标签，甚至干脆换了一个 DE。如果你在授权流水里按 DE61 过滤 MPOS 交易，把同一套 DE61 逻辑照搬到清算流水，过滤器会静悄悄地什么都匹配不到。
有几类交易根本不产生授权腿，它们的标识只存在于清算字典。公开的例子是交通首程风险（First Ride Risk，FRR）索赔：发卡行拒绝了一次非接过闸聚合交易后，交通运营方在满足规定条件时可以直接在清算里收取首程车费。规则明确写着 FRR 索赔不需要授权，在 First Presentment/1240 里以 PDS 0210 子域 1 = 08（First Ride Risk Claim）标识——授权侧没有对应物可找。（它的近亲「交通欠费追缴」则两侧都有：DE48 SE64 子域 1 和 PDS 0210 子域 1 都取 07。）
反方向的情况也存在：在授权侧产生、必须回传进清算的标识。Mastercard 在 0110/0210 应答里下发的 Transaction Link Identifier（TLID），必须放进 First Presentment/1240 的 DE105 里——详见 DE105 实例。