首页
知虾数据
产品
移动端
插件
知虾数据API
注册 | 登录
登录领取更多权益:
  • 新人免费领会员
  • 最新跨境运营干货
  • 看多维度榜单信息
  • 一对一专属导师
立即登录
首页 知虾课堂 运营干货 虾皮货款从哪一步开始算能收

虾皮货款从哪一步开始算能收

运营技巧 知虾干货用法 多店铺运营 数据方舟
2026-11-12 17:28
订单成交的那一刻,后台会跳出一个数字,不少人把它当成钱来看。这个数字还不是钱,它只是一个待处理的结果。从结果变成能支配的余额,中间要走一段有节点的路。每一个节点都要停一停,停多久各有各的说法。这一篇就只走这一段路。
把这一层的意思说白一点。同一笔订单,问它能收多少,是另一篇的事。问它最后记在哪本账上,又是另一篇的事。这一篇只问一句,这笔钱从哪一步开始算能收,走完要几天。四个问题的答案互不相同,谁也不能替谁回答。
所以这一篇只写流转这一段,其余三段各归各位。名义那一段说的是钱被哪些项目切走,这里不重复。折算那一段说的是按什么价记录,这里也不碰。归账那一段说的是最后放进哪一栏,同样留给它自己。三条边界划清楚,这一篇的判断才不会串味。

货款从哪一步开始算能收,先找到起点

很多人把成交那一刻当成收钱的起点,其实并不对。真正能开始计的时点,是订单走完结这一步。这个节点之前的钱,都还挂在交易里面没有动。卖家后台显示的销售额,跟这一刻没有直接对应。要找起点,就先去状态栏找翻成完结的那一栏。

完结这个动作有两种来源,走哪一种差别不小。一种是买家自己点了确认收货,另一种是系统等期限满了自动确认。买家主动点的那一笔,通常当天就能翻状态。系统到期自动确认的,要等平台给的宽限天数走满。两种来源落到时间轴上,起点能差出好几天。

起点找到之后,再往前看都是虚的。下单、付款、发货这些动作,只是把订单往下一步推。它们并不代表卖家已经拥有了这笔钱。把它们跟起点混在一起算,账就会提前一大截。所以起点只有一个位置,就是订单走完结的那一刻。

有些订单的起点还要看售后走没走完。买家提了退货或者退款之后,完结状态会往回退。退回之后原来那个起点作废,要等售后结完再重算一次。这类订单在时间轴上会多出一段。数量不算多,但拖的时间往往最长。

起点这件事看着简单,实际最容易各家算各家。同一个团队里,有人在发货日画线,有人在成交日画线。画线的位置不一样,两张表的应收日期就错开。等到两边对不上再来找原因,常常已经过去一个月。所以第一件要统一的事就是这条线。

找到起点以后,接下来的问题是走几道。货款并不是完结之后就自动跳到账上。中间还要经过几道核验和等待,每一道都有它自己的时长。把它们加起来才是完整的一条路。下面这一段要做的就是把这几道拆开看。

存量的钱和新的钱要分开处理。已经走过几道的订单,和刚刚完结的订单,进度完全不同。把它们放进同一张表按天数平均,得出的数没有意义。按完结日分批,每一批看自己走到第几道。这样才对得上实际的进度。

起点的判定还要看订单有没有拆过包裹。一笔订单分成多个包裹发出的时候,完结的判定会跟着包裹走。有的站点按整单完结,有的按单个包裹算。这两种判定放在同一条时间线上,起点位置不一样。拆过包裹的订单,起点通常更靠后一些。

把起点画在发货日的人,多半会得到一份偏早的应收表。这份表看起来进账很快,实际到账要晚得多。偏差一旦形成,后面每一道的时间都会被压缩着看。压到最后一算,缺口大得没法解释。所以第一块砖必须钉在完结那一刻。

有些类目的完结判定会额外等一段。像预售、定制这类订单,发货本身就靠后。它们的完结时点天然比普通订单晚。把这类订单混进平均值里,会把整体节奏拉长。分开看类目,起点才看得清楚。

起点定下来以后,可以做一件很有用的事。把最近一个月的订单按完结日排一遍,看每天完结多少笔。这一列数字就是后面所有推演的入口。有了它,每道停留的时长才能加到具体某一天上。没有它,就只能停留在大概几天这种说法上。

