Deliveroo Pays Once a Week. Your Bills Do Not Wait.

Meanwhile the week the money came from has bills of its own, and none of them run on a cycle that suits a delivery platform. The fish supplier wants paying on the terms the fish supplier set. The payroll date does not move. Rent goes out when the standing order says. A restaurant in that position is doing something it never agreed to and rarely notices: financing a week of its own trading out of its own working capital, permanently, because takings and outgoings keep different time and only one of those clocks is under the restaurant's control. The overdraft interest, or the supplier quietly being paid late, is the price of that mismatch, and it appears as a line item nowhere.

None of this is hidden. Deliveroo publishes it in its Help Centre, under the Payments & Invoices collection, in an article headed "How invoices and payments work on Deliveroo" and dated 27 February 2026. Partner Hub, named below, is the separate portal that article tells partners to log into for statements and invoices. It sets out the rhythm first:

That is reproduced as the help page prints it: three bullets beneath a single lead-in sentence, run onto one line because that is the only way to quote the passage whole.

Three separate things are weekly there: the calculation, the authorisation, and the window being calculated, which is the completed orders of the previous Monday to Sunday. A second Help Centre article, "When will I be paid by Deliveroo?", fixes the day the money moves:

The ... stands for the line immediately before, naming Wednesday as the payment day in Singapore, the United Arab Emirates and Kuwait. It does not apply to a restaurant trading in the United Kingdom, where the published day is Thursday.

Put the two together and the wait turns into arithmetic rather than impression. An order completed on a Monday falls at the very start of a Monday-to-Sunday window, which does not close for another six days; the calculation and authorisation follow, and the payment is issued on the Thursday of the week after that. Issued is the help page's own word, and it is not the same as arrived: payment is made by bank transfer, so the receiving bank decides when the funds clear. From service to the day the transfer is issued is the better part of ten days, with clearing time on top. An order completed on the Sunday night waits about four. Every order sits somewhere on that ladder.

Visibility is not availability. The help article notes that the statement inside Partner Hub updates daily and reflects the previous day's delivery takings, so an owner can watch the number climb. What that statement carries is delivery takings; the final payout amount is a figure on the weekly invoice, and the invoice has not been raised yet.

The second reason the tablet figure and the bank figure differ is that the invoice is a netting exercise. The same help article sets out its summary section:

Read that as a sequence rather than a list. Total revenue is the top line, the number the tablet showed all week. Commission comes off it, then the additional fees the restaurant owes: customer credit redeemed, refunds, outstanding fees, and then rebates go back on, the examples given being remade and cancelled orders. What is left is the final payout amount, and that figure is what the bank transfer carries.

Two consequences follow for anybody forecasting cash. First, the adjustments are not knowable in advance with any precision. A refund on the Friday, a remade order on the Saturday, credit handed to a customer in response to feedback on the Sunday (which the help article says appears on the invoice as restaurant funded voucher promotions) all land inside the same window and all move the final number. Second, they arrive as one aggregate. The restaurant can apply its own contracted commission rate to the gross figure and get somewhere; what it cannot see until the invoice lands are the refunds, the redeemed credit, the outstanding fees and the rebates that decide the payout.

The operational problem is not the deductions, nor the delay on its own. It is that the two sides of the ledger keep different time, and only the outgoing side respects the calendar the restaurant lives on.

Wages run to a fixed date, deliveries arrive against terms a supplier chose, and a quarterly rent demand does not care which Thursday it is. Against that, a channel pooling seven days of trading into one netted transfer means the more of a restaurant's volume goes through it, the more of the month is carried on credit: a bank's, at a price, or a supplier's, at the cost of the relationship. The strain peaks when it is least affordable, because a strong week produces a bigger receivable rather than a bigger balance.

The same arithmetic compounds with anything that squeezes the gap between what a dish sells for and what it costs to put out. When an input cost has risen and the menu has not caught up, the week being financed is worth less than the till suggests; what each week of delay in repricing the menu actually costs works that side through. A restaurant carrying a stale price and a ten-day wait at once is lending money it is not making.

An order taken on the restaurant's own site does not enter a weekly invoice cycle at all. It is a card payment into a merchant account, and the day it is paid out is a setting on that account rather than a day the channel fixes. That is not the same as a guarantee of speed, and the distinction matters, because the setting can be left somewhere slow: what happens to ordering takings when a payment provider fails makes the point from the other direction, that a direct-checkout payout can sit seven days out on a setting nobody has looked at since the account was opened. Stripe sets out the timings and the schedule options for the United Kingdom:

