A B2B platform implementation on Magento 2 for manufacturers and wholesalers
A platform matched to the rules of your sales. We design, build and integrate B2B platforms on Magento 2 for manufacturers and companies selling to business customers. We move individual price lists, company accounts, user roles, order placement and after-sales service into the platform.
We do not start from a list of modules. We first analyse the sales process, the systems involved and the business exceptions. Only then do we settle the architecture, the implementation scope and the estimate.
- Company account
- users, roles, purchase limits
- Trade terms
- assigned assortment, prices, discounts
- Ordering
- quick ordering, approval, repeat order
- After the purchase
- statuses, documents, order history
Data comes from
- ERP
- PIM
- WMS
- CRM
The scope of a B2B platform: company account, commercial terms, ordering and post-purchase handling
- company accounts and roles
- customer prices and assortment
- orders and approvals
- ERP, PIM and WMS integrations
We move repeat order handling from the sales rep onto the platform
A B2B platform lets customers check the offer, place orders and download documents on their own. Sales reps still own the relationships and the exceptions, but they no longer have to run every repeat task by hand.
We usually start an implementation once the current sales model stops scaling with the number of customers and orders.
- 01
The customer waits for basic information
Availability, the current price, delivery terms or an order status all require contacting an account manager.
- 02
The same order is handled several times
The customer sends an order, a sales rep retypes it into the system, and someone else checks the data or the availability.
- 03
What the customer agreed on stays with the sales rep
Discounts, exceptions, limits and the agreed assortment are scattered between the ERP, spreadsheets and e-mail.
- 04
More orders mean a bigger team
Growing sales bring more and more repetitive operational work.
When we do not recommend Magento 2
If a company serves a small number of customers, has one simple price list and only occasional orders, a full Magento 2 build may not be justified. We assess that before the project starts.
Before we design the platform, we map the whole B2B sales process
We do not start a project from wireframes of the login screen or the catalogue. We first establish how the company recognises a customer, calculates their prices, checks availability and hands the order over to fulfilment.
During the analysis we work with the people responsible for sales, e‑commerce, logistics and the company's systems. We describe the standard customer path and the exceptions the platform has to handle.
The result is a process map, a list of decisions and requirements we can use to design the scope and prepare a credible estimate.
The purchase path of a business customer
- 01
Customer's company
Who can create an account and who approves it? Does the contractor have to exist in the ERP first?
- 02
Company account
Does one company have several users, and who manages them?
- 03
User and role
What permissions and purchase limits does each person have?
- 04
Assortment and prices
What determines the visible assortment, and where are prices and discounts calculated?
- 05
Cart
Is there a logistics minimum, a packaging multiple or a shopping list?
- 06
Approval
Does an order need approval on the buying company's side or the seller's?
- 07
Order
Where does availability come from, and how does the order reach fulfilment?
- 08
Fulfilment
Which system runs the shipment, and which statuses come back to the customer?
- 09
Documents
Which documents does the customer see, and which system are they from?
The analysis produces a functional scope, an integration map and a list of project assumptions. That keeps development from starting on guesses or incomplete requirements.
The key features of a B2B platform on Magento 2
The set we pick a given implementation's scope from. Not every company needs all of it — but it is worth knowing what the platform can do before we start deciding what goes into the project.
Accounts and users
- Company accounts
- The customer is a company, not a single email address. Data, terms and order history belong to the organisation.
- Several users per company
- Procurement, the warehouse and the person approving orders work under one company account, each with their own role and permissions.
Prices and catalogue
- Individual prices and discounts
- A price list attached to a customer or a group, with volume discounts and terms negotiated outside the store.
- Individual catalogue
- The customer sees the range they are entitled to — without products reserved for other channels or markets.
Ordering
- Fast ordering
- A basket built from SKUs or EAN codes, from a saved shopping list or from an imported CSV.
- Reordering
- Repeating an earlier basket in one click — the most used feature in recurring wholesale sales.
Control and payment
- Limits and approvals
- An order above an agreed amount goes to a manager for approval before it is passed on for fulfilment.
- Payment terms
- Deferred payment, a credit limit and terms attached to the customer rather than payment upfront only.
- Documents
- Invoices, specifications and confirmations available in the account, without asking a salesperson to email them.
Integrations
- ERP
- The source of prices, trade terms, stock and order statuses on the fulfilment side.
- PIM
- The source of product data, descriptions and attributes for every sales channel.
- WMS
- Stock levels, picking and shipping information passed back to the store.
- CRM
- Contact history and the account manager, so the salesperson works on the same data as the platform.
Every one of these features needs a decision about where its data comes from and who owns it. We settle that together with the integration design, not after the modules have been chosen.
We design the platform's feature scope from the analysis
We do not implement every available module. We pick features that support a specific step in the customer's process, cut manual work or reduce errors in order fulfilment.
Company account and users
One company can have many users in different roles. The scope can cover inviting employees, granting permissions, purchase limits and internal approval paths.
May cover
- inviting users
- roles and permissions
- purchase limits
- approval paths
The customer's trade terms
Once logged in, a customer can see the assortment, prices, discounts, sales units and delivery rules assigned to them. Where that data comes from has to be settled while designing the integrations.
May cover
- customer assortment
- prices and discounts
- sales units
- delivery rules
- 03
Quick and repeat orders
The platform can support ordering by SKU, repeating an earlier cart, shopping lists or importing a prepared list. Which mechanism fits depends on how the customers work.
- 04
Enquiries and approvals
If the process calls for it, an order can be preceded by an enquiry, a quote or an approval on the buying company's side or the seller's.
- 05
History and documents
The customer can be given access to orders, statuses, documents and the data needed to buy again. Which materials are available depends on the source systems.
- 06
Service by a sales rep
The platform should account for the account manager's role. A sales rep can still own the relationship, agree terms and help with non-standard orders.
We design the integrations and settle one source for every fact
As part of the implementation we establish which system owns the customer, the price, the product, availability, the order and the documents. We then design how data moves between Magento 2 and the company's other systems.
Without a clear split, a price can end up calculated in several places, stock can drift from the ERP, and an order status can stop being trustworthy.
System
Data it owns
- ERP
- contractors
- trade terms
- orders
- settlements
- documents
- PIM
- descriptions
- attributes
- media
- product data structure
- WMS
- stock levels
- fulfilment and shipping
- CRM
- customer relationship
- sales activity
- Magento 2
- customer account
- presenting the offer
- the purchase process
The final split depends on the systems the company runs. Every type of data should have a clearly assigned source and rules for how it is updated.
Companies managing extensive product data can base that layer on a separate system — see Pimcore services.
We close the decisions that shape cost and architecture before development
We describe price lists, permissions, integrations and exceptions before the implementation itself. A decision put off does not disappear. It comes back during development as a change of scope, a delay or extra cost.
| Area | Questions that have to be settled | Impact on the project |
|---|---|---|
| Company registration |
| Registration logic, contractor integration and data security. |
| Users |
| The account model, the company admin panel and permissions. |
| Assortment |
| Indexing, visibility rules and product data. |
| Prices |
| How the price is calculated and how the integration performs. |
| Availability |
| Warehouse integration and the messages shown in the interface. |
| Order |
| The cart, validation and the purchase path. |
| Payments |
| Financial integration and checkout logic. |
| Documents |
| The customer panel, permissions and integration. |
| Handling exceptions |
| Notifications, statuses and the internal process. |
Company registration
Questions that have to be settled
- Who can create an account?
- Who approves it?
- Does the contractor have to exist in the ERP first?
Impact on the project
Registration logic, contractor integration and data security.
Users
Questions that have to be settled
- How many users can one company have?
- Who assigns their roles?
Impact on the project
The account model, the company admin panel and permissions.
Assortment
Questions that have to be settled
- Does every customer see the same catalogue?
- What determines product visibility?
Impact on the project
Indexing, visibility rules and product data.
Prices
Questions that have to be settled
- Does the price come from the ERP?
- Does it depend on quantity, contract, group or product?
Impact on the project
How the price is calculated and how the integration performs.
Availability
Questions that have to be settled
- Does the customer see physical stock, a delivery date or confirmed availability?
Impact on the project
Warehouse integration and the messages shown in the interface.
Order
Questions that have to be settled
- Is there a logistics minimum, a packaging multiple or an approval step?
Impact on the project
The cart, validation and the purchase path.
Payments
Questions that have to be settled
- Which payment methods and terms apply to which customers?
Impact on the project
Financial integration and checkout logic.
Documents
Questions that have to be settled
- Which documents can the customer download?
- Which system are they from?
Impact on the project
The customer panel, permissions and integration.
Handling exceptions
Questions that have to be settled
- Which orders require a sales rep to step in?
Impact on the project
Notifications, statuses and the internal process.
You do not need these answers ready before the first call. It is enough to know who in the company has them — usually sales, logistics and whoever owns the ERP.
This is how we run a B2B implementation on Magento 2
We close every stage with material, a decision or a working part the client can check. That way it is clear what stage the project is at, what has been accepted and what still needs settling.
- 01
Initial conversation
We get to know the sales model, the scale of the project, the systems in use and the problem the platform is meant to solve.
ResultA decision on whether Magento 2 is worth analysing further.
- 02
Process analysis
We describe the customers, roles, trade terms, orders, exceptions and the flow of data.
ResultA process map and a list of decisions.
- 03
Scope and architecture
The split of responsibilities between Magento and the other systems takes shape. The scope of features is ordered by priority.
ResultThe project scope, an integration map and the technical assumptions.
- 04
UX and interface design
We design paths that match how business customers work. Repeat purchases and placing larger orders quickly need particular attention.
ResultWireframes or a prototype for approval.
- 05
Development and integrations
Features and connections with the systems are built to the agreed scope. Changes require their impact on the project to be described.
ResultWorking parts available for acceptance.
- 06
Testing and business acceptance
We check technical scenarios as well as the situations that come up in the daily work of customers and the sales team.
ResultA list of tests, reported issues and a decision on launch readiness.
- 07
Launch and ongoing support
The launch plan covers data, integrations, users and how problems found after go-live are handled.
ResultA working platform and an agreed model for further maintenance.
Scope, responsibility and the way work is accepted must be explicit
A B2B implementation has a lot of dependencies. We limit the risk with documented assumptions, change control, testing business scenarios and regular updates on the project's status.
- 01
Assumptions are part of the estimate
Any larger estimate should state the information it rests on. If the process or a data source changes, the effect of that change on the scope can be assessed.
- 02
Changes do not enter the project without a decision
A new requirement needs a description, an impact assessment and a decision from the person responsible on the client's side. That keeps the backlog from growing past the agreed goal.
- 03
QA checks business scenarios
A test needs data and a specific situation. Knowing that a screen opens does not confirm that the price was calculated correctly, that the right products are visible or that the order reached the ERP.
- 04
The client's team receives documentation
Documentation should cover at least the scope of the integrations, the decisions made about data, the configuration that needs ongoing attention and what is needed to grow the platform.
Fragments of the backlog, a requirement description, a QA checklist and integration documentation are shown on a call. We do not publish them here until the clients they concern confirm their consent.
After launch the platform can be covered by AURORA CARE with monitoring, an SLA and steady technical care. We run further feature work under AURORA EVOLUTION.
We first check whether Magento 2 is the right investment
We do not recommend a technology based only on the number of products or a planned budget. We assess the complexity of the process, the integrations, the scale of sales and the plan for growing the B2B channel.
Signals in favour of Magento 2
- 01many customers use different price lists, discounts or catalogues
- 02company accounts need several users and levels of permission
- 03orders are subject to approval, limits or additional rules
- 04the store has to exchange data with an ERP, PIM, WMS or several other systems
- 05the platform will grow with further processes, brands or markets
- 06the B2B channel matters materially to the company's revenue
Situations that call for a simpler option
- the company serves a small number of customers
- every customer buys on the same terms
- orders come in occasionally
- the platform is mainly meant to be a catalogue and an enquiry form
- the project is meant as a quick, limited test
- the company lacks the resources to maintain an extensive solution
In that situation we point out which assumptions do not justify a Magento 2 implementation and which simpler option is worth considering.
On the first call we get to know the process and the scale of the project. We then say whether Magento 2 is a justified choice and what information is needed to prepare the next stage.
A Magento 2 B2B platform in practice — Hulajnogi Micro
Sales to trusted trade customers ran by email and phone. Together with the migration off Magento 1 we launched a version of the store for business customers that took over the repetitive handling of those orders.
- Starting point
- The store ran on Magento 1, which slowed the platform down and blocked its growth. Wholesale orders were placed outside the store, by email and phone.
- Access for trade customers
- The B2B version is visible only to approved users, whose accounts are created in the admin panel. The wholesale channel is not open to passing traffic.
- Order automation
- The point of the build was for the platform to take over the repetitive handling of wholesale orders and relieve the team, not to replace the relationship with the customer.
- Integrations in the same project
- Magento 2 connected to Opineo, Fakturownia.pl and to the Decathlon offer through the Mirakl module, which passes selected products along with their stock levels.
- 2sales channels in one store
- 3integrations in the same project
- 1platform after migrating off Magento 1
See how the migration off Magento 1, the launch of the B2B channel and the integrations delivered with it ran.
See the Hulajnogi Micro case studyWhat companies want settled before a B2B implementation on Magento 2
The questions that come up most often before a first conversation about a platform for business customers.
Book a call about a B2B platformYes, the platform can be designed as a channel intended for business customers. The scope of features and how they are built depend on the company's processes, the Magento edition required and the modules used. If the sales also have to serve retail, the right scope is a B2C + B2B implementation on Magento 2. The platform's standard catalogue, cart and admin panel are shown by the Magento 2 demo, and the B2B features are designed on top of that standard.
The base is company accounts with several users and roles, individual prices and discounts, a catalogue attached to the customer, fast ordering by SKU, reordering, limits and approval paths, payment terms, access to documents, and integrations with ERP, PIM, WMS and CRM. The full set, with a line on each, is in the section on B2B platform features. Which of them go into a given implementation follows from the sales process, not from a list of modules.
Yes. Discounts can be attached to a customer or a group, apply by volume, or follow terms negotiated outside the store. Payment terms, a credit limit and deferred payment can equally be attached to the company account. One thing has to be settled before the build: whether those terms are calculated in Magento or taken from the ERP.
Yes. An order above an agreed amount, or one placed by a user with limited permissions, can go for approval on the buying company's side before it is passed on for fulfilment. The scope needs to settle who approves, what happens after a rejection, and whether the limit applies to a single order or to a billing period.
Yes. A basket can be built from SKUs or EAN codes, from a saved shopping list, or from an imported CSV. Which mechanism fits depends on how the customer's procurement team works — some paste a list of codes, others upload a file exported from their own system.
Yes, and in most implementations the ERP is exactly where prices, trade terms, stock and order statuses come from. The condition is that the ERP offers a way to integrate. Before the build we settle which system calculates the price, how often the data synchronises and what the platform does when the ERP is briefly unavailable.
Adobe Commerce ships some B2B features as ready modules — company accounts, requisition lists, quote requests — under a commercial model. In Open Source the same processes need modules or custom development, but there is no standard licence fee. What decides is the total cost of implementing and maintaining the processes you need, not the licence alone, and the comparison should be made before the architecture is approved.
The cost depends on the company-account model, how prices are calculated, the number of integrations, the quality of the data, the ordering process and the scope of the interface. A credible estimate requires those elements to be described first.
The timeline depends on the number of features, how ready the integrations are, whether the data is available and how quickly decisions are made. A schedule should follow the analysis, not the name of the platform.
It can exchange pricing data with an ERP, provided the system offers a suitable way to integrate. Before the implementation you have to establish where the price is calculated, how often it changes and what should happen while the ERP is briefly unavailable.
The project can cover a company account with multiple users, roles and permissions. The specific rules follow from who places orders, who approves them and what data each person may see.
That feature can be part of the scope. What has to be settled is how the platform behaves when the earlier product, price, sales unit or availability has changed.
The platform takes over part of the repetitive work: checking the offer, placing standard orders and pulling information. Sales reps still run the relationships, the negotiations and the non-standard situations.
The model for working together after launch is agreed before it. It can cover monitoring, an SLA, handling errors, updates, maintaining the integrations and building further features under AURORA CARE or another agreed arrangement.
Direct-to-consumer sales are covered by the D2C implementation.
Tell us how B2B sales work in your company today
On the first call we go through your customer model, how orders are placed, the systems in use and the main constraints. After the meeting we can say whether Magento 2 fits the project and what the next step should be.
What happens after you send the form
- 1Contact within 1 business day and follow-up questions about the sales process.
- 2A conversation about customers, trade terms, orders and the company's systems.
- 3An answer on whether Magento 2 fits the project and what is needed to prepare a scope.