Best Practices

“Where did this figure come from?” is the question an online channel raises most: the stock a shop shows, a payment with no receipt behind it, a month’s card takings that never match the bank. This page is for whoever runs the channel and whoever closes its books: the e-commerce lead, the accounts clerk and the finance manager. Each practice says who does it, when, what you see if it is skipped, and how you know it held. Read Core Concepts first; every practice below follows from a mechanism explained there.

The example. GadgetSphere Online Sdn Bhd (GSO) runs the group’s website and three marketplace shops (Shopee, Lazada and TikTok Shop) from its fulfilment centre. Each shop is a branch of GSO. Corporate clients of GadgetSphere Distribution (GSD) order through a separate, gated website.

1. Add the Shopping Cart → Sales Order knock-off row before anyone finalises a cart

When a cart is set FINAL, a follow-on job looks for the company’s Knock Off Configuration row for that document type. If there is none, it does nothing and raises nothing, so the cart reports success while the Sales Order’s Search Shopping Cart tab stays empty.

The same job does the same for a sales order. Without a Sales Order → Sales Invoice row, every marketplace order on GSO’s shop branches finalises cleanly. The branch’s available stock then ignores it, and the invoice’s knock-off tab cannot find it when the month’s marketplace sales are invoiced.

Who and when: whoever sets up the company in the Organisation applet, before the first cart is finalised or the first shop is connected.
How you know it held: finalise one test cart and see its lines on the Sales Order’s Search Shopping Cart tab. Then raise a test invoice and find a FINAL marketplace order on its knock-off tab.

2. Use the buffer, not a reservation, to stop overselling on a marketplace

Nothing reserves stock at checkout or when an order arrives. The figure BigLedger sends a Lazada or Shopee shop is recalculated at once in three cases: when a marketplace order is finalised in BigLedger, when a stock movement posts, and when someone saves the branch’s Stock Configuration. So the window in which two shops can sell the same unit is the time a sale takes to reach BigLedger. For a shop whose orders arrive by a scheduled pull, that is up to one run interval of its order job. The stock job’s timing does not decide it.

Size a quantity buffer from that interval. For example, a campaign weekend at GSO: its order jobs’ schedules are set to a 15-minute interval, and the three shops together sell up to four of a flagship smartphone in any 15 minutes. A BUFFER of 4 on each pushed shop covers one interval.

A percentage behaves differently as stock runs down. PERCENTAGE 90 holds back 4 of 40 phones, but only 1 of the last 10, and none at all once five or fewer are left, because the figure is rounded to the nearest unit. The protection disappears at the point where overselling is most likely.

The stock jobs send nothing to a TikTok Shop or Shopify shop. Keep that shop’s stock in its seller centre (Running an Online Channel, Step 2). A Stock Reservation does not lower the shop figure, so use one only to hold units for one customer’s order, never as a margin against overselling.

Which overselling policy to adopt is a business decision, and this page does not make it. There are four honest positions, each with a cost:

Show everything. No lost sales, and every oversell risk stays open.
A quantity buffer. Covers the order-job interval. It hides the buffered units from every shop, even when only one shop is busy.
A percentage share. Protects each shop from another shop’s surge. It hides more stock when stock is plentiful, and less near the end.
Dedicated stock at a location the shop’s configuration does not tick. Guarantees a campaign’s units, and needs a transfer to move units back when the campaign ends.
Who and when: the channel manager chooses the policy when a shop opens, and resizes the buffer before every campaign and whenever the order job’s interval changes.
How you know it held: the stock check in §11 agrees with the shop, and the seller centres report no cancellations for lack of stock.

3. When a payment is “missing”, look on the sales order first

A storefront checkout makes no receipt voucher. When the gateway reports success, the server turns the shopper’s cart into a FINAL sales order and writes the payment onto it as a settlement line carrying the gateway’s merchant reference (Core Concepts §4). The money reaches a cashbook only where the cashbook posting job follows the order’s FINAL on your tenant. That job then posts the settlement line into the cashbook of the settlement item the checkout sent with the payment request.

