Settlement OS for Southeast Asian franchise merchants that auto-splits daily sales into supplier pay, HQ fees, and working capital.

1. Merchant data is finally dense enough to automate cash movement, not just reporting, because unified stacks now combine payments, business software, CRM, and embedded finance.
2. Distribution already exists at meaningful scale, with one merchant platform serving more than 20,000 merchants across four Southeast Asian markets.
3. Transaction-based SME underwriting is already live in production, proving that daily sales data can support short-duration capital products for merchants.
4. Profitability since December 2025 shows the merchant-OS model has matured from subsidized software adoption into durable infrastructure partners can build around.
5. The regional market is large enough to support a specialist treasury layer because Southeast Asia combines a huge SME base with more than US$1T in digital payments activity.

Catalyst. Qashier's proof that 20,000 merchants will run payments, CRM, and finance in one stack, plus evidence that the same data already underwrites US$10M-plus of SME lending, means the raw data and distribution for programmable merchant cashflow now exist.

Franchise Cashflow Waterfall plugs into the merchant OS, settlement feed, and accounting stack to create a daily outlet-level cash ledger. The product applies configurable rules to split receipts into supplier payments, HQ fees, payroll or rent reserves, and optional financing repayment before cash disappears into manual transfers. When forecast sales and bill schedules imply a shortfall, it can trigger a pre-approved supplier or working-capital draw based on verified transaction history instead of a fresh application cycle. The initial product starts as a reconciliation and cash-routing layer for chains on one merchant stack, then expands into treasury analytics, supplier financing, and multi-country merchant controls.

What's different. Most merchant software stops at dashboards, and most SME lenders see only a thin bank or card feed. This company sits between those layers, using the merchant OS as the source of truth for sales, customer activity, and operational context, then turning settlement timing into a programmable cash waterfall. That makes it more actionable than accounting software and safer than pure cash-advance products because alerts and repayment logic are tied to verified daily trading data.

Jobs to be done

flowchart LR
  Sales[Daily Store Sales] --> Engine[Waterfall Engine]
  Engine --> Suppliers[Supplier Payments]
  Engine --> HQ[HQ Fees and Royalties]
  Engine --> Reserve[Working Capital Reserve]
  Suppliers --> Outcome[Fewer stockouts and faster close]
  HQ --> Outcome
  Reserve --> Outcome

Executive takeaways

• Qashier already proves the distribution and data preconditions for the wedge: it processes US$1B in annualised payment volume for 20,000 merchants, has been profitable since December 2025, and has already turned transaction data into revenue-based lending with automatic daily repayment.[1][2][4]
• Buyer pain is operationally acute rather than abstract. Singapore SMEs report widespread cash-flow stress, APAC companies still face 65-day average payment delays, and Singapore F&B suppliers describe invoices stretching from 30 to 120 days.[16][15][17]
• Adjacent competition is real, but it stops short of the exact workflow. Merchant OS vendors such as Qashier and StoreHub sell store operations, Stripe and Adyen sell programmable payout plumbing, and Airwallex sells treasury/AP tooling; none packages franchise-specific daily supplier, royalty, reserve, and financing waterfalls for controllers.[3][7][21][23][29]
• The regulatory and timing window is favorable for a software-led control plane. Singapore and Malaysia are pushing e-invoicing and digital payments at the same time that modern payout APIs, PayNow/DuitNow rails, and data-driven SME lending are maturing.[25][26][27][28][13][30]

Market definition

The market is controller-facing settlement orchestration software for digitally mature franchise and multi-outlet merchants in Singapore and Malaysia: a layer that sits between merchant OS sales data, payout rails, and accounting systems to decide where each day’s cash should go before month-end blind spots emerge.[1][8][21][24][29]

Customer and buyer

The practical buyer is the CFO, COO, or finance controller of a 15-80 outlet beverage, QSR, or adjacent chain that already runs a common POS/payments stack and now needs central cash discipline across outlets. The market shape is credible because Singapore and Malaysia already have dense F&B and franchise footprints plus high digital-payment adoption.[9][10][11][12][13][14][34]

Buying triggers

• New outlet openings, franchise expansion, or multi-country rollout make manual supplier and royalty routing too fragile to keep in spreadsheets. [9][12][34]
• Cash-flow stress or supplier tension forces finance leaders to tighten daily allocation instead of waiting for month-end reconciliation. [16][17][15][20]
• E-invoicing or finance-centralization projects create a natural window to redesign payout and audit workflows. [25][26][27]

Willingness to pay

