Reports

Where did this figure come from? Nothing on the screen says — and for an online channel the figure sits in one of four applets, none of them in this module’s own folder. The order figures are in the sales-order applets, the marketplace views are the EcomSync screens inside Sales Order and Doc Item Maintenance, the merchant report is in Merchant Admin, and the shop’s stock figure is on the item. This page says, for each figure, whether it is stored or worked out when you open it, what it was worked out from, how it lines up with Sales, Inventory and the ledger, what makes the two disagree, and who checks it. The previous version of this page listed four reports by name — an Omnichannel Sales Channel Performance Summary, a Shopping Cart Abandonment Log, a Payment Gateway Settlement & Fee Reconciliation, a Catalog Search & Item Velocity Report — none of which exists in any applet.

Two of these figures are photographs; the rest are taken when you look. The shop’s Balance is written on the listing when the stock job or Calculate Stock last ran, and the merchant monthly report is written when its job runs. Everything else here is a fresh read of the sales orders, invoices and queue rows at the moment you open the screen. So a shop figure or a merchant figure can be stale; an order or sales figure can only be wrong about which documents it counts.

Where each figure comes from

Figure	Seen in	Stored or worked out	From what	What makes it differ from what you expected
Orders and their value	SO Detailed Report, in Sales Order (Internal) and the marketplace build	Worked out when you press Generate	Sales orders dated in the range, 500 at most, with their lines and the invoice linked to each line	It counts every order dated in the range whatever its posting status — a draft and a voided order are rows beside the FINAL ones. The End Date box is replaced with today when you press Generate, whatever you typed, so the range always runs to now. And the Outstanding Qty and Outstanding Amount columns show the quantity and amount already invoiced — the same figures as PO Qty and PO Amount — so a line with no invoice yet is blank and a fully invoiced line shows its whole quantity as outstanding. Read those two columns as “invoiced so far”, and take what is still owed from the next row
What is still to invoice	SO Line with SI KO, Sales Order (Internal) only	Stored	One open-queue row per order line, written when the order went FINAL, reduced as each invoice knocks it off, deleted at zero	The row exists only where the company’s Knock Off Configuration has the Sales Order → Sales Invoice pair; without it the listing is empty for every order, which is why it is not the place to count what you owe online buyers (F-1256). Close ends the row without any invoice. A voided invoice puts the quantity back
Online sales	Sales Report, filtered to the storefront branch and the marketplace branches	Worked out when you run it	FINAL cash bills, sales invoices and returns dated in the range, each multiplied by its amount signum; the cost columns from the cost stored on each line at the basis you choose, moving average unless you change it	The sales order is not in it — only the invoice. A back-dated goods receipt rewrites the stored line cost, so last month’s gross profit can change this month. A marketplace order line carries the channel’s discounted price, with the discount written as zero and the currency as MYR, so a platform-funded voucher leaves no trace and the report can never show list price less discount
Orders, cancellations and sales per day	Ecomsync → Dashboard, Lazada Dashboard and Shopee Dashboard tabs in Sales Order (Internal)	Worked out in your browser each time the tab opens	That marketplace’s sales orders already in BigLedger, taken by the date BigLedger created them, counted back from midnight 30 days (or 7)	The date is the run that brought the order in, not the day the buyer ordered, so a feed that stopped and caught up shows a spike. Total Sales adds a marketplace order price stored with each order, and the order jobs at the current backend do not store one, so the orders they bring in add nothing to it. Take marketplace revenue from the orders or the invoices, filtered to the branch
The shop’s stock figure	The item’s Stock Availability tab in Doc Item Maintenance, Balance column	Stored on the listing, each time it is worked out	The stock balance at the branches the marketplace branch is set to read, less the open quantity of the counted channel orders, less a buffer or times a percentage, never below zero — written by the stock job or by Calculate Stock	The listing keeps the last figure until the next run, so the column lags the warehouse by one push. The deduction takes whole orders, every line of them, and only orders whose marketplace status is on a fixed list, so a cancelled Shopee order goes on holding stock back and most Lazada orders hold nothing back (why). Only a Lazada or Shopee shop is sent the figure. The Stock Availability applet shows the item by location and knows nothing of buffers or shops
Whether a price reached the shop	Marketplace → Checking on the item: No Pricing, Syncing, Synced; the same three lists per branch under Organisation → Branch → Marketplace → Pricing Scheme	Worked out when the tab opens	No Pricing: the item’s price rows against the branch’s default scheme. Syncing: queue rows written whenever a price row is saved or a branch’s default scheme is changed. Synced: the history row the price-push job writes after a successful send	Syncing drains only when the price-push job (`ECOMSYNC_PRICING_SCHEME_QUEUE_PROCESSOR`) runs. It is a registered job that no other job starts, and its code is not among the ones the Doc Item Scheduler screen offers, so it has to be given a row in the Scheduler applet. Until it is, every price change waits in Syncing and Synced stays empty — and a shop whose price was pushed another way still shows the right price while this list says it is waiting. The job sends to Shopee and Lazada basic and grouped listings only
What a payment channel cost	Merchant Admin → Report	Stored, one row per merchant per payment channel per month, written when `PGW_MERCHANT_MONTHLY_REPORT_PROCESSOR` runs	Every payment-gateway transaction record for that merchant code and channel code dated in the month — the count, and the sum of the gateway’s response amount — and the charge columns from the rate cards and contract rates as they stand when the job runs	The job runs for the previous calendar month unless its schedule names months and years. It reads no response status, so a payment the gateway declined but answered with an amount is counted. Each run adds rows; run twice for a month and the listing shows that month twice. Change a rate card and the month already written keeps the old rates. The applet has no button to run it. No journal is written from it

