Mercur

When a Marketplace Seller Changes Its Legal Form

Sellers~13 min
When a Marketplace Seller Changes Its Legal Form

A seller legal entity change on a marketplace is the moment a seller becomes a different company, which ends the contract, the acceptance of the terms, the payout data, and the basis of every document already issued, even though the panel shows it as five editable fields.

A seller writes that they have converted the business into a company and asks you to fix the details on the account. That one sentence invalidates at once your contract with them, their acceptance of the terms, the payout data, the tax data, and the basis of documents you have already issued.

This article breaks down:

  • Why is a new legal form a new entity?
  • Which 3 ways can you handle the change?
  • Which 6 steps keep the history intact?
  • How does the change usually reach you?

Key insights

  • A new legal form is a new entity because the contract, the acceptance of the terms, the payout data, the tax data, and the basis of every document already issued belong to the company that existed before, which is why an identifier is closed and reissued rather than edited.
  • The three ways to handle it are a new account with the offers migrated, which loses the sales history and the position in search; a new entity under the existing trading brand, which loses nothing and needs the entity held separately from the store; and overwriting, which is cheapest today and breaks your books.
  • The six steps are closing the inflow of new orders, settling the tail, a new contract with a fresh acceptance of the terms, new payout details with verification, migrating the offers with their identifiers, and winding the old account down once the balances are at zero, which takes four to eight weeks in practice.
  • The change usually reaches you as a request to change the bank account or an invoice carrying a different tax identifier, so an edit to any of those five fields should start a process: at 1,200 sellers that is two events a month, and handling them costs about seven times less than repairing them afterwards.
Two columns comparing five editable panel fields with the five legal relationships that change with a new entity.

In the panel, a change of legal form looks like five edits: tax identifier, registration number, name, bank account, representation. Outside the panel, something else changes: who is party to the contract, who may be paid, who issues and receives documents, and who the buyer has a claim against.

Five fields on one side, five independent legal relationships on the other.

The world of business entity identification solved this differently from the typical seller panel. In the global standards, an entity identifier is unique and belongs to one entity only, forever, while legal form is a separate coded attribute.

International registers hold thousands of them across two hundred jurisdictions. The conclusion for your data model is direct: when a new entity comes into being, you do not edit the old one's identifier.

You issue a new one and close the previous one.

Take a seller with twenty-six months of history, 4,200 active offers and 180 orders in flight. This series runs on one standard example: a €1,000 cart, a 12% commission, €880 to the seller.

Those 180 orders are €180,000 of turnover, of which €21,600 is your commission and €158,400 is owed to the seller. Owed to one specific entity, which may no longer exist on payout day.

The event looks like a change of details when it is a change of debtor, creditor, and contracting party in one move, and that is why it is among the most expensive events in the seller lifecycle: it has no process, so it lands on the cheapest path available.

Why must you not overwrite the data on the existing account?

Overwriting is the default, because the panel allows it and the first such case gets decided by one person in fifteen minutes. It costs the most, only later.

Overwriting a seller profile versus versioning entity data in time, with the volume of history affected.

History is not a description of the seller. History is the set of events in which one specific entity was a party.

Our seller, at a hundred and fifty orders a month, has 3,900 orders behind them, 78 payout settlements (three a month) and 26 commission invoices. Once you overwrite the tax identifier, all of them point to an entity that did not exist when they were created.

Overwriting does not change history. It falsifies it.

That this is not over-caution shows in how the electronic invoicing standards are built: the seller's registration identifier, tax identifier and legal name are separate, structured fields on the document there. They are separate so that years later somebody can still say who sold (who issues which invoice and corrections and credit notes).

The rescue mechanism does not need inventing. Data warehousing has distinguished for decades between the overwrite, which erases the past, and appending a new version with a valid-from and a valid-to date, which preserves it.

Only the second is right: entity data gets versioned in time and attached to the order rather than the profile (whether you are an intermediary or a seller).

The practical consequence, in one sentence for the committee: a seller's tax identifier cannot be an editable field, because it is an element of every transaction they entered into rather than a property of the seller.

A new account with the offers migrated is clean in the books and expensive in operations. You open a second account for the new entity, move the offers, and wind the old one down.

Sales history, ratings, and position in search results stay with the account you are closing. That means they are gone.

The seller starts from zero with the same assortment and the same brand.

A new entity under the existing trading brand is the only option with no loss, but it requires the platform to keep the legal entity separate from the store and version data over time. That is the model from the structure of a seller account.

The conversion then becomes a swap of the entity with a transition date: old orders point at the predecessor, new ones at the successor, and the buyer notices nothing.

Overwriting is the cheapest today and the only one that breaks your books.

What does each way of handling the change cost?

New account, offers migrated

New entity under the existing brand

Overwriting the data

What happens to the account

a second appears, the old is wound down

the account stays, you swap the entity under it

the account stays, the data is overwritten

