Marketplace Seller Accounts: Entity, Store, Currency, and Users

A marketplace seller account is the data schema that settles who you pay, who signed the contract, and whose name the buyer sees, which is why a year later it is fixed by migrating history rather than by editing a profile.

A seller account looks like a registration form, and it is really a data schema that settles, for years afterwards, who you pay money to, who signed the contract, and whose name the buyer sees. A year later, you cannot fix it by editing a profile. You fix it by migrating history.

This article breaks down:

• Which 3 objects does a seller account hold?
• Why is a second currency a migration?
• Who may change a seller's bank account number?
• When should one company hold several accounts?

Key insights

• The three objects a seller account has to keep separable are the legal entity, the trade brand, and the store: money goes to the entity, offers hang off the brand, the contract covers the entity, and the delivery promise belongs to the store.
• A second currency is a migration rather than a setting, because a currency carries its own number of decimal places, so adding one a year in touches every amount you have stored and every rounding you have applied.
• Only a dedicated path may change a seller's bank account number: confirmation through a second channel, a second approver, a notification to every user on the account, and a payout held in the meantime, because one unverified change on a seller doing 300 orders a cycle is worth €264,000.
• One company should hold several accounts only when an entity object sits above them, because 60 accounts belonging to 25 entities overstate your supply by almost 9% and let a suspended seller return under a new name.

Why does a seller account meet somebody else's commercial register?

Everything else on the platform you design yourself: categories, commissions, order statuses, catalog rules. Here you reproduce a structure that came into being without you and that you do not know at the moment of registration.

The company on the other side has one name in the register, two or three brands, a warehouse in a different country, and a bank account in a different currency from the one it wants to sell in. Your form has a single field labeled "company name."

The problem is neither new nor local. The entity identification systems used in financial markets exist to separate the party to the contract from the name it trades under, and they answer two questions at once: who is who, and who owns whom.

A marketplace needs both answers: the first settles the payout, the second whether two accounts are one company.

The cost of a mismatch is countable from day one. Assume 400 sellers, one in ten of whom has more than one brand or sells in more than one currency: that gives you 40 companies your model does not handle.

This is not a wish list. It is forty workarounds in your settlement data.

The line for the committee meeting: the structure of the seller account is a data schema decision rather than a setting in a panel. Every mismatch comes back as an invoice you cannot issue or a payout you cannot make.

Which 3 objects does a seller account have to keep separable?

At registration, these three things collapse into the single word "seller." In the data, they are independent.

The legal entity. The party to the contract, the recipient of the money, the taxable person, the addressee of the justifications from the rules on decisions about sellers.

It has a register number and a tax number verifiable against an external source, which makes it the only sensible identity key.

The trade brand. The name the buyer sees on the offer page, in the cart and in the email.

One company can have three of them, and usually it does not want the customer connecting them.

The store. A market with its own currency, country, shipping costs, and delivery promise.

The store, rather than the brand, decides how much the buyer pays and when the parcel arrives.

The rule that settles the model fits into one sentence: money goes to the entity, offers hang off the brand, the contract covers the entity, and the delivery promise belongs to the store. If your schema has one object for all of it, one of those four things will always be wrong.

You find out which one at the first invoice or the first return.

Count it on a single seller. Three brands, each with 300 orders a month, a €1,000 cart: €900,000 of turnover, of which a 12% commission leaves €108,000 with you and sends €792,000 to the seller.

If the account is the brand, you split that €792,000 into three payouts and three balances for the same debtor. Then the first refund leaves you with a negative balance on one brand and no way to net it against the positive balance on another (the ledger behind a balance and chargebacks and an empty seller balance).

If the account is the entity and the brand is an attribute of the offer, you get one payout, one balance and one commission invoice for €108,000.

Why are currency and country dimensions rather than fields?

The market splits here into two classes of solution, and this is a real architectural difference rather than a configuration detail. In the first, the currency belongs to the store: one store means one currency and often one commission grid, so a seller on two markets has to hold two sales accounts.

In the second, the base currency belongs to the whole installation, and a second currency means a second installation. Whichever class you land in, the conclusion is the same.

"We will add a second currency later" is not a setting. It is a migration.

The reason is simpler than it sounds. A currency is not a label next to an amount.

The standard for currency codes gives each one the number of decimal places it uses, and that number differs between currencies. An amount without a currency has no defined precision, so adding a second currency a year in touches every amount you have stored and every rounding you have applied.

Who quotes the price is a separate decision. A seller with 5,000 offers on three markets has 15,000 prices to maintain.

If their integrator sends a single price list, two-thirds of those entries will be empty or out of date. That is 10,000 prices, and an offer with no price in a given currency does not sell.

