A corporate group rarely grows in a straight line. One business becomes a sales entity, a manufacturing plant and an acquired specialist dealer, each with its own company code in the ERP. Sales still wants a single shop: one catalogue, one login, one cart. The real work sits between that wish and the accounting department, because every entity carries its own item numbers, its own number ranges, its own warehouses and its own tax codes. Rebuild that separation in the shop and you end up running three shops. Ignore it and you produce documents that accounting can no longer assign. This article shows how a multi-entity middleware keeps the separation where it belongs, namely in the rules, and how ERP integration for wholesale manages without a second shop after the next acquisition.
Key takeaways
- One shop can serve several ERP entities as long as every cart line carries exactly one supplying company. That assignment belongs in a routing rule inside the middleware, not in the shop's item master.
- Overlapping assortments need a business key that sits above the entity. The GTIN, in Europe typically with 13 digits (GS1), and the GLN with 13 digits per location and legal entity (GS1) work as anchors when internal item numbers collide.
- Invoice numbers may run in separate ranges per entity: what is required is a sequential number assigned once by the issuer (German VAT Act). Accounting vouchers have to be retained for 8 years, books and annual accounts for 10 years (German Fiscal Code).
- Currency and tax determination depend on the supplying entity, not on the shop. Above 10,000 euros of union-wide distance sales and electronic services, taxation moves to the country of destination (European Commission), and the recapitulative statement is due monthly above 50,000 euros per quarter (German VAT Act).
- When a cart touches two entities, two orders and two invoices are created. For the customer it stays one order, provided order splitting, shipping cost logic and status display are designed together.
Why groups run several entities and still want one shop
Entities in an ERP are not a technical indulgence; they represent legal entities. As soon as a parent company exercises a controlling influence over another company, consolidated accounts become mandatory (German Commercial Code), while each subsidiary remains independent in bookkeeping terms and prepares its own annual accounts. On top of that come reasons that weigh even more heavily in day-to-day business: a country entity needs its own VAT registration, an acquired business brings its established number ranges and terms with it, and a manufacturing plant values stock differently than a trading business. Remove that separation in the ERP and you lose the basis for tax filings, closing and tax audits. Multi-entity separation is therefore not legacy baggage that a shop rollout clears away in passing, but a fixed constraint.
Sales looks at the same group from the other side. The buyer on the other end orders tools and consumables in a single transaction and has no interest in which company code the goods come from. Two shops mean two sets of credentials, two carts and two free-shipping thresholds. Every additional step in the ordering process costs conversions: across a large number of evaluated studies, the documented cart abandonment rate sits at roughly 70 % (Baymard Institute). The task is therefore not to merge the entities but to keep them invisible in the front end and cleanly separated in the back end. The integration layer sits exactly in between.
Which entity supplies which item
The fundamental decision is this: every cart line carries exactly one supplying entity. Not the customer, not the order, but the individual line. Once that is settled, warehouse, number range, currency and tax determination can be derived from it instead of being maintained one by one. Where the assignment comes from is a question of data ownership, settled in principle by master data synchronisation between ERP, shop and CRM. In practice a handful of criteria evaluated in a fixed order is usually enough. What matters is that the rule lives in one place and does not have to be maintained three times over as a special case in shop, ERP and shipping software.
Assortment split
If exactly one entity carries a product group, the assignment is static and can be stored on the item master.
Delivery country
Shipments to certain countries run through the local entity because registration, customs and returns depend on it.
Availability
If two entities carry the same item, stock at the default warehouse decides, backed by a fixed order of precedence.
Customer mapping
A framework agreement with one entity ties the order to that company, even when another one could also supply it.
Commercial terms
Price lists and discount tiers exist per entity, so the assignment also determines which price applies.
Fallback rule
If no rule matches, a defined default entity applies. Silently guessing the assignment is the more expensive route.
Duplicate item numbers and overlapping assortments
Two grown entities carry the same screw under two numbers, and somewhere they carry two different items under the same number. Both are normal, and both break a shop that uses internal ERP numbers as its key. The way out is a key that sits above the entity. Commercially traded items carry a GTIN, in Europe typically with 13 digits (GS1); locations and legal entities can be identified unambiguously through the GLN, also 13 digits (GS1). Where no GTIN exists, a composite key of entity identifier plus internal number takes its place. How that mapping is built and documented in technical terms is covered in detail by the article on data mapping between ERP and shop.
The business key belongs above the entity
# Assignment per cart line: which entity supplies it
key: GTIN, otherwise entity identifier + internal number
rule 1: assortment = "tools" -> entity 1000
rule 2: assortment = "consumables" -> entity 2000
rule 3: delivery country in (NL, BE, LU) -> entity 2000
rule 4: stock(1000) = 0 and stock(2000) > 0 -> entity 2000
default: -> entity 1000
line.entity = first matching rule
line.warehouse = default_warehouse(line.entity)
line.numberrange = order_range(line.entity)
line.tax = home_country(entity) + delivery country + vat idEntity-specific number ranges for orders and invoices
As soon as the shop writes orders into several entities, each company needs its own number range. That is not tidiness but a precondition for auditable accounting. An invoice has to carry a sequential number assigned once by the issuer (German VAT Act) - several separate series are explicitly permitted, as long as no number appears twice within a series. Retention matters just as much: accounting vouchers have to be kept for 8 years, books, inventories and annual accounts for 10 years (German Fiscal Code). Writing documents from two entities into the same range creates an assignment problem at the next audit that is hard to resolve after the fact. Those rules belong in the ERP inventory integration and not in a script somebody wrote three years ago.
- One range per entity and document type: separate series for order confirmation, delivery note, invoice and credit note, each with a prefix that makes the company code recognisable.
- Assignment in the leading system: the number is created where the document is posted, which is the ERP. The shop displays it but does not invent it.
- Keep the shop reference separate: the shop's order number is a distinct identifier for the customer and does not replace the entities' document numbers.
- Avoid gaps, log aborts: numbers that were reserved but not posted should stay traceable so that a gap in the series remains explainable.
- Secure the return path: cancellations and credit notes run in the range of the same entity, otherwise the original and the correcting document do not match in the books.
Currencies and tax codes per entity
Currency depends on the supplying entity and its price list, not on the language selected in the shop. Technically that is unspectacular, because currencies are identified by three-letter alphabetic codes (ISO) and countries by two-letter codes (ISO). The work begins on the business side: a catalogue price in euros, a Swiss sales entity and a customer with a framework agreement in local currency produce three pricing paths that have to be stored per entity and evaluated per cart line. Rounding rules and exchange rates belong in the leading data set of the ERP so that shop and invoice show the same amount.
For tax, the combination of the supplying entity's home country, the delivery country and the customer's status decides. For intra-community distance sales to private customers a union-wide threshold of 10,000 euros applies; above it, taxation takes place in the country of destination and is reported through a single point of contact (European Commission). In B2B business the tax liability shifts to the recipient in many constellations (German VAT Act), which requires a reliable check of the VAT identification number; the qualified confirmation procedure provides that evidence (German Federal Central Tax Office). And the recapitulative statement is due monthly above 50,000 euros per quarter (German VAT Act). How that logic is implemented in the checkout without special cases in the code is shown by the article on tax determination in the B2B shop.
| Criterion | One shop per entity | One shop across all entities |
|---|---|---|
| Catalogue upkeep | Once per shop, multiplied effort | Once centrally, routing determines the origin |
| Customer view | Several logins and carts | One account, one cart, one order history |
| Item numbers | Collisions stay unnoticed | Business key above all entities |
| Number ranges | Separate per shop, unrelated to each other | Separate per entity, traceable on the document |
| Tax determination | Hard-wired per shop | Derived from entity, delivery country and customer status |
| Adding an acquisition | New shop, new project | New entity, extended rule set |
| Operating effort | Grows with the number of entities | Grows with the number of rules |
Warehouses and stock aggregation across entities
Adding up stock across entity boundaries is tempting and wrong in most cases. What sits in the warehouse of the Dutch subsidiary belongs to that subsidiary on the balance sheet; showing it to the customer as availability of the German entity creates a commitment that can only be met through an intercompany sale. A tiered display works better: stock of the assigned entity as the binding quantity, stock of affiliated entities as an extended lead time. The mechanics behind it differ little from inventory synchronisation across several warehouses; the only new element is that every warehouse also has to be assigned to a company code.
Two stumbling blocks show up regularly. First, reservations: when a quantity is blocked in the shop, it has to be clear in which entity it is blocked, otherwise two companies sell the same pallet. Second, the unit of measure. The same goods are kept in pieces in one entity and in packs in another, which quietly distorts any aggregation when the conversion is missing; the pitfalls are covered by the article on units of measure and pack sizes from the ERP. Both points can be defused early if warehouses, company codes and units are maintained in one shared table instead of being collected from three systems.
Customer records held more than once: mapping at login
A customer who has been buying from two entities of the group for years exists twice in the ERP, with two debtor numbers, two payment terms and possibly two contacts. In the shop they should log in once. The answer is one shop account that points to several debtors, rather than one account per debtor. At login the integration layer loads all assigned debtors, derives the released assortments and the applicable terms from them, and establishes the assignment per cart line. Which assortments a customer may see at all is the same question as in customer approval with customer-specific assortments, extended by the entity axis.
Two details deserve particular attention. First, identity: an email address works as a login but not as a business key, because the same buyer may order for two of the customer's sites. Locations and legal entities can be identified unambiguously through the GLN (GS1), which keeps the assignment stable when addresses change. Second, the credit limit: it is kept per debtor, not per shop account. A cart that touches both entities therefore checks two limits, and the display in the checkout has to stay understandable without exposing internal company codes.
When one cart touches two entities
The mixed cart is the normal case in wholesale. As soon as it appears, the integration layer splits it into two orders, one per entity, each with its own number range, its own invoice and its own delivery note. For the customer it stays one order with one order number, under which both partial orders appear in the account. That split is unspectacular as long as three questions have been answered beforehand: how shipping costs are distributed, how a minimum order quantity is assessed, and what happens when one partial order is rejected in the ERP while the other has already been posted.
The alternative to splitting is a chain transaction: one entity sells to the customer and sources the goods internally from its sister company. In VAT terms that is no side issue, because in such a chain only one supply counts as the moved supply (German VAT Act), and how that movement of goods is allocated is regulated union-wide (European Commission). Which route fits is decided by the tax department, not by engineering; the integration layer has to be able to represent both. How the checkout behaves when one entity temporarily stops responding is covered by the article on fallback operation during an ERP outage.
Separation belongs in the rules, not in the interface
Intercompany recharging and separate document filing
When the sister company supplies the goods, an intercompany turnover arises that has to be priced. The benchmark is the arm's length principle: transfer prices between affiliated companies should match the conditions independent third parties would have agreed (OECD). For the integration that means a second price level next to the customer price, maintained and documented per pair of entities. In the consolidated accounts these internal turnovers are eliminated again, among other things through debt consolidation and the elimination of intercompany profits (German Commercial Code). For that to work, the corresponding documents have to reach accounting flagged as intercompany rather than as an ordinary outgoing invoice.
The document path itself runs separately per entity: its own client, its own chart of accounts, its own document ranges. A DATEV integration reflects that by producing a separate export per company code instead of writing everything into one batch. Formal pressure is rising anyway: domestic companies in Germany have had to be able to receive electronic invoices since 1 January 2025 (German Federal Ministry of Finance), and the transition period for sending them ends on 31 December 2027 for companies with at most 800,000 euros of total turnover in the previous year (German Federal Ministry of Finance). How the document handover can be automated in practice is described in the article on DATEV automation in e-commerce.
Permission boundaries and reporting per entity
With several entities, the question of who may see what becomes a business requirement. The sales manager of the German entity should analyse its orders, not those of the Dutch one; group management wants to see both, grouped by entity. What works in practice is a permission boundary along the company code: every role carries a list of permitted entities, and every backend query filters on it before returning data. The same applies to interfaces: an account that may only write orders for one entity considerably limits the damage from a compromised key. How such accounts are scoped, versioned and logged belongs in the design phase of API development rather than in a later hardening pass. Reporting should likewise know two levels: the per-entity view for day-to-day operations and the consolidated view for the group, with the consolidated view flagging internal turnovers clearly.
Rollout sequence for acquisitions
- Start with the entity with the highest turnover: it produces the most special cases and therefore the most robust rule set for all further companies.
- Survey assortment overlaps up front: before connecting, clarify which items are carried in several entities and which key brings them together.
- Begin read-only: first read catalogue, prices and stock of the new entity and verify them hidden in the shop before orders are written back.
- Accept number ranges and tax codes: pull one complete test document per entity through SAP or another leading system all the way into accounting.
- Merge customer records: map existing debtors of the acquired business onto existing shop accounts and resolve duplicates before activation.
- Hand over rule set and operations: hand over routing rules, entity assignments and monitoring in documented form so that the acquisition after next needs no archaeology; the basis for this is a multi-entity middleware with cleanly separated rule sets per company.
A shop does not become multi-entity capable by hiding the companies, but by being able to assign every single line to one of them.
Sources and Studies