给东南亚加盟商户用的结算操作系统——把每天的销售额自动拆分成供应商付款、总部费用和营运资金。

1. 商户数据终于密度够高，足以自动化资金调度而不只是做报表，因为统一技术栈现在已经把支付、业务软件、CRM 和嵌入式金融整合到了一起。
2. 分销渠道已经在有意义的规模上存在——一个商户平台就为东南亚四个市场超过 2 万家商户提供服务。
3. 基于交易数据的中小企业授信已经在生产环境上线，证明每日销售数据可以支撑面向商户的短期资金产品。
4. 自 2025 年 12 月起持续盈利，说明商户操作系统模式已经从靠补贴推广的软件，成长为一个足够稳固、能让合作伙伴在其上搭建产品的基础设施。
5. 东南亚市场规模足以支撑一个专业财资层，因为这里既有庞大的中小企业基础，又有超过 US$1T 的数字支付活动。

催化因素。 Qashier 证明了 2 万家商户愿意把支付、CRM 和财务都跑在同一套技术栈上，而且同样的数据已经在为超过 US$10M 的中小企业贷款做授信——这说明可编程商户现金流所需的原始数据和分销渠道现在都已经具备。

Franchise Cashflow Waterfall 接入商户操作系统、结算数据流和记账系统，生成一份门店级的每日现金台账。产品会用可配置规则，把收款拆分给供应商付款、总部费用、工资或租金储备金，以及可选的融资还款——在现金消失进手工转账之前完成分配。当预测销售额和账单排期显示会出现缺口时，系统可以基于已验证的交易历史，触发一笔预先批准的供应商或营运资金支用，而不用走一遍全新的申请流程。产品最初是面向单一商户技术栈连锁品牌的对账和现金路由层，之后再扩展到财资分析、供应商融资和多国商户控制。

差异化。 多数商户软件止步于看板，多数中小企业放贷方看到的也只是一条单薄的银行或卡组织数据流。这家公司卡在两者中间——把商户操作系统当作销售、客户活动和运营场景的真相来源，再把结算时机变成一条可编程的现金瀑布流。这让它比记账软件更能落地执行，也比纯现金预支产品更安全，因为提醒和还款逻辑都绑定在经过验证的每日交易数据上。

待完成任务

flowchart LR
  Sales[门店每日销售额] --> Engine[瀑布流引擎]
  Engine --> Suppliers[供应商付款]
  Engine --> HQ[总部费用与特许权使用费]
  Engine --> Reserve[营运资金储备]
  Suppliers --> Outcome[更少缺货、更快结账]
  HQ --> Outcome
  Reserve --> Outcome

高管要点

• Qashier 已经验证了这个切口所需的分销和数据前提：它每年处理 US$1B 的支付流水，服务 2 万家商户，自 2025 年 12 月起持续盈利，还已经把交易数据变成了按日自动还款的营收贷款。[1][2][4]
• 买家的痛点是实打实的运营问题，不是空想出来的。新加坡中小企业普遍反映现金流紧张，亚太企业平均账期延迟仍长达 65 天，新加坡餐饮供应商的应收账款账期从 30 天一路拖到 120 天。[16][15][17]
• 邻近赛道的竞争是真实存在的，但都没做到这个具体工作流。Qashier、StoreHub 这类商户操作系统卖的是门店运营，Stripe、Adyen 卖的是可编程打款管道，Airwallex 卖的是财资和应付账款工具——没有一家把加盟连锁特有的每日供应商付款、特许权使用费、储备金和融资瀑布流打包成一个产品。[3][7][21][23][29]
• 监管和时机窗口都对软件主导的控制层有利。新加坡和马来西亚同时在推进电子发票和数字支付，而可编程打款 API、PayNow/DuitNow 支付轨道、基于数据的中小企业放贷也都日趋成熟。[25][26][27][28][13][30]

市场定义

这个市场是面向新加坡和马来西亚数字化程度较高的加盟连锁及多门店商户的、面向财务主管的结算编排软件——它是一层夹在商户操作系统销售数据、打款轨道和记账系统之间的控制层，在月末盲区出现之前就决定每天的现金该流向哪里。[1][8][21][24][29]