That is the United Kingdom row of the table the documentation heads "Same-day manual payouts are available in the US, UK, and Eurozone under the conditions outlined in the following table", reproduced as the page renders it. The wording quoted is therefore the eligibility condition for a same-day manual payout, not a published statement of the United Kingdom's general settlement schedule; the page keeps that elsewhere, in a collapsed table of settlement timing by country with an initial timing for the first payout and a default for the ones after it.

What the page separates cleanly is worth borrowing. Settlement timing is how long funds take to become available. The payout schedule is when available funds are sent, and that is a setting on the account holder's side: the documentation lists manual payouts, daily payouts, and weekly or monthly payouts on days the account holder names. Choosing a schedule, it adds, does not change how long a pending balance takes to become available; it only controls when payouts are sent. A direct channel can therefore sit on a weekly payout day too. The difference is not an automatic daily rhythm. It is that the day belongs to the restaurant, along with the option of a manual payout initiated before five in the afternoon, London time, which the table makes eligible to arrive the same day, subject to the limits in the same row.

A second difference has nothing to do with speed. A direct order is not netted against a week of somebody else's adjustments before it is paid. Refunds, chargebacks and fees still exist and still cost money, but they sit against the transaction they belong to rather than pooling into one figure that resolves once a week.

The comparison above is structural, and it is worth saying where it stops.

The strongest inference in this article is that moving order volume onto a direct channel gives the restaurant control of the payout day, and that inference is structural rather than a promise of speed: the Stripe row quoted above reads "T+3 settlement timing or slower" as an eligibility condition for a same-day manual payout, the payout day itself is a schedule the account holder sets and can set weekly, and nothing in it promises that a particular direct payment beats a particular marketplace payout.

One limit belongs here rather than anywhere else, because it defeats the obvious wrong reading of the argument. The same documentation states that after a first live payment is received, Stripe typically schedules the initial payout to complete within 7–14 days, and that it can take longer depending on industry, country of operation and risk level. A restaurant opening a direct channel in the week it is short will wait longer for that first payout than for the marketplace invoice. Switching a channel does not relieve a cash gap in the week it is switched.

The pages quoted here are the platform's own, published for partners to read. The question is narrower: which share of a restaurant's order volume should sit on a seven-day netting cycle at all, given that the restaurant's own bills do not.

Two things were deliberately not asserted. No published figure for how many independent UK restaurants name marketplace payout timing as a driver of their cash-flow pressure was located in this research, so no proportion is given. No figure for the average number of days an independent restaurant is short of working capital was located either, so the argument rests on the published cycle.

The practical conclusion is simple enough to act on. The settlement cycle is a property of the channel, not of the food. A restaurant taking all of its orders through one weekly-settling channel has exactly one cash rhythm, and the day it falls on is somebody else's decision. A restaurant that owns a meaningful share of its order volume decides that day for that share.

Owning that share means having somewhere for the order to go: a site the restaurant controls, with the menu on it, taking payment into the restaurant's own processing account. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and direct online ordering sits on its Full plan at £69 a month, excluding VAT, at 0% TableSpark commission, with table QR ordering on the same tier. The published qualifier belongs in the same breath: prices exclude VAT, and Stripe's standard card-processing fees apply to online payments. Restaurants not yet taking orders directly start lower, at Starter for £19 a month or Growth for £39 a month, both excluding VAT.

What the platform settles is where the order arrives and on whose terms it is taken. The date a given payout reaches a given bank account is set by the card processor and the receiving bank, and no such promise is made here.

Five things, none needing a decision about switching anything.

Open the most recent invoice, find the final payout amount and set it beside the gross revenue line at the top of the same document. The difference is what a week of orders costs to collect through that channel, and most owners have never written the two numbers next to each other.

Take one ordinary order from the middle of a recent week and date it through: the day it was completed, the Sunday that closed its window, the Thursday the payout was issued. That span is the restaurant's actual float on marketplace trade.

Check what share of weekly covers now runs on the weekly cycle. If it has crept upwards over a year, the float has grown with it.

Look at what the direct channel offers a guest who wants the same food. Without a route to order outside the marketplace, the share cannot move.

Finally, treat the direct checkout as an operational surface rather than a button, because other people probe it too: the way bots test stolen cards on a restaurant's checkout page sets out the controls that belong on it from the day it goes live.

Knowing which orders are lent out for ten days and which are not is the whole of the decision. The share running through the restaurant's own site is the share whose payout day the restaurant sets, whose gross figure is not netted against somebody else's week, and whose margin is not cut by a marketplace commission before it is paid. Building that owned channel on TableSpark is the recommendation this article ends on.