What to look for, in order

Is there a sales order? Find the shopper’s order on the website’s branch and open its settlement lines. The gateway’s merchant reference is on the line. If the shopper’s basket is still a cart, BigLedger has not been told the payment succeeded: the conversion runs only on a success. An iPay88 payment the gateway left pending is converted later, when the iPay88 status enquiry picks it up, where a clock for that enquiry runs.
Is the money in the cashbook? If the order carries the settlement line and the settlement item’s cashbook shows nothing for it, the cashbook posting job has not posted it. Which follow-on jobs run after FINAL is set per tenant, so ask BigLedger support whether that job is one of yours.

Do not key the receipt yourself first

The settlement line already carries the payment, and a receipt voucher posts to a cashbook as well, so a voucher keyed for the same money can count it twice. How the sales invoice raised from the order is then shown as settled is an open question (Q-1341). Agree it with your accountant before anyone keys anything against those invoices.

Watch the date at month-end

The order and its settlement line are dated at the moment BigLedger converts the cart: the gateway’s callback, or, for a pending iPay88 payment, the enquiry that confirmed it. That is not when the shopper started the checkout, so a payment confirmed late can fall into the next month.

A bill paid through the billing applet works differently

Bills paid through BigLedger’s billing applet use a separate payment route, and there a job does build a receipt voucher. It writes the merchant reference into the voucher’s Client Doc 1 and remarks, then finalises the voucher and knocks it off the bill. If either of those last two steps fails, the voucher stays as a draft, or FINAL with nothing knocked off, and a re-run does not repair it: finalise or knock it off by hand. Do not key that voucher yourself first. The job recognises a voucher only by the gateway reference, which the receipt-voucher screens cannot enter, so it would add a second one.

Who and when: the accounts receivable clerk, every morning, for the previous day’s paid storefront orders.
How you know it held: every successful gateway payment in the gateway’s report has exactly one FINAL sales order carrying a settlement line with its merchant reference. Where the cashbook job runs, the day’s settlement lines add up to the day’s storefront takings in the settlement item’s cashbook.

4. Test shipping rules in the storefront, not in the applet

Only the storefront evaluates a shipping price book, in the shopper’s browser at checkout. It ignores four things the Shipping Pricebook applet lets you set:

Single Line rules are never evaluated.
A Valid Date Range always passes.
A Delivery Region rule’s own negation is ignored, and only the state of the shipping address is compared.
The Status flag is never read, so Inactive price books and price sets are still offered.

Build the price set, then place a test order on the website and read the shipping line it writes. To run a dated promotion, switch price sets by hand on the start and end dates and put both dates in the diary.

Who and when: the e-commerce administrator, before go-live and after every change to a price book.
How you know it held: test orders to two states, one inside a rule and one outside it, are charged the fees you intended.

5. One marketplace branch per shop, and pull the reference data once per branch

Each shop is its own branch, with its own authorisation, settlement method, stock rule and pricing scheme. Do not point two shops at one branch. After creating the branch, run the four Ecomsync Management pulls for it before anyone tries to link an item. The category and brand pickers stay empty until then, and the ticket that results (“cannot choose a category”) is always this.

Who and when: the channel manager, the day the shop’s branch is created.
How you know it held: the category and brand pickers on a new listing for that branch are populated.

6. Count the shop’s orders against the branch’s orders, every day

Most order connectors create the sales order, number it and finalise it in one pass, so nobody works through a queue. Nothing on any screen turns amber when a channel stops feeding. Two exceptions leave orders waiting for a person. On several connectors, an order with a line on the connector’s placeholder item is numbered and left in draft. Orders from the Magento and SelluSeller connectors, where those are in use, are created unfinalised.

The only reliable check is the one the product does not run for you: today’s order count in each shop’s own seller centre against today’s sales orders on that marketplace branch, plus any order on the branch that is still in draft or has no running number. A branch that is suddenly quiet while the shop is not is the symptom of a stopped feed. Absence is the only symptom you get.

When the counts do not match

