When a Marketplace Order Counts as Delivered

A marketplace order delivered status is the verdict that releases the seller's money, and when no fact hands it down, a timer does, which makes the choice of source a credit decision rather than a field in a configuration screen.

In exactly one place in your system, a verdict gets handed down: "this order has been delivered." The seller's money starts running only from that point. If no fact hands down that verdict, the clock does.

A clock is wrong in both directions, and only one of those two errors can be reversed.

This article breaks down:

• Which 4 sources can confirm a delivery?
• How many days of cash does each source buy?
• Does a delivery timer reduce your risk?
• What about orders with no delivery event?

Key insights

• The four sources that can confirm a delivery are carrier integration, buyer confirmation, a timer, and a status entered by the seller, and only the first describes reality: the last one reaches you through the seller's integrator even where the panel blocks it.
• Each source buys a different number of days of the seller's cash cycle: a carrier fact on day 3 against a timer on day 23 is twenty days, which at 100 orders a month of €1,000 leaves close to €58,700 of their capital frozen at all times.
• A delivery timer does not reduce your risk, it executes the case you are afraid of: a label with no parcel behind it flips to delivered on its own after two or three weeks, and a timer produces no evidence you can file in a payment dispute.
• Orders with no delivery event need a named substitute rather than a quiet slide onto the timer: buyer confirmation for untracked shipments, the pickup itself rather than arrival at a parcel locker, and performance confirmed by the buyer for services.

Why is a delivery timer a credit policy?

A timer that says "N days after dispatch we treat the order as delivered" is not a technical shortcut. It is a credit policy toward your sellers.

It settles how much risk you take on so as not to hold other people's money longer than necessary. Nobody puts it that way, because in the configuration it looks like a field with a number of days.

In rollouts, we know default timers of this kind run around two to three weeks from order confirmation. They are often extended by the declared parcel preparation time, and usually you cannot switch them off.

You can only move them to a different number. The timer flips the status whether or not the parcel ever arrived anywhere.

The whole decision sits inside a single asymmetry, and it is worth putting to the committee in exactly that form:

• Recognizing delivery too early. Take the canonical order: a €1,000 cart, a 12% commission, €880 due to the seller. Those €880 go out for a fact that never happened. The only way back is clawing money out of somebody who may not have it anymore.
• Recognizing delivery too late. The seller's working capital sits with you two weeks longer than it should. The way back is one payout and one phone call.

Only the second error is reversible. That does not mean you should drag your feet.

It means two days of caution are paid for in a different currency than two days of haste, so you price them separately.

Which 4 sources can confirm a delivery?

In your system, the fact of delivery can come from four different places, and they differ by an order of magnitude.

1. Integration with a carrier or a broker

A carrier or broker integration is the only source that describes reality. There is a catch.

A carrier does not emit a single "delivered" bit. Public standards for exchanging transport statuses run to dozens of codes, and they keep "arrived at the delivery location", "available for pickup" and "delivery attempt failed" apart as three separate things.

You have to name the exact code that releases the money. That is not an IT decision.

The mechanics of connecting carriers and mapping their statuses into one shared vocabulary belong to carriers, labels and tracking.

2. Buyer confirmation

Buyer confirmation is an email with a “confirm receipt” link, or a button in the order history. It is cheap, you can ship it in a week, and it is the only source that tells you what the buyer thinks.

It has one weakness, and that weakness disqualifies it as your only source: only a minority clicks. Without a fallback, some orders never mature.

3. A timer

A timer is not a source of fact. It is a guess with a fixed value.

Everybody falls back on it in practice, because it costs nothing and it always fires.

4. A status entered by the seller

A status entered by the seller looks like a source, and is a declaration by the party that gets paid on it. The chapter on payout cycles, holds and reserves closes that question in one sentence, and this article does not reopen it.

What is worth knowing is the hole nobody expects: in most rollouts the seller is hard blocked, but their integrator works with the seller's own key. A status pushed in from the seller's external warehouse system is formally a status from the seller.

It only looks like courier data. If your platform does not tell those two apart, the block is cosmetic.

How many days of the seller's cash cycle does each source buy?

The seller bought the goods with their own money and is waiting to get that cash back. In management accounting, this time is called the cash conversion cycle, computed as days of inventory plus days of receivables minus days of payables.

Your choice of delivery source fixes one term of that formula for them: days of receivables in your channel. That is the whole conversation they are having with you.

Take a seller doing 100 orders a month at €1,000 each. At a 12% commission, the receivable is €880 per order, which is €88,000 a month, or €2,933 a day (88,000 divided by 30).

