【供应链】应收帐款(AR)及其数据形式 V0.4

喜乐君 2 min read

供应链应收帐款(AR)的业务逻辑与数据形式详解：信用交易、账龄分析及Tableau应用场景。

企业普遍依赖「信用交易」完成业务，比如喜乐君在与客户签订合同后就预先交付 Tableau 软件，甚至入场服务，前提是我相信客户会按照合同履行，在未来较短时间内按照发票完成付款。合同意味着订单、交付，交付对应发票和回款，可见这是 LtC（从线索到现金）的最后一公里。

合同彼此确认代表正式合作的开始，合同金额意味着卖方的「借」，买方的「贷」，从现金角度看，合同金额对应卖方的「应收帐款」（Account Receivable），对应买方的「应付账款」（Account Payable）。

本文基于喜乐君的项目实践，汇总业务理解和数据表达，帮助业务用户理解真实世界和数据世界的关联逻辑。

一、应收帐款的业务过程

业内普遍定义，AR 应收帐款是企业在赊销商品或服务时，应该向客户收取的款项金额。本质上，应收帐款是信用（credit）、债权（creditor's rights），是对货币所有权的主张。

理解应收有几个关键：赊销、现金、账期。

  • 应收帐款只有在存在「赊销」时才有价值（如果是现金当场交易，不存在后续的应收权利）。

  • 应收帐款对应款项金额，数据中体现为货币数值（以物易物不在这个范围中）。

  • 应收帐款有约定周期（账期），比如未来几周到一年，超过一年无法回收往往会导致科目变化（就像信用卡逾期不还成为坏账，金融的坏账通常是 180 天，即六期）。

应收帐款是企业资产之一，代表企业收入但还没有完全货币兑现的部分，「应收帐款总额」是企业的关键指标。同时，应收帐款对应企业现金流，代表企业在未来一段时间内可以获得的资金流入，因此还需要衡量它的流动效率，使用「周转天数」来衡量。

从“业务-数据-分析”的框架体系，这里先介绍应收帐款对应的业务环境，包括业务对象、业务过程和业务规则。

业务对象是构成业务过程的主体，从技术角度看，业务对象又可以分为实体和属性两大类，比如：

为了避免技术化词语对分析人员的困扰，本文姑且把发票号、发票日期、发票金额统称之为“业务对象”，即业务现实中有具体对应、与行为所指的对象（每次说到这里，我就想起来上一代 BI 的代表产品 BO——BusinessObjects）。

从销售的角度看，交易的主体是人、客户，交易的过程表示为订单ID——谁在何时何地、给谁提供了何种产品的具体交易；可见，订单 ID 的抽象性在于表达一个过程，技术中称之为“事务”（transaction），业务中可理解为“一件具体之事”。

应收账款也是同理，应收帐款的主体包含发票、凭证、买方、卖方、预期回款日期、金额等，应收帐款的过程可以表示“销售方在未来某个时间点，预计从客户获得应收金额的预期”。财务也可与为每一件最具体的应收之事标记一个唯一序号，如“2024-06-A-0520”，这种易读的编码背后会自动生成唯一性 ID，比如“AccountReceivableId”——它仅仅用于数据库内部的关联、完整性约束，与易读编码在业务上等价。

每一个唯一的事务，都反映现实中具体的业务过程。比如“2024-06-A-0520”表示 6 月财务人员 A，为客户 C1 登记了一笔 10 万元的应收帐款预期。每一个具体的业务过程总是由Who、Whom、What、When组成。

“应收帐款业务”最重要的对象包含如下内容：

为什么这里客户名称加个括号呢？客户可是付款的主体呢。从宽表的逻辑上是可以列举的，但从数据库的角度看，客户是 Invoice 发票延伸出去的属性。

另外，有一些业务对象是基于业务规则需求预设设定的，比如“是否提醒”，以及“提醒日期”。财务可以把业务中用日程管理、便签等完成的操作以软件自动化，这就是 Monitor 中 PaymentReminder（布尔，是否提醒）和LatestReminderDate（提醒日期）的来源。每次出现提醒，可以根据需要设置下一次提醒，或者不再提醒。系统设置可以自己累加获得该应收帐款的提醒次数（字段NumberOfPaymentReminders让我惊讶，这就是好工具背后优秀产品经理的价值）。

