Closing a Marketplace Order: Accounting Finality Against the Right to Return

Closing a marketplace order is a decision about where after-sales service happens: inside the system you measure, or in a mailbox nobody measures, and it needs two dates rather than one, because settlement finality and the buyer's rights end at different moments.

This article breaks down:

• Why do some marketplaces never close an order?
• Which 3 forces argue over the closing date?
• Why do you need two separate dates?
• What happens when an event arrives after closing?

Key insights

• Some marketplaces never close an order because a closed order stops accepting returns and complaints, which moves after-sales service into a mailbox where nobody can measure a response time or point to an owner.
• The three forces arguing over the closing date are settlement finality, the window of the buyer's rights, and the measurability of service, and each of them ends at a different moment, so no single date satisfies all three.
• Two separate dates settle it: the settlement finality date says the order no longer moves money by itself, and the case closing date says the order has left the service queue, which can fall much later or never.
• An event arriving after closing becomes its own object with its own date and document rather than reopening the original order, which is also how a correction lands in the right accounting period.

Why do some marketplaces never close an order?

The workaround you see at mature operators sounds absurd: do not close orders for several years. Before you dismiss it as sloppiness, look at what the decision buys.

In some products, a closed order stops accepting returns and complaints. Both paths disappear from the panel, a message thread can no longer be opened against that order, and whatever is left to do gets done off the platform.

The case does not disappear along with the status, because the buyer does not know your statuses.

As long as the order is open, after-sales service happens inside your system, and that is why it can be measured. You have the arrival date, an owner for the case, the seller's response time, and a decision with a justification.

After closing, you have somebody else's email thread and one party's account of what happened. That is the whole stake of this workaround: someone deliberately keeps a million open records so as not to lose the measurement.

The price is real too, and the finance director keeps an eye on it. An open order is a liability that can still move money six months after the sale, in a different accounting period, at a point when the commission has already been reported as revenue.

Practitioners describe exactly this conflict: support wants orders kept open so it can see quality, finance wants them closed so it can close the books.

Which 3 forces argue over the closing date?

1. Settlement finality

Finance needs a moment after which the transaction stops changing: the seller balance is reconciled, the commission recognized, the payout made, and irreversible (payout cycles, holds and reserves).

Without such a moment, every report is provisional.

2. The window of the buyer's rights

You are not the one who sets it, and it runs longer than intuition suggests.

What exactly the customer is entitled to, and for how long, is the subject of who delivers the buyer's rights. One consequence is enough here: that window does not end because your system changed a status.

3. Measurability of service

A commitment to a response time only means something when the case is an object in the system.

Service level agreements are measured by time to first response and time to resolution, and you can calculate neither of those on an account manager's email thread.

These three forces cannot be reconciled in a single date, because each of them measures something different and each of them ends at a different moment. Trying to make one date do all three jobs always ends the same way: one of the parties is lying.

Either finance pretends the money can still move, when the refund in fact goes out by bank transfer alongside the system. Or support pretends the case is finished, when the customer has just written in.

Why does closing an order need two separate dates?

The solution is easy to describe and hard to buy: separate the settlement finality date from the case closing date.

The settlement finality date says: this order no longer moves money by itself. It does not mean "nothing will happen." It means "whatever happens will be a separate event, with its own date and its own document." The mechanics of a refund are carried by who pays for a refund, what happens to the commission by the commission on a refunded order, and assigning a correction to the right period by corrections and credit notes.

The case closing date says something else: this order leaves the service queue and stops being counted as open. It can fall much later, it can never fall at all, and it does not have to block anything.

The test for a vendor is one sentence long: can the system hold the state "settled, but still open"? If it cannot, you have one field answering three questions, and every answer will be the wrong one for two departments.

The market has no single answer here, and this is an architectural question rather than a cosmetic one. Some products run an order through a single status that replaces every previous one along the way and ends in one terminal state.

Others gave up the single status in favor of a set of markers describing the order's history, because no single state can sensibly be assigned to an order in which some lines shipped and others were canceled before shipping. In that second arrangement there is usually no "closed" state at all, so the question is not "when do we close" but "how do we know we are finished." That answer has to be your own.

There is a third interested party nobody remembers at the design stage. For the seller, closing an order is the moment this transaction stops hanging over their account.