Compare the two sources. The carrier recognizes delivery on day 3.

The timer flips the status after 21 days plus 2 days of declared parcel preparation, so on day 23. The difference is 20 days, and 20 times €2,933 comes to close to €58,700 of permanently frozen capital.

This is not a one-off. It is a balance that, at a steady rate of sales, stands there all the time.

Set that against their margin. At a 15% margin on €100,000 of turnover, they earn €15,000 a month, so you are freezing an amount equal to almost four months of their margin (58,700 divided by 15,000 is 3.9).

At a cost of money in the region of 10% a year, that costs them roughly €5,870, which is about half a percent of their annual turnover with you. Substitute your own cost of capital and your own volume.

Do the same math on the middle option. If 35% of buyers click the confirmation with a median on day 4, and the rest wait for the timer, average recognition lands at 16.4 days (0.35 times 4 plus 0.65 times 23).

A cheap improvement has taken just under seven days off a gap of twenty. Better than nothing, and visibly less than the integration.

This is a commercial argument rather than a technical feature. The line "with us you get paid two weeks earlier than where you sell today" pulls harder in seller recruitment than a point of commission, and it costs you once.

Cadence, and what happens to the money after the receivable matures, belong to the chapter on payouts.

Does a delivery timer reduce your risk?

Here is the mistake that goes through most rollout conversations unnoticed. The timer looks like a safeguard, and it guards against nothing it was supposed to guard against.

The case you are afraid of is a seller generating a label with no parcel behind it. Practitioners describe it as the textbook scenario: a tracking number lands in the system, the goods never move off the shelf, and after two to three weeks the status flips on its own and the money goes out.

The timer does not screen that case out. It executes it.

All it does is push the payout back.

Now price the integration at platform volume. At 10,000 orders a month at €1,000 each, the turnover is €10 million and seller receivables are €8.8 million.

Assume hypothetically that 0.4% of shipments never reach the buyer. Then 40 orders a month times €880 is €35,200 that the integration never lets out of the account, for the plain reason that the delivery event does not exist.

Over a year, that is €422,400. Set it against the cost of connecting carriers before you file this as a project for after launch.

There is a second benefit that nobody puts in the budget. The record that releases your money is the same record you defend yourself with later in a payment dispute.

Public documentation from payment providers describes a separate dispute category for "item not received", and the evidence expected in a response is the carrier name, the shipment number, the dispatch date and, on more expensive goods, the recipient's signature. A timer produces nothing you can file in a dispute like that.

The rules and consequences of those disputes belong to chargebacks and an empty seller balance.

What about orders where no delivery event exists?

Every catalog has its exceptions, and each of them needs a named substitute event rather than a quiet slide onto the timer.

1. Shipments with no tracking

Economy post, bulky goods moved on the seller's own transport, installation at the customer's home.

Here, buyer confirmation is the primary source rather than a supplement.

2. Pickup points and parcel lockers

This is the most confusing thing in the whole category.

"Available for pickup" is not "picked up", and public order vocabularies keep those two states apart, exactly as transport standards do. Several days can sit between them, and some parcels go back unclaimed.

If you recognize the money the moment the parcel reaches the point, you are paying out on shipments that will come back.

3. In-store pickup and handover at the counter

In-store pickup and handover at the counter have an event stronger than any scan: goods passed from one hand to another. There is one condition.

Somebody has to click it through, and the person doing it is a store employee nobody has ever measured on it.

4. Services and intangible goods

Services and intangible goods have no parcel at all. The event is performance confirmed by the buyer.

Settle that in the open, because otherwise a rule written for parcels will settle it for you.

Separately: with cash on delivery (COD), the moment of delivery is also the moment of payment, and the money never passes through your account.

Why is switching the delivery source a treasury event?

This warning is specific to this one decision, and almost nobody raises it in advance.

Suppose you move from a 23-day timer to an integration that recognizes delivery on day 3. On the day you switch, every order currently sitting between day three and day twenty-three matures at once.

At 10,000 orders a month, receivables build at €293,333 a day (8.8 million divided by 30), so the one-time spike is 20 times €293,333, which is €5.87 million above the normal run rate.

This is not a technical problem. It is a liquidity problem on one specific day.

Shortening the cycle has to be planned with whoever owns the cash rather than announced as an improvement. The alternative is to spread it over several weeks, walking the timer down in stages instead of switching it off overnight.

What does the delivery event change about the rest of your build?

1. One input event feeds three separate machines