业务规则：系统规则和人为管理规则

理解了应收帐款其实是赊销业务中生成的债务，对于企业现金流等而言至关重要，企业自然就会加强考核和管理。

如果没有回款方面的考核，销售人员会在利益驱使下盲目扩大销售，导致坏账越来越多；如果缺乏管理，企业资金周转会越来越慢。这也是销售普遍以销售业绩设置目标，但以回款发放绩效的原因。

应收帐款的规则有主客观两个方向，客观的规则我称之为业务规则，主观的规则我则倾向于称之为“管理规则”。

客观的方面，每一笔应收帐款都有默认的到期日期（DueDate）、是否允许分期支付、是否收取利息等。客观的业务规则可以是全公司默认统一的预设规则（比如公司默认都不收取客户利息），或者按照“一单一议”的方式在创建时勾选（比如是否允许客户分期多次支付）。

客观的业务规则往往是行业朴实规则，也是 ERP 和财务系统开发时默认的功能设定。当然，优秀的软件工具总是包含更多的行业经验和最佳实践，能适应企业各种需求的变化。

主观规则，又称为管理规则，常常是随着企业经营情况变化随时调整的，比如近期公司现金流紧张，超过逾期日期不能付款的应收帐款一律增加利息，并调低该客户的信用额度。此类规则往往难以在系统层面自动化执行，需要人为的干预。

客观的业务规则是可以基于业务系统的，主观的管理规则是基于数据和分析工具的。

应收帐款的逾期（OverDue）和坏账（Bad Account）

如果客户因为经营困难或其他风险导致无法支付应收帐款，就会出现逾期（超过合同时间不付款）甚至坏账（无法收回帐款）。坏账对企业利润会由显而易见的影响，因此也是业务分析的重点。

二、应收帐款的数据表达

每一个数据字段都是对业务的「蚀刻」过程。数据不仅仅是反映，更是恒久的记录。

如下图所示，展示了 Monitor ERP 的应收帐款明细表字段:

状态Status 字段，0 代表批准 Approved、1 代表已打印 Printed、2 代表取消 Cancelled。

与 cancel 相关的字段就有五个：CancelDate、CancelBookingId、CancelBook、CancelComment、CancelComment 。

优秀的 ERP 工具会尽可能反映现实，同时提供高级抽象逻辑，比如在应收帐款明细中提供“付清日期”（PaidFullDate），这是在收款明细基础上增加了特别业务判断而来的收款属性。

为什么本应属于回款阶段的“付清日期” （PaidInFullDate） 和“剩余金额”（RestAmount），出现在了应收帐款环节呢？这可以视为业务规则带来的影响。

假设一个客户欠款 100 元，已经支付了 30 元，尚有 70 缺口，如果仅仅以为剩余必然是应收总额 和 回款金额的差，那就没有单独设置字段的必要性。但很多业务实际并非如此，比如因为特殊原因，我方自愿购销部分应收金额（write off）此时，余额就成了可以直接干预的业务对象，而非计算出来的衍生字段。

……

三、应收帐款的逻辑值和指标分析

基于数据表的日期、状态等字段，就可以计算各种汇总、比率、账龄分段等复杂业务，这就是抽象世界的价值。

这里要思考一个关键问题：为什么“剩余应收金额”和“付清日期”出现在了上一个阶段，直接出现在了数据表中，但非常重要的“账龄”却没有呢？

在这里，喜乐君把“账龄”称之为逻辑字段，而非和“剩余应收金额”一样的物理字段，它可以直接基于物理字段按需计算而来，而且没有任何的规则调整空间，所以在明细表中预先计算虽有意义，但并无必要，甚至会带来性能和准确性问题。

逻辑字段：应收帐款的「账龄」（Aging）

不同客户的回款周期有明显差异，一个客户的多笔货款也有差异，比如有的一周回款，有的 5 周回款，业内把周期称之为“账龄”（aging）。 应收帐款的账龄（accounts receivable aging）分析和规划，就是企业管理会计的重要工作。

