> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Days Since Last Payout, JD.com > Days Since Last Payout for JD.com stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Marketplace](/nerve-centre/connectors#connectors-by-type) ## At a glance > **Days Since Last Payout** is a simple cash-flow watchdog: how many days have passed since JD last settled money into your account. JD pays POP marketplace sellers on a settlement cycle, and a healthy store sees that clock reset regularly. When the counter climbs past the normal cycle, it is an early warning of a held settlement, an account-standing flag, a banking or compliance hold, or simply a cycle that has stalled. For finance it is the difference between assuming cash is on the way and discovering a freeze a week too late. It sits in the Economics family and reads best beside the pending-payouts, oldest-pending-payout, and net-revenue cards below. | | | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | The number of days elapsed since the merchant last received a JD settlement payout, counted to the present. | | **Sample type** | Backend API data from JD.com, refreshed on the standard data refresh. | | **Why it matters** | A payout clock that runs longer than the normal settlement cycle is the earliest sign of a held or stalled settlement, an account-standing issue, or a banking hold. Catching it early protects cash flow and gives time to resolve the cause before it compounds. | | **Reading the value** | Read it against your normal settlement cycle. A value at or below the cycle length is healthy; a value climbing past it, especially past the 7-day alert, signals a payout that has not landed when expected. | | **Currency** | count | | **Time window** | `RT` | | **Alert trigger** | `>7d` | | **Sentiment key** | `jd_payout_age` | | **Roles** | owner, finance | ## Calculation The date of the most recent settled JD payout subtracted from the current date, in whole days. The clock resets to zero each time a new payout settles. Pending or scheduled payouts that have not yet landed do not reset the counter, so the value reflects actual cash received, not promised cash. It is a real-time read, recomputed on every refresh. ## Worked example *A representative reading of **Days Since Last Payout** for a typical merchant on JD.com.* Suppose your settlements normally land every 5 to 7 days, so the counter usually sits between 0 and 6. This week it reads 9 and the alert has tripped. Cross-referencing the pending-payouts card shows a sizeable balance accrued and ready, which rules out "no sales to settle" and points to a held or delayed settlement. The likely causes narrow to an account-standing flag, a bank-detail mismatch, or a compliance review. The action is to check JD Seller Centre's settlement and account-health pages immediately, confirm bank details, and open a ticket if the hold is not self-explanatory, rather than waiting for the next cycle and losing another week. For deeper investigation, use Vortex Mind to correlate the payout gap with account-standing events; for natural-language exploration, ask Ask Viq "has my JD payout cycle slipped past its normal cadence". ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | [`jdc_payouts_pending`](/nerve-centre/kpi-cards/jd-com/pending-payouts) | Economics sibling: the balance waiting to settle, which the payout clock should be clearing. | | [`jdc_payout_age_days`](/nerve-centre/kpi-cards/jd-com/oldest-pending-payout) | Economics sibling: how long the oldest specific payout has been pending. | | [`jdc_net_revenue`](/nerve-centre/kpi-cards/jd-com/net-revenue-after-jd-commission) | Revenue sibling: the net revenue that ultimately feeds settlements. | | [`jdc_fee_total`](/nerve-centre/kpi-cards/jd-com/marketplace-fees-paid) | Economics sibling: fees deducted before settlement. | | [`jdc_revenue_at_risk`](/nerve-centre/kpi-cards/jd-com/revenue-at-risk) | Economics sibling: revenue exposure that a held payout can compound. | ## Reconciling against the vendor's own dashboard **Where to look in JD.com's own dashboard:** JD's Seller Centre settlement and bill views list each payout with its settlement date. The most recent settled date there should match the reset point this card counts from. The account-health page is where a hold or standing flag would explain a stalled counter. **Why the Vortex IQ value may legitimately differ:** | Reason | Direction | What to do | | -------------------------------------------------------------------------------------------------------------------------------- | --------- | ------------------------------------------------------------ | | **Settled vs scheduled.** Vortex IQ counts from the last settled payout; a scheduled-but-unpaid payout does not reset the clock. | Variable | Confirm the payout has actually settled, not just scheduled. | | **Time zone.** The day count uses China Standard Time; confirm your reporting profile aligns. | Marginal | Confirm time zone match. | | **Refresh lag.** A payout that settled minutes ago may not have synced; the counter resets on the next refresh. | Marginal | Force a manual refresh after an expected settlement. | | **Banking transit.** JD may mark a payout settled before it clears your bank; the clock follows JD's settled date. | Marginal | Allow for bank transit time separately. | **Cross-connector reconciliation:** read with the pending-payouts card to tell apart "nothing to settle" from "settlement is held". For divergence investigations, use Vortex Mind. ## Known limitations / merchant FAQs **Q: How often does Days Since Last Payout update?** It is a real-time read, recomputed on every refresh (typically every 30-60 minutes for live integrations). When a payout settles, the counter resets to zero on the next refresh. For an immediate reset after an expected settlement, force a manual refresh. **Q: Why does my JD.com dashboard show a different number?** The usual causes are the settled-versus-scheduled distinction (only a settled payout resets the clock), time-zone alignment, and refresh lag right after a settlement. Match those before assuming a real divergence. **Q: The counter is high but I have pending payouts ready. What does that mean?** That combination, a high clock plus a healthy pending balance, points to a held or stalled settlement rather than a lack of sales. Check JD's account-health and settlement pages for a standing flag or bank-detail issue, and open a ticket if needed. **Q: Can I customise the alert threshold?** Yes, the day threshold (default 7) is configurable per profile in the Sensitivity tab. Set it just above your normal settlement cycle so the alert fires only when a payout is genuinely overdue rather than on routine timing. *** ### Tracked live in Vortex IQ Nerve Centre *Days Since Last Payout* is one of hundreds of KPI pulses Vortex IQ tracks across JD.com and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.