起点还有一个容易忽略的特征,它是可以往回退的。退的触发条件是售后状态发生变化。只要售后还没结完,这笔钱的起点就一直悬着。悬着的订单不该被算进已完结那一批。把它们单列出来,进度表才不会被拉偏。

关于起点,团队里值得留一句写下来的约定。约定内容就是哪一天算第零天,第零天之后每道怎么加。一句话写清楚,后面所有估算都有共同的底。写不清楚,每个人心里那本时间表都不一样。这一句约定值多少,做过一次跨月对账的人心里有数。

起点找到以后,还有一个动作顺手就能做。把每一笔的起点和当前状态标在同一行里,扫一遍就知道走到第几道。行数不多的时候这是手工活,行数一多就需要工具来帮忙。这一步不做,后面只能凭感觉判断进度。而感觉在跨月的时候最容易出错。

收尾时把起点这件事再说一遍。起点只有一个位置,就是订单走完结的那一刻。售后没结完的订单往后挪,预售和拆包订单各有各的位置。把这三种情形分开记,这条路的第一块砖就算铺稳了。

流转的五道骨架,每一道都有一段自己的停留时间

流转的五道骨架,每一道都有一段自己的停留时间

从确认收货到可提,中间要过几道

从完结到能提出来,中间大致分几道,可以按状态栏上的抬头来数。第一道是完结本身,第二道是售后期挂账,第三道是平台的核验,第四道是余额转成可用。最后一道是提现出账,这五道是多数站点都有的骨架。

第一道最快,通常当天就翻。第二道的时长取决于站点的售后期,短的三天长的七天。第三道看平台多久做一次核验,常见是一到三个工作日。第四道跟第三道往往连在一起走。第五道就是提现提交之后的处理时间。

这五道里面有两条是硬等,有两条可以提前准备。售后期和提现处理是硬等,卖家做什么都跳不过去。核验和余额转换可以提前把资料备齐,少走回头路。分清哪条只能等、哪条能动,心里才不慌。这是数段数最实际的用处。

有些站点会把两道合起来走。完结和核验一起做,售后期单独挂。合起来之后状态栏里的抬头变少,实际花掉的时间并没有少。数段数要看时间有没有省掉,不是看抬头有几个。这一点在跨站点对比的时候最容易被绕进去。

段与段之间有先后,不能并行往前赶。余额没转成可用,提现这一步就发不出去。提前点了提现,系统只会把请求挂起来。挂起来之后还是要等前面那道走完。所以顺序这件事,比时长更值得先记住。

段数这件事还要看订单走的是哪种结算方式。有的订单按批次结算,单笔完结之后要等批。批次凑齐了才走最后两道。这类订单的段数看着一样,实际中间多了一层等待。按批次结算的订单,进度要按批来看。

事后复盘的时候,把每道停留的实际天数记下来很有用。记满一个月,就能看出哪一道是稳定的,哪一道是弹性的。稳定的那几道可以直接当常数来用。弹性的那几道要单独标出来盯。这份记录比凭经验判断要可靠得多。

提现这一步本身还可以再细分。提交请求是一下子的事,进入批次要等排期。有的站点一天排一次,有的按周排。排完之后还要等银行处理这一步。这一段是所有段里最容易被低估的,低估它就等于把到账日算早。

银行处理这一段跟收款的账户类型有关。账户在本地还是跨境,处理路径的长短不一样。跨境的还要过一层中转,时间上更难给出准数。给不出准数的时候,要按最长的那一档来留。宁可留宽一点,也不要取平均数。

到一个新站点开店的头几个月,把每道实际天数记下来尤其重要。新站点的规则和节奏跟老站点不一样,照搬老站点的经验容易出错。头一两个月按保守值估,后面再用真实观测值来修正。知虾站点分析里给出了各站点的节奏差异,可以拿来做估算的一处旁证。

段数讲清楚之后,有个问题会自然浮出来。这五道里面哪一道是钱真正动起来的地方。答案是余额转成可用的那一道。在那之前钱只是一个状态,在那之后钱才是可以支配的余额。记住这条分界线,比记住五道的名字更有用。

