What to Build for Wholesale and B2B Trading Businesses

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Owner or MD of a UK wholesale or B2B distribution business turning £5M–£50M annually, running on a patchwork of Sage, spreadsheets, and a legacy order system, who has just lost a major account because they could not offer a self-serve ordering portal or real-time stock visibility

For a UK wholesaler turning £5M–£50M, the highest-ROI software build is almost never the customer-facing trade portal owners ask for first. It is the automated credit-limit engine that pulls Companies House and Experian data at the moment an order is placed, so the order releases in seconds instead of sitting in a 24–48 hour manual review queue. Build that, wire your order management system into Sage or Xero properly, and only then launch the self-serve portal. Do it in the other order and you will have an attractive website funneling orders into the same bottleneck.

This post lays out the three places margin actually leaks in a mid-market UK wholesale business, what to build to close each gap, and the sequence that makes the next build cheaper than the last one.

Where the money actually leaks

If you lost a major account recently because you could not offer self-serve ordering and real-time stock, the instinct is to commission a B2B trade portal and be done with it. That instinct is half right. The portal matters — 83% of B2B buyers now prefer placing orders through self-serve online channels rather than phone or email, and 88% of users say its availability positively affects supplier selection. You will lose more accounts if you do nothing.

But a portal on top of broken back-office processes amplifies the problems rather than fixing them. In a typical UK wholesale business of this size, three gaps do most of the damage:

• Manual credit checks delay order release by 24–48 hours. New customer orders and over-limit orders from existing customers sit in a queue waiting for someone to pull a credit file, check payment history, and sign off. During that window, your retail buyer places the emergency order with a competitor.
• Every reorder goes through a sales rep's inbox. APQC benchmarks put manual B2B order processing at 8–12 minutes for simple orders and 20–30 minutes when pricing or inventory needs checking, at a per-order cost of $14–$54. On 500 orders a week, that is a full-time salary and a lot of transcription errors.
• Month-end close takes four days or more. Your order management system and Sage or Xero do not reconcile cleanly, so the accounts team spends month-end matching invoices to despatches by hand. Ledge's benchmarking study found 50% of finance teams still take more than five business days to close, with cash reconciliation alone consuming 20–50 hours per month.

Fix these in the wrong order and each fix costs more than it should. Fix them in the right order and the portal — when you finally build it — is almost free because the plumbing already exists.

Build 1: The automated credit-decision engine

This is the unglamorous build nobody pitches you, and it is almost always the one that pays back fastest.

What it does

When an order is placed — whether through the sales team, EDI, or eventually a portal — the engine runs an automated check before releasing it to the warehouse. It pulls the customer's current exposure from your order management system, their payment history from your ledger, their filed accounts from Companies House, and a real-time trade credit score from a bureau API. Experian's Commercial Delphi model, backed by the CAIS data pool, covers over 8 million UK businesses and returns scores in real time, which is what makes instant decisioning possible at all.

Based on configurable rules you set, the engine does one of three things: auto-release the order, hold it for human review with the relevant data already attached, or reject with a reason code. The human review queue shrinks from "every new or over-limit order" to "the handful the rules genuinely cannot decide."

What changes once it exists

• Order-to-despatch time for creditworthy customers drops from 24–48 hours to minutes.
• Your credit controller stops being a bottleneck and becomes an exception handler.
• Bad debt exposure goes down because limits are enforced at the point of order rather than discovered at month-end.
• Sales reps stop calling the office to "get this one released" — a cultural change that matters more than it sounds.

What it takes

This is a focused build, not a platform. You are integrating three or four systems (your OMS, your ledger, Companies House, a credit bureau like Experian or Creditsafe) behind a rules engine your credit controller can edit without a developer. Scope is driven by how clean your current customer master data is, how many ERP or OMS endpoints the engine needs to read from and write to, and how sophisticated the rules need to be. A business with one OMS, Sage 200, and a well-maintained customer list builds this far faster than one with three legacy order systems and duplicate customer records.

What it is bad at