How these figures line up with Sales, Inventory and the ledger

An online order is an ordinary sales order from the moment it lands — numbered and FINAL for a marketplace, converted from the cart for the storefront — and it posts nothing and moves no stock. That one design decision explains the whole table above: there is no e-commerce ledger report because nothing in this module posts, and the figures the module adds are all about documents before the invoice. A reader who expects a webstore to have its own books is looking in the wrong module.

The chain, and which figure reads which link of it:

The order arrives. It is a row in SO Detailed Report and the dashboards, and its open quantity lowers the shop’s Balance on the next push. Nothing else has happened. The seller centre and BigLedger agree on the order count, if the feed is running.
The sales invoice goes FINAL. This is the first document in the online chain that touches anything outside Sales: stock leaves (quantity signum −1), the journal posts receivable, sales and tax, the cost of the line is stored on the invoice line, and the order’s open-queue row falls. From here the order is in Sales Report and the invoice is in the Sales account of the ledger. The two agree document for document; what checks it is the Stock Flow Report (Inventory › Reports), which compares sales-document amounts with the journal lines on the Sales account.
Month end. No sale posts cost of sales; Month End Processing writes it from the stock ledger. A margin read from Sales Report before the close is the stored line cost; a margin read from the Profit and Loss after it is the period’s cost-of-sales journal. They are not the same number and are not meant to be (the margin report and the P&L).
The money. A storefront payment becomes a receipt voucher through a job, one per payment. A Shopee payout becomes one receipt voucher for the net amount, matched to no invoice. A gateway’s fee is priced on the merchant monthly report and posted by nobody. So the receivable on the marketplace branch stays open until a person books the settlement report (Reconciling Marketplace Payouts), and the fee reaches the ledger only through a journal finance writes.

Where these figures sit

Three things must exist before any of them means anything: a marketplace branch per shop (Organisation → Branch → Marketplace), because every filter above is a branch filter; the company’s Sales Order → Sales Invoice knock-off pair, because without it the open-queue figure is never written and SO Line with SI KO is empty for every order; and a schedule row for each job that writes a stored figure — the stock push, the price push, the merchant report — because none of them runs on its own. Once those exist, the invoice lets you read online sales beside counter sales in one Sales Report, and the open queue lets availability and the shop’s figure see the orders you still owe. When two figures overlap, use the stored one (SO Line with SI KO, the shop’s Balance) for what the system is acting on, and the live one (SO Detailed Report, the Stock Availability applet) instead of it for what the documents say now. What breaks when the upstream is wrong is never local: a missing knock-off pair empties the listing and stops availability seeing the orders, and a stale Balance oversells on the shop. In practice each figure is read alongside something from outside BigLedger — the settlement report together with the marketplace cashbook, the gateway’s statement with the merchant report, the seller centre’s order list with the branch’s orders — and the comparison, not the figure, is the control.

Pairs that will not agree, and why

