
I wanted to isolate one of the most important cash questions in Sellvia economics: how much money should I keep ready specifically to process new orders? I did not use a claimed platform average because the required amount changes with order volume and the processing amount attached to each order. Instead, I built a processing-capital model around the current Sellvia commission lifecycle and then stress-tested it at several order speeds.
Quick Answer
My processing-capital formula is: expected orders during the funding window Γ average cash required to process one order + a timing cushion. I do not treat Pending or Incoming commission as processing capital because those amounts are not yet Available. In a modeled case where processing requires $18 per order, five orders per day need $630 for seven days before any cushion; ten orders per day need $1,260. Those $18 examples are assumptions, not Sellvia averages.
How I tested this
I treated this as a modeled treasury test. I first checked the current Sellvia terms and current public offer to separate platform rules from assumptions. Then I varied only four inputs: orders per day, modeled processing cash per order, runway in days and safety percentage. That lets me see which variable actually drives the capital requirement.
Verified platform values: Sellvia currently lists the base subscription at $39 per month after a 14-day free trial. More importantly for this calculation, the current commission lifecycle says an order-related commission can begin as Pending, move to Incoming after the associated order is processed, remain Incoming for up to 72 hours, and then become Available subject to the platform rules. Current terms also state that commission may be allocated progressively: typically up to 75% can transition after the standard Incoming period while the remainder may stay in a validation window of up to 125 days.
Verified hands-on observations: I did not have authenticated account-level order records available to inspect during this test, so I am not claiming that I personally processed a specific order, received a payout or observed a specific processing amount today.
Modeled assumptions: every order count, $18 processing amount, safety percentage and runway below is an explicit modeling input. I use them to demonstrate the economics, not to imply a universal Sellvia result.
This distinction matters. The useful answer is not a generic statement such as ‘keep $1,000 ready.’ The useful answer is a formula that can be filled with the actual processing requirement visible on the operator’s own orders.
What I mean by processing capital
I define processing capital narrowly: cash reserved to meet the next batch of order-processing obligations before commission becomes usable. I keep it separate from the broader Sellvia working-capital calculation, which can include promotion, recurring charges and other operating commitments.
That separation made the model much clearer for me. If I mix promotion cash, subscription charges, processing cash and expected commission into one number, I can no longer tell why the cash requirement changed. With a dedicated processing-capital pool, an increase in order velocity has an obvious financial effect.
Processing capital = orders per day Γ average processing cash per order Γ runway days.
Optional conservative version: processing capital Γ (1 + safety percentage).
Why the timing gap creates a capital requirement
The key mechanic I checked is the sequence. Commission associated with an unprocessed order is Pending. After the order is processed, it moves into Incoming for verification. Current terms allow that Incoming period to last up to 72 hours. Only after the relevant conditions are met does commission move toward Available status, and progressive allocation can extend part of that path.
From a finance perspective, this means I should not assume that the same order instantly replenishes the cash I used to process it. Even when the underlying unit economics are attractive, the timing can create a temporary funding gap. That gap is exactly what processing capital is designed to cover.
I see this as a planning feature rather than a flaw in the model. Once I stop expecting every order to self-finance immediately, I can choose a runway deliberately. The same principle appears in my Sellvia cash conversion cycle analysis, but here I am narrowing the lens to new-order funding only.
Scenario 1: five modeled orders per day
For the first test I assumed five new orders per day and $18 of processing cash per order. Again, $18 is not a published Sellvia average. It is simply a clean modeling input.
| Runway | Formula | Processing capital | With 20% cushion |
|---|---|---|---|
| 3 days | 5 Γ $18 Γ 3 | $270 | $324 |
| 5 days | 5 Γ $18 Γ 5 | $450 | $540 |
| 7 days | 5 Γ $18 Γ 7 | $630 | $756 |
| 10 days | 5 Γ $18 Γ 10 | $900 | $1,080 |
What I found is simple but useful: runway matters just as much as order pace. A seven-day reserve is not inherently superior to a three-day reserve. It simply buys more time. I would choose the runway based on how conservative I want the cash plan to be and how stable the actual processing pattern has become.
Scenario 2: order volume doubles
Next I held the $18 assumption constant and doubled modeled order volume from five to ten per day. The seven-day base requirement rises from $630 to $1,260. With a 20% cushion it rises from $756 to $1,512.
This is where the processing-capital metric becomes valuable. More orders can improve the economic opportunity while also increasing the amount of cash temporarily committed to the cycle. Growth and liquidity pressure can therefore appear at the same time. I do not interpret that as bad economics by itself; I interpret it as a signal that the cash pool needs to scale with activity.
This is also why I would recalculate processing capital before increasing promotion materially. If promotion successfully increases order flow, the processing pool has to be ready for the higher pace. My first-30-days ad budget model handles the promotion side separately so I can avoid mixing the two cash buckets.
Original runway chart