The connection’s heartbeat. Where the credential-refresh job is scheduled, it writes the connection record’s Remarks on every run for Lazada, Shopee and TikTok Shop: Auto updated by ECOMSYNC_REFRESH_CREDENTIALS_PROCESSOR when it worked, Failed to refresh credentials when it did not. Its Updated date is the nearest thing to a heartbeat the platform has.

Before trusting that line, confirm the job has a schedule in the Scheduler. Where it has none, nothing updates Remarks on a schedule. A Lazada connection’s Updated date can still move, because Lazada also refreshes on demand. BigLedger records a Shopee access token as good for four hours and a Lazada one for about thirty days, so a stopped refresh shows on a Shopee shop the same day and on a Lazada shop weeks later.

The order pull is a lookback window, not a cursor. Each run asks the channel for orders updated in the last n (the job’s interval) and keeps the ones BigLedger does not already hold. An outage longer than that window leaves a gap that no later run fills by itself. Widen the interval once, by hand, to pick the missing orders up. Stay inside the channel’s own limit, which for Shopee is fifteen days.

Who and when: the online operations lead, each morning, for the previous day.
How you know it held: the counts match, no order on the branch is in draft or unnumbered, and the connection’s Updated date is within one run of the refresh job’s schedule.

7. Journal the gateway fee yourself, on a schedule

A storefront payment’s settlement line is for the full amount the shopper was charged, on the settlement item sent with the checkout’s payment request, so where the cashbook job posts it, it lands in that item’s cashbook. The gateway then pays you that amount less its fee. The module records the gateway’s charge lines on the payment record and prices the fee on the monthly merchant report from the rate cards in Merchant Admin, but nothing posts it.

So if GSO takes RM 50,000 by card in a month and the gateway deducts RM 1,000, the settlement lines say RM 50,000 and the bank receives RM 49,000. The RM 1,000 sits as an unexplained difference until a person journals it. Do not expect a “gateway holding account” to clear itself.

The treatment is the finance manager’s choice, and this page does not make it

Agree it once, write it down, and apply it monthly. Three things to decide:

Decision	One way	The other way	What each costs
Where the payments land	A clearing cashbook per gateway, chosen through the settlement item. The gateway’s payout is moved to the bank, and the fee journal leaves the clearing balance equal to what the gateway still owes you	Straight into the bank cashbook	Clearing: one more cashbook and a transfer per payout, and a balance you can prove. Bank: a simpler chart, with a reconciling difference on every payout until the fee is journalled
Where the fee figure comes from	The gateway’s own statement	The merchant report’s rate-card figure	The statement is what you were charged. The report is only as right as the rate cards someone maintains, and is the figure to use if you accrue before the statement arrives
How often	Per payout	Monthly	Per payout keeps the clearing balance true daily; monthly is less work and leaves the balance overstated mid-month

This is a different job from marketplace fees. Shopee pays a net payout onto one receipt voucher, and its deductions are booked as described in Reconciling Marketplace Payouts.

Who and when: the finance manager chooses the treatment before the website takes its first payment. The accounts clerk posts the fee journal on the agreed schedule.
How you know it held: after the fee journal, the clearing cashbook (or the bank cashbook) agrees with the gateway’s statement for the period, to the sen.

8. Gate a B2B portal at the sales order, not with the spending limit

The Spending Limit rule in CP Commerce Admin was built to raise an alert after an order, not to stop one. Today it does neither: the job that would send the alert is not started by anything, so a corporate buyer’s order goes through whatever the rule says.

Two controls do refuse an order.

The portal’s own credit gate, at checkout. On a website with Restrict View/Access by Entity on, when a client’s basket is within their available credit, checkout places the order on account: the cart becomes a FINAL sales order with no gateway and no payment. Above it, checkout sends the client to the gateway, or refuses with “Your Credit Limit has been exceeded.” when the client has chosen no way to pay. The available credit is worked out by the server from the client’s smallest active credit limit in the cart’s currency, for the company that owns the website’s branch. A client with no limit in that currency has none, so every order they place goes to the gateway or is refused. The check runs in the client’s browser, a screen-level control by design, so an order created through the API is not measured by it.
The credit check on the Sales Order screen. With the applet’s credit-limit setting on, pressing FINAL refuses an order once the customer’s available credit in that company is used up. The refusal message names the available limit. It measures only documents finalised on that screen, so it never sees an order the portal placed itself, whether paid at the gateway or on account.