Willingness to pay is plausible because merchants already buy per-location operating software, absorb payment-processing fees, and lose real finance time to reconciliation. The wedge does not need to invent a new budget line so much as convert existing software, payments, and finance-ops spend into a daily control layer. [3][7][18][19][31]

Category dynamics

Growth signal SEA QSR spend is projected to reach $91B by 2028, Malaysian e-payments grew 24% YoY in 2023, and one SEA embedded-finance forecast points to 57.7% CAGR through 2030.

Validation signals

• QashierLoans already uses daily sales data for automatic repayment, validating the core “programmable settlement as credit signal” thesis.
• StoreHub and Qashier both explicitly target multi-outlet F&B merchants, confirming the availability of a concentrated launch segment.
• Singapore F&B merchants still spend real time on accounting and face heavy closure/late-payment pressure, so workflow pain is not hypothetical.
• Restaurant operators using faster payment rails show better profitability and cash-flow outcomes in benchmark research.

Regulatory & technical constraints

• A launch design that avoids becoming principal money mover is materially lower risk than directly holding or pooling merchant funds.
• IRAS InvoiceNow and Malaysia e-invoicing turn payout events into tax and audit events, so event logs and entity mapping are product-critical.
• Programmable payout rails exist, but timing and country support vary; payout control must be abstracted carefully across partners.
• If financing is attached too early, consent, repayment ordering, and exception handling become part of the product surface, not just the economics.

The competitive set breaks into four classes: merchant OS incumbents (Qashier, StoreHub), payout infrastructure (Stripe, Adyen), CFO stack and treasury tools (Airwallex, Xero), and lender/platform finance analogs (Grab, Funding Societies). That makes rivalry high at the edges but leaves a workflow gap in franchise-specific cash waterfalls, especially for chains that need supplier pay, HQ remittance, reserves, and financing rules in one operating view.[1][6][7][21][23][29][30]

Why incumbents do not win by default

• Merchant OS vendors. Qashier and StoreHub win the store workflow, but their product surface still emphasizes payments, inventory, CRM, and lending/reporting rather than neutral multi-party treasury logic for franchise HQ.
• Payment infrastructure platforms. Stripe and Adyen expose the right primitives for split transfers and payout timing, but they are developer platforms, not controller workflows for supplier calendars, royalty rules, and cross-entity exceptions.
• Treasury and AP suites. Airwallex and accounting-led stacks automate HQ disbursements after funds arrive, but they do not natively intercept outlet-level settlement events or merchant-OS sales signals.
• Lenders and platform-finance providers. Grab, Funding Societies, and QashierLoans prove demand for transaction-data-driven capital, but financing alone does not solve the daily allocation and exception workflow that determines whether a chain uses capital well.

Franchise Cashflow Waterfall targets Singapore-headquartered beverage and quick-service franchise groups with 15-80 outlets across Singapore and Malaysia that already run a unified merchant stack but still allocate cash manually after each day of trade. The acute pain is control rather than reporting: finance teams still use spreadsheets, bank portals, and ad hoc transfers to decide which supplier, royalty, reserve, and short-term obligations get paid first, so cash problems surface after stockouts, supplier escalation, or month-end close. The product plugs into one merchant OS, one payout partner, and the accounting stack to create an outlet-level daily cash ledger plus approval-based waterfall rules for supplier payables, HQ remittance, reserve accounts, and optional partner-led financing repayment. This wedge is credible now because Qashier and StoreHub already show dense multi-outlet distribution, programmable payout rails exist in both launch markets, and transaction-data-based SME lending is already live. The first commercial system should be a paid pilot sold to a CFO or COO during outlet expansion, finance centralization, or e-invoicing rollout, with pricing anchored to per-outlet SaaS plus optional basis-point fees on orchestrated or financed volume. The strategic choice is to start as a software-led control plane, not a principal lender or POS replacement, because speed to proof and regulatory simplicity matter more than capturing balance-sheet economics in year one. The biggest unresolved questions are how many target chains can expose write-accessible payout controls through their existing stack and whether daily waterfall automation is urgent enough versus weekly batch control for the first buyers. If the company can prove faster close, 95%+ on-time priority payments, and paid renewals on one launch stack, it can expand into adjacent retail and service chains and later become a broader treasury and financing orchestration layer for Southeast Asian SMB commerce.

Problem