用户与买方

真正的买家是拥有 15 到 80 家门店的饮品、快餐（QSR）或相邻连锁品牌的 CFO、COO 或财务主管，他们已经在跑一套通用的 POS/支付堆栈，现在需要跨门店的集中现金纪律。这个市场轮廓是可信的，因为新加坡和马来西亚本身就有密集的餐饮和加盟网络，加上很高的数字支付普及率。[9][10][11][12][13][14][34]

购买触发点

• 新开门店、加盟扩张或跨国铺店让手工路由供应商款和特许权使用费在 Excel 里越来越撑不住。 [9][12][34]
• 现金流紧张或供应商关系紧绷，逼着财务负责人收紧每日分配，而不是等到月末再对账。 [16][17][15][20]
• 电子发票或财务集中化项目给了一个重新设计打款和审计流程的自然窗口期。 [25][26][27]

支付意愿

付费意愿是站得住脚的，因为商户本来就在为门店级运营软件付费、承担支付处理费，也在对账上耗费大量真实的财务时间。这个切口不需要凭空造出一条新预算线，只需要把已有的软件、支付和财务运营支出，转化成一层每日控制层。 [3][7][18][19][31]

品类动态

增长信号 东南亚 QSR 支出预计到 2028 年将达到 $91B，马来西亚电子支付在 2023 年同比增长 24%，另有一份东南亚嵌入式金融预测显示到 2030 年复合年增长率将达 57.7%。

验证信号

• QashierLoans 已经在用每日销售数据实现自动还款，验证了“可编程结算即信用信号”这一核心论点。
• StoreHub 和 Qashier 都明确以多门店餐饮商户为目标客户，证明了一个集中的启动细分市场确实存在。
• 新加坡餐饮商户仍然要花大量真实时间在记账上，还面临沉重的关店/逾期付款压力，说明这个工作流痛点不是假设出来的。
• 在基准研究中，使用更快支付轨道的餐厅经营者展现出更好的盈利能力和现金流表现。

监管与技术约束

• 只要在设计上避免让自己变成主要资金流转方，风险就比直接持有或归集商户资金低得多。
• IRAS InvoiceNow 和马来西亚电子发票把打款事件同时变成了税务事件和审计事件，因此事件日志和主体映射是产品能否成立的关键。
• 可编程打款轨道确实存在，但时机和国家支持程度各不相同；打款控制必须在不同伙伴之间做谨慎的抽象封装。
• 如果融资环节接入得太早，授权同意、还款排序和异常处理就会变成产品本身的一部分，而不只是经济模型问题。

竞争格局分四类：商户操作系统的现有厂商（Qashier、StoreHub）、打款基础设施（Stripe、Adyen）、CFO 工具栈和财资工具（Airwallex、Xero），以及放贷/平台金融的对标者（Grab、Funding Societies）。边缘地带的竞争很激烈，但在加盟连锁专属的现金瀑布流上留了一个工作流空档——尤其是那些需要在一个操作视图里同时管理供应商付款、总部汇款、储备金和融资规则的连锁品牌。[1][6][7][21][23][29][30]

为什么现有厂商不会默认胜出

• 商户操作系统厂商. Qashier 和 StoreHub 拿下了门店工作流，但它们的产品重心仍然是支付、库存、CRM 和放贷/报表，而不是面向加盟总部的中立多方财资逻辑。
• 支付基础设施平台. Stripe 和 Adyen 提供了分账转账和打款时机的正确原语，但它们是开发者平台，不是面向供应商日历、特许权使用费规则和跨主体异常处理的财务主管工作流。
• 财资和应付账款套件. Airwallex 和以记账为核心的工具栈能在资金到账后自动完成总部付款，但它们并不原生拦截门店级的结算事件或商户操作系统的销售信号。
• 放贷方和平台金融提供商. Grab、Funding Societies 和 QashierLoans 证明了基于交易数据的资本有需求，但融资本身解决不了决定连锁品牌能否用好这笔资本的每日分配和异常处理工作流。

