Chain Store Unified Collection: Account Structure, Split Settlement, and Who Issues the Invoice

Chain Store Unified Collection: Account Structure, Split Settlement, and Who Issues the Invoice

Chain store collection looks like a question of whether money can be taken, and it never is. With one store, a payment QR code ends the discussion. With ten or fifty, two questions demand answers: whose account receives this money, and who issues this invoice. That combination determines the account structure, whether split settlement is required, how reconciliation is split, and which account refunds come from. For the compliance boundary and the second clearing test see aggregate payment and the service provider model. Channel integration details belong to the channel tutorials on this site; this article covers structural design for the chain scenario only.

1. The Real Question Is Not Whether You Can Collect

Single-store complexity lives in hardware and connectivity: one terminal, one code, one phone with a network. Chain complexity lives in structure: does the head office collect centrally or does each store collect, which store gets credited when an online mini-program order arrives, whose performance counts when a member buys in store A and consumes in store B, which account pays the refund, and whose taxpayer identification number appears on the invoice.

Many chain projects solve only the first layer. At launch everything looks smooth: one aggregate payment code across all stores, one smart terminal covering the offline floor, total turnover visible in the head office dashboard. Three months later problems erupt, almost always in the same place.

First, it cannot be split. The head office account receives payments daily but cannot tell which store, which terminal, which time slot produced each one. Without a store dimension there is no store performance and therefore no store settlement.

Second, the invoice cannot be issued. A customer asks for an invoice and finance discovers the operating entity behind the order may be a franchisee. The head office issuing it means issuing for someone else's transaction, an unacceptable risk; asking the franchisee to issue means the order data is not in the franchisee's hands.

Third, stores do not accept the arrangement. Money sits in the head office account, stores cannot see their own receipts, and suspicion about settlement is natural. Once a settlement amount is disputed, neither side can produce details the other accepts.

The shared root cause is that the collection design considered payment success but not ownership of the money. A solution that only fixes payment success rate typically collapses within three months on reconciliation and invoicing, not on collection failures.

2. Account Structure for Head Office and Stores

There are only three options: head office central collection, store-level collection, and a hybrid of the two. Each maps to a different fund flow, invoicing entity and split settlement need, and the choice follows the operating model rather than technical preference.

Trade-offs Among the Three Structures

Central collection delivers a unified experience, a connected membership system and consolidated operating data, letting the head office see total turnover and run unified campaigns. It costs three things: funds accumulate in the head office account, and redistributing them to franchise stores moves into collection-and-disbursement territory; tax and revenue recognition concentrate at the head office; and stores do not trust the safety of their money.

Store-level collection is simple to keep compliant because money enters the store account directly and the head office never touches it, which franchisees accept most readily. It costs data fragmentation: membership cannot cross stores, campaigns cannot be redeemed uniformly, and head office commission depends on post-hoc reconciliation and dunning, enforced by contract rather than system.

The hybrid model is the most common real-world choice: online channels such as mini-programs, delivery platforms and group buying are collected by the head office, while offline stores collect for themselves. This keeps the head office out of franchisee money but requires two reconciliation logics, two invoicing flows, and a clean rule for cross-chain orders such as online purchase with in-store fulfilment.

One practical test when choosing: if you must distribute money to multiple entities, confirm whether the flow is customer to entity or customer to head office to entity. The former is compliant; the latter requires a license. That test matters more than any technical design.

3. Online Orders and In-Store Redemption

Chain online business is rarely purely online; it is online order with in-store fulfilment. What makes it different from ordinary e-commerce is that payment completion is not delivery completion. Delivery happens in the store, while revenue attribution, performance calculation and refund responsibility all hang on the store dimension.

Three Paths from Online Order to In-Store Redemption

The first is voucher redemption. The customer buys a package or stored-value voucher online and presents a code in store, where redemption completes delivery. This suits prepaid business best; the delivery moment is clear, but the redemption step breeds problems: duplicate redemption, expiry disputes, cross-store redemption.

The second is in-store payment. The customer books or orders online and pays by scanning in store, so the money is generated at the store. Attribution is cleanest here, but the online conversion chain breaks and the customer may not order after arriving.