Sales history available after the change (months out of 26)

0

26

26

Does the history point at the entity that sold

yes, split across two accounts

yes

no

Operator work per conversion (hours)

40

6

0.5

Break in the seller's selling (days)

10 to 20

0 to 2

0

Ratings and position in search results

lost

kept

kept

What it requires from the platform

offer export and import, dead links

entity split from brand, dated data versions

nothing

When it is the right choice

when the platform does not split entity from brand

always, when the model allows it

never

The "operator work" row says why the market chooses overwriting, and the "does the history point at the entity" row says what that costs later. The difference between 40 hours and 6 is not about how efficient your team is.

It is the consequence of one decision about the data model, taken before launch.

Six steps, in this order, no shortcuts:

  1. Close off the inflow of new orders to the old entity. The offers stop being buyable. This is a decision about a seller, so it needs a reason, delivery, and a trail (the rules on decisions about sellers).
  2. Finish and settle the tail. Orders in transit, the returns window, corrections, the payout of the balance. With 180 open orders and a thirty-day returns window, the tail closes around the sixth week rather than within one.
  3. A new contract and a fresh acceptance of the terms for the new entity, with the document version and the date (the documents you sign with a seller).
  4. New payout details, with verification. A new entity means a new verification rather than an update of the old one (verifying a seller at the entrance).
  5. Migration of the offers, preserving their identifiers, their links to product pages and the addresses under which they were known.
  6. Winding down the old account, only once the balances are at zero and the tickets are closed.

These six steps take weeks rather than days. Realistically, four to eight, and most of that time goes on step two, which you do not control.

The market bar is harder than most plans assume: some products will not let you close a seller account at all until every order is closed or canceled, every after-sales ticket is resolved, and the balance is at zero. Closing the account is therefore sometimes the end condition of the process rather than a click.

And the question somebody has to settle, because it will not settle itself: selling cannot stand still for six weeks, so which entity sells during the transition? Price the silence.

A hundred and fifty orders a month at €1,000 is €150,000 of turnover: €18,000 of your commission and €132,000 for the seller. That is what a month of standstill costs.

The seller will do that math faster than you and start selling on the old account in the name of the new entity, which means they choose overwriting for you, with no record of it.

There are two honest options: the old entity sells up to the transition date and the new one starts the next day with the full catalog (steps 3 to 5 prepared in parallel), or both accounts run inside a narrow, explicitly closed window, with a rule saying which offers are active. Improvising produces orders you cannot assign to anyone.

One seller acquiring another. Two accounts, one offer base, two balances.

None of them disappears on a business decision. With 4,200 offers on the acquired side and 1,800 on the acquiring side, you have 6,000 offers, hundreds of them duplicates on the same product pages (who wins the page: the rule that picks the winning offer).

The balances are sharper: €158,400 payable on one account and a negative balance on the other are two financial relationships, and you may not net them off without a basis.

A company splitting in two. Harder than an acquisition, because some things cannot be divided: the catalog splits, the ratings do not.

Decide explicitly which entity inherits the history. Then say so to the seller before the migration rather than after.

A change of bank account only, with no change of entity. It looks the most innocent, and it is the most common fraud vector in the seller lifecycle.

Public guidance from agencies dealing with economic crime is consistent: a request to change settlement details gets confirmed through a channel other than the one it arrived on. At three payouts a month against a balance of €158,400, one swapped instruction is €52,800 sitting at somebody else's address (fraud on a change of bank account and verifying a seller at the entrance).

A change of trading name with no change of entity. The opposite mistake and expensive too: a forty-hour path for an event that is a single field edit.

That is why the process starts with one question that settles it: does the registration or tax identifier change? If it does, this is a new entity.

If not, this is a sign over the door.

What happens when the seller's entity no longer exists?

The hardest case is cessation rather than conversion: the death of a person running a sole proprietorship, removal from the register, insolvency. You are left with open orders, a balance, and complaints, and the contracting party is gone.

This is a question for a lawyer. Who stepped into the rights and obligations, who may be paid, and who answers to buyers depend on the route by which the entity ceased to exist, and on the jurisdiction.

Your task is narrower and doable: have the data a lawyer can work on. Six things: the last version of the registration data with its date, the contract version and proof of acceptance, the balance split by order, the list of open orders and tickets in progress, the trail of contact with the representing person, and the documents issued to that entity.

Without one of them, the lawyer is not advising. They are reconstructing.