Franchise Cashflow Waterfall 瞄准的是总部在新加坡、在新马两地拥有 15 到 80 家门店的饮品和快餐加盟集团——他们已经跑在同一套商户技术栈上，但每天交易结束后的现金分配仍然靠手工完成。这个痛点的核心是控制力不足，而不是缺报表：财务团队仍然靠 Excel、银行网银和临时转账，来决定供应商、特许权使用费、储备金和短期负债谁先拿到钱，结果现金问题总是在缺货、供应商施压或月末结账之后才浮出水面。产品接入一套商户操作系统、一个打款伙伴和记账系统，生成门店级的每日现金台账，并配上供应商应付款、总部汇款、储备金账户和可选伙伴主导融资还款的审批式瀑布流规则。这个切口现在可信，是因为 Qashier 和 StoreHub 已经证明了密集的多门店分销存在，两个目标市场都有可编程打款轨道，而基于交易数据的中小企业放贷也已经在生产环境上线。第一套商用系统应该是卖给 CFO 或 COO 的付费试点，落地时机选在门店扩张、财务集中化或电子发票上线的窗口，定价锚定在按门店收费的 SaaS 加上对编排或融资现金流水的可选基点费用。战略上的选择是先做一个软件主导的控制层，而不是自己下场放贷或替代 POS，因为在第一年，证明速度和监管简洁性比抢占资产负债表经济利益更重要。最大的悬而未决的问题是：到底有多少目标连锁品牌能在现有技术栈上开放可写入的打款控制权，以及对第一批买家来说，每日瀑布流自动化是否真的比每周批量控制更急迫。如果公司能在第一套启动技术栈上证明更快的结账速度、95% 以上的优先付款准时率和续约率，就可以扩展到相邻的零售和服务连锁，之后再成长为东南亚中小商户更广泛的财资与融资编排层。

问题

• 多门店加盟集团结算到账后，仍然在 Excel 里手工决定每天的供应商付款、特许权使用费汇款和现金储备，导致门店缺口总是在缺货或月末结账之后才被发现。
• 现有的商户操作系统、打款基础设施和记账工具各自掌握一部分数据，但没有一个真正扮演跨门店、跨交易对手、跨义务的财务主管现金政策层。
• 通用的中小企业放贷能填补偶发的流动性缺口，但解决不了决定哪笔义务先付、什么时候付的每日排序问题。

解决方案

• 用商户操作系统的销售和结算数据，生成门店级的每日现金台账，再套用可配置的瀑布流规则来分配供应商应付款、总部费用、租金或工资储备金和放贷方还款。
• 先从审批式执行、异常队列和审计日志入手，在一套商户技术栈上落地，让财务团队能控制资金流转，而不用替换 POS、打款或银行系统。
• 只有当规则引擎和已验证的销售数据显示确实存在缺口时，才把预测到的短缺上报给合作放贷方或供应商，让融资始终绑定在真实运营场景上，而不是变成孤立的申请。

为什么我们会赢

• 这家公司卡在商户操作系统记录系统和打款轨道之间，把已有的原语打包成一个财务主管工作流产品——而 Qashier、Stripe、Adyen 和 Airwallex 目前都没有把这个完整产品卖出来。
• 可复用的饮品和 QSR 瀑布流模板，加上门店级异常数据，既能形成流程层面的切换成本，也能提供比通用应付账款或现金预支工具更好的授信信号。
• 与持牌伙伴合作、软件主导的方式让监管范围保持收窄，同时仍然有机会让产品成为供应商、特许权使用费、储备金和融资决策的默认控制面。

里程碑

flowchart LR
  Wedge[20-50 家门店的加盟试点] --> MVP[单一技术栈瀑布流引擎]
  MVP --> Proof[更少手工结账时间, 95%以上优先付款准时率]
  Proof --> Expansion[更多连锁, 再到更多技术栈和伙伴主导融资]

创始团队

实验路线图

风险评估

必须成立的条件