分析中就有很多典型的问题：

对业务和客户熟悉的财务可以预测不同账龄的应收金额，从而帮助企业做好资金规划（Accounts Receivable Aging Schedule）。

客户名称

1-30天

30-60天

60天以上

合计 Total

客户名称

1-30天

30-60天

60天以上

合计 Total

客户 A

$500

$1,000

$500

$2,000

客户 B

$500

$100

$100

$700

客户 C

$1,000

$200

$0

$1,200

客户 D

$1,000

$0

$100

$1,100

客户 E

$2,000

$50

$0

$2,050

合计Total

$5,000

$1,350

$700

$7,050

…… （后补）

逻辑指标：应收帐款周转率（AC Turnover Ratio）

假设喜乐君公司 2023 年获得了全年 360 万 净收入，年底有 120 万元 为赊销收入净值；年初应收帐款 20 万，年底应收帐款 40 万。

应收帐款周转率 = 赊销收入净额 / 平均应收帐款
               = 120万 / ((20万 + 40万) / 2)
               = 120万 / 30万
               = 4 次

从业务角度看，企业负责人为了维持 360 万元的营业收入，需要预先垫付货币资金维持企业运营。应收帐款的周转天数对于企业而言意味着资金效率。周转率越高，意味着越高效。

从业务角度看，企业负责人为了维持 360 万元的营业收入，需要预先垫付货币资金维持企业运营（比如人员工资、库存成本、生产、外协等），因此应收帐款的周转天数对于企业而言意味着资金效率。周转率越高，意味着越高效。

企业销售变现天数（DSO）

DSO（Days Sales Outstanding）企业销售变现天数，是衡量客户付款速度的核心指标。它显示您完成销售后客户向您付款所需的平均时间，帮助您确定资金催收策略的有效性。
DSO = (Total Accounts Receivable / Total Credit Sales) × 365

后续补充……

应收账款最佳周转天数（Best Possible DSO）

应收账款最佳周转天数 (Best Possible DSO) 显示客户付款的平均天数（假设他们总是按时付款）。

Best Possible DSO = (Current Accounts Receivable / Total Credit Sales) × 365

应收账款平均拖欠天数（ADD）

ADD（Average Days Delinquent）显示您的应收账款平均逾期时间。

ADD = DSO - Best Possible DSO

销售坏账率

销售坏账率 = 未收回销售额 / 年销售额 × 100%

收款有效性指数（CEI）

CEI（Collection Effectiveness Index）可帮助您衡量应收账款团队在特定时期收回应收账款的效率。

参考：https://www.payoneer.com/zh-hans/resources/accounts-receivable/

四、跨主题：从应收帐款与收款明细

应收帐款的下一步环节就是“回款”（IncomingPayment），从这个角度，可以理解不同业务场景之间的关联和分析。

业务理解

应收帐款对应预期收款，随着时间临近，每天都会有大量的收款对应应收帐款科目。考虑到两个业务属于不同业务场景，而且都是包含数据值的业务过程，因此这里不便于合并，先抽象地理解如下的关系：

从业务上看，两个不同的业务之间，有两个重点逻辑：

从业务到数据

从数据的角度，上述两个业务特征会分别描述为「应收帐款数据表」和「收款明细表」的关系特征：

当然，理解关系的前提是理解两个业务的关联依据，技术上称之为外键（foreign Key）。如下所示：

能到这一步，就算打通了业务现实与数据世界的关系了。

优秀的 BI 让我们不需要过度思考技术上的实现形式，但没有必要的技术理解，我们也难以理解抽象世界。

如果结合付款进度，就有了账龄和付款之间的相关性分析了。

后续补充。

喜乐君 Jun 1, 2024

6月23日 补充

参考：

📌 本文核心要点

➊ 应收帐款 = 赊销产生的债权，核心三要素：赊销、现金、账期
➋ 账龄（Aging）= 应收帐款的时间维度，用于资金规划和坏账预测
➌ 周转率 & DSO = 衡量企业资金回收效率的关键指标
➍ 数据表达：物理字段（明细数据）→ 逻辑字段（账龄）→ 逻辑指标（周转率/DSO）

No comments yet

Continue reading