B2B Customer Groups, Roles & Permissions in Shopware
In B2B, a single person rarely does the buying. Behind an order stands an organisation with departments, budgets, approval paths and different responsibilities. According to Forrester, an average of 13 people (Forrester State of Business Buying, 2024) are involved in a B2B buying decision, and 89 percent (Forrester State of Business Buying, 2024) of purchases touch two or more departments. A B2B store that fails to map this reality forces business customers into processes that do not match their buying organisation. This article shows how to implement customer groups, company accounts, role and permission models, plus budgets and approvals in Shopware so that digital buying respects the established structures of your customers - and thereby becomes their preferred ordering channel.
Why B2B Needs More Than a Single Customer Account
In B2C, one account per person is enough: one login, one address, one means of payment. In B2B, by contrast, the customer is not a person but a company with several people buying, one or more approvers, and an administration that defines who may do what. This difference is not a detail; it determines whether a buyer can use the store at all. McKinsey reports that 79 percent (McKinsey B2B Pulse, 2025) of B2B buyers prefer to place repeat orders online - but only if the system reflects their way of working rather than slowing them down.
A company account bundles several users under a shared roof: they share the negotiated terms, the delivery addresses, the payment methods and the order history of their company. At the same time, every user has an individual login and a role that defines which actions they may perform. It is precisely this combination of shared context and individual rights that makes up a company account. Sana Commerce finds that 85 percent (Sana Commerce B2B Buyer Report, 2025) of B2B organisations now run an online store or self-service portal - the standard is set, and buyer expectations are correspondingly high. How such a portal is built as a whole is covered in our article on B2B customer portals.
Customer Groups
Control prices, the visibility of assortments and net or gross display. A reseller sees different terms than an industrial customer or an open guest.
Company Account
Bundles several users of a company under shared terms, addresses and a shared order history - with an individual login per person.
Roles and Permissions
Define per user which actions are allowed: ordering, approving, managing users or viewing prices - following the principle of least privilege.
Approvals
Orders above a limit are not placed directly but go to an approver for review - the approval path from real-world procurement.
Budgets
Monthly or project budgets per user or cost centre cap the order volume and make spending plannable and traceable.
Cost Centres
Orders can be assigned to cost centres or projects, which considerably simplifies later booking and the customer's internal reporting.
Customer Groups: The Foundation of B2B Differentiation
In Shopware open source, the customer group is the central lever for distinguishing business customers from private customers and resellers from industry. It controls several things at once: whether net or gross prices are shown, which prices and tiers apply, which assortments are visible at all, and which payment and shipping methods are available. Since 65 percent (Boston Consulting Group, 2025) of B2B revenue already flows through digital or digitally influenced channels, this differentiation must take effect online just as precisely as in personal sales.
In practice, you map typical customer groups such as resellers, industrial customers, retailers or end customers. Each group receives its own pricing logic and visibility. One group may see only a partial assortment, while another has access to the full range. The activation of new business customers can also be controlled via groups: newly registered companies first land in a group with restricted rights and are moved into the appropriate target group manually or automatically after the VAT ID and business registration have been verified. How closely customer groups are interwoven with price resolution is shown in our article on price lists and tier pricing.
Separate Customer Group and Sales Channel
Company Accounts and Multi-User Structures
A company account is the digital representation of the buying organisation. Under one corporate account sit several user accounts that share the negotiated terms, delivery addresses, stored payment methods and the common order history. This has immediate practical benefits: a new employee in procurement does not have to be re-activated or set up with terms again but is simply created as a user by the company's administrator and assigned a role. When someone leaves the company, their access is deactivated without the history being lost.
This structure matches exactly how B2B buying actually works, and it pays off: Sana Commerce finds that 71 percent (Sana Commerce B2B Buyer Report, 2025) of professional buyers say the availability of self-service influences their loyalty to a supplier. A company account that knows several buyers, clear roles and traceable permissions is therefore not a technical extra but a retention instrument. In Shopware open source, this multi-user logic is mapped via B2B extensions or bespoke development depending on the requirement, the scope of which we define together in e-commerce consulting.
- A company account bundles several users under shared terms
- Every user has an individual login and an assigned role
- Delivery addresses, payment methods and order history are shared
- The company's administrator creates users and assigns roles
- Departed employees are deactivated without data loss
- Orders remain traceable even when staff changes
Role and Permission Model: The Principle of Least Privilege
A well-thought-out role model answers a simple question: who may do what? Instead of assigning rights to each user individually, rights are bundled into roles, and every user is given one or more roles. This approach is called role-based access control (RBAC) and was formalised as standard ANSI/INCITS 359 by the National Institute of Standards and Technology (NIST). It considerably reduces administrative effort, because new employees immediately receive the appropriate rights through their function, and it makes permissions auditable.
The guiding rule is the principle of least privilege: every role receives exactly the rights needed to fulfil its task and none beyond that. The OWASP Foundation lists this principle in its Authorization Cheat Sheet as a fundamental recommendation for secure applications (OWASP). In the B2B store this means concretely: a buyer may fill a cart and use order lists but may not place orders above their limit themselves. An approver may review and approve as well as manage budgets. Only the administrator may create users, assign roles and change the configuration. This clean separation of creating and approving is not only common in procurement but often also a compliance requirement.
| Role | Typical Rights | Limits |
|---|---|---|
| Buyer | Fill cart, use order lists, view prices, place orders up to limit | No approvals, no user management, bound by budget |
| Approver | Review and approve orders, manage budgets, higher limit | No creation of new users, no change of configuration |
| Administrator | Create users, assign roles, maintain addresses and configuration | Should not bypass any operational order limit themselves |
| Observer | View order history and reports, download documents | No orders, no approvals, read-only |
| Cost-centre manager | Assign and analyse orders for a cost centre | No cross-organisation user management |
Do Not Cut Roles Too Finely
Budgets and Spend Control
Budgets transfer the spend control of procurement into the store. A user or a cost centre receives a monthly, quarterly or project budget against which every order is booked. Once the budget is exhausted, further orders are blocked or require an approval. This creates predictability on the customer side and prevents unplanned spending. That this need is real is shown by the figure for so-called maverick spend, that is, buying outside the agreed processes: procurement analysts put the savings lost as a result at 10 to 20 percent (Ivalua, 2025).
It is important to think of budgets and approvals as a connected system. A budget limit is the ceiling for a user; an approval threshold is the value above which an order must additionally be approved. The two can be combined: a buyer with a 2,500 euro monthly budget can order freely below it, while above it approval by a superior applies. This keeps routine buying fast while larger spending is controlled. What matters is that the thresholds are derived from the customer's real buying rules - an aspect we clarify at the start of every project as part of our B2B e-commerce services.
Show the Budget Transparently
Approval Workflows for Orders
The approval workflow is the heart of the buying organisation inside the store. It mirrors what the approval path is in real-world procurement: a buyer assembles a cart, in doing so exceeds their limit or a defined threshold, and the order is not placed immediately but forwarded as an approval request to an approver. The approver reviews the request and can approve it, reject it or return it with a query. Only after approval is the order placed bindingly. For many business customers this mechanism is a basic prerequisite for being allowed to use the store officially at all.
Several details are decisive in the implementation. The workflow must send notifications to the right people so that approvals do not get stuck - because research into procurement shows that slow, sluggish approval processes themselves become a driver of buying outside the rules (Ivalua). An order that waits days for approval leads employees to bypass the official path. A good workflow is therefore fast, transparent and equipped with clear deputy rules so that absences do not become blockages. The entire order completion benefits considerably, as our article on B2B checkout optimisation shows.
{
"companyAccount": "K-10482",
"role": "buyer",
"user": "a.schmidt",
"budget": {
"period": "monthly",
"limit": 2500.00,
"currency": "EUR",
"spent": 1840.00
},
"approvalRules": [
{
"trigger": "cartTotalNet",
"threshold": 2500.00,
"approver": "approver",
"notify": ["email", "portal"]
},
{
"trigger": "paymentMethod",
"value": "invoice",
"approver": "approver"
}
]
}The example shows a typical rule structure: per company account and user, a budget with a period and limit is maintained, and approval rules define which trigger above which value obliges whom to approve. It also becomes visible here that the payment method itself can trigger an approval - for instance when buying on invoice runs against a credit limit. How buying on invoice, credit limit and payment approvals interact is explored in our article on payment methods, buying on invoice and credit limits.
Order Lists, Reordering and the Role Context
Roles and permissions only unfold their value in interplay with the daily workflows of buyers. A central example is order lists and quick order: a buyer maintains recurring needs in lists from which they generate a cart at the click of a button. McKinsey reports that 79 percent (McKinsey B2B Pulse, 2025) of B2B buyers prefer to place repeat orders online - and it is precisely this use case that depends on a clean role assignment. The buyer may create and use lists, but placing larger orders remains subject to the budget and approval logic.
This is where it becomes clear why roles, budgets and ordering processes must not be viewed in isolation. An order list that a buyer turns into a cart with one click can exceed the monthly limit and thus trigger an approval - the system must recognise this and guide it cleanly through the workflow without confusing the user. How quick order and order lists are implemented concretely, and what role permissions play in this, is described in our article on quick order and order lists. The goal is always the same: routine fast, exceptions controlled.
Order Lists per User
Every buyer maintains their own or shared lists of recurring items and generates a cart from them with one click - within the scope of their role and their budget.
Reordering
Earlier orders can be placed again. If the reorder exceeds the limit, the approval process kicks in automatically.
Shared Templates
The administrator can provide standard lists for the entire company account, for instance for recurring project needs or consumables.
Traceability
Every order is assigned to a user, a role and, where applicable, a cost centre - which makes the customer's internal reporting robust.
Security, Data Protection and Governance
A role and permission model is always also a security question. Whoever has access to a company's prices, order histories and payment methods is moving in sensitive territory. The principle of least privilege is not just convenience here but protection: the fewer rights a compromised login carries, the smaller the possible damage. The OWASP Foundation has for years listed broken access control as one of the greatest application risks (OWASP Top 10). A clean server-side check of every permission - not merely hiding buttons in the frontend - is therefore mandatory.
Added to this are data-protection aspects under the GDPR. Personal data of the users of a company account may only be processed for the agreed purposes, and when an employee leaves it must be clearly governed what happens to their access and their data. A well-thought-out model cleanly separates the corporate account that carries the business relationship from the personal user accounts. Such governance questions belong in every serious B2B project and are addressed early in our e-commerce consulting so that they do not become a problem later.
Check Permissions Server-Side
ERP Integration: One Truth for Accounts and Terms
In most companies, the leading truth about customers, terms and partly also about buying organisations lives in the ERP system. Customer numbers, credit limits, framework contracts and cost centres are maintained there. In this architecture the store is not the leading system but an ordering and self-service channel that consistently mirrors the data held in the ERP. A clean integration ensures that a company account created in the ERP, with its terms, is automatically available in the store as well - and that budgets and credit limits do not have to be maintained twice and inconsistently.
Which data the leading system supplies and which the store manages itself is a central design decision. Frequently the master data of the company account, the terms and the credit limit come from the ERP, while the fine-grained role and budget assignment is maintained in the store because it sits closer to ordering practice there. A clear, documented split is important so that no contradictory states arise. How such an integration is built robustly and performantly is described in our article on API architecture, and concrete project approaches are shown in our references.
From the Standard to the Right Buying Organisation
Shopware open source provides a solid foundation with customer groups, sales channels and the administration's permission concept. For pronounced B2B requirements - multi-stage approvals, fine-grained budgets, cost centres and complex company hierarchies - these building blocks are supplemented by B2B extensions or bespoke development. What matters is not activating as many functions as possible but mapping exactly the structure that the customers' buying organisation actually has. A mid-market reseller with three buyers needs a different model than a corporation with hundreds of users and multi-stage approval paths.
That is why every good permission project begins not with the technology but with the question of how the customer actually buys: who orders, who approves, which budgets and cost centres exist, and what the approval paths look like? From these answers a permission concept emerges that is then implemented cleanly in technical terms. Anyone who skips this step and activates functions without a concept builds up complexity that is hard to maintain later. Sound Shopware development therefore thinks of customer groups, roles, budgets and approvals as a connected system from the start - and thereby creates an ordering channel that business customers experience as professional and trustworthy.