Selling on TikTok, Shopee, FoodPanda & Grab: Punching, Pricing, and Getting Paid

Orders from TikTok, Shopee, FoodPanda, Grab and similar platforms are different from walk-in sales in two ways: the platform owes you the money (the customer paid them, and they pay you later, minus commission), and the platform's prices usually differ from your store prices. Set things up as below and both differences are handled — your inventory and reports stay right, and you can prove exactly which orders the platform has or hasn't paid.

One-time setup (per platform)

Under Settings → Payment Types, create (or edit) one payment type per platform — "Shopee", "TikTok", "FoodPanda", "Grab" — and on each:

• Marketplace Channel: ON. This tells the system the sale is money the platform owes you, enables payout matching, and tags each sale with its channel for reporting.
• Requires Reference No.: ON. The cashier must key the platform's order ID when charging. This is what lets a payout be matched to your orders line by line — without it, unpaid orders can't be identified.
• Channel Price Adjustment (%): if your platform prices are, say, 25% above store prices, enter 25. When the cashier selects this payment type at checkout, the POS reprices the whole cart automatically so the punched total equals what the customer actually paid the platform. (Arrives with the next POS app update — until then, use the price override per item.)
• GL Account: a dedicated clearing account per platform (e.g. "Shopee Receivable") — not your bank account. Ask your bookkeeper, or create one under Accounting → Chart of Accounts as a current asset.

Day to day: punching platform orders

1. Ring up the order on the POS as usual.
2. At payment, pick the platform's payment type. Prices adjust to the platform's pricing automatically (you'll see a chip like "Shopee pricing: +25% applied").
3. Key the platform's order ID as the reference number when asked.

That's it — inventory deducts, the kitchen fires, and reports show the sale under its channel. Nothing lands in the cash drawer, so shift counts are unaffected. If the platform cancels an order, punch a refund on the POS with the same payment type.

When the payout arrives

Each payout cycle, download the platform's payout / income statement (CSV or Excel from the seller center) and go to Accounting → Marketplace Payouts:

1. Pick the platform, choose the file, and click Parse & Match. Columns (order ID, amounts, fees) are detected automatically.
2. Review the match: every payout line shows whether it matched a POS order, the amount differs, or the order is not in the POS at all. Below that is the important list — your POS orders the payout did NOT cover. Recent ones are just the next cycle; old ones are what you chase the platform about, order ID in hand.
3. Click Post Payout, picking the bank account the money landed in and an expense account for the commission. One journal entry records everything, and the covered orders are marked paid.

How do I know if a platform still owes us?

Two places, both automatic:

• Marketplace Payouts shows unpaid order counts and amounts per platform, with the oldest unpaid order's date.
• The Shift Reconciliation page's Non-Cash Settlements card shows each platform's outstanding balance and how many days old the oldest unsettled peso is — green when fresh, red when a payout looks skipped.

When the Platform Sometimes Pays at the Counter

Some platforms run both modes — FoodPanda especially: on some orders the customer paid the platform (they pay you later), on others the rider hands over cash at the counter. These are different kinds of money and must be punched with different payment types, or your drawer counts and payout matching will both be wrong.

Create two payment types for such a platform:

• "FoodPanda" — Type Other, Marketplace Channel ON, Requires Reference ON, clearing GL account set. Use for platform-paid orders. No money enters the drawer; the order waits for the payout.
• "FoodPanda – Cash" — Type Cash (counts in the drawer), Marketplace Channel ON, same price adjustment %. Use when the rider pays cash at pickup. The money counts toward the drawer's expected cash like any cash sale, the platform pricing still applies, and the sale is still tagged to the channel for reporting — but it never appears as "awaiting payout", because nothing is owed.

Getting it wrong shows up immediately: punching a cash-paid order on the platform tender makes the drawer count come up over (cash the system didn't expect) and the order sits forever as "unpaid by the platform". Punching a platform-paid order as cash makes the drawer come up short and the payout line shows "not in POS". If your reconciliation page shows a matching overage + a stale unpaid order (or a shortage + an unmatched payout line), a mixed-up tender is the usual culprit.

When Platform Prices Aren't a Neat Percentage

Many stores don't price platforms with a uniform markup — an item can be ₱150 on FoodPanda and ₱190 in store, while another item costs the same on both. For that, use the Channel Price Book: go to Products → Channel Prices and you'll see your products in a grid with one column per marketplace channel. Type the exact platform price into each cell (variants have their own rows); it saves as you go.

At the POS, selecting the platform's payment type reprices the cart from the price book automatically — the chip reads "FoodPanda menu pricing applied". Per item, the POS uses: the channel price if you set one → otherwise the tender's percentage adjustment → otherwise the store price. Add-on modifiers stay at their store prices on top.

Keeping the price book accurate pays off at payout time: your punched totals match the platform's statement to the centavo, so any "amount mismatch" the payout matcher flags is a genuine platform-side discrepancy worth chasing — not punching noise.