NC Cloud应收应付模块实战：从立账、核销到账龄对账全解析

简介：NC Cloud 2021.05全产品培训之应收应付模块，面向用友NC Cloud实施顾问、财务管理人员及企业数字化项目成员，系统讲解应收应付业务全流程管理。PDF讲义共1个文件，压缩包约8.6MB，内容密度高，便于快速查阅与培训复用。目前已有782人学习下载。讲义从收付单据、转移并账、协同管理、核销处理等十大功能展开，覆盖预收现销、预付现购等业务场景，并给出催款、账龄分析、汇兑损益及期末建账关账等实务操作，还涉及退款、预核销、RPA机器人等2021.05版新增特色功能，以及税务云、电子会计档案系统对接方案。适合希望系统掌握NCC应收应付配置逻辑、提升财务共享与自动化处理能力的从业人员学习。

1. 应收应付模块在NC Cloud里的位置，以及它管的是哪本账

每次讲NC Cloud全产品培训，应收应付模块总是我留给现场互动时间最多的部分。原因很简单：这个模块不像总账那样只跟财务自己打交道，也不像销售、采购那样业务做完就收工，它的上游连着销售出库和采购入库，下游接着收付款和总账凭证，中间还要处理核销、暂估、红蓝对冲这些财务老法师都容易绕晕的场景。可以说，一家企业上了NC Cloud之后，应收应付模块跑得顺不顺，直接决定财务月结要不要加班。

1.1 为什么全产品培训要把应收应付单独拿出来讲

在NC Cloud里，应收应付扮演的是“翻译器”的角色。销售出库在业务上只是库存减少，但如果要做成财务数据，就必须变成收入确认和应收账款增加；采购入库在业务上是存货增加，在财务上则要与供应商形成负债。这个“翻译”的动作，由应收单、应付单配合会计科目映射完成。如果只看总账，你只能看到科目余额，但看不到这笔钱对应的是哪个客户、哪张发票、哪笔合同；如果只看业务单据，你又不知道财务入账是否准确。应收应付模块恰恰是打通这两层的数据中枢，它记录每一笔往来的来龙去脉，再按规则沉淀到总账。

从培训定位来看，应收应付模块面向的岗位也特别宽。销售会计用它确认收入、跟踪回款，采购会计用它核对供应商余额，资金岗通过收付款单做资金计划，审计和税务在年末也要从这里取数。一个模块服务这么多角色，自然需要单独讲透。

1.2 应收应付在NC Cloud里的功能分区与周边模块联动

以NC Cloud 2021.05版本的功能布局来看，应收应付相关的功能大致可以分成五块：立账单据管理（应收单、应付单、暂估单等）、收付款管理（收款单、付款单、退款单等）、核销处理（手工核销、自动核销、往来对冲）、账龄分析与信用管理、期末处理与对账。每一块都有对应的高频业务场景。

模块间的联动关系可以用下面这张表来理解：

我在培训时经常提醒学员：一定不要只盯着应收应付模块内部的菜单操作，要先建立这张联动图。因为你遇到的很多“异常”，根源往往不在应收应付本身，而在上游单据没推送过来，或者下游总账改了科目。这个判断思路，比记住任何一个具体操作都重要。

2. 参数和基础档案：上线前定好，上完线少熬夜

2.1 最重要的几个应收应付参数，以及选错之后的后果

NC Cloud应收应付的参数不算特别多，但每个都像交通规则，定下来之后全员都要遵守。如果上线时随意设，等业务数据进来了再改参数，历史单据往往跟着错乱，处理成本极高。

我特别关注三个方向的参数。第一个是立账时点：销售的应收是开票时立账，还是出库时立账；采购的应付是发票校验时才立账，还是入库即暂估。这直接决定收入确认和负债确认的时点，选错可能影响税务口径和财务报表出具。第二个是凭证生成时机：应收单审核后立刻生成凭证，还是审批完成后才生成。这个参数决定了总账出现未审核凭证的窗口期，很多财务人员发现“总账没凭证”，多半就是这里设置成审批后才生成，而审批流程还没走完。第三个是核销控制参数：是否允许超额核销、是否允许部分核销、反核销是否需要审批。这些控制不严，就会出现同一个客户余额被反复冲来冲去，最后账龄越拉越长。

