A business customer placing an order expects to see the products relevant to them, at the price agreed with them, and in quantities they can actually order. Behind that action sit a catalog, commercial agreements, inventory, permissions, and connections to the organization's systems. When one of these is out of sync with the others, the result can be incorrect orders and manual work for the sales team.
Choosing a B2B system for importers starts with understanding how your company sells and manages information, not with the website design. In this guide, we'll look at four key areas to compare: catalog, price lists, permissions, and integrations. We'll also cover questions about inventory, costs, and implementation that will help you make an informed decision.
Start with the business process, not the feature list
Before approaching vendors, it's worth mapping the order journey: who your customers are, how they get a price, who approves the deal, and which systems take part in the process. That way you can tell the difference between a capability that looks impressive in a demo and one that solves a problem in your business.
Involve representatives from sales, operations, finance, and IT in the mapping. Each knows a different part of the process: the sales team knows the commercial exceptions, the warehouse team knows the pack sizes, and IT knows where the data is managed.
- What types of customers order from you, and does each have different trade terms?
- What product details are needed for a customer to choose and order without help?
- At which stages is a manager's approval, a stock check, or a sales rep's involvement required?
- Which systems currently manage products, customers, prices, inventory, and orders?
Also document recurring problems, such as price corrections or orders in quantities that don't match the pack size. They will serve as the basis for your test scenarios. For more on the considerations and costs, see the guide to choosing a B2B ordering system.
Catalog management: does the system understand how you sell?
An importer's catalog may contain thousands of products, brands, and versions. Beyond the name and image, a business customer may need a SKU, a barcode, technical specifications, a unit of measure, or packaging information. When comparing B2B e-commerce platforms for importers, it's important to check not just how a product looks, but also how its data is managed and updated.
Variants, packs, and order quantities
Choose a few representative products: a product with sizes or colors, a product sold by the carton, and a product with a minimum quantity. Ask to see how each one is set up and displayed to the customer. Does the customer choose units or packs? What happens if the quantity entered isn't a multiple of the pack size? Can an alternative product be shown when an item is unavailable?
Check search and filtering too. A customer who knows the SKU or barcode may want to go straight to the item, while another will search by brand or category. Use terms your customers know when you test.
Who updates the information?
Find out which fields come from the ERP system and which come from a product information management system, if you have one. For example, the SKU and dimensions may be managed in the ERP, while images and descriptions are edited elsewhere. Define who is responsible for each field and what happens when the same data changes in more than one system.
In the demo, ask the vendor to update a product in the source system and follow the change as it appears in the catalog. Ask how missing fields, discontinued products, and replaced spec files are handled. An initial import capability alone doesn't guarantee an orderly, ongoing update process.
Managing price lists for business customers: test the exceptions
In business-to-business commerce, the price may vary by customer, customer group, currency, quantity, promotion, or commercial agreement. The question isn't just whether you can set up price lists, but also how the system decides which price to show when several rules apply at once.
For example, a customer may belong to a group with a discount, have a personal price list, and order a quantity that qualifies for a different price. Ask the vendor to show the order of precedence: which rule wins, whether discounts stack, and how you can check where a displayed price came from.
- Validity: what happens when an agreement expires or when a future price list takes effect?
- Missing price: is the product hidden, shown without a price, or passed to a rep to handle?
- VAT and currency: how are prices displayed, and at what stage is the final calculation shown?
- Price change: what happens if the price is updated after the customer has added a product to the cart?
Pick a real customer and a few products with different terms, and compare the system's results with the prices your organization expects. If the result requires development or manual maintenance, it's important to know that before signing.
Permissions: who can view, order, and approve?
A business customer isn't always a single user. One company may have buyers, branch managers, and approvers, each with different responsibilities. That's why it's worth looking at whether the system separates the buying company's account from the users acting on its behalf.
Depending on your sales process, check whether you can grant separate permissions for viewing prices and documents, creating orders, and approving them. Some businesses will also need restrictions by branch or by a specific budget. Make sure the system supports the process that's relevant to you.
Ask for a demo of a complete scenario: a buyer prepares an order, a manager receives it for approval, and the order moves on for processing only after the required approval. Also check what happens when an order is rejected, when a user leaves the company, or when their role changes.
Securing permissions beyond the interface
Hiding a button is no substitute for access control. Permissions should also be enforced on the server side and in APIs, to reduce the risk of exposing price lists, orders, or customer details across accounts. Ask how the vendor tests the separation between customers, how permissions are managed, and what the process is for reporting and handling security incidents.
Check with the relevant professionals in your organization which security and privacy requirements apply to the data you'll be managing. Evaluating the system doesn't replace a review of your organization's processes and contracts.
Integrating a B2B system with an ERP system: who owns each piece of data?
An ERP integration is more than a line item in the proposal. For data to flow consistently, define a source system for each type of data and the process that runs between the systems. For example, which system manages SKUs and prices, which one calculates available inventory, and which one creates the official order?
Map the data flows: which data comes from the ERP into the commerce system, which goes back to it, and which stays on the sales platform. For each integration, define the sync frequency, who is responsible for monitoring, and how to handle cases where data doesn't arrive on time.
- How is a sync error detected, and who gets alerted about it?
- How do you prevent a duplicate order if a submission fails and is retried?
- How do you reconcile orders created in the commerce system with those received in the ERP?
- Who handles a failure when it's unclear whether it originates in the platform, the integration, or the ERP?
Ask to see a failure scenario as well. For example, send an order while the ERP is unavailable and check how it's saved, who sees the failure, and how it's received once the issue is fixed. It's advisable to document how responsibility is divided between vendors in the proposal and the service agreement.
Inventory availability: what does the customer see, and what can you deliver?
Physical stock in the warehouse isn't necessarily stock available for sale. Some of it may be allocated to other customers, and there may be open orders or goods spread across several warehouses. Stock in transit isn't necessarily available for immediate delivery either.
Find out which figure is displayed on the site, how it's calculated, and how often it's updated. Ask what happens when a customer sees an item as available but the stock changes before the order is confirmed: can they order a partial quantity, is an estimated delivery date shown, or is the order sent for review? The answers should fit your service policy, not just the technical capability.
Comparing costs: beyond the subscription fee
To compare proposals fairly, set the same contract period and ask each vendor for a breakdown by the same components. The subscription fee is only one possible part of the total cost.
- Setup and migration: requirements specification, configuration, migrating the catalog, customers, and price lists, and checking data quality.
- Integration and customization: ERP integration, required development, testing, and integration maintenance.
- Ongoing operation: support, maintenance, and service, including service levels and response terms.
- Variable costs: pricing by users, orders, or integrations, where applicable.
- Ending the contract: data export options, data format, and switching costs, if any.
Ask for a written distinction between built-in capabilities, capabilities that require configuration, and capabilities that require development or an additional service. Also find out who approves changes and what happens to costs if your business volume grows. For more on planning and launch, see the guide to building a B2B website.
How to choose a B2B system in practice: a matrix and a demo
After the mapping, prepare a requirements matrix for the four areas: catalog, price lists, permissions, and integrations. For each requirement, note its importance, the test scenario, and the vendor's answer: available in the product, requires configuration, requires development, or not supported. Add cost, timeline, and an owner where relevant.
Send the same matrix to all vendors and ask for a demo with representative data, using the information safely. Four useful scenarios are a customer with a personal price list, a product sold in packs, an order that requires approval, and an ERP sync error. At the end of each scenario, document what was shown and what still needs clarification.
You can evaluate WideCommerce alongside alternatives, using the same matrix and the same scenarios, without assuming in advance that any particular capability exists. For a broader comparison, see also the guide to choosing a vendor to build a B2B website.
Frequently asked questions
What should you check in the catalog of a B2B system for importers?
Check support for SKUs, variants, packs, minimum quantities, and alternative products. Also check how the information is updated from the ERP system or from a product information management system.
How do you evaluate price list management for business customers?
Check customer-, group-, or quantity-specific pricing, the order of precedence between pricing rules, price list validity, and how VAT is displayed.
What should you define in an integration between a B2B system and an ERP?
Define a source system for each type of data, sync frequency, error handling, and prevention of duplicate orders. It's advisable to test ordering and permission scenarios using representative data while keeping the information secure.
Summary: choose based on the process the system needs to serve
The right system helps customers order on the right terms and helps teams manage the process clearly. Testing the catalog, price lists, permissions, and integrations with representative scenarios will help you spot gaps early, understand the total cost, and choose a solution that fits your company.