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

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

企业普遍依赖“信用交易”完成业务，比如喜乐君在与客户签订合同后就预先交付 Tableau 软件，甚至入场服务，前提是我相信客户会按照合同履行，在未来较短时间内按照发票完成付款。合同意味着订单、交付，交付对应发票和回款，可见这是 LtC（从线索到回款）流程中的一个缩影。
合同彼此确认代表正式合作的开始，合同金额意味着卖方的“借”，买方的“贷”，从现金角度看，合同金额对应卖方的“应收帐款”（Account Receivable），对应买方的“应付账款”（Account Payable）。
本文基于喜乐君的项目实践，汇总业务理解和数据表达，帮助业务用户理解真实世界和数据世界的关联逻辑。

一、应收帐款的业务过程

业内普遍定义，AR 应收帐款是企业在赊销商品或服务时，应该向客户收取的款项金额。本质上，应收帐款是信用（credit）、债权 （creditor’s rights），是对货币所有权的主张。
理解应收有几个关键：赊销、现金、账期。
其一，应收帐款只有在存在“赊销”时才有价值（如果是现金当场交易，不存在后续的应收权利）。
其二，应收帐款对应款项金额，数据中体现为货币数值（以物易物不在这个范围中）。
其三，应收帐款有约定周期（账期），比如未来几周到一年，超过一年无法回收往往会导致科目变化（就像信用卡逾期不还成为坏账，金融的坏账通常是 180 天，即六期）。
Accounts receivable is anyamount of moneyyour customersoweyou for goods or services they purchased from you in the past.
Nick Zaryzcki
应收帐款是企业资产之一，代表企业收入但还没有完全货币兑现的部分，“应收帐款总额”是企业的关键指标。同时，应收帐款对应企业现金流，代表企业在未来一段时间内可以获得的资金流入，因此还需要衡量它的流动效率，使用“周转天数”来衡量。
从“业务-数据-分析”的框架体系，这里先介绍应收帐款对应的业务环境，包括业务对象、业务过程和业务规则。

1、业务对象和业务过程

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

• 发票是具体的业务对象，数据形式上表现为“发票号”（InvoiceNumber）
• 发票有很多属性，比如每一张发票对应的发票日期（InvoiceDate）、发票金额（InvoiceAmount）等
  为了避免技术化词语对分析人员的困扰，本文姑且把发票号、发票日期、发票金额统称之为“业务对象”，即业务现实中有具体对应、与行为所指的对象（每次说到这里，我就想起来上一代 BI 的代表产品 BO——BusinessObjects）。
  从销售的角度看，交易的主体是人、客户，交易的过程表示为订单ID——谁在何时何地、给谁提供了何种产品的具体交易；可见，订单 ID 的抽象性在于表达一个过程，技术中称之为“事务”（transaction），业务中可理解为“一件具体之事”。
  应收账款也是同理，应收帐款的主体包含发票、凭证、买方、卖方、预期回款日期、金额等，应收帐款的过程可以表示“销售方在未来某个时间点，预计从客户获得应收金额的预期”。财务也可与为每一件最具体的应收之事标记一个唯一序号，如“2024-06-A-0520”，这种易读的编码背后会自动生成唯一性 ID，比如“AccountReceivableId”——它仅仅用于数据库内部的关联、完整性约束，与易读编码在业务上等价。
  每一个唯一的事务，都反映现实中具体的业务过程。比如“2024-06-A-0520”表示 6 月财务人员 A，为客户 C1 登记了一笔 10 万元的应收帐款预期，记录在凭证 001 之下。每一个具体的业务过程总是由 Who、Whom、What、When、Where、How、How Much 这样的业务对象构成的。这也是后续“数据表”中最重要的元素。
  关键词：
• Account 会计、账户
• Booking 账簿
• BookingKeeping 账簿
• Ledger 分类账
• General Ledger 总账GL
• Subsidiary Ledger 明细分类账
• AccountsReceivable 应收帐款 AR
• AccountsPayment 应付账款 AP
• Voucher 记账凭证
• Payment Voucher 付款凭证
  “应收帐款业务”最重要的对象包含如下内容：
