Can a B2B ecommerce platform handle how your buyers actually order?

What does a real B2B buyer need to do?

Consider this illustrative order from a parts wholesaler. A buyer signs in for the North branch of a customer with two branches. The buyer orders 48 cases of one item at an agreed price of 250 per case. Each case contains 12 units. The total is 12,000 in the account currency. The buyer enters purchase order N-1048 and expects 30-day payment terms.

The customer requires a manager to approve orders above 10,000. Finance has only 11,000 of unused credit available. Operations can supply 30 cases now and 18 next week. The buyer will accept two deliveries if the dates are clear. No single requirement is unusual. Together, they force the platform to join rules that often live in different systems.

Use this difficult order as a stress test, then choose other paths from recent orders. Look at how often buyers reorder from order history, ask for a revised quote or submit a purchase order for approval. Test the paths that account for the most orders or revenue. If your buyers rarely request quotes, spend the demo time on reorders instead.

A B2B ecommerce platform is the buyer-facing system for business orders. It may also manage prices, approvals and orders, or it may ask other systems to decide. The distinction matters more than the feature name. For example, Shopify documents company locations with their own pricing and terms, while Adobe Commerce documents purchase-order approval rules. Neither document proves that a proposed setup can complete this whole order. The demonstration must do that.

Can the right buyer see the right products and price?

Start the demonstration with two users from the same company and one user from a different company. Switch between the North and South branches. The North buyer must see only products that branch can buy, the contract price for a case, the case size and the delivery address that belongs to that branch. A price meant for another customer must never appear because two accounts share a customer group or an old price list.

Ask where the contract price comes from. If the ERP owns it, the commerce platform needs the customer ID, branch ID, item ID, unit, price, currency and effective dates. A price update must reach the right buyer before the next order. If pricing is calculated at request time, the team must define what the buyer sees when that service is unavailable. If prices are copied into commerce, the team must define how stale a copy can be before ordering stops.

What happens to the purchase order, approval and credit hold?

Submitting a cart is not the same as accepting an order. For this test, the buyer submits N-1048 for 12,000. The company manager must approve it. Finance must then resolve the credit hold. Only after both decisions can the order be released to operations. Your business may apply those decisions in another sequence. Write that sequence down before a vendor configures the workflow.

The buyer should see a useful state such as “waiting for your manager” or “held for account review.” Sales needs the same reason and the person who can act. The platform must retain the purchase-order reference, the price that the manager approved, the approval time and the order revision. If the buyer changes the quantity after approval, the rule must say whether the manager approves again.

Test a rejection as well as an approval. Then submit N-1048 twice. The system must show whether a duplicate purchase-order reference is allowed under this customer and prevent an accidental second operational order. A failed message to the ERP must remain visible for repair and retry against the same order ID. It must not turn into another order when the connection returns.

Separate buyer approval from seller credit approval. A purchasing manager can authorize an employee to spend; that does not mean the supplier has agreed to extend credit. If finance owns the credit decision, the commerce platform needs a current result and a safe response when it cannot get one.

Can the platform explain a shortage without losing the order?

The warehouse has 30 cases that it can allocate now. Another 18 are expected next week. The buyer should see whether the 30 can ship first, when the rest is expected and what happens if the date changes. The platform needs the supply decision from the system that owns stock and reservations. A raw “30 on hand” number is not a delivery promise if those cases are already committed elsewhere.

Ask the vendor to create two shipments against the same order line. After the first dispatch, the buyer should see 30 shipped and 18 still open. The ERP and fulfilment system need the same outstanding quantity. If the business invoices by shipment, finance needs the exact shipment and line references. If it invoices on another rule, test that rule instead. A single “fulfilled” flag for the whole order cannot explain a split delivery.

Now delay the remaining 18 cases and cancel three of them. The record should show 30 shipped, 15 still open and three canceled. The buyer, sales, stock owner and finance team must see the same revised obligation. This is where a pleasant buyer portal either remains useful or becomes a separate screen that staff cannot trust.

Which system is allowed to make each decision?

Do not assume that one product must own everything. A smaller company may hold account, price and order rules in one platform. A distributor may keep contract pricing and credit in an ERP and dispatch in a warehouse system. Name one authority for each decision. Then define the input, response and failure path at every boundary.

Each handoff also needs a response. “Sent to ERP” is not proof that the ERP accepted the order. Record the source order ID, destination order ID, line IDs, current revision, last successful step and any rejection reason. That lets support answer the buyer and lets the team retry a failed transfer without guessing.

Are your account, price and stock records ready to test?

Prepare the facts that the demo needs before asking a vendor to load them. For this order, that means the parent company, billing account and North ship-to IDs; the buyer’s role; the item ID and 12-unit case definition; the contract price, currency and effective dates; the approval rule; the available credit; and the quantity and date that operations can promise. Name the system or team that owns each fact.

If a price exists only in a spreadsheet, an approval limit lives in someone’s memory, or two systems disagree about the ship-to address, record a data or process gap. The platform cannot prove an accurate order from contradictory inputs. Fix the source, or agree on a controlled temporary rule, before judging the vendor’s result. The price owner may be an ERP, a pricing service or the commerce platform; the test is whether the buyer sees the authorized answer.

What must a vendor demonstrate before you choose the platform?

Give every shortlisted vendor the same test company, buyer roles, contract, approval limit, credit balance and stock state. Ask for a working demonstration in a test environment, with the operator showing both the buyer view and the records behind it. A screenshot of a feature menu or a promise that an app can do the work is not a passed test. Run the purchase-order case below, then add the quote and reorder tests if those paths appear in your real buyer mix.

Record each result as passed, passed with configuration, passed with an extension, requires custom work or failed. For anything outside the base product, ask who will build, test, support and upgrade it. A connector label is insufficient evidence. Shopify, for example, warns that some external integrations do not map B2B company and catalogue data correctly. The same principle applies to any proposed stack: inspect the actual record, not the connector name.

What will it take to make a passing workflow operate every day?

A passed demonstration is the start of a cost estimate. Separate what works in the licensed product from what needs configuration, an app, an integration, custom code or a change to the business process. Add the people who will maintain prices, customer access, approvals and exception queues. A low licence fee can conceal a costly operating model if staff must repair every unusual order.

For each gap, record the orders it affects each month, the manual minutes per order, the one-time build cost, recurring fees and the support owner. For example, if staff repair 200 orders for five minutes each, that is 1,000 minutes, or 16 hours 40 minutes, every month before review and rework. Use your own order volume and labor cost when comparing candidates. Price the work needed after launch as well as the initial implementation.

A platform is a fit when the buyer can complete the order and the teams behind it can explain every decision, exception and remaining obligation. If the shortlist is still open, use the B2B platform comparison to choose candidates. If accepted orders already break between systems, the lead-to-cash guide follows the later handoffs. For help turning a real order into a scoped implementation, see Harmatiq’s ecommerce and B2B work.