还有一类订单值得单独拿出来说。买家确认收货之后又发起退款的,一道都没有往下走就会停住。停住的位置通常在第二道。这类订单的段数看着跟别人一样,实际永远走不到第四道。把它们单独归一类,不要混进正常队列里。

数段数还有一个好用的地方,就是拿来对照平台给的时间表。平台给的是每条路的最长时限,不等于每一笔都会走满。两者一比,就能看出自己的单子比标准慢在哪一道上。慢的那一道就是下一步该去查的方向。

段数不需要数得太细,数成十几道反而看不清重点。抓住五道骨架,把每道的实际时长填进去就够了。多出来的细节放在附录里,不要挤在主线上。主线越短,跟别人沟通的时候越好用。这也是为什么四型要分开写。

这一节把五道数完了,下一步就要看时间怎么落到具体日子上。五道只是骨架,没有天数就还是空的。把每道的典型时长接到起点那一天,才算把这条路铺到地上。接下来要拆的就是每一道的时长从哪里来。

六项停留里,前五项有相对稳定的经验值,最后一项没有准数

六项停留里,前五项有相对稳定的经验值,最后一项没有准数

哪一道最容易停住,停住的原因是什么

五道里面最容易停住的是售后挂账那一道。原因很直白,它等的不是平台处理,而是买家那边不再有动作。买家不点确认也不提售后,这一道才会自然走完。任何一个新动作,都会让这一道重新计时。所以它停住的次数最多。

售后挂账的时长有下限没有上限。站点规则给的售后期是下限,买家在这个窗口里提一次售后,窗口就重开。重开之后前面等的那几天不算数。这类情形在退货率高的类目里特别常见。时间一拖就是一轮新的等待。

第二类容易停的是平台核验。核验停住的时候,后台通常不给显式的报错,状态就停在那里不动。不动的原因要自己去找,平台不会主动告诉你卡在哪一项。这种沉默最消耗排查的时间。很多人会在这里白等好几天。

核验停住的常见原因是资料口径不一致。收款账户的名字跟店铺主体对不上,或者证件已经过期。也有的是银行信息填错了一位数。这些小问题在提交当时看不出,走到核验这一步才会暴露。暴露之前那几天是纯粹的损耗。

第三类容易停的是提现出账。这一道停住往往跟批次有关,跟金额大小没有关系。同一批里别人已经到账了,自己这一笔还挂着。这时候要去查的是账户状态而不是订单状态。查错方向会再多耽搁一天。

停住的表现形式有两种,一种是状态不动,一种是状态在动但天数在涨。后一种更隐蔽,看着在走,实际在原地。要区分这两种,只能靠记录每一天的实际状态。光看当天的截图,分不出走和停。所以记录本身比判断更重要。

判断停住要看的是日期的变化,而不是状态栏上的文字。把订单的完结日和当前状态合起来看,停在哪儿就能推出来。单看状态文字,同一个词在两笔订单上可能代表不同阶段。混着读就会得出相反的结论。这一点在批量看的时候尤其明显。

停得最久的往往不是金额最大的订单。金额小、买家又不着急的单子,反而更容易被放着不管。这类小单分散在每个月里,单看一笔不显眼。加起来占用的时间不少。按月把这类单子汇总一次,才会看见它们的分量。

售后挂账这一道停住,连带影响的不止这一笔。同一批的进度统计会跟着被拉长。平均值被拖下去之后,整个月的节奏判断都会偏。所以停住的单子要从批量统计里摘出来。摘出来之后,剩下的数才代表正常水平。

停住的单子要单独列一张清单,每天更新一次,缺一天可比性就断了。清单上只放三列,完结日、当前状态、停在哪儿。列越少越容易坚持更新。列一多,做两天就没人接着填了。这张清单的价值全在连续性上。

核验停住时的排查顺序有讲究。先查主体信息,再查收款信息,最后查证件的有效期。按这个顺序查,多数问题在第二步就能定位。顺序反过来的话,会把时间花在不太可能出错的地方。顺序对了,排查就快一大半。

提现停住的情况里,有一部分是自己造成的。账户信息刚改过,系统需要重新确认一遍。这类停住有明确的原因,只是不会提前告知。改动账户信息之后紧跟着做一次提现,就容易撞上。知道这一层,就能自己错开时间。