The third is store order with head office fulfilment. The customer orders in the store while goods ship from a head office or regional warehouse. Collection happens at the store and fulfilment at the head office, the most dispute-prone combination in reconciliation, so revenue attribution rules must be agreed in advance.

All three paths impose one shared system requirement: redemption must be idempotent. Redeeming one voucher twice records the same revenue twice and makes two stores fight over performance. The redemption endpoint should key on the redemption code and return the same result for repeated requests rather than executing again.

Refunds follow redemption. A refund must inherit the original order's store attribution; otherwise revenue is booked in store A while the refund leaves the head office account, store performance is overstated, and an unexplained outflow appears at the head office. For channel-side refund handling see the refund and settlement operations handbook.

One easily missed technical point: the merchant number used by the mini-program or official account determines which account receives funds. If the head office mini-program uses the head office merchant number, all online orders land at the head office even when attributed to a store. This must be settled in the technical design, not adjusted afterwards.

4. Split Settlement for Head Office Commission and Store Settlement

What the head office charges stores is either transaction sharing, where one payment is divided among parties, or a fee, where the store pays management and brand fees to the head office. The two have entirely different compliance paths, and mixing them creates problems.

Two Bases for Head Office Commission

The first is commission on turnover, based on transaction amount. The basis is simple and stores understand it, but it is unfair to stores with high refunds or heavy discounting because turnover includes amounts later refunded. If used, the basis must specify whether it applies to paid amount or net of refunds; the difference becomes obvious in refund-heavy months.

The second is commission on gross margin, being turnover minus cost. Fairer, but it requires stores to disclose cost data, which franchisees generally resist, so it rarely works in practice.

Once the basis is chosen, the settlement timing follows. Splitting at payment success is the most real time but makes refund reversals painful; end-of-day batch splitting lets the day's refunds net out first, producing cleaner books. Most chain projects choose end-of-day batch splitting because it aligns naturally with the store reconciliation cycle.

Split settlement receivers must complete onboarding first. Store corporate accounts, franchisee entity documents and settlement account ownership all have to be in place. Onboarding usually takes longer than technical integration, so it must start early.

One key judgment: management fees should not run through split settlement. Split settlement distributes transaction funds, while a management fee is consideration for services. Using split settlement to collect management fees makes the fund flow hard to explain. Management fees belong in a separate fee settlement process through corporate transfer or entrusted debit, invoiced separately.

Mainstream domestic split settlement capability comes from WeChat Pay and Alipay. When offline acquiring and bank card scenarios must be covered at the same time, products from the UnionPay system are usually added, and multi-channel management often relies on an aggregate provider such as Ping++.

5. Multi-Store Reconciliation and Fund Concentration

Two Methods of Fund Concentration

The first is automatic concentration: store receipts transfer automatically to a designated head office account on an agreed cycle, keeping the head office balance consolidated for unified deployment. This fits direct-operation systems, where store accounts already belong to the head office.

The second is manual remittance: stores manage their own collection accounts and pay what they owe the head office on a cycle. This fits franchise systems, keeping the head office out of store funds at the cost of dunning and bad debt exposure.

Once the method is chosen, reconciliation logic follows. Automatic concentration focuses on whether transfers are complete; manual remittance focuses on whether receivables arrived.

For general reconciliation method and bill structures see the reconciliation and bill download handbook. Chain reconciliation volume scales with stores times channels times dates, which no spreadsheet can sustain; for automation ideas see reconciliation automation scripts.

6. Who Issues the Invoice

Invoicing is the most underestimated link in chain collection because it does not appear at launch. It surfaces the first time a corporate customer asks for an invoice.

Three Invoicing Entity Situations

The first is that the contracting entity is the invoicing entity. Whoever contracts with the customer issues. This is the clearest situation and typical of direct operation, where the head office contracts and invoices while stores are delivery locations.

The second is online by the head office and offline by the store. A common hybrid arrangement: online orders are invoiced by the head office entity, offline store consumption by the store entity. This requires explicit order source flags in the system, otherwise finance cannot determine who issues.