• Multi-outlet franchise groups still decide daily supplier pay, royalty remittance, and cash reserves in spreadsheets after settlement lands, so outlet shortfalls surface after stockouts or month-end close.
• Existing merchant OS, payout infrastructure, and accounting tools each own part of the data, but none acts as the controller's cash policy layer across outlets, counterparties, and obligations.
• Generic SME lending can fill occasional liquidity gaps, but it does not solve the daily sequencing problem that determines which obligations get paid and when.

Solution

• Create an outlet-level daily cash ledger from merchant OS sales and settlement data, then apply configurable waterfall rules for supplier payables, HQ fees, rent or payroll reserves, and lender repayment.
• Start with approval-based execution, exception queues, and audit logs on one merchant stack so finance teams can control money movement without replacing POS, payouts, or banking systems.
• Escalate predicted shortfalls to partner lenders or suppliers only when the rule engine and verified sales data show a gap, keeping financing attached to operational context rather than standalone applications.

Why we win

• The company sits between merchant OS record systems and payout rails, packaging existing primitives into a finance-controller workflow that Qashier, Stripe, Adyen, and Airwallex do not currently sell as a complete product.
• Reusable beverage and QSR waterfall templates plus outlet-level exception data create process switching costs and a better underwriting signal than generic AP or cash-advance tools.
• A software-led launch with licensed partners keeps regulatory scope narrow while still letting the product become the default control surface for supplier, royalty, reserve, and financing decisions.

Milestones

flowchart LR
  Wedge[20-50 outlet franchise pilot] --> MVP[One-stack waterfall engine]
  MVP --> Proof[Less manual close time and 95% plus on-time priority payments]
  Proof --> Expansion[More chains then more stacks and partner-led financing]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 6 of the first 20 target SG/MY chains fit the single-stack, centralized-finance profile and will share outlet-level settlement workflows.
• One launch-stack partner combination can support approval-based payout execution without the startup becoming the principal money mover.
• The first 3 pilots reduce weekly cash-allocation work by at least 30% and keep on-time supplier or royalty payments above 95%.
• At least 2 pilot customers convert to annual contracts worth US$50k-$90k before optional financing fees.
• A second merchant stack or adjacent chain vertical can reuse most of the template within 18 months, proving the wedge is not a one-off services business.

Open diligence questions

• How many 15-80 outlet SG/MY chains actually run one merchant stack end to end and expose daily settlement files?
• Which merchant OS plus payout-partner combination gives the fastest path to live approval-based waterfalls?
• Are supplier, royalty, and reserve obligations frequent enough that daily control beats weekly batch workflows for the first buyers?
• What KPI threshold causes a CFO to renew at the proposed per-outlet price?
• Why will Qashier, StoreHub, Stripe, Adyen, or Airwallex not absorb this feature once demand is proven?

Model sanity

• Revenue engine. The base case is driven by growing from 100 to 600 live outlets while holding blended revenue near the research-based $3.225K per outlet.
• Must go right. Pilot-to-production conversion has to stay near the 45-day-to-90-day deployment window so a 10-person Y2 team can reach 300 outlets without turning into a services business.
• Model breaks if. If sales cycles stretch toward six months or attach fees fall back toward subscription-only pricing, the downside case takes cash below zero before Y3 ends.
• Next-round proof. The next round is justified once the company reaches about 300 live outlets, 5-8 production groups, second-stack proof, and at least one financing-module validation by month 24.

Scenarios

Sensitivity

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

Flags: Reported gross margin is still below the 70% target in Y3 because implementation and compliance costs are not yet spread across enough live outlets. · Revenue per FTE remains below mature SaaS benchmarks, which is acceptable only if the company keeps reusing the same launch-stack template rather than custom-projecting every chain. · The base case finishes with only about $185K of cash, so one quarter of delayed pilot conversion would likely force a top-up or a slower hiring plan. · The model still depends on a concentrated set of 20-25 multi-outlet groups by Y3, so a handful of delayed rollouts or churned chains would move EBITDA materially.

• Platform dependency. If merchant OS or payment-provider integrations are shallow, the product may not automate enough of the cash workflow to become mission-critical. Mitigation: Start with one deeply integrated launch stack, prove value with read-write settlement automation there, and add read-only fallbacks for adjacent systems.
• Credit-loss blowup. If the company takes direct balance-sheet risk too early, a few bad merchants could erase software margins. Mitigation: Keep early financing partner-led, restrict use cases to short-duration supplier or working-capital advances, and repay from daily settlement flows.
• SME change management. Franchise operators may tolerate manual finance processes longer than expected, slowing adoption even when pain is real. Mitigation: Sell into expansion or finance-centralization moments and anchor ROI on faster close, fewer cash gaps, and measurable supplier-payment reliability.