Pair	Why they differ	Which to trust for what
The seller centre’s sales for a month and Sales Report for the marketplace branch	The seller centre counts orders; Sales Report counts invoices. Orders not yet invoiced, orders cancelled after arrival (a Shopee or Lazada cancellation changes the order’s channel status and leaves it FINAL), returns the platform processed (no job brings a return in), and platform-funded vouchers all sit in the gap	The seller centre for what buyers bought; Sales Report for what you have recognised as sales
SO Detailed Report and SO Line with SI KO for the same orders	The report works outstanding out from the invoice links each time, and then shows the invoiced figure under the outstanding heading; the listing shows a stored open-queue row, which exists only with the knock-off pair configured and which Close can end without an invoice	SO Line with SI KO for what is still open, where the pair is configured; the seller centres’ open-order lists otherwise. Read SO Detailed Report for the orders themselves
The shop’s Balance and the Stock Availability applet	A stored figure from the last push, net of a buffer and of whole channel orders, against a live figure per location net of every open document	The applet for what is on the shelf; the Balance for what the shop was last told
The dashboard’s Total Sales and anything	It adds a stored order price that the current order jobs do not write	Neither; the orders on the branch
The merchant report’s charges and the gateway’s statement	The report prices the month from your rate cards at the moment it ran, over every transaction record dated in the month; the statement is what the gateway charged	The statement for what you paid; the report for whether the rate card still matches the contract
Sales Report and the Sales account on the Trial Balance	Same documents, two makers: the report sums document lines, the account sums journal lines, and a document can be FINAL with no journal	The Stock Flow Report names the documents in the gap; Trace Document says why (Financial Report applet)

Why it is built this way

A marketplace order is a document nobody in your office keyed — it arrived, numbered and final, from a system that remains the system of record for the order’s own life: payment, packing, shipping, cancellation and return all happen in the seller centre. BigLedger’s part is the ledger side — the invoice, the stock, the receivable and the tax — and so its reports are the ordinary sales reports with a branch filter, not a copy of the seller centre’s. The alternative, a second order lifecycle kept in step by sync, would be wrong every time the two disagreed and would still not be the one the platform pays you on. The cost of the design is the gap in the first row of the table above, and the gap is somebody’s job to explain each month.

When a number is wrong

What you see	The usual cause	Check first	What to do
SO Detailed Report shows more orders than the seller centre	Draft or voided orders in the range, or the range reaching to today	The order listing for the branch with a posting-status filter	Count FINAL orders in the listing, not the report
Outstanding Qty on SO Detailed Report is full on an order you invoiced in full	The column shows the invoiced quantity	SO Line with SI KO for the order	Use the listing; treat the report’s column as “invoiced so far”
SO Line with SI KO is empty for every online order	The company has no Sales Order → Sales Invoice row in Knock Off Configuration	Organisation → Company → Knock Off Configuration	Add the row; it takes effect for orders finalised after it. Until then, the seller centres’ open-order lists are the count
Sales Report for the marketplace branch is lower than the seller centre	Orders not invoiced yet, cancelled orders still FINAL as orders, returns and vouchers	Open orders on the branch, then the platform’s cancelled and returned lists for the month	Invoice what is shipped; raise the credit notes the platform’s returns need; book vouchers the way Running an Online Channel describes
The dashboard’s Total Sales reads 0	Expected with the current order jobs	—	Read sales from the orders or Sales Report by branch
The shop shows less stock than the warehouse has	The buffer, then whole orders being deducted, then a push that has not run	The item’s Stock Availability tab: Balance, Sales Order, buffer columns	Calculate Stock; then the held-back check in Running an Online Channel, Step 2
A price change sits in Syncing for days, Synced stays empty	The price-push job has no schedule row	Scheduler applet, a row for `ECOMSYNC_PRICING_SCHEME_QUEUE_PROCESSOR`	Schedule it; then check the shop itself, because a price may have reached it another way
Merchant Admin → Report is empty	The job has not been run for that month	The Scheduler applet	Schedule `PGW_MERCHANT_MONTHLY_REPORT_PROCESSOR`, or ask BigLedger to run it for the months you need, once per month
A month appears twice in the merchant report	The job ran twice for it	The rows’ created dates	Read one set; ask BigLedger to remove the other
The merchant report’s fee differs from the gateway’s statement	Rate cards out of date when the month ran, or declined transactions counted	The rate card against your contract; the gateway’s statement	Correct the rate card for next month; book the fee from the statement

Who checks which figure, and when

None of these figures checks itself, and most of the disagreements above are found by a person comparing two of them on a schedule. The jobs that remain yours:

Every morning, the channel manager compares yesterday’s order count in each seller centre with the orders on that marketplace branch. A gap is a feed that stopped, and nothing in BigLedger will say so (Step 8). Right looks like: the two counts agree, or every difference is an order the platform cancelled before the feed ran.
Before every campaign, the online team presses Calculate Stock on the items going on sale and runs the held-back check, because the Balance column is only as fresh as the last push.
Once per settlement report, the accounts clerk books it; on the last day of the month they compare the marketplace cashbook with the seller centre’s balance still to be paid (Step 4). The finance manager, who did not book the vouchers, signs the comparison.
Monthly, finance journals the gateway fee per channel from the gateway’s own statement, using the merchant report to see whether the rate card still matches the contract, and judges each channel on contribution after its costs (Step 9).
After every price change, whoever changed it opens the item’s Checking tab the next day. If the row is still in Syncing, the push job is not running; if the shop already shows the new price, the list is behind, not the shop.

How you know the figures agree: a one-minute check

Pick one marketplace branch and yesterday’s date.

Count yesterday’s orders in the seller centre.
Open the sales-order listing for the branch, filter to yesterday and FINAL, and count. The two should match. If SO Detailed Report for the same day shows more, the extra rows are drafts or voids.
Open SO Line with SI KO and filter to the branch. Every uninvoiced order from step 2 should be there. If the listing is empty for all of them, the knock-off pair is missing.
Open Sales Report › SR By Document for the branch and yesterday. The total should equal the invoices raised yesterday — not the orders.

Four figures, three agreements, and the one that fails tells you which link of the chain to read.

GadgetSphere Online’s September. The Shopee seller centre shows RM 184,300 sold. Sales Report for branch GSO-SHOPEE shows RM 171,900, the dashboard’s Total Sales shows RM 0, and SO Detailed Report lists 2,140 orders where the seller centre has 2,085. The RM 12,400 gap is 61 orders shipped on the 29th and 30th and not yet invoiced (RM 9,100, all on SO Line with SI KO), 14 orders the buyer cancelled after they arrived, still FINAL sales orders and never invoiced (RM 2,300), and RM 1,000 of platform-funded vouchers that the order prices already net off. The 55 extra orders on the report are drafts from a half-finished import test and the cancellations. Nothing is wrong; every number was made from a different set of documents, and the month closes with the list of 61 written down.

Which report answers which question

Question	Report
How much did we sell online last month?	Sales Report, filtered to the `GSO` storefront branch and the marketplace branches — invoiced sales only
Which online orders are still owed to buyers?	SO Line with SI KO where the company has the Sales Order → Sales Invoice knock-off pair; otherwise each seller centre’s own list of open orders, read by the channel manager
What did each marketplace order?	SO Detailed Report by marketplace branch, reading its outstanding columns as invoiced-so-far, or the sales-order listing with a posting-status filter
Why is the shop showing the wrong stock?	The item’s Stock Availability tab, then Calculate Stock, then the held-back check
Why is the shop showing the wrong price?	The item’s Marketplace → Checking tab, remembering that it tracks one push path and may say Syncing about a price the shop already has
What did the gateway charge us?	The gateway’s own statement. The merchant monthly report prices the month from your rate cards and is the check on the rate card, not on the gateway

What has no report, and who does the job instead

Cart abandonment. Carts are INTERNAL_SHOPPING_CART rows; a cart that never reached FINAL or checkout is a DRAFT in the Shopping Cart (Internal) listing, and that listing is the nearest thing to an abandonment view. No job counts, ages or e-mails them. The storefront owner reads the DRAFT list by date when they want the number.
Channel performance across storefront and marketplaces. Sales Report by branch gives gross sales per channel; contribution after the platform’s fees is possible only if the fees are booked separately — Running an Online Channel, Step 9. Finance builds it, monthly or quarterly, from the fee accounts.
Gateway settlement reconciliation — gross charged, fees, net paid out against the bank. The payment transaction records the gateway’s charge lines and the receipt voucher records the money; the only place the two meet the bank statement is Bank Reconciliation, which is a manual match the accounts clerk does.
Catalogue search, page views, add-to-cart rates. The storefront records ratings, reviews and comments per post; it records no search or view analytics that any applet reports. The web team reads them from the analytics tool on the storefront’s pages.
Payout reconciliation per marketplace. Where a payout job runs it creates a net receipt voucher; no listing puts a shop’s settlement report beside it. The month-end comparison that takes its place is Reconciling Marketplace Payouts, Step 4, and it is the accounts clerk’s, every month.