2.2 客户和供应商档案里的财务字段，填错一个全是坑

比参数更容易被忽略的，是客商档案里的财务信息。做培训时我经常现场统计：有多少人上线前花过完整的时间去核对客商档案？实际举手的人很少。这个环节做得粗，后面所有跟客商相关的单据都会跟着错。

客户档案和供应商档案的财务页签里，至少要确认四类信息。一是默认应收科目和默认应付科目，模板里如果没带出来，制单人又不太熟悉科目体系，一批凭证的往来科目就会挂错。二是结算方式，是电汇、承兑汇票还是现金，它会带到收付款单上，影响资金计划。三是币种和结算币种，如果客户偶尔用外币结算但档案里写死人民币，收汇时汇率差异处理就麻烦。四是信用额度与付款条件，这直接关联信用管控和账龄分析里的逾期判断。很多合并范围的集团客户还要维护“内部客商”标志，否则做合并抵销时，内部往来的数据怎么都对不上。

我在项目上习惯让财务负责人亲自过一遍客商档案清单，不要完全交给IT代录。财务更清楚“这个客户平时怎么收款、挂哪个科目、信用期多久”，IT只是辅助导入。宁可上线前多花两天核档案，也不要在结账前一天对着差异表怀疑人生。

3. 单据流转全记录：从销售出库到收款核销的完整链路

3.1 销售侧标准链路：应收单如何从业务单据中长出来

NC Cloud里销售侧应收的典型链路是这样：销售订单审核后，仓库做发货和出库；如果是开票立账，销售发票校验之后会自动或手动生成应收单；应收单审核通过，生成收入、税和应收账款的凭证；客户回款时做收款单，再把收款单和对应的应收单做核销。

这条链路里最关键的一步是应收单的来源。很多制单人觉得“我手工在应收模块加一张单也行”，实际上手工录入不仅效率低，还容易漏税率、漏合同号、漏项目字段，导致后续对账无据可查。我通常建议客户优先用推式生成或拉式生成，让应收单从销售发票或出库单带出全部业务信息，这样可以保证业务单据和财务单据一对一对得上，也为审计追溯留了完整证据链。

3.2 采购侧标准链路：应付单的形成与付款

采购侧的逻辑和销售侧对称，但又容易夹着一个“暂估”的特殊分支。标准流程是采购订单完成后仓库入库，收到供应商发票后做发票校验，再由采购发票生成应付单，审核后生成应付账款和相关成本、进项税凭证。到了付款环节，资金岗做付款单，然后与应付单核销，表示这笔负债已经结清。

如果企业采用“货到票未到”的结算方式，在发票校验之前还要先走暂估应付。此时系统会生成暂估应付单，入账的金额一般按订单金额或历史价格估算。财务上常用月初回冲或者在收到发票后做差额调整来处理。这块我放在下一节专门展开，因为它确实是项目上翻车率最高的场景之一。

3.3 凭证生成逻辑：业务数据怎么变成财务凭证

应收应付生成凭证的逻辑，可以理解成一个自动填分录的机器：业务单据上的金额、税率、客商、存货、费用项目，按配置好的凭证模板，填到科目、辅助核算和摘要里，最后输出到总账。典型的销售应收凭证分录是：

借：应收账款——某客户 贷：主营业务收入 应交税费——应交增值税（销项税额）

采购应付凭证一般是：

借：原材料/库存商品 应交税费——应交增值税（进项税额） 贷：应付账款——某供应商

看起来简单，但实际项目上最容易出问题的是辅助核算没带全。比如应收账款科目挂了“客商辅助核算”，模板里却只映射了科目，没有把单据上的客户名称填进去，生成的凭证虽然有金额，但辅助余额表里永远查不到明细。所以培训时我反复讲一句话：凭证模板配置完一定要做“穿透检查”，带着一个真实单据从头跑到尾，去看总账凭证里的科目、辅助核算、金额、摘要四个维度是否全部正确，不能只盯着借贷平衡。

4. 暂估、红蓝对冲、部分核销：三个最容易翻车的场景

4.1 货到票未到时的暂估应付与月初回冲

