WooCommerce for B2B: What Custom Development Actually Involves

WooCommerce out of the box is a retail store: one price for everyone, pay now, see everything. A B2B store needs prices that depend on who is logged in, orders that start as quotes, invoices paid on terms, catalogs that differ by account, minimum quantities, a manager who approves before anything ships, an ERP that is the real source of truth, and customers who do not pay tax. Custom development for B2B on WooCommerce means adding those eight things, choosing for each whether a plugin is enough or code is needed, and, above all, making them agree with each other. The individual features are not hard. The interactions are.

What core WooCommerce does not do

Core has no concept of a company, only of a customer. It has no per-customer price, only a regular price, a sale price and coupons. It has no quote state, no credit terms, no approval step, no catalog visibility rules, no quantity rules beyond stock, and no per-customer tax exemption. It does have good foundations for all of them: customer roles, order statuses you can extend, a REST API, webhooks, and hooks around pricing, cart validation and checkout. That is why the answer is usually WooCommerce plus work, rather than a different platform.

Feature by feature: plugin or custom

Customer-specific pricing

The most common need and the one with the most plugin coverage. Wholesale pricing plugins handle role-based price lists and quantity breaks well. Where they stop: pricing per individual account rather than per role, contract prices imported from an ERP, and precedence when a customer qualifies for more than one discount. Those need custom code on the price filters and a written rule for which price wins, because the plugin's default is rarely the one the sales team expects. Decide early whether trade prices display with or without tax, since that touches every template.

Quote requests

Request-a-quote plugins replace the add-to-cart button with add-to-quote and give the admin a screen to reply with prices. That is enough for stores where quotes are occasional. When quoting is the main sales process, the gaps show: quotes need versions, expiry dates, a conversion to an order that keeps the quoted prices, and a link back to the CRM. That is a custom order flow built on a new order status and a few custom screens.

Net terms and invoice payment

Core's offline gateways, bank transfer and cheque, let an order complete without payment. That is not net terms. Net terms means a credit limit per account, a due date per invoice, an outstanding balance the customer can see, a block on new orders when the account is over its limit, and reminders. No plugin does all of that well, because the credit decision belongs in the accounting system. The usual build is a custom payment gateway that checks eligibility against a limit stored on the account, plus a sync so the accounting system marks invoices paid and the store updates. Partial payments and deposits, if needed, are a separate piece.

Role-based catalogs

Hiding products, categories or prices until login is well covered by plugins. Showing a different catalog to each account, with different SKUs and different names for the same item, is not, and it carries a performance cost: a catalog that varies by user cannot be page cached, so the store must be fast without caching. Plan the hosting and the query work at the same time as the visibility rules.

Minimum quantities, pack sizes and order minimums

Plugins handle minimum and step quantities per product. Rules that combine, like a minimum order value per account, a minimum per product line, and a pallet quantity that rounds up, are custom cart validation. Write the rules down as a table before anyone codes them, including the exact message the buyer sees when a rule fails.

Approval workflows

A buyer places the order, a manager at the same company approves it, then it goes to the warehouse. This needs a company entity with several users and roles, an order status between placed and processing, notifications to the right person, and an approval screen in the customer account. The B2B suites include a version of it. When the approval rules depend on order value, budget period or product category, it becomes custom, and it is also where checkout customization gets involved, because the checkout has to know whether this buyer can complete the order or only submit it.

ERP sync

This is the piece that most decides whether the project succeeds. Products, prices, stock and customers usually come from the ERP. Orders go back to it. Invoices and payments come back again. Every ERP has an API or a file export, and each has its own idea of what a customer or a price is. The integration is a custom plugin built against the ERP's actual data and tested with the ERP's actual quirks, with logging, retries, and a screen where staff can see what failed and re-run it. It is custom plugin development in its own right and should be scoped as such, not as a line item.

Tax exemption

Core WooCommerce has tax classes on products and rates by location, but no way to mark a customer as exempt. Plugins add a VAT or tax ID field with validation for some jurisdictions and remove tax when it passes. Cross-border B2B, reverse-charge rules, exemption certificates that expire, and reporting go beyond that and tie back into the ERP sync, since the accounting system usually holds the exemption status.

What tends to be underestimated

• Precedence. A customer with a role discount, a contract price, a quantity break and a coupon. Which one applies. Every project meets this and few scope it.
• The company model. Plugins model a customer as a person. B2B buyers are companies with several people, addresses and payment methods. Retrofitting that later is expensive.
• Data ownership between systems. If the ERP owns prices, nobody edits prices in WooCommerce. Deciding that for every field, and enforcing it in the admin, saves months of arguing about which system is right.
• Performance. Per-customer pricing and catalogs mean uncached pages for logged-in buyers. Postmeta-heavy price lookups multiply on category pages. Size the hosting and design the queries for it from the start.
• Plugin stacking. A wholesale plugin, a quote plugin, a tax plugin and a checkout field plugin from four vendors, each hooking the same price and cart filters, will disagree. Fewer, better-chosen plugins plus custom glue is more reliable than a full stack of them.
• Testing. Guest, retail customer, each trade role, over limit, exempt, approval pending. Each against each gateway. The test matrix is large, and it is where a second developer reviewing the work earns their place.

Plugin, custom, or both

Our default: use a plugin where the feature is standard and the plugin is maintained, build custom where the rule is specific to the business or the data lives elsewhere, and never edit a plugin's own code. Wholesale pricing by role, hiding prices until login, simple quantity rules and a VAT field are plugin territory. Net terms, ERP sync, approval rules, quote-to-order flows and per-account pricing are custom. Stitching the two together, using documented hooks so updates do not break anything, is the real job, and it is the reason to hire a WooCommerce developer who has done B2B before rather than a generalist.

Common questions

Is WooCommerce suitable for B2B at all?

Yes, for most B2B stores, provided the budget includes the work above rather than assuming a plugin covers it. It gives you full control over pricing logic and data, which the hosted platforms restrict to their top tiers. Very large catalogs with complex per-account pricing need careful database work to stay fast.

Can one plugin do all of this?

The B2B suites cover pricing, visibility, quotes, basic quantity rules and a simple approval flow reasonably well. None covers net terms with credit control or ERP sync in a way that fits a real accounting setup. Expect a suite plus custom work, not a suite alone.

How long does a B2B build take?

It depends on how many of the eight features you need and whether an ERP is involved. The ERP integration is usually the longest single piece and the one that depends most on people outside the project. Scope it first.

Can we run retail and B2B on one store?

Yes, and it is common. Guests and retail customers see retail prices and pay at checkout. Trade accounts log in and see their pricing, terms and catalog. The rules that separate the two need to be explicit in every template, email and report, which is part of the scope.

Next step

Send us the list of what your buyers need to do that they cannot do today, and which ERP or accounting system holds the truth, through start a project. We will come back with a plugin-versus-custom split and a fixed price.