In some systems, formally closing a seller account requires that no orders are open. A policy of "we do not close for years" then also means this: you cannot close anyone's account until the last order from three years ago expires (the tail of obligations after a seller leaves).

How many orders stay open, and what does that cost?

You can work out the number of open orders before you launch anything, because it is governed by a relationship known from queueing theory: the average number of cases in a system is the arrival rate multiplied by the average time they spend inside it. It does not depend on the distribution of arrivals or on the order in which you handle them.

Put your own numbers in. At 1,000 orders a day, a closing window of 30 days gives you 30,000 open orders, a window of 60 days 60,000, and giving up closing for three years 1,095,000.

These are not dead records: every list works on them, every export, every "open orders" counter, and the seller panel.

Now the headcount. Assume that 4% of orders generate an after-sales case, which is 40 a day, and that handling one inside the system takes 25 minutes.

If 20% of cases arrive after day thirty and 10% after day sixty, then with closing at 30 days, 8 cases a day fall outside the system. Outside the system, the same case costs more, because the agent has neither the data nor a path: assume 45 minutes.

The arithmetic: 32 × 25 minutes plus 8 × 45 minutes is 1,160 minutes a day, which at six effective hours is 3.2 full-time people. With a 60-day window, it comes to 1,080 minutes and 3.0 people, and with no closing at all, 1,000 minutes and 2.8 people.

The difference in headcount is small, and it is not the cost. The cost is that 8 cases a day, around 240 a month, have no arrival date, no owner, and no trace of a decision: you will not see them in any report, and you cannot produce them in any dispute.

On the other side stands an amount your finance person will calculate for you. At 1,000 orders a day, a €1,000 cart and a 12% commission, €880 goes to the seller and €120 to you.

If 1% of orders come back after day sixty, that is 300 orders a month: €300,000 in cart value and €36,000 in commission, which is €432,000 of commission a year. Your closing policy does not determine whether that amount exists.

It settles only which side of the system it passes through.

What happens when an event arrives after closing?

It will arrive, so settle this in advance. You have three answers.

1. Reopening the order

The most honest and the least often available.

The question is not "can it be done" but whether the closed state is reversible at all, who has the right to do it, and whether it leaves a trace.

2. A shadow case linked to a closed order

A new case linked to an order that itself stays closed.

You keep the date, the owner, and the measurement, and the money travels a separate path. This is a compromise you can defend, and most often it is the right answer.

3. Handling it outside the system

The default, because it requires no decision, and the most expensive, because it deletes the evidence.

It also has a consequence support never sees: a refund made by bank transfer alongside the platform shows up neither in the seller balance nor in the bank reconciliation, so two registers that were supposed to agree drift apart by an amount nobody booked as a difference (the ledger behind a balance and payment reconciliation).

On top of that comes a trap you cannot see on a process diagram. Closing can switch off the contact channel.

If the buyer's address is masked behind an alias valid only for an open order, then after closing the seller has no way to answer the customer, even when they want to and even when they are right. Masking itself belongs to data protection (who controls the personal data), but its expiry date is an operational decision, and by default it is tied to closing.

And a warning specific to this topic and far from obvious. A quality metric calculated on closed orders responds to your closing policy rather than to the quality of service.

Halve the window, and you improve your return rate and your complaint rate without changing anything in reality, because events after the window simply do not exist in the data. Statistics has a name for this: censoring of observations.

When measurement stops at a moment fixed in advance, everything that would have happened later lands in one bucket labeled "not observed" and systematically understates the result. There are two consequences, and both of them hurt when you enforce thresholds (seller quality thresholds).

You cannot compare a seller with a long delivery time against one who ships the same day, because the window cuts them differently, and you cannot compare your own metrics from before the policy change against the ones from after it.

When does an order have to close for good?

You cannot always leave a case open, and it is not always worth it.

When the system cannot separate the two dates. Closing is then the only finality you have, and it is better to have it openly than to pretend the books never close.

When a seller leaves. The final settlement needs a list of orders that stops growing.

When the record has to be archived or deleted in line with your data retention policy.

When the cost of keeping the state open exceeds the value of the measurement. A million records in every list is a real slowdown for the team's work, and the value of the measurement falls as the case ages.

The rule of thumb that comes out of these four cases: close the money date hard and early, close the case date softly and late.