So the credit controller chooses how GSD’s corporate clients buy on credit, and the choice is theirs:

Way	What it gives	What it costs
Let the portal place orders on account up to each limit	Clients order at any hour; nobody keys anything	The order is FINAL before anyone at `GSD` sees it, and the limit is only as good as the one on the customer record
Have staff raise the orders from the carts	Every order passes a person and, with the setting on, the Sales Order screen’s check	Slower; staff time per order; a client who checks out on the portal still meets the portal’s own gate, on account within their limit

Either way:

Link each client’s account on the website’s Account tab, so that only those clients can see the portal.
For the staff way, have the carts finalised by staff and raised into sales orders from the Search Shopping Cart tab.
To limit who may finalise, turn on the Sales Order applet’s setting that hides FINAL, and grant the permission that shows it again only to the people allowed to commit stock and credit. This is a screen control by design: it decides who presses the button, not what the server accepts.
Who and when: the credit controller sets each client’s limit, in the cart’s currency, before the client is given a login. The sales administrator raises the orders for the staff way.
How you know it held: a test client with a known limit and nothing owing checks out a basket under the limit, which is placed on account, and then signs in afresh and tries one over it, which goes to the gateway or is refused. An order above the limit finalised on the Sales Order screen is refused with the available-limit message.

9. Do not promise third-party sellers a seller-order queue until a test order produces one

The Seller Applet shows a seller the seller orders allocated from your sales-order lines. In this version of the platform, the first of the three steps that allocate them, the one that queues a finalised sales order for allocation, is not among the jobs a schedule can run. The next step reads a different queue, which is otherwise filled only through the API. So a sales order on its own produces no seller order.

Before any seller depends on the applet, place a test order for one of that seller’s items and see whether a seller order appears. If none does, settle with the seller from your own records: list the period’s sales-order lines for that seller’s items and compare them with the seller’s purchase invoice before you pay it. Set every seller item’s financial-item link as well, because the allocation finds the seller through it.

Who and when: whoever approves sellers’ purchase invoices, before each payment.
How you know it held: at month-end, the seller’s sold lines for the period equal the lines their purchase invoices covered, and the difference is a known amount still owed.

10. Remember which build of the order applet the desk is using

The Tiktok Sales Order Applet shows the same orders as Sales Order (Internal) with fewer menus and no settings screens. A tenant that installs it expecting the order applet’s defaults, printables and custom statuses gets none of them. That includes the hide-FINAL setting and the credit check setting from §8, which that build reads but gives you nowhere to switch on. Install Sales Order (Internal) for the sales desk; the marketplace build is for a desk that only pulls and packs.

Who and when: the administrator who installs applets, when the desk is set up.
How you know it held: the sales desk’s applet has a Settings menu.

11. How you know the practices are holding

Check	How	What it catches
Orders	Each seller centre’s count against the branch’s sales orders, and no draft or unnumbered order on the branch (§6)	A stopped or gapped feed; an order waiting for a person
Paid storefront orders	Each payment in the gateway’s report against a FINAL sales order carrying its merchant reference on a settlement line, and the day’s settlement lines against the settlement item’s cashbook (§3)	A success BigLedger was never told about; a settlement line the cashbook job did not post
Shop availability against your figure	For three items on a Lazada or Shopee shop: the balance at the ticked locations, less what the held-back check shows, then the buffer (`BUFFER` subtracts; `PERCENTAGE` multiplies) — against the item’s Balance on its Stock Availability tab and against the shop	Your arithmetic and Balance agree but the shop differs: the shop refused an update. Your arithmetic and Balance disagree: the stock configuration
Gateway money	The clearing or bank cashbook against the gateway’s statement after the fee journal (§7)	An unbooked fee or a payout not yet moved
Marketplace payouts	The shop’s settlement report against the marketplace cashbook (Reconciling Marketplace Payouts)	Unbooked fees, a clawed-back refund, a held order, a payout job that did not run