It will not help you with first-order customers who have no filed accounts or trade history — those still need human judgement, and the engine should route them accordingly. It also will not fix bad credit policy. If your current limits are wrong, automating them just makes you wrong faster.

Build 2: The OMS-to-finance integration

This is the one that gets your month-end back.

What it does

A proper two-way integration between your order management system and Sage or Xero. Sales orders, despatches, and credit notes flow into finance as they happen. Customer and product master data stays in sync. Cash receipts applied in Sage or Xero update the OMS credit exposure in near-real time, which — not coincidentally — is what makes Build 1 work accurately.

Most mid-market wholesalers already have "an integration" between these systems. It is usually a nightly CSV export, a middleware tool nobody fully understands, or a part-time job for someone in accounts. That is not what we mean. We mean an event-driven integration with proper error handling, a reconciliation dashboard, and alerts when something fails to post.

What changes once it exists

• Month-end close moves from four or five days toward the three-day benchmark that only 18% of finance teams currently hit.
• Cash application stops being a manual spreadsheet exercise.
• Your credit engine (Build 1) sees accurate real-time exposure, so its decisions get better.
• You can trust the margin numbers you look at on the 5th of the month.

What it takes

Scope here is driven almost entirely by how many edge cases your business has — part-shipments, consignment stock, rebates, retrospective discounts, multi-currency, intercompany. A food wholesaler with simple pricing and no rebates is a much smaller build than a steel trader with tonnage-based pricing, scrap allowances, and quarterly volume rebates. Spend a week documenting the edge cases before you brief anyone to build this. The documentation itself is worth the time.

What it is bad at

Integration will not fix a chart of accounts that has drifted over ten years, and it will not clean up historical mismatches. Those are separate pieces of work. Decide upfront whether you are migrating history or drawing a line.

Build 3: The self-serve trade portal

Now, finally, the thing your customers asked for. The reason you build it third rather than first is that a portal is a thin layer on top of the OMS and the credit engine. If those are solid, the portal is a straightforward build. If they are not, the portal becomes a Frankenstein with its own order queue, its own credit workarounds, and its own reconciliation problem.

What it does

Trade customers log in and see their price list (not the generic one), their stock availability in real time, their order history, their statements, and a reorder flow that takes them from "last month's order" to "placed" in three clicks. Orders flow into the OMS, hit the credit engine, and either release or route to review — the same path a rep-entered order takes.

What changes once it exists

• Reorders stop clogging rep inboxes. Reps spend their time on new business and on the accounts that genuinely need a human.
• You can win RFPs that require a self-serve channel — the kind of RFP you just lost.
• Buyers get the 24/7 ordering they expect, with the stock visibility that stops them double-ordering elsewhere.

What it takes

The build itself is well-understood — authentication, catalogue, pricing engine, cart, order submission, account area. What drives scope is the complexity of your pricing (customer-specific price lists, contract pricing, break pricing, promotions), the number of integrations beyond the OMS (PIM, DAM, carrier APIs for live delivery dates), and whether you need a mobile app for buyers who order from the warehouse floor.

What it is bad at

A portal will not win back customers who left for reasons other than channel. If your service levels, lead times, or pricing are uncompetitive, a nicer ordering experience does not fix that. Diagnose honestly before you build.

What is probably not worth building yet

Owners at this size often get pitched three more things. Be sceptical:

• A full custom ERP. You already have one — it is called Sage, or NetSuite, or whatever runs your warehouse. A custom wholesale ERP build makes sense at a different scale and only when the standard products genuinely cannot model your operation. Most of the pain you are feeling is integration pain, not ERP pain.
• An AI demand forecasting tool. Useful eventually. Not useful until your sales and stock data in one place is clean. Forecasting on dirty data produces confident wrong answers.
• A marketplace or multi-vendor platform. Different business model. Do not confuse "we want a portal" with "we want to become Amazon Business."

The sequence, and why it compounds

Build 1 (credit engine) depends on reading accurate exposure from your OMS and ledger. Build 2 (OMS-finance integration) makes that exposure accurate. Build 3 (portal) needs both to work. You can do them in parallel if you have the budget, but if you are sequencing them one at a time, the order is:

1. OMS-to-finance integration foundation (data model, master data cleanup, event flow).
2. Automated credit-decision engine on top of it.
3. Trade portal that uses both.

Each build makes the next one cheaper. Each build also produces a return on its own, which matters when you need to justify the next phase to the board.

What the numbers depend on

Owners always want a figure. The honest answer is that cost and timeline for all three builds depend on four things, and until these are scoped, any figure is fiction:

• The state of your master data. Clean customer and product masters make everything faster. Duplicates, missing fields, and inconsistent SKUs can double the integration effort.
• How many systems need to talk to each other. One OMS and Sage 200 is a different build from three legacy order systems, a bespoke warehouse system, and Sage 50.
• How complex your pricing and credit rules are. Flat price lists and standard terms are quick. Contract pricing, tonnage breaks, rebates, and bespoke credit terms per account are not.
• Whether you are migrating history or drawing a line. Migrating years of transaction history for continuity is a project in itself.

What McKinsey has shown, cited via third-party analysis, is that businesses relying on manual order processing spend around 30% more on operational cost than those that automate — which is the shape of the return, not a quote. To turn any of this into a real number you need a two-hour scoping conversation about those four variables above.

How CodeNicely can help

The pattern above — rules engine on top of credit bureau APIs, driving automated decisioning at the point of transaction — is close to what we built for Cashpo, a lending business where the entire economic case depended on moving credit decisions from manual review to real-time. The specifics are different (consumer lending versus trade credit), but the architecture is the same: pull bureau data, apply configurable rules a non-developer can edit, auto-decision the clear cases, route the edge cases with full context attached.

For the OMS-to-finance plumbing and the portal, our work with GimBooks on accounting workflows and with Vahak on marketplace order flows is more directly relevant. We work with UK SMB and mid-market businesses on exactly this kind of sequencing problem — deciding what to build, what to buy, and what to leave alone. Full IP ownership and no vendor lock-in, which matters when the thing you are commissioning will run your business for the next decade.

Frequently Asked Questions

Should we replace Sage, or integrate with it?

For most wholesalers in the £5M–£50M range, integrate. Sage handles the ledger, VAT, and statutory reporting fine. The pain you feel is almost always at the boundary between Sage and your order system, not inside Sage itself. Replacing it is a 12–18 month distraction that solves a problem you probably do not have.

How long before a credit automation engine pays back?

Payback is driven by three things: how many orders currently sit in manual credit review, how often those delays cause lost orders or emergency orders elsewhere, and how much credit controller time is spent on routine checks versus genuine exceptions. Businesses where credit review is a daily bottleneck see the fastest return. Those with mostly repeat customers on stable limits see it slower. A short scoping exercise measuring current review volume and delay times will tell you which camp you are in.

Can we use an off-the-shelf B2B platform like BigCommerce B2B or Shopify Plus instead of custom?

For the portal layer, often yes — especially if your pricing and credit logic are relatively standard. Off-the-shelf gets you to market faster and you avoid maintaining frontend code. Custom becomes the right answer when your pricing rules, customer-specific catalogues, or credit workflows cannot be modelled in the platform's configuration. The credit engine and the OMS-to-finance integration are almost always custom regardless, because they are specific to your systems.

What does a B2B order management system cost to build?

A full custom OMS is rarely the right answer at this size — the cost model is dominated by features that already exist in products like Cin7, Unleashed, Brightpearl, or NetSuite. What you typically commission custom is the integration and automation layer on top: the credit engine, the Sage or Xero sync, the portal. Scope on those is driven by the four variables listed above (master data quality, number of systems, pricing complexity, history migration). A conversation about those four is what turns the range into a quote.

Do we need to sort out our data before we start, or can the build fix it?

Some of both. You do not need pristine data to start — part of a well-run build is identifying and cleaning the data issues that would otherwise cause integration failures. But if your customer master has 40% duplicates and your SKU list has three different conventions, budget for a data cleanup workstream in parallel. Pretending it is clean and discovering otherwise mid-build is the most common cause of overrun on these projects.