暂估单是我在培训时花了最多时间讲的业务场景，因为它涉及的业务判断最多。采购已经入库，仓库库存已经变化，但供应商发票还没到，财务怎么确认负债？此前很多企业在线下会手工做一笔暂估入库凭证，等发票到了再全部冲回，重新入账。NC Cloud里的逻辑与此一致，只是把暂估、回冲、差额调整变成了系统单据。

在落地操作上，常见做法是月末对未结算的采购入库单生成暂估应付单，入账金额按不含税订单价。次月初系统自动生成红字暂估应付单，把原暂估应付冲掉，等发票校验后再生成正式应付单。如果暂估金额和发票金额不一致，差额部分直接体现在正式应付单上，暂估环节只需要保证当月存货和债务口径接近真实即可。这块操作需要注意的细节是暂估单有没有纳入审核流，如果没有，月末结账时会有一批未审核暂估单，导致应付暂估余额和总账对不上。

4.2 红蓝对冲：退货和价格调整怎么处理

红蓝对冲的说法听着复杂，实际就是负数单据和正数单据之间的“相互抵消”。我在培训现场经常遇到销售退回的业务：客户退货，仓库做退货入库，销售模块生成红字发票，应收模块收到红字发票后生成红字应收单。此时如果客户还欠着款，红字应收单就会抵扣原应收余额；如果客户已经把钱付清，红字应收单就变成了一笔“其他应付款”或预收款的抵减项，需要根据具体退款路径决定后续动作。

采购退货同理，红字应付单会冲减对供应商的应付余额。如果付款已经完成，则要配合收款单或退款单处理。还有一类场景是价格调整，比如合同约定因质量问题扣款，供应商给予货款折让，此时不用动原单据，直接做一个差额应付单或者红字应付单即可。做这几种操作时，我最想提醒的是：核销方向一定要看清楚，红蓝单据之间的核销顺序错了，余额表会变得一团糟。

4.3 部分核销：分批收款下的余额和账龄管理

部分核销在应收侧尤其常见：客户明明有10笔应收单，这次回款只够覆盖其中3笔，或者单笔应收单100万，客户分批打了60万。此时核销可以按单据一笔一笔勾选，也可以在同一张应收单内做部分核销。剩下的余额继续挂账，继续参与账龄分析。

但这个功能也有“副作用”：如果财务人员偷懒，长期不做核销，或者核销时只勾大额不勾小额，账龄分析表就会失真。比如某笔应收已经逾期两个月，但因为它一直被当成“未核销”挂在账上，而实际上对应的款项已经通过其他方式收回了，账龄分析仍然显示它逾期，信用管理就失去了意义。所以，部分核销使用得越频繁，越需要约定核销的及时性和核对周期。我建议客户每周至少做一次收款核销，不要等到月结前集中处理，那时根本来不及细看。

5. 核销、账龄与期末对账：月结前必须做对的几件事

5.1 核销完成度，直接决定账龄分析准不准

账龄分析是应收应付模块里管理层引用最多、却最容易被基础数据拖累的报表。账龄的计算逻辑并不复杂：按客户和应收单立账日期，把余额按区间切片，0到30天、31到60天、61到90天这样排下去。真正决定账龄可信度的是这个余额有没有被及时核销。

如果核销滞后，本来已经回款清零的应收单还在账龄表里占据额度，信用部门就会以为客户还欠着一大笔钱，进而做出错误的授信判断。我在项目上会帮客户设一个“核销检查”的日常动作：每个工作日下班前，财务只看一眼今日新增的收款单里有没有未核销的记录，原则上当天回款当天核销。省下的沟通成本远比这个动作花掉的时间大。期末做账龄分析时，再配合一个强制检查项，确保没有异常的大额未核销数据。

5.2 应收应付余额表与总账科目余额的对账路径

月结前最容易让财务焦虑的，就是应收应付模块的余额表和总账科目余额对不上。原因通常就那么几类，追查时可以按顺序排查：

第一，应收单或应付单还没有生成凭证，业务模块已经审核了，但总账没有对应凭证，导致模块余额大于总账余额。第二，凭证已经生成却被人为改了摘要、科目或辅助核算，导致总账里的往来余额和业务单据方向不一致。第三，财务直接在总账手工做过往来类凭证，比如手工调了一笔应收账款，但事前没有同步到应收模块，两边口径分道扬镳。第四，期初数据导入时模块期初和总账科目期初不是同一套数，之后越差越多。