Obligations toward buyers do not disappear (who delivers the buyer's rights), and the tail of obligations after a seller departs is carried by the tail of obligations after a seller leaves.

You almost never get a message saying "we are changing our legal form". You get a request to change the account number or an invoice with a different tax identifier than the one on the account.

Both arrive through a channel where nobody is looking for legal events.

Hence the product rule that handles most of the problem: a change to any of the five fields (tax identifier, registration number, legal name, bank account, representation) starts a process rather than a save. A request, an owner, verification, a decision, a trail, payouts held until it is confirmed.

Count what that costs, because the number is small. With 1,200 sellers and two percent of them changing one of those fields over a year, you have 24 events a year, which is two a month.

Handled as a process at six hours each, that is 144 hours a year, under a month of one person's work. The same 24 events repaired after the fact at forty hours each is 960 hours, which is six months.

Detection is almost seven times cheaper than repair. That is the whole economics of this chapter.

Bar comparison of 144 hours a year handling changes as a process against 960 hours repairing them after the fact.

1. The entity has to be an object separate from the store, and its data has to be versioned

One architectural decision before launch settles whether a conversion costs six hours or forty. The account model is carried by the structure of a seller account.

2. The five identity fields stop being profile fields

They become requests with an owner and a decision, like the tickets from sellers in requests from sellers.

3. The payout has to be able to ask who is entitled today

Not "what account is in the profile", but "which entity was party to this order and who represents it today". Holds and reserves: payout cycles, holds and reserves.

4. The contract has to provide for this before it happens

The balance, the open orders, and the data on conversion, acquisition, and cessation of the entity: three clauses rather than one.

How do you check this with a vendor?

Five questions for the demo, each requiring an answer shown on screen:

  1. Show an order from last year and say how the system knows which tax identifier the seller had then. If the answer is "from the seller profile", the history is overwritable.
  2. Can an entity other than the registered one stand behind a single account, with a transition date? The answer is binary, and it settles the table above.
  3. Move 4,200 offers from one account to another. How long does it take, who does it, and what happens to the page addresses and the links with product pages?
  4. A seller changes their account number: is that a save or a request? Who approves it, whether payouts are held, and whether you can see the previous value.
  5. Try to close an account with open orders and a non-zero balance. Does the platform block it, warn you, or let it through?

Two questions for a lawyer: does this route of conversion carry the contract to the new entity, or require a new one, and who do we pay the balance of an entity that has ceased to exist, and on what basis?

Fifteen minutes today, a history you cannot reconstruct, forever. It comes out at the first question about a past order.

2. A new entity let into selling before the contract and verification

You get orders concluded by an entity you have no contract with, and amounts payable you cannot pay out.

3. A change of bank account treated as a save rather than a request

The cheapest gap in the seller lifecycle and the one with the highest loss per incident.

4. Offers migrated before the tail is settled

The old account is left with orders and returns, and the seller has stopped looking at it.

5. The heavy path fired off for a change of sign over the door

The team learns the process is overblown and works around it at a real conversion.

What do you still have to settle about your own process?

This article does not settle the legal effects of a particular route of conversion. Whether the contract passes to the successor or has to be concluded anew, and who is liable for obligations from before the change, stay open.

Take three families of questions to a lawyer: succession and continuity of obligations on conversion, division and acquisition, issuer data requirements on documents and how long they must be kept, and obligations on a change of entity data and beneficial owners on the anti-money-laundering side.

This article does not describe verification as a process, the versioning of acceptance of documents, the issuer and corrections (who issues which invoice and corrections and credit notes), or the structure of the account: entity, brand, currency, users. This article describes the event.

All the numbers here are openly hypothetical. The arithmetic travels, the values do not: substitute your own number of sellers, your own returns window, and your own offer migration time.

Weeks of calendar time if you run it as a process, and your books if you do not. The panel shows five editable fields; outside the panel are the party to the contract, the recipient of the money, the issuer of documents, and the company the buyer has a claim against, all change at once.

That is why the identifier of an entity is closed and a new one opened rather than overwritten, and why entity data belongs to the order rather than to the profile. The expensive part is the tail: 180 open orders and a thirty-day returns window close around the sixth week, and somebody has to decide which entity sells in the meantime, because a seller losing €150,000 of monthly turnover will decide it for you.

Ask a vendor what happens when you edit a seller's tax identifier, and whether last year's orders still point to the company that made them. Building a marketplace where a change of entity is a process with a transition date rather than five saved fields?

Talk to us about the build.

A marketplace should treat a change of legal form as a new entity with a transition date rather than as an edit to the old one. The old company stops taking new orders, settles its tail, and is wound down; the new one signs its own contract, accepts the terms in its own name, and passes verification before any payout reaches it.

Can a marketplace update a seller's tax number in place?

Updating a seller's tax number in place is the one option that breaks your records. A seller with 3,900 orders, 78 settlements, and 26 commission invoices behind them ends up with every one of those documents pointing at a company that did not exist when they were created.

Overwriting does not change history; it falsifies it.

A change of legal form takes four to eight weeks in practice, and most of that is the tail you do not control. With 180 orders in flight and a thirty-day returns window, the old entity cannot be closed before about the sixth week, and some platforms refuse to close a seller account at all until every order is finished and the balance is at zero.

Ready to build?

We build marketplaces where a change of entity is a process with a transition date, so last year's orders still point at the company that made them.