Nordic and EU wholesale groups rarely sell from one legal company alone. A Swedish AB may own stock, a Finnish Oy may invoice local retailers, and a German GmbH may hold another range—yet buyers still expect one login. Multi-entity B2B wholesale is how you give them that single branded experience without collapsing catalogues, VAT identity, warehouses or accounting into one messy pot.
This article explains how a distributor portal can route each order to the right legal company for price list, stock, VAT and invoice—and what should sync into Fortnox per company so finance is not left reconciling by hand.
What is multi-entity B2B wholesale?
Multi-entity B2B wholesale is a selling model in which a group operates more than one legal entity (separate companies with their own VAT numbers, books and often warehouses) but presents a unified ordering surface to approved retailers and distributors. A legal entity is the company that contracts, invoices and reports tax—not a brand name or a sales region label.
In practice, the portal holds one retailer identity (login, ship-to addresses, buyer users) and many sell-from relationships: which entities that retailer may order from, which multi-currency price lists apply, which stock pools are visible, and which company will be the invoicing entity on each order.
Several company buildings feeding one shared storefront gateway
Why do Nordic and EU groups run several legal selling companies?
Groups split selling companies for ordinary commercial and tax reasons—not for portal convenience. Common drivers include local VAT registration where you hold stock or have a fixed establishment, ring-fencing credit and liability by market, separate brand or channel ownership, and historical acquisitions that never fully merged.
Cross-border B2B goods supply also pushes structure. Place-of-supply and invoicing rules depend on who supplies, where goods are dispatched from, and the buyer’s VAT status.[1] Intrastat and related statistical reporting can apply when goods move between member states.[2] None of that disappears because marketing wants one website. The job of multi-entity design is to encode those realities in order capture—not to paper over them with duplicate logins.
What breaks when you force retailers onto separate logins per company?
Separate logins per company feel simple to IT and disastrous to buyers. Retailers re-enter assortments, forget which password belongs to which market, and open duplicate purchase orders for stock that sits in another entity’s warehouse. Sales teams field “which shop do I use?” tickets instead of selling. Finance still re-keys or manually assigns invoices because the frontend never carried invoicing entity in the first place.
A retailer single sign-on experience across the group fixes the human problem only if the backend still stamps every cart line with entity, VAT identity, warehouse and price list. One login without that routing is theatre.
How do you present catalogues and stock from multiple entities in one portal?
A catalogue per entity is the clean default: SKUs, case packs, languages and multi-currency price lists are owned by the company that sells them. The portal then composes what each retailer may see—union of allowed entities, filtered by territory, assortment rights and contract.
Stock and warehouse assignment should follow the same grain. Show availability from warehouses the chosen selling entity may ship from; do not sum group stock into one fake number if another company cannot legally or operationally fulfil. When the same GTIN exists in two entities, treat them as separate sellable offers (entity A / entity B), not one ambiguous tile.
Practical patterns that work:
- Entity badge on product and cart lines so buyers know who will invoice
- Warehouse or ship-from hint when lead time or cut-off differs
- Price list and currency resolved from the retailer–entity relationship
- Clear split carts or a single cart that may not check out until lines share a compatible invoicing path (group policy choice—document it)
Product tiles each marked by a distinct company seal before a shared basket
Cross-entity catalogue wholesale is fine for browsing; fulfilment and invoice still need a single responsible company per order or per order split.
How should VAT identity and invoicing entity be chosen per order?
VAT identity is the supplier VAT number (and related registration) under which the supply is reported. The invoicing entity is the legal company named on the invoice and in the contract of sale. In a well-run multi-company wholesale portal they are the same company for a given order line set—or the order is explicitly split.
Choose them with rules, not free text at checkout:
- Buyer and ship-to context — domestic vs intra-EU B2B, VAT number present and validated, delivery country.
- Dispatch context — which entity’s warehouse ships (ship-from drives more than logistics).
- Contract context — which entity the retailer is onboarded to buy from for that range.
For intra-EU B2B goods, valid buyer VAT identification and correct supplier identity underpin reverse-charge style treatment where applicable; invalid or missing numbers should block or flag before fulfilment.[1] Use VIES VAT number validation at onboarding and at order time so stale IDs do not reach the invoice.[3] Broader EU VAT compliance for B2B wholesale belongs in the same design review as portal routing.
Pro forma, order confirmation and commercial invoice must all show the same invoicing entity, VAT number, company address and payment details. Changing the stamp after pick is how credit notes multiply.
An order path splitting toward two invoice stamps and one delivery truck
How do multi-warehouse and ship-from rules interact with legal entities?
Warehouses are not legal entities—but stock is usually owned by one. Multi-warehouse rules should ask: which company owns or may dispose of this stock, and which company is the seller on the order? Prefer ship-from options that keep ownership, seller and invoice aligned. If one entity sells while another’s warehouse ships, you need an internal process (intercompany sale or stock transfer) before or beside the external invoice—otherwise Intrastat, inventory and revenue land in the wrong place.[2]
Treat multi-warehouse EU ship-from rules as part of entity design: cut-offs, carriers and packing slips inherit ship-from; tax and ledger inherit seller. When those disagree, stop and split the order rather than “ship mixed and fix in finance.”
What should retailers see when they log in once across your group?
After one login, retailers should see a calm, branded workspace—not an org chart. Typical contents:
- Assortments and price lists for every entity they are approved to buy from
- Stock truth for the warehouses those entities can ship from
- Open orders, invoices and credit notes labelled by invoicing entity
- Users and roles for their own staff (who can order, who can see cost, who can approve)
- Entity-specific terms, MOQs and cut-offs where they differ
They should not need to understand your group legal structure beyond “this order is sold by Company X.” Onboarding still collects VAT numbers, billing entity on their side, and ship-to master data once, then maps trading relationships to your companies. Retailer self-service roles and controls keep buyer permissions tidy without giving every user every entity.
How do you structure roles, credit limits and price lists across entities?
Credit limit per company is the safe default: exposure, insurance and collection live on the legal seller. A group-wide courtesy view of total exposure is optional for sales—enforcement stays per entity. Payment terms can follow the same relationship (see your net terms policy per company, not one informal side deal).
Price lists: attach multi-currency lists to the retailer–entity pair (or segment). Customer-specific pricing, rebates and promotions should name the funding entity so margin reports match invoices.
Internal roles: group admins configure entities; entity ops manage their catalogue and warehouses; sales may represent several entities but every quote still carries one seller. Do not let “brand admin” imply permission to move another company’s stock without intercompany rules.
What data should sync to Fortnox for each legal company?
Each legal entity needs its own books. In a multi-entity wholesale setup, Fortnox sync should target the organisation that matches the order’s invoicing entity—never a single dump drawer for the whole group.
Per legal company, sync at least:
- Customer master — billing name, org/VAT numbers, addresses, payment terms, credit settings as you maintain them for that seller
- Articles / prices — the SKUs and price lists that entity sells
- Orders and order changes — including warehouse/ship-from references you rely on operationally
- Invoices and credit notes — order-to-invoice output from the same entity that captured the sale
- Stock movements where you integrate inventory—only for warehouses that company owns
Shared retailer login IDs in the portal must map to the correct customer record in each company’s books (often one customer per legal entity, linked by external id). Fortnox wholesale integration per company is the operational checklist; accounting accuracy still depends on not mixing entity payloads.
Parallel ledger books each receiving their own order ticket from one central desk
If goods cross entities before external sale, record the intercompany leg in the ERPs first. Portal automation should not invent revenue in the company that merely held stock.
Putting the model to work
Order-to-invoice automation only pays off when entity, VAT identity, warehouse and price list are fixed at capture. Start from retailer onboarding maps, catalogue ownership and your per-company Fortnox list; then hide the complexity behind one branded storefront.
Brandgate is built for Nordic and EU wholesale teams that need a branded distributor portal with multi-currency catalogues, VAT-aware invoicing and native Fortnox paths—without forcing retailers through a maze of logins. If you are structuring multi-entity B2B wholesale and want to see entity-aware ordering in practice, book a demo or see pricing.