Where the figures on this page come from

A shop’s Balance on the item’s Stock Availability tab is a snapshot. It is stored when the figure is recalculated, before it is sent to the shop, and it is not a live figure. If the shop refused the update, the Balance and the shop disagree until the next recalculation.
A storefront payment’s settlement line carries the amount on the payment record, taken from the checkout’s payment request. The line and its sales order are dated at the moment the cart was converted, not when the shopper started the checkout.
The gateway fee is computed on the monthly merchant report, from the rate cards as they stand at the time the report is run. No ledger figure carries it until someone journals it.
A Shopee payout voucher is the net payout, one line, on the cashbook named in the payout job’s own schedule, not the branch’s Settlement sub-tab (Core Concepts §4).

When it goes wrong

What you see	Why	What to do
A FINAL cart never appears on the Sales Order’s Search Shopping Cart tab	No Shopping Cart → Sales Order knock-off row (§1)	Add the row, then raise the order from the cart
An invoice’s knock-off tab cannot find a marketplace order	No Sales Order → Sales Invoice row (§1)	Add the row, then repair the orders finalised before it as Sales Order (Internal) troubleshooting describes
Two shops sold the last unit	The buffer is smaller than one order-job interval’s sales, or a percentage near the end of stock (§2)	Raise the quantity buffer before the next campaign
A shopper paid and there is still only a cart	BigLedger was not told the payment succeeded, or an iPay88 payment is still pending (§3)	Compare with the gateway’s report; a pending iPay88 payment converts when the status enquiry picks it up
A paid storefront order’s money is not in the cashbook	The cashbook posting job does not follow the order’s FINAL on your tenant (§3)	Ask BigLedger support which follow-on jobs run after FINAL
A storefront payment is in the cashbook twice	A receipt voucher was keyed for money the order’s settlement line already carries (§3)	Reverse one of the two, in the way your accountant settles these invoices (Q-1341)
Checkout charges a fee your rules should not allow	A Single Line rule, a date range, a negated region or an inactive set (§4)	Rebuild the rule as the storefront reads it, and test on the website
A branch’s order count falls to zero while the shop is busy	The feed stopped. The connection’s Remarks may read Failed to refresh credentials (§6)	Re-authorise the shop, then widen the order job’s interval once
Card takings never match the bank	The gateway fee has not been journalled (§7)	Post the fee journal under the treatment finance chose
A corporate client ordered past their limit	The order passed neither check: it was created through the API, or finalised on a screen without the credit-limit setting on (§8)	Find the path the order came by, and close it
A seller says they see no orders	No seller order has been allocated (§9)	Settle from your sales-order lines

How these practices connect to the rest of BigLedger

What must exist first. The company’s Knock Off Configuration rows (§1), a branch per shop with its connection and its Ecomsync Management pulls (§5), a listing for each item, and the order, payout and stock jobs on the Scheduler.
What becomes possible. Once the sales orders are complete and counted, the document your month-end uses for marketplace sales can be raised from them in Sales. That document posts the journal and moves the stock.
When to use which. Use the buffer rather than a stock reservation for a margin against overselling (§2). Use a credit check, the portal’s own at checkout or the Sales Order screen’s, rather than the Spending Limit rule to gate a corporate buyer (§8).
What breaks elsewhere. A missing Sales Order → Sales Invoice row makes the branch’s available stock ignore every marketplace order (§1). A storefront payment confirmed after month-end, such as a pending iPay88 payment the status enquiry picks up later, dates its order in the next month. The date on whatever document carries the month’s marketplace sales decides which month’s consolidated e-invoice takes it: the consolidated run picks up only documents dated before the 1st of the current month, Malaysia time (Consolidated E-Invoice).
What it is used together with. Running an Online Channel is the channel manager’s side of the same work, and Reconciling Marketplace Payouts is finance’s.