Converting at an exchange rate moves three questions onto your side: whose rate, from which moment, and what happens on a refund two weeks later (who pays for a refund and the commission on a refunded order).

Country is not currency, and mixing the two is the most common shortcut. Currency governs the money.

Country governs the delivery promise, the return, the document, and the tax. In some solutions, the country is not a first-class dimension.

"Opening a market" then consists of five separate settings rather than one switch. The language layer is covered by a multilingual catalog.

Which users and roles does a seller account need?

A seller is not a person. Behind one account, you usually have the owner, somebody from the warehouse, somebody from accounting, somebody who handles complaints.

And then there is a fifth participant nobody thinks about: the integrator's technical account, which is not a human being. In the rollouts we know, most offers reach the platform through integrators rather than the panel, so in practice that account is the seller's most active user.

The consequence follows straight from the documentation of identity systems: you do not create a non-human identity on an employee's account. A technical account needs its own credential, a narrow scope, an explicit owner and its own path for revoking access.

If the integrator runs on a salesperson's login, the whole catalog stops flowing on the day that person leaves. The ticket you get says "your API is down."

Roles are a measure of maturity rather than an ornament. The canon is simple: a role is a set of permissions, and you assign people to roles rather than permissions to people.

The two failure modes are opposites. Roles that are too coarse mean you cannot take away one dangerous action without taking away half of somebody's daily work.

Roles that are too tangled mean nobody can say what was granted to whom. Practitioners running large installations admit they are not sure what they set on the roles screen.

Operator permissions and impersonation belong to the seller panel.

And the single most important permission in the whole panel: who can change the bank account number. Public anti-fraud guidance is unambiguous: a request to change settlement details is verified through a channel other than the one it arrived on.

The security canon supplies the other half. No single user should hold permissions sufficient to abuse the system on their own, and the working version of that principle is the two-person rule.

So a change of bank account needs a path of its own: confirmation through an external channel, a second approver, a notification to every user on the account, and a window in which the payout is held. The fraud mechanism itself is covered by fraud on a change of bank account.

Count both risks. With 400 sellers and three users per account, you hold 1,200 identities, and at 30% turnover a year that is 360 access revocations, or roughly seven a week.

Nobody does that by hand without leaving gaps. On the other side, a seller with 300 orders in a cycle and a €1,000 cart has €264,000 due for payout after a 12% commission.

One unverified change to one field is worth a quarter of a million euros, with no way back.

When should one company hold several seller accounts?

Several accounts for one company arise for three reasons. The first: different categories, because the seller wants to keep equipment and accessories apart.

The second: negotiated rates, because one line got a different commission and a second account was the easiest way to give it one. The third is the most important, and nobody ever reports it: getting around a suspension.

New name, new email, same company.

Without an "entity" object above the accounts, the sanction ladder from seller quality thresholds can be walked around in five minutes, and your supply report lies. Assume 400 accounts, of which 60 belong to 25 entities: you really have 365 sellers while the plan shows 400.

That is an overstatement of almost 9%. The same error carries over into revenue concentration: two accounts with 6% of turnover each look like diversification, and they are one seller with 12%.

Detection is workable, so long as you compare at entity level rather than account level: a tax number verified in a public register, a bank account number, beneficial owners, the registered address, the same technical integrator account. The decision is yours, and it has to be explicit: you may have many accounts, but you may not have two identities.

If the reason for the second account is a negotiated rate, the problem is that the commission grid attaches to the wrong object. You fix that with a grid per category rather than with an account.

What you will not change later: the assignment of offers, orders, and documents to the object they were created on. Changing the account structure a year in is a migration of history rather than a profile edit.

It has one most common trigger, described as a change in the seller's legal form: a change in the seller's legal form, after which many rollouts require a brand new account.

What does the seller account model change about the rest of your build?

1. Commission attaches to an object. Which one?

The entity, the brand, or the store. The answer decides whether one company can hold two rates with you and whether that is a feature or a hole.

Versioning of terms is covered by the rules on decisions about sellers.

2. The payout, the balance, and the document go to the entity

If the account is a brand, you break one settlement into several and lose the netting between them (payout cycles, holds and reserves, the ledger behind a balance and chargebacks and an empty seller balance), and at invoicing you have to settle who the party is (who issues which invoice and whether you are an intermediary or a seller).

3. The front shows the brand and the entity answers for it

The buyer has to know who they are entering into a contract with, so both objects have to be on the page and must not drift apart (showing who the seller is).

4. You measure quality on a chosen object, and that is a political decision

Thresholds counted on the sales account are gentler than those counted on the entity, because they spread the errors across several baskets.