停住这件事的成本不只是时间。它占着的是一段时间里的资金预期,预期落空会连带影响后面的采购安排。每一笔停住的钱背后,都对应着一条可能被推迟的补货计划。所以盯停住的钱,实际是在盯后面的节奏。

有些停住是可以提前避开的。售后窗口临近届满的订单,提前查一下买家那边有没有新的动作。有动作就早点处理,没动作就安心等它自然走完。这个动作花不了多少时间,能省下不少天。关键在于固定成一个动作,而不是想起来才做。

停住这件事查到最后,原因多半不在平台那一侧,而在订单自身和账户信息的细节里。所以排查的方向应该从自己这边开始,而不是先去问平台为什么这么慢。方向对了,天数才压得下来。方向错了,问一圈也拿不到答案。

流转的一道起点信号典型停留卡住时的表现
订单完结
买家确认或系统到期
当天到一天
售后未结,状态往回退

最容易记岔的,是把可提当成已提了

可提和已提这两个词只差一个字,含义差着一步。可提说的是余额已经解除限制,随时可以申请提出来。已提说的是申请已经提交并且走完了后面的处理。这两个时点之间还有一段提现出账的路要跑。把两者当成一件事,账就错在起点上。

把可提当成已提,最直接的后果是应收表和银行流水对不上。表上记着这笔钱,账上还没有到。对不上的时候容易先怀疑平台算错,查半天才发现是自己这两个词混着用了。这种错查起来最费时间,因为方向一开始就偏了。

这个偏差不会平均分布在整月里,平时看不出痕迹。月末和季末提现集中的时候,偏差会堆得特别明显。越是要出报表的时点,这两个词的差别越容易咬人。平时看不出问题,一到结算日就会集中冒出来。

判定的方法很朴素,只要看提现记录有没有回执。没有回执的就是可提,有回执的才算已提。回执上通常带一个处理单号,这个单号是拿来跟银行流水对上的凭证。两者都有单号可查,所以这件事本身并不难判。

有些站点在可提和已提之间还有一层,叫提交中。这一层的钱既不符合可提的状态,也还没到已提。把它忽略掉,两边的数就永远合不拢。这一层的金额通常不大,但次数很频繁。次数一多,累出来的差额就不小了。

三个状态放在一张表里最清楚。可提一列、提交中一列、已提一列,加起来才是这段时间的全部货款。三列摆开之后,哪一列在涨、哪一列在跌,看两行就能看出资金松紧的变化。三列缺一列,这张表就失去了判断力。

把可提当成已提的另一个后果是重复记账。同一笔钱在两个时间点各记了一次,总数就翻倍。翻倍之后不光毛利算错,连采购量的判断都会跟着偏。这种错会一路传到下一季的备货上。错在起点,代价落在几个月以后。

团队里不同岗位看到的是不同状态。运营看可提,财务看已提,两边口径不一样就容易争执。争执的根源不在人,在于没有先说清楚以哪个状态为准。把这句话先讲明白,后面的讨论才不会跑题。

解决的办法是统一用同一个字段当锚点。要么都用可提时点,要么都用已提时点,事先说定一个。说定之后所有报表都按这个锚点出,谁也不用再猜别人说的是哪个状态。一个锚点能省下很多来回确认的时间。

提现出账这一段的时间在月内是不均匀的。月初提交和月末提交,实际到账的间隔可能不一样。同样是三天的处理时间,跨过一个周末就会变成五天。排资金计划的时候要把这个因素算进去。算进去之后,付款日的安排才不会落空。

有些款项会长期停在可提一直不动。卖家自己不提,平台也不会来催,这笔钱就一直在余额里躺着。躺着的时间长了,容易在核对的时候被当成新到的钱重复计算。这笔钱其实早就走完了前面几道,只差最后一步。

长期停在可提的钱也有成本,只是这个成本不体现在费用上,而体现在资金的使用效率上。钱停在余额里不生息,跟放在银行活期相比,差别就是这段时间的机会成本。这个成本平时看不见,等到算全年的时候才会显出来。

把这两个词分清之后,做预算时的宽松度就可以收得更紧一些。可提的部分可以算进来,提交中的要打折扣。折扣打多少,按各站点历史实际到账的天数来定,不要拍脑袋填一个数。拍出来的数看着顺眼,用起来会一直偏。