我习惯建议客户在每个月结日做一套固定动作：先跑应收/应付余额表，再跑总账对应科目的余额表，用Excel把两套数的差异导出来，逐条核到单据。只要把上述四个原因逐一排查完，差异一般都能在半小时内定位。

5.3 期末处理的顺序建议

NC Cloud的期末处理顺序有讲究，不能想先结哪个就结哪个。应收应付模块的期末处理一般放在供应链单据关闭之后、总账月结之前。因为应收应付的数据来源于供应链，如果供应链还有未完的单据，应收应付取数就不完整；而总账月结前又需要应收应付把所有业务凭证都送过去，形成一个封闭的环。

实际操作中，我喜欢把顺序列成这样一个清单：先确认所有采购入库、销售出库、发票校验完成，然后对应收应付的所有立账单据过一遍审核流，接着做收付款核销，再检查未生成凭证的单据，把凭证全部送到总账，最后跑余额表和账龄表，做完差异核对再进入总账月结。照着这个顺序走，月结效率会高很多，财务也更有底气。

6. 培训现场被问得最多的五个问题

6.1 为什么应收单审核后总账里看不到凭证

这个问题的排查路径很固定：先看凭证模板是否挂在了正确的交易类型和单据类型上，再看参数里的凭证生成时机是审核时还是审批完成后，最后看制单人有没有权限生成凭证。我遇到过不少次，答案是审批流还没走完，财务就着急查凭证。这提醒我们：任何涉及流程的排查，都要先确认单据当前处在流程的哪个节点，这个节点是否满足触发条件，再去怀疑系统配置。

6.2 同一个客户既是供应商又是客户，能不能直接对冲

可以，但在NC Cloud里要通过往来对冲的功能实现，不能直接手工修改余额。操作逻辑是把对同一客商的应收和应付按规则对冲，生成相应的往来对冲单，再按规则生成总账凭证。这里有个前提：两边余额都要真实准确，不然对冲之后会出现“负往来”，比不对冲还难解释。我在培训里建议企业先立规矩，明确哪些情况允许对冲、每月几号做、由谁复核。

6.3 收款时给了客户现金折扣，核销金额怎么处理

这个场景在销售折让中很常见。客户应付100万，经协商只收98万，2万作为现金折扣。此时先正常收款，按实际98万做收款单，再对原应收单做一笔折让处理，差额2万形成销售费用或财务费用，通过凭证模板生成总账凭证。切忌直接把收款单做成100万，再找一个科目平掉2万，那样应收余额是平了，但业务和财务口径就漂移了。

6.4 期初往来余额上线时怎么导入

上线前的期初余额导入，我强烈建议按客商、按单据明细导入，而不是只导一个总金额。哪怕历史数据里很多单据已经很久远，也要尽量拆到原始单据维度。因为后续如果有客户来函证往来余额，只有明细级数据才能回应“这个余额由哪几笔构成”。如果实在无法还原明细，要将无法拆分的部分单列为“期初调整”类余额，并书面记录来源，方便审计追溯。

6.5 月末结账时应收应付模块锁死，怎么处理

结账时提示有未完成事项、业务单据未审核、有未核销记录，这些都是常见提示，按提示逐项处理即可。真正麻烦的是做了反向操作，比如反审核了已核销的单据，导致对账错乱。我给客户的建议是：把反核销、反审核的权限限制给到极小范围的财务主管，日常制单人没有反向操作权限。项目上线稳定之后，出问题的单据几乎全是反向操作和绕过流程补的单据，把这扇门关紧，月结能省一半时间。

我在项目上有个习惯，每次上线前都要做一次全量往来自查：把应收应付模块的期初余额表、总账科目余额表、客商辅助余额表同时导出来比对，把所有差异在正式业务数据进入之前处理干净。这段时间花得值，因为它决定了未来每一期报表的数据质量。应收应付这个模块，说到底就是先立规矩、再做数据、最后谈效率；规矩立住了，后面所有流程都是顺水推舟。

本文还有配套的精品资源，点击获取