You have done the honest work. The VAT is stripped, the goods are priced at what they cost you now, the parcels, the payment fees and the ad spend are all in the statement, and the statement still says the store earns money. Then the bank statement arrives and disagrees. This is the question that follows making sales but no money in the bank one level deeper: not whether the profit is real, but why real profit is not showing up as cash. The answer is four calendars. Profit is booked to the day it is earned; cash moves on the schedules of your suppliers, the tax office, your customers' returns and your payment provider, and each of those schedules can drain a genuinely profitable account for weeks at a time. Name the four and the gap between the statement and the bank stops being frightening, because it becomes itemisable.
- Profit and cash are both true and answer different questions: profit is earned per day, cash settles on the calendars of suppliers, the tax office, refunds and payouts.
- Stock is the widest gap: the example store's roughly €9.500 profit month is outweighed by a single €14.000 restock, and the faster a store grows, the wider that gap gets.
- Roughly a fifth of every gross euro sitting in the account is VAT waiting to be collected: on €60.000 of net takings at 19%, €11.400 was never yours.
- The plan for a profitable store is not more margin, it is calendars: a VAT sub-account, a reorder plan sized in weeks of cover, a refund reserve and a payout buffer.
Profit and cash answer two different questions
A profit statement books each amount to the day it was earned or incurred: the sale on the day it was ordered, the goods on the same day, the refund on the day it was issued, the ad spend on the day it ran, the fixed costs spread across the days they cover. A bank account books each amount to the day money actually moved, which is almost never the same day. Both are correct. The statement answers whether the business model works; the account answers whether you can pay Friday's invoice. Stores get into trouble when they use one to answer the other's question, and the commonest version of that mistake is reading a falling balance as proof the model is broken.
Two prerequisites before the calendars can explain anything. First, the profit has to be real: if you have not yet built the statement, calculate your true profit first, because everything below assumes goods, parcels, fees, ad spend and the fixed block are honestly in. Second, your reports have to agree with each other about what the period earned; if they do not, the definitions are bending somewhere, and why your Shopify numbers never match walks through where. With both settled, the example store's month is the working case: €60.000 of net revenue across 706 orders, about €16.500 of contribution, €7.000 of fixed costs, roughly €9.500 of operating profit, with the fixed block covered around day 22, when the month passes its break-even point on paper. A month like that can still end with less in the account than it started with, and here is how.
Calendar one: stock leaves as cash before it exists as cost
The statement charges the goods on the day they sell. The supplier charged you weeks or months earlier, for quantities sized to future sales, not past ones. A stable store barely notices, because this month's supplier payment roughly equals this month's cost of goods. A growing store notices immediately: growth means every reorder is bigger than the sales it replaces, so cash out runs permanently ahead of cost booked, and the faster the growth, the wider the wedge. This is the single biggest reason stores are profitable and broke at the same time, and it is a sign of success wearing the costume of failure.
The number that sizes this calendar is stock coverage, the weeks of sales your current stock can serve. Buy twelve weeks of cover and you have paid today for a quarter of future revenue; the profit on those sales exists only in the future, while the cash is gone now. The arithmetic on the example store's own month makes the point without any drama:
| The month | Amount |
|---|---|
| Operating profit, on paper | ≈ €9.500 |
| One restock paid to the supplier this month | −€14.000 |
| Cash movement from these two lines alone | ≈ −€4.500 |
Nothing went wrong in that table. The store earned €9.500 and chose to convert it, plus €4.500 of existing cash, into stock that will earn again. The problem is only ever not seeing it: an operator who cannot separate the two lines reads the −€4.500 as a loss, panics, and cuts the ads that were funding the profit.
Calendar two: the VAT was never yours
Every gross euro a customer pays contains the tax authority's share, and at 19% that share is not small: on the example store's €60.000 of net takings, €11.400 of VAT was collected alongside it. It sits in the same account as your money, looks identical, and leaves in a lump when the declaration is due. A store that reads its bank balance as its own money structurally overestimates itself by the VAT rate, feels rich for a month, and then experiences the remittance as a disaster that was in fact scheduled from the day of each sale.
The fix costs one standing order. Open a sub-account, move the VAT share of takings into it weekly, and the declaration becomes a non-event: the money was treated as gone on the day it arrived, which is the day it stopped being yours. The same discipline, applied mentally, is why the statement works from net revenue: profit computed on the gross figure borrows the tax office's money to flatter every margin in the book.
Calendar three: refunds are earned in one month and paid in the next
A return takes time: the customer decides, the parcel travels, the warehouse checks, the refund is issued. Two to three weeks is normal, which means a strong month's refunds drain the account of the mediocre month that follows it. The cash effect is real and unavoidable; the reporting effect is optional and worse. Booked against the original order, a refund rewrites a month you already closed, so last month improves every time this month bleeds. The reporting half of the problem, which day a refund belongs to, has a firm answer: the day the refund was issued, always, so that the statement's history stands still while the cash calendar does its lagging in plain sight.
The cash fix is a reserve. Size it from your trailing return rate against your strongest recent month, not your average one, because it exists precisely for the month after a spike. A store returning 8% of revenue that just took €80.000 should regard roughly €6.400 of its balance as already spoken for; holding that mentally, or in the sub-account next to the VAT, turns refund season from a shock into a withdrawal you had already made.
Calendar four: the payout arrives after the promise
The customer paid at noon; the gateway pays you out days later, minus its fees, and sometimes minus a rolling reserve it holds against future refunds and chargebacks. A spike weekend therefore reads as an empty Monday, and a big campaign's cash arrives after the campaign's own invoices have left. This is the smallest calendar of the four, but it is the one that makes daily balance-watching so misleading: the balance answers what has settled, never what was earned, and the two questions diverge hardest on exactly the days that matter most.
Know the schedule cold. The settlement lag plus any reserve is the number of days your own money spends in transit, and it belongs in the same calendar as the supplier payments and the VAT dates, because all three drains hit the same account. A store that can say 'Tuesday's takings land Friday, the reserve releases in thirty days, the supplier collects on the first' has replaced anxiety with logistics.
| Calendar | Direction | Typical lag | First check |
|---|---|---|---|
| Stock | cash leaves before the cost is booked | weeks to months | supplier transfers this month, next to the month's profit |
| VAT | cash sits in the account, already owed | until the declaration | the VAT share of takings, set aside or not |
| Refunds | cash leaves after the revenue was booked | two to three weeks | refund totals tracked against last month's sales, not this month's |
| Payouts | cash arrives after the sale | days, plus any reserve | the gateway's payout schedule and reserve terms |
The cash plan that fits a profitable store
- Open a VAT sub-account and move the tax share of takings into it weekly. The declaration stops being an event the day the habit starts.
- Plan reorders in weeks of cover rather than gut feel, and put the supplier payment dates in the same calendar as the ad budget and the VAT dates, because all of them drain one account.
- Hold a refund reserve sized on the trailing return rate against your strongest recent month; it exists for the month after the spike, which is exactly when it will be needed.
- Write down the payout schedule: settlement lag plus reserve equals the days your own money is in transit, and campaign timing should respect it.
- Once a week, put the statement's profit next to the bank's movement and itemise the gap with the four calendars until nothing is left over. A named gap is planning; an unnameable one is a finding.
Three questions that always come next
Should I finance stock with debt? A credit line that bridges the stock calendar on a proven unit is a timing tool, not a failure: the profit is real, the cash is scheduled, and the interest is the price of not shrinking a working machine. The order matters, though. Prove the unit economics on the statement first, because borrowing to feed an unprofitable unit does not bridge a gap, it buys a bigger loss on a schedule.
Does a falling balance mean I should raise prices? Not by itself. Price answers a margin question, and this diagnosis begins from the finding that margin is fine. Raising prices to fix a VAT lump or a restock treats the wrong organ, and can damage the one thing that was working, the unit that sells at its current price. Change price when the statement says the unit keeps too little, not when the bank says a calendar came due.
When is it a profit problem after all? When the itemising fails. If supplier transfers, the VAT share, the refund lag and the payout lag together cannot absorb the gap between profit and the bank, then the statement itself is flattered somewhere, usually by a missing cost or a backdated refund, and the margin question reopens. The four calendars are an explanation, never an alibi: they earn their keep only over a statement that is honestly built.
What a tracker changes about the four calendars
Nothing above needs software, but all of it needs the profit side to hold still: refunds on the day they were issued, ad spend on the day it ran, fixed costs spread across their days, and closed days that never quietly change. That is what nouz keeps, nightly, from your own orders and costs, so the profit half of the comparison is simply done every morning, and the whole question shrinks to reading the bank against a number you trust.
A profitable store that runs out of cash is one of the oldest ways a working business dies, and it is entirely a visibility failure. Split the two questions, let each report answer its own, and the falling balance turns back into what it actually is on a profitable store: stock you chose to buy, tax you always owed, refunds you already earned past, and money of yours that is simply still in the post.