给这两个状态各设一个固定的查看节奏也很重要。一天看两次和一周看一次,得到的状态分布完全不同。看得太频繁的人容易焦虑,看太少的人容易漏掉异常。一天一次是比较合适的节奏。节奏定下来,判断才有可比性。

这条分界线其实就一句话,可提是能申请,已提是已到账。中间那一段路没走完之前,两个词不能换着用。换着用的代价,总是在做月报的那一天集中爆发出来。把它写在报表的表头上,这个错就很难再犯。

一条路走完,要填进去几天时间

把五道的典型时长加一遍,顺利的单子大致在两周左右走完。这个数不是标准答案,它是一个可以拿来用的估算底。真实的天数会因为站点和类目的不同而上下浮动。用它之前先想一想自家的单子属于哪一类。

加上售后挂账那一道的不确定性,区间要放宽到两周到三周。碰到买家提了售后,还要再往后延一次。延多久取决于买家什么时候给出回应,这一项卖家控制不了。控制不了的部分,只能靠留余量来对付。

估算的时候要按最长的那一档算,不能按平均算。平均数是事后统计出来的,事前只能按最坏的情况留。按最坏情况留出来的数,用起来才不会被突发的延后打乱。这一条听起来保守,实际最省事。

提现出账的时长跟提交的日期有关系。周期开始的时候提交和周期末尾提交,到账日能差出好几天。如果刚好撞上长假,间隔会被拉得更长。排期的时候要把假期单独标出来。标出来和不标出来,差的就是那几天。

跨境账户的处理时长天然比本地账户长。中间过一层中转,时间上就要多留一道。这一道不是平台能压缩的,属于通道本身的属性。能做的只是提前预留。预留之后,资金计划才不会卡在这上面。

把这几项加起来的算法,可以写成一张很简单的纸条。起点日加上各道的上界天数,得到最晚到账日。纸条上的规则越少越管用,规则一多,执行的人就会开始自己加解释。加解释之后,每个人算出来的日期又不一样了。

最晚到账日的用处比预期到账日大。预期到账日用来排计划,最晚到账日用来排付款。付款这种不能迟到的事,必须挂在最晚到账日后面,而不是挂在预期日后面。两个日子分清楚,排期才有安全垫。

估算还要按类目分开做。预售和定制的单子起点靠后,用普通单子的天数去套会算不准。分开做的时候要注意样本量,样本太少的类目先把天数设得保守一些。样本积累够了,再慢慢把天数收到正常水平。

不同站点的天数不能混着平均。站点之间的规则差异比想象中大,混起来算出来的数谁都用不了。按站点各出一张小表,用的时候取对应的那一张,这样才不至于张冠李戴。站点的表放在一起,才能看出哪一站拖得更久。

有了天数之后,可以做一件更有用的事。按完结日把订单分组,每组加上天数,得到一张到账日历。这张日历的横轴是日期,纵轴是当天预计到账的金额。它的形状跟真实流水会很接近。日历做出来,讨论资金就有了共同的参照。

到账日历一出来,资金这件事就从感觉变成了排期。哪一周会紧、哪一周会松,看日历就知道。知道得越早,调整的余地越大,临时找钱的可能性就越低。这一步做完,后面的采购安排才好定。

日历要每月更新一次。规则调整、站点变化、账户变动,都会让天数往上或者往下挪一点。不更新的话,日历会随着时间慢慢失真,用上两个月就没人愿意看了。更新这件事本身不费时间,费的是有没有人去坚持。

更新的时候只改变化的那几道,不要整张重做。整张重做容易把之前跑出来的经验值丢掉。改动的地方做个标记,下个月再看就知道哪几道一直在变。一直在变的那几道,就是规则最活跃的地方。

天数这件事有个容易忽略的点,它是可以靠操作压缩的。窗口期内主动跟进买家,能减少挂账的意外延长。提前把资料补全,也能让核验这一道少走一次回头路。知虾公开页面的多站点数据一栏把各类结算规则按站点并排铺开,数值逐日回填到前一交易日。

把天数接进去之后,一条路就从骨架变成了可以排期的东西。接下来要看的是哪些情形会让这条路走不通。走不通和走得慢是两种不同的麻烦,处理的方法也不在同一层面上。分开处理,才不会把力气用错地方。