The third is stores without invoicing capability. Some franchisees are small-scale taxpayers or sole proprietors with limited capability, and the common workaround is head office issuance on their behalf. The risk must be stated clearly: the head office issuing for a transaction that is not its own creates a mismatch between invoice and actual operating entity, a high-risk practice that should not become a standard arrangement.

The only principle is that the invoicing entity must match the actual transacting entity. That principle constrains the account structure in reverse: if you want the head office to invoice centrally, the head office must be the contracting party, and that in turn adjusts the fund flow. All three decisions must be designed together, never separately.

For automated invoicing, header collection and reversal see the invoicing and billing system guide. Tax rates and invoicing rules follow tax regulations and are not judged here. Invoice details should be collected in the payment or ordering flow rather than requested later.

7. Structural Differences Between Direct Operation and Franchise

The difference between direct operation and franchise is not store count but legal entity. A direct-operated store is not a separate legal person, so its collection account can be managed by the head office. A franchisee is a separate legal person or sole proprietor whose account, tax and liability are isolated from the head office.

Three Extra Constraints in Franchise Models

The first constraint is that funds cannot be freely disposed of. The head office cannot sweep a franchisee's receipts or require the settlement account to be bound to its own name, or the nature becomes collection on behalf of others. If the head office must collect centrally in a franchise system, split settlement is the only way to route funds directly to stores.

The second constraint is that the head office cannot decide refunds for franchisees. A refund is a transaction action, the transacting entity is the franchisee, and the refund decision belongs there. The head office may set service standards but cannot promise refunds on the franchisee's behalf, or responsibility and handling diverge when a dispute arises.

The third constraint is data and membership ownership. Who owns member data, how cross-store consumption is credited, and whether the head office may use franchisee transaction data for marketing must all be written into the franchise agreement and reflected in system permissions. The technical contribution is making attribution rules configurable rather than hardcoded.

Direct operation is structurally simpler: central collection, internal allocation, head office invoicing, no external split settlement and therefore no second clearing question. But direct operation still faces multi-store reconciliation and store performance accounting, only with simpler fund relationships. For cost structure differences see domestic payment channel fee structure, whose comparison of acquiring methods is directly relevant to chain selection.

8. Rollout Path and Implementation Checklist

Chain collection projects rarely fail on technology; they fail on rolling out too fast. A sound path is staged, with each stage solving one structural problem.

Four Phases of Rollout

Phase one is single-store validation. Pick one or two stores and run the full chain: order, payment, redemption, refund, invoice, reconciliation. The goal is not coverage but proving data can be split along the store dimension.

Phase two is a regional pilot. Pick one city or region and validate reconciliation and settlement with stores running in parallel. This stage is meant to expose split settlement and concentration problems, not payment problems.

Phase three is full rollout. The core here is onboarding and training: collecting store entity documents, deploying terminals, standardizing clerk operations. This workload far exceeds technical integration.

Phase four is automating split settlement and invoicing. Everything patched manually in the first three phases gets automated, including split result verification, refund netting and batch invoice issuance.

For the checklist, confirm before launch: the ordering flow forces store and terminal identifiers; redemption endpoints are idempotent and traceable; refunds inherit the original order's store attribution; split settlement receivers have completed onboarding with correct settlement account ownership; split failures have a dedicated reconciliation job and compensation flow; invoicing entity matches the actual transacting entity; online and offline invoicing rules are defined under the hybrid model; store statements export per store and are accepted by both sides; the concentration method matches the reconciliation logic; and entity qualification and business filing meet requirements, detailed in the payment compliance and filing guide.

If the structure must be replicated across regions, sub-merchant management under the service provider model also matters; that onboarding and permission design is covered in aggregate payment and the service provider model.

A closing suggestion: before any technical selection, write three answers on paper. Whose account receives the money, who issues the invoice, and how store performance is calculated. Once those are settled, channel and product choices become obvious; choosing channels before settling them pushes structural problems three months down the road.

More payment scenarios are collected under the Payment category.

Source: 16IDC original. Split settlement, acquiring and entrusted debit capability follow the official WeChat Pay, Alipay and UnionPay documentation as well as regulatory rules.