• Who：凭证号（LedgerId）、发票（InvoiceNumber）、联系人（ContactId）
• （Whom：客户（customer））
• Where：账簿（BookingId）
• How：是否拆分付款（isSplitPayment）、支付方式
• When：开票日期（InvoiceDate）、到期日期（DueDate）、付清时间（PaiedInFullDate）
• How Much：发票金额（InvoiceAmount）、剩余应收金额（RestAmount）
  为什么这里客户名称加个括号呢？客户可是付款的主体呢。从宽表的逻辑上是可以列举的，但从数据库的角度看，客户是 Invoice 发票延伸出去的属性。
  另外，有一些业务对象是基于业务规则需求预设设定的，比如“是否提醒”，以及“提醒日期”。财务可以把业务中用日程管理、便签等完成的操作以软件自动化，这就是 Monitor 中 PaymentReminder（布尔，是否提醒）和LatestReminderDate（提醒日期）的来源。每次出现提醒，可以根据需要设置下一次提醒，或者不再提醒。系统设置可以自己累加获得该应收帐款的提醒次数（字段NumberOfPaymentReminders让我惊讶，这就是好工具背后优秀产品经理的价值）。

2、业务规则：应收帐款的系统规则和人为规则要素

理解了应收帐款其实是赊销业务中生成的债务，对于企业现金流等而言至关重要，企业自然就会加强考核和管理。
如果没有回款方面的考核，销售人员会在利益驱使下盲目扩大销售，导致坏账越来越多；如果缺乏管理，企业资金周转会越来越慢。这也是销售普遍以销售业绩设置目标，但以回款发放绩效的原因。
应收帐款的规则有主客观两个方向，客观的规则我称之为业务规则，主观的规则我则倾向于称之为“管理规则”。
客观的方面，每一笔应收帐款都有默认的到期日期（DueDate）、是否允许分期支付、是否收取利息等。客观的业务规则可以是全公司默认统一的预设规则（比如公司默认都不收取客户利息），或者按照“一单一议”的方式在创建时勾选（比如是否允许客户分期多次支付）。
客观的业务规则往往是行业朴实规则，也是 ERP 和财务系统开发时默认的功能设定。当然，优秀的软件工具总是包含更多的行业经验和最佳实践，能适应企业各种需求的变化。
主观规则，又称为管理规则，常常是随着企业经营情况变化随时调整的，比如近期公司现金流紧张，超过逾期日期不能付款的应收帐款一律增加利息，并调低该客户的信用额度。此类规则往往难以在系统层面自动化执行，需要人为的干预。
客观的业务规则是可以基于业务系统的，主观的管理规则是基于数据和分析工具的。

3、应收帐款的逾期OverDue 和坏账 bad account

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

• 逾期比率
• 逾期金额

二、应收帐款的数据表达

在了解了应收帐款的基本业务之后，我们可以聚焦数据上的反映形式——每一个数据字段都是对业务的“蚀刻”过程。之前我常说“反映”（representation），这个词虽然准确，但不够“深刻”。数据不仅仅是反映，更是恒久的记录。
如下图所示，展示了 Monitor ERP 的应收帐款明细表字段:
状态Status 字段，0 代表批准 Approved、1 代表已打印 Printed、2 代表取消 Cancelled。
与 cancel 相关的字段就有五个：CancelDate、CancelBookingId、CancelBook、CancelComment、CancelComment 。
优秀的 ERP 工具会尽可能反映现实，同时提供高级抽象逻辑，比如在应收帐款明细中提供“付清日期”（PaidFullDate），这是在收款明细基础上增加了特别业务判断而来的收款属性。
为什么本应属于回款阶段的“付清日期” （PaidInFullDate） 和“剩余金额”（RestAmount），出现在了应收帐款环节呢？这可以视为业务规则带来的影响。
假设一个客户欠款 100 元，已经支付了 30 元，尚有 70 缺口，如果仅仅以为剩余必然是应收总额 和 回款金额的差，那就没有单独设置字段的必要性。但很多业务实际并非如此，比如因为特殊原因，我方自愿购销部分应收金额（write off）此时，余额就成了可以直接干预的业务对象，而非计算出来的衍生字段。
……

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

基于数据表的日期、状态等字段，就可以计算各种汇总、比率、账龄分段等复杂业务，这就是抽象世界的价值。单从日期角度，我们就可以计算多个区间和账龄：