同样的五道骨架,落到不同站点上,卡的位置并不一样

同样的五道骨架,落到不同站点上,卡的位置并不一样

哪几种异常会让这条路直接断掉

第一种会断链的情形是订单被平台标记待查。标记之后,前面走过的那几道全部冻结,要等人工放行。冻结期间状态不会往下翻,天数却照常累加。这一类最容易被误判成单纯的走慢了。误判之后,等着等着就等过了账期。

第二种是售后升级成纠纷。纠纷一旦立案,货款会被扣住直到结论出来,这个过程没有确定的时长。处置的节点掌握在平台那边,卖家能做的只是把材料备齐。材料备得全,结论通常出来得更快一些。

第三种是收款账户出现异常。账户被冻结、信息过期、名字不符,都会让提现这一步发不出去。这一类的前面几道都是通的,卡在最后一步,所以也最容易被忽略。前面走得顺,反而让人放松了后面的检查。

第四种是订单本身被判定违规。这一类最彻底,不是延迟而是这笔钱不再进入正常的流转。碰到这一类,要做的是复盘订单来源和商品描述,避免同类情形再出现。这一类数量少,但每一笔的金额往往不小。

断链和延迟是两件不同的事,处理的方式也不一样。延迟是等,断链是要先把问题解决掉再看能不能继续走。把断链当成延迟来处理,只会白白消耗天数。两种麻烦混在一起看,处置的优先级就排不出来。

判断断链的早期信号,是状态连续多天不动并且售后那边有新动作。两者同时出现,基本可以下判断。这时候还按正常的天数去估到账日,估出来的数一定是错的。错一次不致命,连着错几次就会打乱整月的排期。

断链的订单要单独建一个台账。台账上记清断在哪一道、原因是什么、谁在跟进、下次查看是什么时候。台账的作用不是记账,是不让这几笔钱从视线里消失。这四列写全了,交接的时候也不会漏掉人。

断链最常见的起因是资料问题,而不是交易本身的问题。资料问题排查起来快,修好之后能把后面的道补回来。所以碰到断链,先花十分钟把资料过一遍,往往比先去问平台更省时间。把这一遍过资料的动作固定下来,处置速度会明显快起来。

有一点要提前说清楚,断链期间这笔钱不该被算进可用资金。算进去之后,付款计划就会落空。落空一次之后,后续所有排期都要重做,代价远大于当初少算这一笔。宁可少算,也不要多算,这是排资金时的一条纪律。

平台标记待查这类情形,主动提交说明材料通常能缩短处理时间。材料要按平台列出的那几项逐一对应,缺哪一项补哪一项。一次性交齐比来回补交要快得多。补交一次就要重新排一次队,排队的时间也要算进总天数里。

售后升级的纠纷,处理的关键在时间窗。窗口内回应和窗口外回应,结果差别很大。窗口的长度各站点不一样,要在订单完结的时候就把这个日期标出来。标出来之后,跟进的人就不用每天去翻规则。

账户异常这一类的排查顺序是先看主体再看账户。主体信息没问题,再去查账户状态和证件的有效期。按顺序查的好处是不会漏,代价是慢一点,但对断链这种情形来说,查全比查快更重要。查全一次,比查快三次更省时间。

断链的订单还有一个特征,它会连带影响同一批里的其他订单。按批次结算的情形下,一笔卡住会拖慢整批。所以发现问题的时候要顺手核对同批的其他单子。同批的单子一起看,才知道这次断链影响的范围有多大。

有些异常是可以提前预警的。售后率高、买家回应慢、订单金额异常大的单子,都是高风险的信号。把这些信号做成一个简单的打分,超过阈值就单独盯,能在断链之前先把风险降下来。打分不用复杂,三四个指标就够用了。

断链的处置有一条总原则,先把原因查清楚再谈进度,光盯着天数没有意义。原因找到了,要么能修要么不能修,两种情形都有明确的下一步。原因没找到,就只能一直等下去。所以处置的第一步永远是定位,而不是催。

顺利的单子一周内走完,受阻的单子在同一条轴上还留着一截

顺利的单子一周内走完,受阻的单子在同一条轴上还留着一截

走完这几道,归账在后面那一节