• 在最初 20 个新马目标连锁品牌里，至少 6 个符合单技术栈、财务集中管理的画像，并愿意共享门店级结算工作流。
• 有一套启动技术栈的伙伴组合能支撑审批式打款执行，而不需要这家创业公司变成主体资金流转方。
• 前 3 个试点能把每周现金分配工作量减少至少 30%，并把供应商或特许权使用费的准时付款率维持在 95% 以上。
• 至少 2 个试点客户在扣除可选融资费用前，转化为价值 US$50k 到 90k 的年度合同。
• 第二套商户技术栈或相邻连锁垂直品类能在 18 个月内复用大部分模板，证明这个切口不是一次性的服务生意。

待尽调问题

• 到底有多少家 15 到 80 家门店的新马连锁真正端到端跑在一套商户技术栈上，并能开放每日结算文件？
• 哪种商户操作系统加打款伙伴的组合，能最快跑通实时审批式瀑布流？
• 对第一批买家来说，供应商、特许权使用费和储备金义务是否频繁到让每日控制比每周批量工作流更划算？
• 什么样的 KPI 门槛会让 CFO 按提议的每门店价格续约？
• 一旦需求得到证明，Qashier、StoreHub、Stripe、Adyen 或 Airwallex 为什么不会自己把这个功能吸收进去？

模型合理性

• 收入引擎. 基准情形靠运营门店数从 100 增长到 600 家驱动，同时把混合收入维持在基于研究测算的每门店 $3.225K 附近。
• 必须跑通的环节. 试点转生产合同的转化必须维持在 45 到 90 天的部署窗口附近，这样一支 10 人规模的第二年团队才能在不沦为服务型公司的前提下做到 300 家门店。
• 模型崩溃的条件. 如果销售周期拉长到六个月左右，或附加费退回到纯订阅定价，下行情形会在第三年结束前把现金推到零以下。
• 下一轮的验证依据. 一旦公司在第 24 个月达到约 300 家运营门店、5 到 8 个生产环境集团、第二套技术栈的验证，以及至少一次融资模块的验证，下一轮融资就站得住脚。

情景

敏感性

flowchart LR
  DirectOutreach --> PaidPilots
  PaidPilots --> LiveOutlets
  PartnerReferrals --> LiveOutlets
  LiveOutlets --> SubscriptionRevenue
  LiveOutlets --> VolumeFees
  SubscriptionRevenue --> GrossProfit
  VolumeFees --> GrossProfit
  GrossProfit --> Cash

警示项: 第三年报告毛利率仍低于 70% 的目标，因为实施和合规成本还没有摊薄到足够多的运营门店上。 · 每 FTE 收入仍低于成熟 SaaS 的基准水平，只有当公司持续复用同一套启动技术栈模板、而不是为每个连锁做定制项目时，这才是可以接受的。 · 基准情形结束时现金只剩约 $185K，一个季度的试点转化延误就可能迫使公司增资或放慢招聘节奏。 · 模型仍然依赖第三年集中在 20 到 25 个多门店集团身上，少数几个部署延迟或流失的连锁就会明显拖动 EBITDA。

• 平台依赖风险. 如果商户操作系统或支付服务商的集成做得不够深，产品可能没法自动化足够多的现金工作流，无法成为客户离不开的核心系统。 缓解措施: 先从一套深度集成的启动技术栈开始，用可读写的结算自动化在那里证明价值，再为相邻系统补充只读兜底方案。
• 信贷坏账风险. 如果公司过早自己承担资产负债表上的直接信用风险，几个坏账商户就可能吃掉软件业务的利润。 缓解措施: 早期融资保持由伙伴主导，把使用场景限制在短期供应商或营运资金预支，并从每日结算流水中还款。
• 中小企业变革管理风险. 加盟商可能比预期更长时间容忍手工财务流程，即便痛点是真实的，采用速度也会因此放缓。 缓解措施: 在门店扩张或财务集中化的节点上销售，把 ROI 锚定在更快的结账速度、更少的现金缺口和可衡量的供应商付款可靠性上。