Shopware B2B: check component fit before estimating development
A dealer can see the catalogue in Shopware but cannot submit a cart for approval. The team is already planning a separate module, although the cause may be the version, commercial plan or a feature not enabled for that customer. Assess Shopware B2B against the specific installation, not a presentation's feature list. First check component availability, then its configuration, and only then the need for development.
Fit-gap means comparing a business requirement with what works and identifying the gap. The result is an evidence-based solution map: core functionality, an official commercial component, a third-party extension or custom development.
1. Record the installation baseline before discussing features
Record the full installed Shopware version, deployment model, current plan and contractual entitlements. Separately record the version and status of Shopware Commercial, active B2B components, third-party extensions, theme and custom changes. “Shopware 6” is not enough: it does not explain which capabilities your particular store has or what prevents an update.
Plan, extension and activation are separate conditions
According to official documentation checked on 10 November 2026, B2B Components are available from the Evolve plan through the Shopware Commercial extension. So “includes B2B” does not mean every feature is included in every installation or the free core. An entitlement also does not prove that the necessary extension is installed, active and configured.
The documentation lists Employee Management from Shopware 6.5.6.0 and order approvals from 6.5.8.0, both with the Evolve plan. These are the versions where capabilities were introduced, not a recommendation to remain on those old releases. Before making changes, check current platform and Commercial compatibility; do not choose a version on the basis of a single B2B scenario.
2. Check exactly who has components enabled
The B2B Components documentation describes several levels of availability. Features for an individual customer are enabled in the administration customer record under Customers → Overview. For a customer group, B2B features can be preset for registration; this requires activating the group's corresponding customised registration form.
Global defaults under Settings → Customer → B2B Components apply only to newly created business customers. They do not update existing companies in bulk. If a feature appears for a new dealer but is missing for an existing one, first compare their settings. Do not commission a migration script before establishing whether the issue actually requires a data change.
3. Build a coverage matrix, not a wish list
A component compatibility matrix must start with a verifiable outcome. Instead of “we need corporate roles”, write: “a company employee creates a cart but cannot complete the order without the specified approval”. The business logic of roles can be clarified separately using the article on a B2B self-service portal; the task here is different — to locate the mechanism in a specific Shopware installation.
| Criterion or requirement | Where to look for coverage | Evidence required |
|---|---|---|
| Managing company employees | Employee Management in B2B Components; check version, plan and activation | A test employee receives only the agreed permissions |
| Approval before placing an order | Order Approvals; check availability and rules | A prohibited bypass does not create an order; the permitted route completes |
| An existing standard store scenario | Check core settings first; do not buy a duplicate | A reproducible test without an additional module |
| Special contract or ERP logic | Check available tools and extensions; describe the remaining gap separately | Consistent results in the store and accounting system |
| A third-party module for the required feature | Compatibility of the specific release, licence and support terms | A test alongside Commercial, the theme and other extensions |
For every row, add priority, business-rule owner, implementation method, dependency and status. Useful statuses include “confirmed by test”, “configuration needed”, “update needed”, “investigation needed” and “gap”. Do not label an unknown capability as custom: unfamiliarity with the documentation is not evidence that a ready-made mechanism does not exist.
4. Separate configuration, extensions and custom development
Estimates often use “native” to mean different things. Distinguish the Shopware core from official commercial components: the latter do not become free core functionality simply because the platform vendor produces them. A third-party extension has a different supplier and its own support cycle. Custom development means code and responsibility assigned to your team or contractor.
When configuration is enough
If the required workflow can be fully reproduced by activating a component and configuring rules, estimate configuration, testing and training rather than building the feature from scratch. Ask for a demonstration using the agreed configuration. The deliverables should include a settings description, test data and a criterion for repeating the check after an update.
If a ready-made tool covers only part of a requirement, state the boundary. For example, store approval alone does not prove that an ERP debt check blocks shipment. Contract pricing also requires a separate check of the mechanism and entitlements: availability of B2B Components does not imply availability of every pricing model.
When development is justified
Consider custom development for a specific unmet rule, not for “improving B2B” in general. Describe inputs, outcome, errors, responsibilities and the update approach. Before choosing a third-party module, check not only its feature listing but also conflicts, supported releases, data export and who resolves failures at the boundary with Commercial.
5. Hypothetical example: approval works only for new dealers
This is a hypothetical scenario, not a GL.ua case study. A wholesaler uses Shopware with the Evolve plan, Commercial installed and a version compatible with the required components. A new company has access to the approval workflow, but an existing dealer does not. The business also wants to prevent orders being sent to the ERP when the accounting system reports overdue debt.
The first check is not building a new account area. The team compares component activation for the two companies and the approval rules. Because global settings concern only new business customers, the existing dealer's record is checked separately. If the scenario passes after correct configuration, that matrix row is resolved through configuration.
The debt rule remains a separate gap until the integration is checked. An illustrative acceptance criterion is: when the ERP confirms a prohibition, the order is not sent onwards and the responsible person can see the reason. If the ERP is unavailable, the system follows a previously agreed policy rather than silently assuming there is no debt. This is a requirement of the example, not a promise of native Shopware behaviour.
The solution is split into two tasks: configuring the available component and investigating the debt check. The latter first requires the ERP response format, the moment of checking and the retry rule. Only after testing is a ready-made extension or code selected. This keeps the estimate from mixing a configuration fix with genuinely new business logic.
6. Run sequential tests before launch
Carry out B2B feature acceptance testing in a test environment with the relevant configuration and anonymised data. For each step, record the expected outcome and actual evidence.
- Compare Shopware, Commercial and dependent extension versions against the baseline. Confirm entitlements and the absence of unapproved differences between environments.
- Test an existing and a new business customer separately, registration through the group form, and an ordinary buyer. Features must be available only to the agreed customer categories.
- Follow the permitted order creation and approval route. Then attempt to complete it as a user without the required permission and record the rejection.
- Change the cart after approval if that scenario is possible in your configuration. Check that the outcome follows the agreed rule for renewed control.
- Test the ERP response, unavailability and repeat submission. Acceptance conditions must rule out unnoticed order loss and uncontrolled duplicates.
- Reproduce critical scenarios after the planned update on a test copy. Check recovery and rollback before changing production.
7. Assess risks, cost components and timeline dependencies
The main risk is treating a component name as a fulfilled requirement. Other risks include an incompatible third-party module, different environment settings, changes in contractual availability and custom code without regression tests. Define detection methods and an owner for each. In particular, check whether two modules duplicate one process or modify the same data.
Costs comprise inventory and fit-gap analysis, plan and extension entitlements, updates, configuration, integrations, development, testing and training. Add test-environment infrastructure, support and repeated checks after releases. These are separate cost items: one-off development does not eliminate recurring payments and maintenance.
Timelines depend on access to the installation and contract, update status, module compatibility, ERP readiness and how quickly rules are approved. The sequence is: baseline → availability check → demonstration of the risky scenario → gap assessment → implementation → acceptance. An unknown integration should not be hidden behind an exact calendar deadline in the overall estimate.
After fit-gap analysis, you can prepare a comparable request for contractors: confirmed components, unmet requirements, evidence and exclusions. The article on RFI, RFP and RFQ for an online store can help you choose the procurement format. Feed it verified boundaries, not assumptions that any B2B wish is included in the plan.
8. Decide on the basis of gaps, not the platform brand
A good assessment produces a short list of confirmed capabilities, settings, dependencies and separate development tasks. If your existing Shopware setup covers critical scenarios, the complexity of initial configuration alone is no reason to change platforms. If the gaps are significant, compare options using identical acceptance rules and the full cost of support.
To discuss the business architecture of a Drupal web system, contact GL.ua (Glyanec) through the business website development page. Prepare a requirements map, data owners and verified gaps. This is a basis for a focused consultation, not a promise of Shopware implementation or a recommendation that you must replace your platform.
Just one step to your perfect website