这一篇讲的是钱怎么走,走到哪一步才算能收。五道骨架、每道的停留、最容易停住的地方,都摆在这一层里。落到哪一步算收,这一层把它说明白了。除此之外的东西,这里都刻意没有展开。一条线只讲一段,讲透了才有用。

走完之后钱会落到一个位置上,那个位置该放在哪一栏里,不属于这一篇的范围。放进营收、放进往来、放进别的科目,各有各的道理,也各有各的前提。这些前提要单独摆出来看,混在这里讲只会讲乱。

同样,这一路上被哪些名义切走,也留给另外一段去说。这一篇刻意不重复那些条目,也不去排它们的先后。名目之间怎么叠、按什么顺序扣,是另一件需要单独说清的事。把两件事挤在一段里,读者不知道该先看哪一头。

按什么价来折算这件事也不在这里。它跟流转是两件事,一个管时间,一个管换算,换算偏一点结果就差一截。时间搞对了换算没搞对,最后拿到的数照样是偏的。两边都要对,数才是能用的数。

四段各管一段的好处是每一段都能说透。混在一起说,最后往往是每段都只说了个大概。四条线各走各的,合起来才是完整的落账过程,分开写反而更容易合上。分开不是割裂,是让每一块的边界都清楚。

这一篇的输出可以理解成一张时间表。表上只有两样东西,一个是起点,一个是各道的天数。这两样东西虽然少,但足够回答钱什么时候能到手这个问题。问题答清楚了,这张表就完成了它的任务。

时间表拿到手之后,下一步是把它接到账本上。接的那一步在结算那一段里讲。这里只提醒一句,接的时候要用同一个时点,不要在中间换口径,时点换了前后就对不上。换一次口径,前面那张表就白做了。

这里留一个提醒,天数不是固定的。规则改一次、站点变一次,这张表就要跟着改一次。改的时候把老值留着,方便对比是哪一次变化带来的影响,改一次记一次脉络才清楚。留着老值,变化的方向和幅度才看得见。

用这张表做判断的时候,最容易犯的错是把它当成承诺。它是估算,不是平台给出的回执。估算偏保守是优点,偏乐观才是麻烦。所以宁愿多留两天,也不要少留。多留出来的那两天,是排期里的缓冲。

估算的用处在于排期,不在于证明。排期排得对,资金就不会在最紧的那一周掉链子。排期排错了,后面补窟窿的成本会比当初多留两天高出很多。把估算当排期的工具,而不是当结论,方向就对了。

如果把这一篇和另外三篇放在一起看,会发现四段其实是一条线上的四个位置。顺序上,流转排在最前面。前面这一段不清楚,后面就落不了地。顺序在前的部分做扎实,后面的部分才有意义。

起点错了、天数错了,后面的归法和口径都会跟着错。这也是为什么这一篇要花这么多篇幅只讲一段路。看起来啰嗦,实际是在给后面几段打地基,地基不稳上面的结论都是空的。地基不稳,上面的讨论越细越容易偏。

这一篇不做结论性的建议,只把这一段路描述清楚。读者拿着这张表去对自家的单子,哪一道慢、慢了多少,差异自然会浮出来。这一步不需要别人替你说。把事实摆清楚,判断谁都能自己做。

七个小节摆完,起点、段数、卡点、区分、天数、断链、边界各占了一处。每一条都可以单独拿去用,也可以合起来拼成一张完整的流转图。拼完之后,这一段该管的范围也就跟着清楚起来了。

接下来的那一步,是把走完路的钱接到账本上去。路走完了,钱总要有一个落脚的栏位,栏位定在哪里、按什么规矩去定,是另一节要回答的问题。这一节要回答的那一句,写到这里就答完了。

常见问题(FAQ)

