Headline gross revenue. The single number the founder checks at 9am Monday.
At a glance
Headline gross revenue across all Shopline orders in the period. Sum of every order’s total field from the Shopline Orders API, before fees, gross of refunds, in the merchant’s primary store currency. The number the founder checks at 9am Monday before opening the Shopline admin.
| What it counts | SUM(order.total) across orders with created_at in the selected window, pulled from Shopline’s Order endpoint. Each order’s total contains item subtotal, shipping, taxes, discounts (already deducted), and any platform service fees the merchant has chosen to pass through to buyers. |
| API endpoint | GET /v1/orders on the merchant’s Shopline domain ({shop}.shoplineapp.com/api). JWT-authenticated; tokens are long-lived (often 1 to 2 years) but can expire silently. |
| VAT / tax treatment | Depends on the store’s regional setting. APAC stores (HK, TW, SG, MY) typically have prices_include_tax = true (consumer-side prices include GST/VAT/sales tax); JP stores follow the same convention. Mainland CN stores typically run tax-exclusive. Read the field once on the store-info call rather than guessing. |
| Shipping | Included. order.total already contains shipping_total. |
| Discounts | Already deducted. Promo codes, Shopline-native flash sales, and member-tier discounts are all reflected in order.total. |
| Refunds | NOT deducted. A fully refunded HK 800 to this number. For the netted view use refund-rate plus refund-value cards. |
| Cancelled orders | Excluded. Orders with status = cancelled are filtered out by the engine, regardless of payment status. |
| Partial-paid orders | Included. Shopline supports deposit-then-balance flows (common for furniture and pre-orders); the partial total is counted as revenue once the order moves to paid or partially_paid. See shopline_partial_paid for the count of orders sitting in this state. |
| Currency | Single currency per store, but Shopline is heavily multi-region. A merchant running stores in HK and TW will have two Shopline connections, each in its native currency (HKD and TWD). The card runs per-store; cross-store consolidation is a separate roll-up. |
| APAC payment methods | The total is method-agnostic. Alipay, WeChat Pay, JKO Pay, FPS, and credit card all contribute equally; the breakdown is in shopline_payment_methods. |
| Time window | 30D vsP (default 30D vs the prior 30D). |
| Alert trigger | drop >15% vsP. Driven by sentiment_key: revenue_trend. |
| Roles | owner, finance, marketing. |
Calculation
Calculated automatically from your Shopline data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
An APAC fashion brand running a Hong Kong Shopline store, week of 21 Apr 26 to 27 Apr 26. The brand sells womenswear, runs HKD as primary currency, accepts FPS, Alipay HK, WeChat Pay HK, and credit cards via Stripe. They have 1,200 SKUs, ship within HK same-day for orders before 3pm.| Metric | This week (21 Apr 26) | Prior week (14 Apr 26) | Change |
|---|---|---|---|
| Orders | 184 | 162 | +13.6% |
| Total Revenue (this card) | HK$ 142,800 | HK$ 124,500 | +14.7% |
| Refund Value | HK$ 8,420 | HK$ 11,200 | n/a |
| Discount applied | HK$ 17,300 | HK$ 14,800 | n/a |
| Net of refunds | HK$ 134,380 | HK$ 113,300 | +18.6% |
shopline_alert_revenue_drop anomaly card.
The cross-channel readings worth pairing: at HK 620k / month) Shopline DTC, with no Amazon connector live, this is the merchant’s single largest channel. Layer 2 (Amazon, eBay) integration would change this picture; today it is the headline number that owns Monday morning.
Sibling cards merchants should reference together
Total Revenue is the headline number; on a region-rich platform like Shopline it is rarely useful in isolation. Pair it with these:| Card | Why it matters next to Total Revenue | What the combination tells you |
|---|---|---|
| Total Orders | The denominator behind AOV. | Revenue up + orders flat = bigger basket; revenue up + orders up = real demand growth. |
| Average Order Value | Revenue per order. | AOV trends drive most revenue movements; check before assuming the lift is “more buyers”. |
| Refund Rate | The quality canary. | Revenue up + refund rate up = artificial lift; the lift is being clawed back later. |
| Revenue Over Time | The 90D shape. | Lets you see whether this period is on-pattern or a real break. |
| Payment Methods | The APAC payment-mix view. | Sudden revenue drop with FPS share dropping = FPS gateway issue; with credit-card share dropping = Stripe outage. |
| Discount % of Revenue | Discount leakage. | Revenue up + discount % up sharply = the lift was bought with promo, not earned. |
| Cross-Channel: Marketplace Revenue Share (Amazon) | The portfolio view. | If connected, lets you see whether Shopline DTC is growing in absolute or only in share. |
| Shopline Health Score | Composite operational health. | A revenue rise alongside a falling health score is the warning that other things are breaking under the surface. |
Reconciling against the vendor’s own dashboard
Where to look in Shopline’s own dashboard: The closest Shopline-native view is:
Shopline Admin ({shop}.shoplineapp.com/admin) -> Reports -> Sales report
Filter by date range; the “Total Sales” tile is the apples-to-apples comparison.
For a quick sanity check, the Admin home dashboard tile “30-day sales” should land within ~1% of our 30D figure for a single-store account.
Why our number may legitimately differ from Shopline’s Admin:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Shopline’s report uses the store’s configured time zone (Asia/Hong_Kong, Asia/Taipei, etc); we use UTC. The boundary effect on a 30D window is small but on “today” or “yesterday” it can shift the number meaningfully, especially for HK and TW stores 7 to 8 hours ahead of UTC. |
| Cancelled orders | Theirs higher in some views | Shopline’s Sales Report can include cancelled orders if the merchant has not toggled the exclusion; we always exclude them. |
| Refunds | Theirs lower in netted view | Shopline’s “Net Sales” mode subtracts refunds; this card is gross. Compare against the “Gross Sales” toggle. |
| Multi-store consolidation | Either | A merchant running parallel Shopline stores in HK + TW + SG will see each store’s number per-connector. Shopline does not provide a cross-store admin roll-up; we run the cards per-store. |
| Sync lag | Ours lower for “today” | Our index polls GET /v1/orders every 5 minutes; the most recent ~5 min of orders may not be in. Yesterday and earlier are caught up. |
| Service fees | Either | Shopline charges a small platform fee on certain APAC payment methods (FPS small-merchant tier, Alipay HK overseas tier). Shopline reports gross of these in “Total Sales” by default; we follow the same convention. |
| Pre-order deposits | Marginal | Pre-order with deposit-then-balance flows can show different totals depending on whether the snapshot was taken before or after balance settlement. |
shopline_total_revenue = shopline_aov x shopline_order_count
These three cards are mathematical siblings; if they disagree by more than rounding (under 0.5%), it is a sampling artefact, not a real disagreement.
Cross-connector reconciliation. If the merchant runs Amazon or other marketplaces:
Use shopline_xc_amazon_revenue_share to read the channel split. There is no order-level reconciliation possible (the same buyer cannot place the same order on Shopline and Amazon), but the portfolio view gives proportions.
Known limitations / merchant FAQs
Why does my Shopline Admin show a higher number than this card? Three usual suspects. (1) Shopline Admin defaults to gross including cancelled orders in some views; we always exclude cancelled. (2) Time zone: Shopline uses store-local (Asia/Hong_Kong, Asia/Taipei, etc), we use UTC, so the day boundary is offset by 7 to 8 hours. (3) Sync lag: our poll runs every 5 minutes. If the gap is still more than 2% after checking those, raise a sync issue. Does this include taxes? For APAC stores: yes,order.total is tax-inclusive in HK, TW, JP, SG, MY by default. For mainland CN stores: typically no, the platform default is tax-exclusive. The card sums order.total blindly; the convention follows Shopline’s regional preset. Read the store-info call to confirm if you are unsure.
My store accepts JKO Pay / Alipay HK / WeChat Pay; do those count differently?
No. Method-agnostic; every payment method contributes to order.total equally. The breakdown is in shopline_payment_methods. The card surfaces method only when there is a sudden mix-shift (e.g. FPS share dropping suddenly indicates a gateway issue).
Why is my revenue different from my settlement amount in the bank?
Settlement lags revenue. Shopline payment processors typically settle T+2 to T+7 depending on method (FPS settles next day, Alipay HK 2 days, credit card 5 to 7 days). The settlement amount is also net of processor fees, which order.total does not deduct. Use settlement reports for cash-flow planning; use this card for revenue trend.
I run two Shopline stores (HK + TW). Why do I see two separate numbers?
Because Shopline runs separate JWT credentials and separate storefronts per region. We connect each as a distinct integration to keep currency, tax, and language settings clean. To see consolidated revenue, use the multi-store roll-up view in Nerve Centre, which converts each store’s local currency to a chosen reporting currency at daily-close FX rates.
Why does Shopline charge a fee on small-merchant FPS transactions?
Below a HK$ 50,000 / month merchant tier, Shopline pays the FPS fee on the merchant’s behalf and recovers a small platform fee per transaction. Above the tier, FPS is fee-free for the merchant. The card sums what the buyer paid, not what landed in the merchant’s account; the difference appears in the platform-fee report inside Shopline Admin.
Are pre-orders included?
Yes, once the order moves to paid or partially_paid. Deposit-only pre-orders count the deposit amount until the balance is settled, at which point the full order.total is reflected. See shopline_partial_paid for orders sitting in this state.
Why do my Sundays look 2 to 3x bigger than weekdays?
APAC fashion and homeware skew heavily to Sunday DTC traffic, much more than Western markets. HK and TW shoppers concentrate browsing-then-buying on Sunday afternoons, often via mobile after lunch. A 2 to 3x Sunday spike is normal; if it disappears suddenly, your payment rails or app store binding is most likely broken.
My revenue dropped 30% this week. What should I check first?
Run this playbook in order. (1) Check shopline_alert_token_expiry, Shopline JWTs are long-lived but silent expiry is the #1 cause of “revenue went to zero”. (2) Check shopline_payment_methods for sudden mix-shift indicating a gateway outage. (3) Check shopline_inventory_alerts, if hero SKUs went OOS, demand exists but cannot convert. (4) Compare to last year’s same week; APAC has many regional holidays (Lunar New Year, Mid-Autumn, Golden Week) that move year-on-year and look like organic drops.