How do you check a seller account model with a vendor?

Six questions for the demo. Each one requires showing it on screen rather than describing it.

1. Set up a company with two brands and two currencies. How many objects have to be created, how many contracts signed, how many bank accounts entered?
2. Add a second currency to a seller with 5,000 offers and a year of history. What happens to the prices, to last year's orders, and to the balance?
3. Change the bank account number. Who holds the permission, who confirms it, what do the other users on the account see, and is the payout held in the meantime?
4. Show the integrator's technical account. Does it exist without a human being? Does it have its own credentials and scope? What happens to it when an employee of the seller leaves?
5. Suspend a seller, then register a second account on the same tax number and bank account. Does the system let it through, warn, or block?
6. Move offers and orders from one object to another. Is that a function in the panel, a migration script, or "you cannot"?

Two questions outside the demo. For the lawyer: what data about the entity and its representatives you are allowed to require, and how long you may keep it (verifying a seller at the entrance and who controls the personal data).

For finance: whether your accounting system will accept a single payout to the entity for the sales of three brands.

Which mistakes do operators make about seller accounts?

1. The account as a brand

Money and the contract then hang off a commercial object. The consequence: a rebrand by the seller turns into a migration, and a negative balance on one brand cannot be netted against a positive one on another.

2. Currency added later

It looks like a setting. It is a migration of every amount you have stored and every rounding you have applied.

The consequence: history in two regimes, and settlements you cannot reconstruct.

3. One login for the seller's whole company

The consequence is double: the decision trail points at the company rather than the person, so the authorship requirement from the rules on decisions about sellers goes unmet, and an employee leaving either cuts off the rest of the team or leaves them with access forever.

4. The bank account number as an ordinary profile field

The consequence: one change without confirmation through an external channel costs a full payout cycle for the seller, with no way back.

5. No "entity" object above the accounts

The consequence: you do not know how many sellers you really have, revenue concentration is understated, and a suspension is walked around with a new registration.

What do you still have to settle about your own account model?

This article describes the structure rather than the events that disturb it. Verifying identity and beneficial owners belongs to verifying a seller at the entrance; contracts and the versions in which they were accepted, ownership of product data, payouts with their cycles and holds, the panel and impersonation, fraud on a change of bank account, multilingual handling, and registration as a funnel each have a chapter of their own.

A change in the seller's legal form as an event, and the order in which it has to happen, has its own chapter: a change in the seller's legal form.

Nor does it settle what data you are allowed to require, which of it you may show the buyer, and how long you may store it. That depends on your role and your markets.

The mechanisms are carried out by verifying a seller at the entrance, whether you are an intermediary or a seller and who controls the personal data, and you confirm the wording itself with a lawyer before you design the registration form.

All the numbers here are openly hypothetical. The arithmetic travels, the values do not: substitute your own number of sellers, your share of multi-brand companies and your number of markets, because they decide whether column A of the table is a saving for you or a debt.

Summary: What does a seller account have to get right?

Three objects and one permission. The legal entity is the party to the contract and the recipient of the money, the brand is what the buyer sees, and the store carries the currency, the country, and the delivery promise; collapse them into one record and one of those four things will always be wrong.

Currency and country are dimensions of that model rather than fields on a form, which is why a second currency a year in rewrites every amount and every rounding you have stored. Above the accounts sits the entity, without which you cannot say how many sellers you really have or stop a suspended one from registering again.

And one field in the panel is worth more than all the others: the bank account number, where a single unverified change can carry away a full payout cycle.

Ask a vendor to set up one company with two brands and two currencies in front of you, then change its bank account. Building a marketplace where the entity, the brand, and the store are separate objects from the first migration?

Talk to us about the build.

Frequently asked questions on marketplace seller accounts

How should a marketplace model a seller account?

A marketplace should model a seller account as three separable objects: the legal entity, the trade brand, and the store. The entity is the only sensible identity key, because it has a registration number and a tax number you can verify against an external source.

The brand is an attribute of the offer, and the store carries the currency, the country, and the delivery promise.

Can one company hold several seller accounts?

One company can hold several seller accounts, as long as an entity object sits above them and ties them together. Without it, your supply numbers are wrong in two directions: 60 accounts belonging to 25 entities overstate the seller count by almost 9%, and two accounts with 6% of turnover each look like diversification when they are one seller with 12%.

Who should be allowed to change a seller's bank account number?

Changing a seller's bank account number should sit behind a path of its own rather than on an ordinary profile screen. Public anti-fraud guidance is consistent on this: a request to change settlement details is verified through a channel other than the one it arrived on, with a second approver, a notification to every user on the account, and the payout held while it is confirmed.