• 从 Invoice Date 到 PaidFullDate计算完整付款周期
• 没有付清日期的，基于 InvoiceDate 到 Today 计算账龄
• 基于账龄分段，类似于金融行业的 MOB1、MOB2-5等(以30天为分解)
  这里要思考一个关键问题：为什么“剩余应收金额”和“付清日期”出现在了上一个阶段，直接出现在了数据表中，但非常重要的“账龄”却没有呢？
  在这里，喜乐君把“账龄”称之为逻辑字段，而非和“剩余应收金额”一样的物理字段，它可以直接基于物理字段按需计算而来，而且没有任何的规则调整空间，所以在明细表中预先计算虽有意义，但并无必要，甚至会带来性能和准确性问题。

1、逻辑字段代表：应收帐款的“账龄”aging

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

• 不同回款周期的收款金额和笔数
• 每家客户的平均回款周期天数
  对业务和客户熟悉的财务可以预测不同账龄的应收金额，从而帮助企业做好资金规划（Accounts Receivable Aging Schedule）。 当然，下面的示例，是建立在每一笔应收帐款的账龄计算，以及分类汇总基础上的，因此完全属于分析的范畴。
  客户名称 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

…… （后补）

2、逻辑指标代表：应收帐款周转率 AC turnover ratio

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

• 日均应收帐款金额 = （期初 +期末 ） / 2 = 30 万
• 周转率 Turnover Ratio = 赊销净额 / 日均应收帐款 = 120/30 = 4 次
  从业务角度看，企业负责人为了维持 360 万元的营业收入，需要预先垫付货币资金维持企业运营（比如人员工资、库存成本、生产、外协等），因此应收帐款的周转天数对于企业而言意味着资金效率。周转率越高，意味着越高效。

2、企业销售变现天数 (DSO)

企业销售变现天数是一个应收账款指标，可显示您完成销售后客户向您付款所需的平均时间。 它可以帮助您确定资金催收策略的有效性。
要计算您的 DSO，请将应收账款总额除以赊销总额，然后乘以 365。
DSO = [Total Accounts Receivable / Total Credit Sales] x 365
后补……
3、应收账款最佳周转天数 (Best Possible Days Sales Outstanding)
应收账款最佳周转天数 (Best Possible DSO) 显示客户付款的平均天数（假设他们总是按时付款）。
要计算应收账款最佳周转天数，请将当期应收账款除以赊销总额，然后乘以 365。
应收账款最佳周转天数 (Best Possible DSO) = [Current Accounts Receivable / Total Credit Sales] x 365
4、应收账款平均拖欠天数 (ADD)ADD 显示您的应收账款平均逾期时间。
平均拖欠天数 = 企业销售变现天数 – 最佳周转天数
5、销售坏账公式：未收回销售额/年销售额 x 100
6、收款有效性指数 (CEI)
CEI 可帮助您衡量应收账款团队在特定时期（例如一个月或一年）收回应收账款的效率。
注：上述指标逻辑，参考https://www.payoneer.com/zh-hans/resources/accounts-receivable/

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

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

1、业务理解

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

• 一个应收帐款条目，可以对应多次收款；即客户可以分笔、分期支付，直至全部结清。
• 一个应收帐款条目，可以没有收款与之对应，特别是刚刚创建的应收帐款；反之，每一笔收款必要要有应收科目与之对应。但是，考虑到企业罚款、银行利息这类与客户无直接关联的收款，实际上收款明细也只是部分对应。

2、从业务到数据

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

• 基数比：应收帐款数据表中的 一行，可以对应 收款明细表 的多行，即1：M 关系
• 引用完整性：应收帐款中到收款明细表是“部分引用”，反之依然。
  当然，理解关系的前提是理解两个业务的关联依据，技术上称之为外键（foreign Key）。如下所示：
  能到这一步，就算打通了业务现实与数据世界的关系了。
  接下来，就可以基于应收帐款科目（ledger），汇总应收金额和实际收款金额了。优秀的 BI 让我们不需要过度思考技术上的实现形式，但没有必要的技术理解，我们也难以理解抽象世界。
  
  如果结合付款进度，就有了账龄和付款之间的相关性分析了。
  后续补充。
  喜乐君 Jun 1, 2024
  6月23日 补充
  参考：