It starts the receivable maturing, it usually opens the after-sales window, and it starts the clock on closing the order (closing an order). A single change to the timer moves all three at once, so this is not a setting that lives "in orders".

2. The quality of the source carries straight into the quality of the promise you make the buyer

The date on the offer, and the measurement of who keeps it, is the delivery date you promise. Without a trustworthy "delivered" you cannot compute a single one of those metrics, so your quality thresholds rest on the same foundation (seller quality thresholds).

3. Recognition from a guess poisons the balance

The seller sees an amount due that follows from an event that never took place (the ledger behind a balance).

How do you check the delivery event with a vendor?

1. List every way an order can acquire the delivered status. That includes the ones somebody switched on once and then forgot about.
2. What is the default timer, which event does it count from, and can it be switched off completely? If it can only be lengthened, say so plainly.
3. Can you see in the system which source a given status came from? Without that, you cannot tell a fact from a guess, and you cannot build a report out of it.
4. Which carrier code exactly releases the money, and what happens to the "available for pickup" event?
5. Is a status brought in on the seller's key treated differently from a status set by the operator?
6. Show me the report of orders that flipped on the timer rather than on a fact. The existence of that report is the only real control you have over this layer.
7. What happens to maturing if I switch the integration on tomorrow? The answer "everything at once" is the correct one, and that is exactly why you want to hear it early.

Which mistakes do operators make about the delivered status?

1. A timer inherited from the default settings

Nobody picked it, so nobody feels like its owner. And it is the thing that settles when money leaves.

2. Treating the timer as a safeguard

It protects you only against risk that correlates with time. Against a label with no parcel, it protects you not at all, because the timer is what pays out.

3. Blocking the seller without blocking their integrator

On paper, the source of the status is the operator. In practice, it is the seller's key.

This hole leaves no trace in any report.

4. Counting arrival at a pickup point as delivery

You are paying out on shipments the buyer has yet to collect, and some will never be collected.

5. Shortening the cycle announced as a technical improvement

The one-time spike in payouts hits an account nobody prepared for it.

What do you still have to settle about your own delivery event?

This article does not say what happens to the money once the receivable has matured: cadence, holds, reserves, and the first payout to a new seller are payout cycles, holds and reserves. It does not describe connecting carriers or mapping their statuses into one shared vocabulary, the delivery date you promise the buyer, or closing the order and what that triggers.

This article does not touch the legal dimension, and that is deliberate. When the withdrawal window runs, and what the buyer can demand of you when a shipment never arrived, is carried by who delivers the buyer's rights.

The mechanics of refunding money are who pays for a refund, and the fate of the commission on a return is the commission on a refunded order. The "delivered" record in your system is an operational event rather than a ruling on anybody's rights.

It should not be used as one in either direction.

All the numbers above are openly hypothetical. Your one real number is the share of orders whose delivery status came from a fact rather than from time passing.

Nobody can hand it to you, because it is a measurement on your own traffic. Until you know it, you do not know whether your payouts describe reality or the calendar.

Summary: What should release the seller's money?

A fact, and a named one. Four things can play that part and they are an order of magnitude apart: the carrier describes reality, the buyer tells you what they think, the timer guesses, and a status from the seller is a declaration by the party being paid.

The right setup is a precedence rather than a pick: carrier first, buyer's confirmation second, timer last and flagged openly as a guess. Everything else follows from that choice, including twenty days of somebody's working capital, the evidence you can produce in a payment dispute, and whether a label with no parcel behind it ends in a payout.

Ask a vendor which carrier code flips the status, and whether a status arriving through the seller's integrator is told apart from the carrier's. Building a marketplace where the money follows a delivery event rather than a countdown?

Talk to us about the build.

Frequently asked questions on the delivered status

When does a marketplace order count as delivered?

A marketplace order counts as delivered when a named source says so, and the order of preference is carrier, buyer, timer. Carriers do not emit a single delivered bit: public transport standards keep arrival at the delivery location, availability for pickup, and a failed attempt apart, so you have to name the exact code that releases the money.

Can a marketplace mark orders delivered with a timer?

A marketplace can mark orders delivered with a timer, and should treat it as the last resort it is. The timer fires whether or not the parcel ever arrived anywhere, which means it executes the fraud case rather than preventing it, and it leaves you nothing to file when a buyer disputes a payment for goods they never received.

Who should confirm delivery on a marketplace?

Confirming delivery should sit with anyone except the party that gets paid for it. The carrier is the strongest source, the buyer is the cheapest to add, and a status entered by the seller is a declaration.

Most platforms block the seller in the panel and let the same status through on the seller's own integration key.