货款从哪一步开始算能收,起点到底落在哪一天
起点是订单走完结的那一天,不是成交日也不是发货日。买家主动确认和系统到期确认都算,只是后者天然要晚几天。售后没结完的订单,原起点作废,要等售后再重算一次。
从完结到能提,中间到底要过几道
多数站点是五道,完结、售后挂账、核验、转为可提、提现出账。有些站点会把核验和转换合成一道,抬头少了但时间没少。按批次结算的订单在中间还会多一层等批。
哪一道最容易停住,停住时怎么判断
售后挂账最容易停,它等的不是平台而是买家的动作。核验和提现也会停,前者多半是资料问题,后者多半是账户问题。判断靠日期和状态一起看,状态文字在动而天数一直涨,那就是停在原地。
可提和已提只差一个字,为什么不能混着用
可提是能申请,已提是已到账,中间还有一段提现出账的路。混着用会让应收表和银行流水对不上,月末季末提现集中的时候偏差最明显。判定的方法是看有没有回执,没有回执的一律按可提处理。
一条路走完要填几天,估的时候按哪个值
顺利的单子按两周左右估,碰到售后要放宽到三周。估算要按最长的那一档算,不要按平均算,平均数给的是事后的统计,排付款必须按最晚到账日。跨境账户和周期末尾提交的单子要再多留一点。
哪几种异常会让路直接走不通
订单被标记待查、售后升级成纠纷、收款账户异常、订单被判定违规,这四种会让路断掉。断链跟延迟不是一回事,前者要先解决问题再看能不能继续走。断链期间这笔钱不该算进可用资金。
这一篇讲完,名目、口径和归账为什么都不提
这三样是另外三段的事。名目讲钱被哪些名义切走,口径讲按什么价折算,结算讲最后放进哪一栏。四段混在一起写,每一段都容易说不透。各写各的,读的时候才知道该看哪一段。
▎结语
这一篇只走流转这一段。起点落在订单完结那一天,售后没结完的订单起点往后挪,预售和拆包订单各有各的位置。中间大致五道,完结、售后挂账、平台核验、转为可提、提现出账,有的站点会把其中两道合着走,时间并不因此省下来。最容易停住的是售后挂账,因为它等的是买家的动作;核验和提现也会停,前者多是资料问题,后者多是账户问题。顺利的单子两周走完,碰到售后要放宽到三周,估算按最长一档留。订单被标记、售后升级、账户异常、判定违规这四种会让路断掉,断链的钱不能算进可用资金。钱被哪些名义切走、按什么价折算、最后归到哪一栏,属于另外三段。
用数据做 Shopee,就用知虾
9 大站点数据 · T+1 实时更新 · 100+ 项功能,覆盖选品、关键词、竞品监控全流程
点击下方按钮,免费体验知虾数据工具
立即免费体验 →
上一篇

虾皮货款最后进哪一本账

下一篇

虾皮货款按哪一版汇率折,差的不是几分

相关文章
shopee广告基础词汇
东南亚全站点热销选品&运营指南攻略来袭!
shopee台湾入仓费用是什么?怎么收费?
资深⼤卖不愿意说的运营技巧,学会⼀招就够了
孵化期通关指南
最新文章
虾皮利润核算最后归到哪个周期上
虾皮利润核算从哪一步开始倒推
虾皮利润核算取哪一层数,结论完全不一样
虾皮利润核算前,先把扣的名目列全
虾皮成本归集最后落成哪一份表
虾皮成本归集从哪一步开始做
虾皮成本归集按什么口径分摊
虾皮成本归集先把名目分清楚再谈归
虾皮对账的结果最后归到哪本账
虾皮对账走过哪几道关口
虾皮对账两边口径不统一,差就永远对不上
虾皮对账要对的是哪几本名目
虾皮结汇之后按哪个币种入账
虾皮结汇这笔钱中间要过几道换手
虾皮结汇取哪一天的汇率,差在哪一档
虾皮结汇的损耗挂在哪些名目上
虾皮货款最后进哪一本账
虾皮货款从哪一步开始算能收
虾皮货款按哪一版汇率折,差的不是几分
虾皮货款到手前被哪些名目切过
专注东南亚电商市场服务,帮助合作伙伴掌控准确的前沿数据,创造广阔的商业价值!
产品服务
知虾数据
数据方舟
虾秘-Shopee虾皮达人邀约工具
俄罗斯卖家导航
tiktok达人邀约软件
流量森林
译秒通(免费)
快速导航
关于萌啦
最新资讯
青虎云电脑
LinkPix图片优化
AI爆款与投放
联系我们
020-22300518 (工作时间:10:00-12:00, 14:00-19:00)
https://www.menglar.com
zhixia mini program code
知虾小程序
zhixia data APP code
知虾数据APP(IOS版)
Copyright © 2020 广州萌啦信息科技有限公司 粤ICP备2020085523号