真正值得先查的,不是银行少了多少钱,而是这笔费用到底对应哪一个订单、哪一次交易、哪一个计费规则。
真正值得先查的,不是银行少了多少钱,而是这笔费用到底对应哪一个订单、哪一次交易、哪一个计费规则。
Allegro订单销售佣金对账与退佣核对
很多中国卖家第一次认真看Allegro账单,会卡在一个很小的数字上:财务表里算出来的销售佣金,和后台的 Sales commission 差了几毛钱;另一边,订单已经取消或退款,原来的佣金却还留在账上。于是第一反应往往是截图、问客服、等平台解释。
其实,这类问题有一个更省事的顺序:先把一笔费用自己算到能够解释,再决定它是正常扣费、尚未形成调整,还是值得提交申请或投诉。
本文只锁定一个假设账户:一家中国卖家的 Allegro Business Account,在 allegro.pl 的 PLN Billing Account 中结算;只追一项费用——Sales commission。广告、Feature、订阅、配送等其他费用不混进来。下面的订单号和数字均为匿名假设,只用于演示对账方法。
如果一个月里已经有十几笔订单,直接拿银行流水倒推佣金,基本是在给自己制造第二层混乱。
Allegro的自动扣费机制可能把销售佣金和其他应付金额从销售所得中统一收取,而当前余额本身还会随着费用、退款、付款和自动扣款持续变化。它并不适合回答“这0.30 PLN究竟是哪一笔订单产生的”。
真正有用的起点是 Settlements with Allegro 里的 Operations History。找到具体的 Sales commission 费用行,再回到对应订单,把订单号、商品金额、数量、买家选择的配送方式和费用、付款状态,以及后续取消或退款记录接起来。
假设现在有一笔匿名订单:
PL-ORD-20261008-001
商品成交价为100 PLN,买家承担5 PLN配送费,订单正常付款。为了演示计算,假设该订单交易时适用的销售佣金率为6%净额。
那么卖家表格如果只算商品价格,会得到:
100 PLN × 6% = 6.00 PLN
但Allegro的销售佣金并不只看商品价格。买家承担的配送成本也可能进入销售佣金计费基础。因此这笔订单的应计佣金是:
(100 + 5)PLN × 6% = 6.30 PLN
如果 Operations History 里的 Sales commission 正好是6.30 PLN,那么:
应计6.30 PLN,实计6.30 PLN,差额0 PLN。
那0.30 PLN不是平台多扣了,而是卖家自己的计算口径少了一项。
这里的6%只是规则演示假设,不能拿来当所有Allegro类目的统一费率。实际订单必须回到交易当时的具体类目、报价状态和适用费率。Allegro当前价目表也是按类目设置费率,部分类目还会根据价格区间采用不同费率。
还有一个很容易被忽略的边界:佣金是在交易成立时收取,费率对应的是Offer所在的适用类目。如果之后Offer发生了类目调整,不能简单拿今天后台看到的类目去替代交易发生时的计费条件。
对于很低客单价的订单,也不能只做“计费基础×百分比”。现行条款对allegro.pl销售佣金还设置了每件0.40 PLN的最低净额,所以算出来低于这个水平时,要继续核对最低佣金规则。
把销售佣金算出来之后,下一步才是看订单状态。
一个订单如果已经退款,并不意味着原销售佣金应该在同一时间、以你预想的方式消失。这里至少要把三种状态拆开:
订单已经取消,但退佣尚未形成。
订单符合退佣条件,但需要卖家提交申请。
订单已经被平台认定不符合退佣条件。
这三个状态,在财务表里可能看起来都像“佣金还在”。
以 PL-ORD-20261008-001 为例,如果买家后来取消了订单,先不要看到退款记录就直接在账上减掉6.30 PLN。要继续看取消发生的方式、付款状态以及退款路径。
对于买家取消未付款订单、买家取消已付款订单且平台完成自动退款,以及部分因付款未完成而被自动取消的Buy Now订单,Allegro目前规定存在自动交易返还销售佣金的情形。但这并不等于“任何取消都自动退佣”。
如果是拍卖订单因付款未完成而自动取消,现行规则要求卖家申请交易返还,而不是看到取消状态后就默认系统一定会把佣金退回来。
退款订单也一样。买家通过Purchase History提交退货,卖家通过Allegro完成退款,在满足其他条件时,销售佣金可能自动形成transaction rebate。现行规则下,部分自动退佣场景还会考虑卖家的销售质量等级;这正是为什么同样一笔“已退款”订单,两个账户的处理结果未必完全一样。
所以对账时最好把订单状态写成一句完整的话,而不是只填一个“退款=是”。
例如:
> PL-ORD-20261008-001:已付款 → 买家取消 → 通过Allegro退款 → 买家是否通过Purchase History操作 → 退款原因是什么 → 是否已有transaction rebate记录。
这样客服看到的也是一条完整事实链,而不是一张孤零零的账单截图。
这是很多卖家最容易误判的地方。
Allegro的 Fee Summary 并不是实时展示所有当天变化。官方说明中,该页面展示的是前一天的数据,并且每天重新计算。因此,今天刚发生的订单、退款或费用变化,不能因为今天页面还没出现对应调整,就直接认定平台没有处理。
这并不意味着可以给自己设一个“等一天一定会退”的固定承诺。真正应该看的,是调整有没有形成,以及调整形成后落在哪个Billing Account、哪个结算周期。
还有一个时间点容易让财务误会。
交易返还销售佣金,是按照实际被授予的月份进入Allegro服务结算,而不是按照卖家提交申请的月份计算。比如一笔订单在10月发生退款,卖家在10月底申请退佣,但平台在11月才授予,那么这笔transaction rebate原则上会进入11月的服务结算,而不是把已经形成的10月账单重新变成另一张数字。
因此,看到原始佣金还在,并不够判断“平台没退”。
先找有没有对应的transaction rebate记录,再看它是不是进入了当前Billing Account的调整。
对于中国卖家,这一步尤其值得单独检查。
Allegro从2026年3月1日起,对符合条件的非波兰卖家调整了费用展示方式:如果卖家注册地不在波兰,并且已经声明固定营业场所不在波兰,费用和销售佣金直接按净额计收和展示,不再像此前那样先按包含23% VAT的总额显示,再在月底调整VAT。
所以,如果你的这个PLN账户符合上述条件,就不能继续拿旧账表里的“含23% VAT佣金”逻辑去核对2026年3月之后的新订单。
还是拿前面的假设订单:
商品100 PLN,配送5 PLN,假设销售佣金率6%,应计就是6.30 PLN净额。
这时候为了“找税”,再机械地把6.30乘以23%,反而可能把正确的费用重新算错。
但反过来也不能看到结算行是净额,就直接得出“这笔费用完全没有税务处理”。你的账户税务身份、固定营业场所声明和实际发票内容才是判断依据。
还要注意,Allegro的e-commerce VAT结算属于另一类账务项目。它不能和 Sales commission 混成一笔。对中国卖家而言,如果某笔交易触发了平台代收的电商VAT,应该先把它作为独立结算项目识别,而不是为了凑平银行流水,把它塞进销售佣金。
订单参加了平台促销时,最不能做的事情就是直接拿买家最后支付的数字去倒推所有费用。
以AlleDiscount这类活动为例,Allegro的规则是:买家按照折后价格购买,平台再把原价与折后价之间的差额以结算调整的形式计入卖家的账单,减少卖家应付给Allegro的金额。同时,销售佣金按卖家报名活动时提交的商品价格计算。
这意味着同一笔订单里,至少可能同时出现:
商品成交信息、销售佣金、促销造成的价格差额,以及后续可能发生的退款或交易返还。
如果财务只看“买家实际支付金额”,很容易把平台承担的优惠调整也当成销售佣金计算基数的一部分。
因此,遇到活动订单,先问一句:这笔钱是订单价格变化,还是平台对优惠差额做的结算调整?
两者在账上承担的作用不同。看到一笔正数或负数,也不要直接把它命名成“佣金退回”。
把前面的步骤做完,真正的决定就简单多了。
比如订单号、成交金额、买家承担的配送费、交易时类目费率全部对得上,Sales commission也能算回去;或者退款刚发生,平台的交易返还还没有形成记录,但订单状态已经符合正常处理路径。
这种情况不适合急着发起投诉。
先把记录留好,继续从 Operations History、Fee Summary 和后续结算文件观察这笔订单是否闭合。
如果订单没有自动形成transaction rebate,但从订单记录来看已经符合申请条件,就不要把一般客服咨询当成退佣申请的替代品。
现行规则下,卖家申请交易返还销售佣金的时间窗口是交易成立后45天。因此,真正需要盯的是交易日期,而不是“我今天刚发现这笔账”的日期。
申请前把这些信息整理好:
- 订单号; - 销售佣金费用行; - 买家付款状态; - 取消或退货记录; - 实际退款记录及退款方式; - 买家退货原因; - 如果是货到付款等场景,对应的物流追踪信息。
尤其是通过Allegro收款的订单,如果需要退款,退款路径本身就是判断退佣资格的重要条件。不能一边在Allegro之外把钱退给买家,一边默认平台应该自动把佣金一起退掉。
如果问题不是“退佣还没发生”,而是你已经按照交易当时的条款把订单、类目、计费基础、税务展示、优惠调整和费用行全部核过,最后仍然无法解释为什么平台收取了这笔 Sales commission,这时才值得正式提出异议。
现行Allegro Terms & Conditions的投诉机制允许用户针对服务没有按照条款提供的情况提交Complaint。电子方式可以通过Help部分的contact form提交,也可以书面提交。投诉至少应包含账户登录名、具体异议以及希望如何处理。
Allegro现行条款规定,投诉一般在收到后14天内处理;如果资料不足,补齐资料后重新计算处理期限。对投诉决定不服的,现行条款还规定可以在平台告知决定后6个月内提出Appeal。
这里有个很重要的区别:
45天是交易返还销售佣金的申请窗口,不是所有费用争议统一适用的“45天投诉期限”。
如果是退佣申请被拒,应优先使用退佣专用的Appeal入口。Allegro目前的退佣申诉表会展示最近120天的相关申请。一般费用计费错误,则走服务投诉机制。不要把两个入口混为一个。
财务对账最怕先定性,后找证据。
比如一笔订单的销售佣金,卖家自己算的是6.00 PLN,平台扣的是6.30 PLN。只看数字,很容易写成“多扣0.30 PLN”。
把订单打开之后才发现,买家另外支付了5 PLN配送费。问题到这里已经结束了。
另一笔订单,买家退款后原佣金还在,又很容易写成“退款后平台没退佣”。继续往下看,可能只是transaction rebate尚未形成;也可能是订单退款路径、退货原因或者其他资格条件不满足。
所以最实用的内部表,不需要做得很复杂,只要保证每一笔都能回答四个问题:
应计是多少?
实计是多少?
差额是多少?
差额属于“已解释、待调整,还是待申诉”?
只要这四个字段能够闭合,客服沟通就不会再从“为什么扣我钱”开始,而是可以直接变成:“订单PL-ORD-20261008-001,Sales commission应计6.30 PLN,实计7.10 PLN,订单成交价与买家配送费均已核对,交易时类目费率也已核对,请说明多出的0.80 PLN对应哪一项计费依据。”
这才是一条平台真正容易处理的询问。
对于这个只使用PLN、只追销售佣金的账户,可以固定三个位置。
第一处是 Settlements with Allegro → Operations History,用它定位具体费用行和交易记录。
第二处是 Fee Summary,用它观察订单、费用以及transaction rebate在结算层面的归类。要记住它按前一天数据更新,因此不要把当天页面的暂时空白当成最终结果。
第三处是 Invoices。账单开出来以后,再把服务费用与前面的交易记录对应起来。Allegro目前还提供从发票进入费用明细的入口,但该功能只对符合条件的近期发票提供,修正或多付款项对应的文件并不一定有同样的费用明细入口。
如果transaction rebate跨了月份,也要按“实际授予月份”去找,不要坚持认为它必须修改最初产生佣金的那张月度账单。
截至2026年10月16日,Allegro还已经公告了一个即将发生的日期变化:2026年10月27日起,自动交易返还销售佣金时将不再把卖家的销售质量等级作为条件之一,但买家通过相应表单撤销、退款通过Allegro处理等核心条件仍会保留。所以,如果你正在处理的是10月27日之后的新交易,不能把今天看到的自动退佣条件原封不动套过去。
同样,Allegro计划在10月27日起在Help Center加入AI Assistant,并允许转接人工。这是未来入口,不应拿来替代截至10月16日仍可使用的现行联系路径。
如果你现在已经拿到Allegro订单,真正值得做的不是把所有账单都翻一遍,而是先挑出这一笔,把订单号、费用行、退款或取消记录和交易时规则连成一条线。能被规则解释的差额,就不用把时间花在询问上;真正值得追的,是证据已经闭合以后,仍然没有计费依据的那一行。
如果还处在进入Allegro之前的阶段,ESG跨境作为Allegro官方招商合作伙伴,可以提供前置资料预审和专席对接;而一旦已经开始出单,后面的账,最终还是要回到订单级记录上。
作者:平台观察
声明:本文系作者独立观点,不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性,实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流,欢迎随时与我们联系。
二维码加载中...
使用微信扫一扫登录
使用账号密码登录
平台顾问
微信扫一扫
马上联系在线顾问
小程序
ESG跨境小程序
手机入驻更便捷
返回顶部