Vendor pre-payments 未显示在 NetSuite 银行对账中

2026-10-24支付小周

结论

Vendor Prepayment 中的“预付款账户”不需要设置为银行账户。通常应按以下方式配置：

Bank Account：账户类型必须为 Bank，代表实际付款账户。
Vendor Prepayment Account：通常使用 Other Current Asset，记录尚未核销的供应商预付款。

银行对账读取的是交易过账到银行账户的明细，不是预付款账户本身。如果预付款没有显示，应检查银行账户、过账状态、日期范围和对账页面的筛选条件。

正常的会计影响

创建并过账 Vendor Prepayment 后，总账通常会产生以下分录：

Dr Vendor Prepayment Account    预付款金额
Cr Bank Account                 预付款金额

将预付款应用到 Vendor Bill 时，通常会产生：

Dr Accounts Payable
Cr Vendor Prepayment Account

因此，参与银行对账的是创建预付款时贷记银行账户的交易。之后应用预付款时，不会再次影响银行账户。

排查步骤

1. 检查交易上的 Bank Account

打开 Vendor Prepayment，确认 Bank Account 与当前正在对账的账户一致。

常见问题包括：

选成了其他银行账户。
选择了名称相近、内部 ID 不同的账户。
银行账户属于其他 subsidiary。
使用了账户类型不是 Bank 的普通总账账户。

银行对账通常只显示过账到 Bank 类型账户的交易。

2. 查看 GL Impact

打开预付款交易的 GL Impact，确认其中至少有一行指向目标银行账户。

如果 GL Impact 中没有银行账户行，这笔交易不会出现在银行对账页面。此时需要检查：

交易是否已保存并过账。
交易是否仍在审批中。
Bank Account 是否填写正确。
会计期间是否允许过账。
自定义工作流或脚本是否修改了账户，或者阻止了过账。

如果启用了 Vendor Prepayment Approval，尚未批准的预付款可能不会产生最终过账。实际行为取决于账户的功能配置和审批流程。

3. 检查 Vendor Prepayment Account

预付款账户通常应设置为 Other Current Asset，不应设置为：

Bank
Accounts Payable
Expense

这个账户用于保存尚未应用到 Vendor Bill 的资产余额。将其设为银行账户无法解决对账问题，还可能导致账户余额和现金流分类错误。

相关首选项的菜单名称可能随 NetSuite 界面和已启用功能而变化。可以在 Accounting Preferences 或 Vendor Prepayments 的相关配置中查看默认预付款账户。

4. 检查对账日期和筛选条件

确认银行对账页面的日期范围包含预付款的 Transaction Date，并检查以下项目：

Statement End Date 是否早于预付款日期。
交易是否已在其他对账单中完成对账。
页面是否只显示未匹配或未对账的交易。
当前选择的 account、subsidiary 和 currency 是否与交易一致。
交易是否处于 voided、rejected 或 non-posting 状态。

如果使用 Match Bank Data，还要确认导入的银行流水在金额方向和日期上能与预付款对应。即使自动匹配失败，只要交易已正确过账到银行账户，通常仍可在待匹配交易中手动找到。

使用 SuiteQL 检查总账行

如果拥有 SuiteAnalytics 或 SuiteScript 权限，可以直接查询交易是否已写入目标银行账户。以下示例仅用于诊断，不会修改数据：

define(['N/query'], (query) => {
  const inspectVendorPrepayment = (transactionId) => {
    const result = query.runSuiteQL({
      query: `
        SELECT
          t.id,
          t.tranid,
          t.trandate,
          t.posting,
          BUILTIN.DF(t.status) AS status,
          a.id AS account_id,
          a.acctnumber,
          a.fullname AS account_name,
          a.accttype,
          tal.debit,
          tal.credit,
          tal.netamount
        FROM Transaction t
        JOIN TransactionAccountingLine tal
          ON tal.transaction = t.id
        JOIN Account a
          ON a.id = tal.account
        WHERE t.id = ?
        ORDER BY tal.transactionline
      `,
      params: [transactionId]
    });

    return result.asMappedResults();
  };

  return { inspectVendorPrepayment };
});

查看查询结果时，确认：

posting 表明交易已经过账。
至少有一行的 accttype 是银行账户类型。
该行的 account_id 与当前对账银行账户的内部 ID 相同。
银行行的金额方向与付款一致。

SuiteQL 字段是否可用，可能受账户版本、角色权限和 Analytics 数据源影响。如果某些查询字段不可用，也可以通过交易的 GL Impact 或 Account Register 完成相同核对。

仍未显示时

如果 GL Impact 已明确贷记正确的银行账户，日期、subsidiary、currency 和对账状态也没有问题，但交易仍未出现在页面中，需要确认当前使用的是传统 Bank Reconciliation，还是 Match Bank Data / Reconcile Account Statement。

不同对账界面可能采用不同的交易类型和筛选规则。可以继续执行以下检查：

在银行账户的 Account Register 中确认交易存在。
清除对账页面的筛选条件，然后重新加载。
确认相关银行功能和角色权限已经启用。
使用管理员角色复查，排除 subsidiary 或交易权限限制。
向 NetSuite Support 提供交易内部 ID、银行账户内部 ID、GL Impact 和所用对账页面，请其确认当前账户版本是否存在交易类型限制。

除非原交易的会计影响确实有误，否则不要通过额外录入 Journal Entry 来补充对账记录，以免银行账户重复入账。