What does closing an order change about the rest of your build?

1. The closing clock starts from an event you usually do not measure

If you count it from a "delivered" status, you take on all the fragility of that status (when an order counts as delivered).

2. Your closing policy changes your payout exposure

The earlier you finalize the money, the more risk stays on your side, because you have nothing left to deduct from, and reconciling events like these against a bank statement is separate work.

3. Seller quality thresholds have to be recalculated after every change to the window

Otherwise, you are enforcing values that were calculated on a different basis.

4. Support will work out the consequence faster than finance

For the complaints team, closing is not a status. It is the answer to one question: does the case get done in the system, or in an email?

How do you check order closing with a vendor?

Five questions for your vendor. Ask to be shown on screen rather than answered in a feature table.

1. Show me an order that is settled and still open for service. If that state does not exist, the rest of the questions are theoretical.
2. What exactly stops working after closing: the return, the complaint, the message thread, the contact channel with the buyer? Ask for the full list rather than a slogan.
3. Is closing reversible, who has the right to do it, and does it leave a trace?
4. What controls the closing window? Is it one global setting, or can you vary it by category and by fulfillment model?
5. Does an order with a partial return close itself? In some products it never closes, so you grow a tail of records nobody planned for.
6. Can the window be changed after launch, and what happens to orders that are already closed? Extending it usually does not resurrect what is already finalized, and shortening it can close several tens of thousands of records in bulk overnight.

A question to ask yourself before you ask the vendor: at our volume, how many cases stay open with a window of X, and who looks at them on Monday morning?

Which mistakes do operators make about closing orders?

1. One date for three needs

The consequence is predictable: finance gets a number it does not believe, and support gets a process that cannot be measured.

2. A closing window left at the default and never recalculated

Nobody chose it, so nobody defends it, and it drives your metrics, your headcount, and your result.

3. Pushing cases out of the system and calling it a saving

The work did not disappear. Only its trace did.

You pay for it exactly as before, and you will not see it in any report.

4. Comparing metrics calculated with different windows

After a policy change, you hold two sets of data that look like one time series.

5. A "we close nothing" policy with no settlement finality date

You buy the measurement, and you sell the closing of the books, the seller settlement, and your ability to end the relationship.

What do you still have to settle about your own closing rule?

This article does not say how long the buyer is entitled to anything, or from what moment those periods run. That is who delivers the buyer's rights and a conversation with a lawyer rather than a product decision.

Your closing policy has to fit that window rather than set it.

This article does not describe the mechanics of a refund, what happens to the commission on a refund, or assigning a correction to a period. It settles only whether the event passes through the system at all.

This article does not settle where you take the fact of delivery from or when a receivable enters a payout. Both decisions set the start of the clock you stop here.

All the numbers here are openly hypothetical. The arithmetic travels, the values do not: substitute your own volume, your own share of cases, and your own distribution of when they arrive, because every conclusion above depends on them.

Summary: When is a marketplace order finished?

On two different days, and pretending otherwise is what breaks. Finance needs a moment after which the transaction stops changing, so the books can close.

The buyer's rights run on a calendar you do not control and take no notice of your statuses. And support can only measure a case while it is still an object in the system, which is why some operators keep a million orders open on purpose.

One date cannot serve all three without somebody lying about it: either the money is still moving after finality, or the case is marked finished while the customer is writing in.

Ask a vendor what a closed order still accepts, and whether a return can be opened against one. Building a marketplace where settlement finality and the end of a service case are two separate dates?

Talk to us about the build.

Frequently asked questions on closing a marketplace order

When should a marketplace close an order?

A marketplace should close an order on two dates rather than one. The first ends the money: the balance is reconciled, the commission recognised, the payout irreversible.

The second ends the case, and it can fall months later, because the buyer's right to return is set by law rather than by your status field.

What happens if a buyer returns something after the order is closed?

A return after closing has to open an event of its own, with its own date and its own document. Reopening the original order drags a settled period back into play; a separate event lands the correction where it belongs and leaves the original settlement intact.

Should a marketplace order ever stay open indefinitely?

An order staying open indefinitely is a deliberate trade some operators make, and it has a price. Keeping the case inside the system is the only way to measure response times and hold an owner, and it also keeps a liability alive that can move money in a later accounting period.