Scenario 3: processing amount changes
Order count is only half the equation. I also tested what happens when the average cash needed per order changes. At eight modeled orders per day over seven days, the capital requirement is $672 at $12 per order, $1,008 at $18, $1,400 at $25 and $1,960 at $35.
| Modeled cash per order | Orders/day | 7-day base | 7-day + 20% |
|---|---|---|---|
| $12 | 8 | $672 | $806.40 |
| $18 | 8 | $1,008 | $1,209.60 |
| $25 | 8 | $1,400 | $1,680 |
| $35 | 8 | $1,960 | $2,352 |
This sensitivity test is why I would never copy another operator’s processing-capital target. Two stores can have the same order count and still need very different cash pools if the processing requirement per order differs.
How I would calculate the real number from an account
If I were managing the live account, I would not start with a guessed $18. I would take a recent sample of actual processing obligations, calculate the average and also note the high end. Then I would multiply the average by a conservative order forecast and my chosen runway.
I would use a sequence like this:
- Record the processing cash required for a representative batch of recent orders.
- Calculate the average processing cash per order.
- Calculate a second figure using a higher percentile or conservative high case.
- Estimate orders per day from recent actual activity, not a marketing target.
- Choose a runway, such as three, five or seven days.
- Add a safety percentage only after calculating the base requirement.
The advantage is that the model improves as real operating data accumulates. Early on, I would use a wider safety margin. Later, once actual order pace and processing amounts become more predictable, I can make the reserve more capital-efficient.
Why I do not subtract Pending commission
Pending commission is economically relevant, but I do not use it to fund the next order in my model. The reason is timing. Current terms say Pending commission is associated with unprocessed orders; after processing, it moves into Incoming. Counting it as if it were already usable would make the cash model depend on a state transition that has not happened yet.
I apply the same conservative logic to Incoming commission. The current terms allow an Incoming period of up to 72 hours. That is close enough to matter in a cash forecast, but not close enough for me to call it immediate processing capital.
Available commission is different, but even there I distinguish an account balance from external cash. Current terms impose redemption conditions, verification requirements and minimum redemption amounts. As of my fact-check, the published minimum is $100 for U.S. residents and $300 for residents of other countries. Because those conditions can matter, I do not automatically treat every Available dollar as same-day bank cash.
How progressive allocation changes my conservative case
The current terms also say that commission may be allocated progressively. Typically, up to 75% may transition to Available after the standard Incoming period, while the remaining portion can stay in a validation window for up to 125 days. The exact allocation can depend on account and risk factors.
For processing-capital planning, I do not need to predict the exact reserve outcome on every order. I simply avoid assuming that 100% of expected commission will replenish my cash pool immediately. That keeps the model robust even when timing varies.
I cover the broader effect of timing and reserves in Sellvia Cash Flow Explained. Here, the practical conclusion is narrower: processing capital should be sized from obligations first, not from optimistic future availability.
Processing capital versus liquidity buffer
These two numbers are related but not identical. Processing capital is the cash needed for new orders. A liquidity buffer is broader. It can include processing capital, promotion, subscriptions, optional services and a general safety reserve.
For example, if my seven-day processing requirement is $1,260, I might reserve $1,512 after a 20% processing cushion. If I also have $140 of committed promotion and a $39 subscription renewal inside the same week, my broader liquidity need is higher. That broader calculation belongs in my Sellvia liquidity buffer model.
I like keeping both metrics because they answer different questions. Processing capital tells me whether I can fund the next order cycle. Liquidity tells me whether I can fund the operating plan as a whole.
A simple processing-capital coverage ratio
I also use a ratio to make the number easier to monitor:
Processing capital coverage = cash reserved for processing Γ· modeled daily processing requirement.
If I have $1,800 reserved and the modeled daily requirement is $180, coverage is 10 days. If the daily requirement rises to $360 while the reserve stays at $1,800, coverage falls to five days. Nothing else needs to change for liquidity pressure to double.
This ratio is useful because it reacts immediately to growth. A fixed dollar reserve can look comfortable until order activity accelerates. Coverage days reveal the change faster.
Stress test: a seven-day surge
To see how quickly processing capital can tighten, I modeled a store that normally requires $180 per day for processing and holds $1,500 in its dedicated pool. At the normal pace, that is 8.3 days of coverage. If activity doubles and the daily processing requirement becomes $360, the same pool covers only 4.2 days.
If I want to preserve a seven-day runway after the surge, I need $2,520. With a 20% cushion, the target becomes $3,024. The math is straightforward, but the management implication is important: a successful increase in order activity can consume the processing buffer faster than expected.
That is why I would treat a surge as a reason to recalculate, not as a reason to panic. The underlying activity can be positive; the capital structure simply has to catch up.
What I would monitor every day during growth
I would keep the daily check short. I need only four figures: processing cash reserved, average cash required per processed order, recent orders per day and coverage days. If one of those changes materially, I rebuild the seven-day requirement.
I would also watch the commission states separately. Pending, Incoming and Available are useful operating indicators, but I do not blend them into one cash number. Keeping the states separate makes it easier to see whether a temporary gap comes from higher order activity, higher processing amounts or slower conversion into usable funds.
Common mistakes I avoid
Using one fixed dollar target forever
A fixed reserve becomes stale as order pace changes. I prefer coverage days because they scale with activity.
Assuming every order has the same processing requirement
For planning I use an average plus a conservative high case. That protects the model from a mix shift.
Counting expected commission twice
If I use expected commission to justify profitability and also subtract it from near-term cash needs before it is usable, the model becomes too optimistic.
Mixing promotion and processing cash
I keep separate buckets. That way a promotion decision cannot accidentally consume money reserved for the next order cycle.
Ignoring the timing cushion
A mathematically exact base requirement assumes the forecast is exact. Real activity varies, so I prefer an explicit cushion rather than hidden optimism.
How processing capital affects break-even thinking
Processing capital is not itself an expense in the same sense as a fee. It is a funding requirement. That distinction matters when I compare liquidity with profitability.
Suppose the modeled order economics are profitable. I may still need substantial processing capital because cash is committed before commission completes its lifecycle. Conversely, having plenty of processing cash cannot rescue weak unit economics. For the profitability side, I use the formulas in my Sellvia break-even analysis.
This separation is one of the most useful things I found in the model. Profit answers whether the activity is economically worthwhile. Processing capital answers whether I can finance the timing of that activity.
My actionable framework
If I were setting the reserve today, I would start with a seven-day base case, because it is easy to understand and conservative enough to expose a funding gap. I would calculate actual average processing cash per order, multiply it by recent daily order volume and then by seven. I would add 10-30% depending on how variable the data is.
Then I would create two thresholds. The first is a warning level at five days of coverage. The second is a hard floor at three days. Those are my management choices, not Sellvia rules. If coverage falls below the warning level, I recalculate before increasing promotion. If it approaches the hard floor, I prioritize restoring the processing pool.
As more account data becomes available, I can tighten the assumptions. The goal is not to hold the largest possible reserve. The goal is to hold enough capital to keep the next operating cycle predictable.
FAQ
How much Sellvia processing capital do I need?
There is no universal amount. I calculate orders per day Γ average processing cash per order Γ desired runway, then add a deliberate safety cushion.
Is processing capital the same as the order cost?
No. Processing capital is the pool of cash reserved to meet multiple upcoming processing obligations. The amount required for an individual order is one input into that pool.
Can I count Pending commission as processing cash?
I do not. Current Sellvia terms distinguish Pending, Incoming and Available commission. My conservative model counts only cash that is actually usable for the next obligation.
How long should the runway be?
I model three, five, seven and ten days. Seven days is a useful planning case, but the right runway depends on actual order variability and the operator’s tolerance for liquidity risk.
Does the 72-hour Incoming period mean I only need three days of capital?
Not necessarily. The terms say Incoming can last up to 72 hours, and other redemption and progressive-allocation rules can still matter. I would not set the entire reserve from that one timing figure.
What happens if orders double?
If the average processing requirement per order stays constant, the base processing-capital requirement doubles for the same runway. That is why I recalculate before scaling.
Should I include the $39 subscription in processing capital?
I do not. I put the current $39 monthly base subscription in the broader liquidity budget, not in the narrow processing-capital pool.
Final takeaway
After modeling the order cycle at several speeds, I think processing capital is one of the cleanest Sellvia metrics to manage. It converts an abstract cash-flow concern into a simple operating question: how many days of new-order processing can I fund with cash already reserved?
The answer should rise and fall with real activity. At five modeled orders per day and $18 per order, seven days requires $630 before a cushion. At ten orders per day, it requires $1,260. At twenty, it would require $2,520. The relationship is linear, which makes the metric easy to forecast.
What I would not do is assume future commission will arrive early enough to solve the next cash requirement automatically. I would size the processing pool from obligations, keep commission states visible but separate, and expand the reserve before deliberately increasing activity. That approach makes the Sellvia model more predictable and gives growth a clearer financial foundation.

Freya Morgan is an ecommerce content writer and platform researcher at Sellvia.biz. She focuses on Sellviaβs digital selling tools, subscription plans, advertising features, store management, and financial workflows. Freya aims to make complex platform information easier to understand by presenting clear explanations, practical examples, and balanced analysis. Her articles help beginners evaluate costs, understand how Sellvia operates, and choose an approach that fits their online business goals.
