# 📖 财务日常对帐
一天的经营结束后，对于负责公司财务的你来讲，事情可能才刚刚开始。你应该需要制作出一些企业内部的相关报表供上级查阅或存档。这其中免不了从众流提取源数据进行加工或核对相关账目是否吻合，那就跟着我的流程，看看如何顺利的完成这个工作。
# 对账前的一些基础知识
一般而言，财务需要在众流系统中核对的账目分为以下几类:
为了对清楚上方这3种账目，我们需要对众流平台的相关规则有一定了解，这样后续账目核对起来才能事倍功半。如你已对我们的规则有一点的了解，你可直接点击上方链接进入主题。
# 💁 众流经营指标的归档规则
众流的经营指标采用标准的自然日归档，即每天的00:00:00至23:59:59为最少归档单位，数据按天存档，所有经营类的指标数据，都将遵循这个原则。如营业额，客单数等均是如此，该类型的指标不允许查询 < 天的单位。（小时、分钟、秒不受支持）
若有疑问，你可以查阅 👉 为何要按自然日归档？
# 🚅 前台收银订单的入账规则
前台收银的订单可分为3个阶段，未支付、支付部分、支付完成。
订单只有在支付完成后才会被统计到众流后台（下统称入账），入账的时间为订单完成的当天（即最后一笔尾款支付的时间），未支付或支付部分的订单不会入账，这是因为订单未全部支付完成时很多联动的业务无法继续，如商品成本的计算，优惠金额的分摊都依赖于订单完成。
订单虽然未完成，但若使用聚合支付付了一部分的话，会被上游第三方支付机构（下统称上游）记录到当天的交易额，因为客户确实今天支付了这边钱。这里敲黑板了，由于该订单仅支付了部分（此处假定微信支付了87元），众流并不会将该订单统计到经营指标内（你可以理解为众流认为该订单暂时并不存在），到第二天和上游对账时（聚合支付），会出现对账单上上游比众流账面多了客户支付的87元，难道众流账面的钱算错了？
显然在这个例子中，即使上游和众流账面的值并不能吻合，但却都是正确的，之所以不吻合是由入账规则决定的。
我们继续这个例子，当这个订单最终在前台被完成时，订单会在完成的那天入账，当你再来核对订单入账当天的聚合支付账单时，会发现上游刚好比众流少了87元。
是不是很神奇？哈哈，你肯定已经懂了这个意思～日常对账的时候，这个问题需要注意下，尤其是在咱们台球行业（单个订单金额高，单个订单的完成周期长，客户多人、多次进行同一笔订单的支付）。
# 🧑🏫 财务一般需要使用哪些应用
我们整理了一些接下来你可能会高频使用的应用：
- 店铺经营日报
直观查看店铺经营相关指标的综合报表 - 支付方式收款报表
直观查看商户下所有支付方式的收款金额 - 店铺支付方式收款报表
直观查看店铺下所有支付方式的收款金额 - 助教时长报表
球房所有助教上钟的时间信息汇总 - 订单中心
所有订单的集结地，配合应用右上角🔎，很强大 - 聚合支付对账单
负责和上游支付结构对账，省时利器 - 交接班概览
用作和收银员核对班次信息 - 余额概览
会员、卡片的余额汇总及明细都在这里
上述应用你都可以在众流生意端的应用页面找到，或直接搜索到。
让我们稍作休息。☕
OK，那除了上面这些外，咱们还得先熟悉几个基本指标，这很关键，建议做个笔记：
# 1️⃣ 营业额（GMV）
计算公式：
各支付方式总和 -（ 会员充值 + 卡片发行及充值 ）
营业额指经营周期中所有的真实商品交易（广义商品）总额，在球房经营角度来看的话，营业额由三大块构成（即广义商品由三大块构成）:
- 商品金额
- 台桌和包厢费
- 助教上钟费
所有产生真实价值的商品，不包含会员充值和卡片发行及充值（这2者为预付款，并不和具体商品价值对应，不纳入营业额的计算范畴）。
聪明的你应该发现了，营业额是为了准确反映店内实际商品的交易状况而准备的，它应该是基于真实的、纯粹的商品交易关系。即构成营业额的项目，应当完成了自身交易关系的闭环，不用过多考虑甚至不用考虑和客户未来的某笔交易产生依赖关系。
营业额是所有商业交易中最能直观、准确的反应店铺的真实经营状况的指标。
# 2️⃣ 总收入
计算公式：
各支付方式总和 -（ 会员支付金额 + 卡片支付金额 ）
指经营周期中的所有销售进项，不区分是会员充值或卡片发行及充值还是商品交易，此处之所以减除会员支付金额，是因为各支付方式总和已经包含充值的金额，若不剔除支付的金额的话，会员充值的每一笔钱，接下来都会计算2次。
该指标能直观反应店铺特定周期内，合计收入的金额。但其包含类似会员充值款在内，交易关系并未完成闭环，存在一定的误导性。若严重依赖该指标，可能会间接导致运营层面忽略经营的本质，不利于店铺的长期健康发展。
# 3️⃣ 聚合支付实际到账
计算公式：
非原生支付
支付方式中微信 + 支付方式中支付宝 - 上游支付手续费
原生支付
支付方式中微信 - 上游支付手续费 及 支付方式中支付宝 - 上游支付手续费
该指标并非常规指标，它主要用作反应支付宝支付+微信支付的总额，会等于老板或收款人的银行卡实际到账金额。
# 和店内收银员对帐
收银流程：
收银员每天上班前需要在众流收银前台（下统称前台）登陆自己的账户进入当班收银，下班时需在前台进行班次交接，每当进行班次交接时，系统会将该班次闭环及统计出该收银员在当班期间产生的相关指标，并打印交接班小票。
# ❓ 为什么要和收银员对帐
前台收银负责销售商品，同时记录并完成交易，交易完成后会同步至后台（即云端，也可以理解为众流生意看到的相关数据报表或图表，下统称后台），但由于同步依赖于网络或受其他不确定因素影响，在同步的过程中可能会失败，这就决定了客观上存在前台和后台数据不一致的情况，当发生这种不一致时，我们就需要去核实原因，将数据修正为一致（如因为网络断开导致数据无法传上来则需要将网络恢复正常，或由于前台存在异常订单未进行处理导致两边不一致则需要处理异常的订单）
也就是说，和收银员那边核实各项指标是财务开展工作的第一步，只有后台数据和前台一致，后台数据才有意义，因为前台是数据产生的源头。
# 🌹 怎么和收银员对帐
看到这里你可能会觉得有个问题，你知道众流是按自然日进行数据指标汇总的，但收银员上班时间可能会横跨自然日，比如从1号18点上班，至2号2点下班。这个班次会横跨1号和2号，这种情况我该如何核对收银员的某个班次是否有误？
针对于上图中莉莉的这个班次，我们制作了一个用作核实收银员班次的小应用 #交接班概览#：
入口👉：众流生意 ➡️ 应用 ➡️ 数据分析 ➡️ 交接班概览，或直接在应用页面搜索
在交接班概览中，我们会帮你自动核对好后台和前台的数据是否一致，你无需关注班次跨天的问题，你需要做的仅仅是在交接班概览中核实班次信息是否一致，只要前台和云端的班次数据一致，我们就可以认为众流后台提供的数据报表是可以信赖的，是和前台收银数据相吻合的。
# 和聚合支付实际到账对帐
众流对接了上游第三方支付公司（均为国内大型支付结构或银行，持有支付牌照），前台能非常方便的收取支付宝、微信、银联等第三方款项，大部分情况下你都无需关心客户是用微信还是支付宝，众流前后台均做了相关聚合处理。
一般来说，若你那边是走的非原生通道（不确定是不是非原生可咨询贵公司和众流对接的伙伴），当天的聚合支付款项将会在第二天凌晨打款到收款人的银行卡内（即T+1），你肯定需要知道实际到卡的钱有没有问题，和前台实际交易的金额是否能完全吻合，我们制作了一个专门用作财务核实聚合支付实际到账的应用 #聚合支付对账单#：
入口👉：众流生意 ➡️ 应用 ➡️ 订单管理 ➡️ 聚合支付对账单，或直接在应用页面搜索
我们需要着重关注下方图片的指标:
- 交易数量：订单数量，由上游支付结构提供，此处5970单是我们示例的数据。
- 手续费：支付手续费，由上游支付结构提供，即上游打款时扣减的真实手续费。
- 实际到账：实际到贵公司收款人卡内的金额（已减除手续费），由上游支付结构提供。
- 交易金额：未减除手续费之前的金额交易总金额，由上游支付结构提供。
- 系统账面：众流后台支付方式中微信、支付宝、银联等聚合支付的总和。
- 对账结果：经众流计算后和上游指标比对的结果。
- 下载对账单：在上图的右上角，点击将下载上游提供的详细对账单。
你仅仅只要关注对账结果这个指标块的结果是否是无误，能和上游支付结构完全对上的话则会显示无误，对不上我们就要找下原因，看看哪个环节出了问题。
# 和其他外部的第三方对帐
在前台的支付方式中，有些是系统内置的，如聚合支付，现金，会员支付，卡片支付这些。有些可能是贵公司管理员自己加的，如加了一个美团团购用作记录团购过来的套餐金额。
这些支付方式中，只有内置的聚合支付、会员支付、卡片支付是系统自动扣减。 系统会自行校验款项是否扣除成功以及有没有异常。
其他的支付方式则是完全由收银员手动触发，手动录入金额来完成的 即使是内置的现金也是如此，即系统仅仅是帮收银员记录了这笔金额使用了某个支付方式，但具体款项是否收到，或者怎么个到账规则系统并不清楚。
财务指标关系图解 👇
如你在后续对账时，发现了陌生的支付方式，可向贵公司负责这块的伙伴联系，咨询下他具体的情况。