Most UK builders merchants run on a trade counter till, a separate accounts package and a stack of spreadsheets for pricing, credit and branch stock. The software a merchant actually needs is an ERP that handles trade pricing tiers, credit accounts, quotes-to-order, branch transfers and a delivery and hire fleet in one place. Odoo, configured for merchant trade, is a common fit for this in 2026.
If you run a builders merchant or a building supplies distribution business, you already know your operation does not look like a normal shop. You serve trade customers and the public from the same counter, you sell the same bag of cement at five different prices depending on who is buying, half your stock is sand and aggregate sold by weight or by the part load, and a chunk of your money is tied up in credit accounts and unbilled deliveries. Off-the-shelf retail software was never built for any of that. This article walks through what a builders merchant genuinely needs from its software, then shows where a properly configured ERP fits.
There is a difference between what merchants currently use and what the work actually demands. A lot of yards run a point of sale system at the trade counter, a finance package such as Sage for the books, and then a layer of spreadsheets and paper to cover everything the two systems do not talk about. It functions, but it leaks time and money at every join.
The operational reality of a builders merchant has a specific shape, and software either fits that shape or it fights it. Here is what the day-to-day actually involves.
A builder walks in, picks up timber and fixings, and expects to be served at his agreed account price without anyone phoning the office. The next person through the door is a member of the public paying the marked retail price in cash. The counter system has to switch between those two worlds instantly. It needs to recognise the account customer, pull their agreed pricing, check their credit headroom and put the sale on their account, all while the queue behind them grows. A till that cannot tell an account customer from a cash sale forces your counter staff to work it out manually, and that is where the wrong price gets charged.
Pricing in a merchant is not a single number. The same product carries a retail price, several trade tiers, special net prices for specific contracts, and one-off agreed rates for a big job. Customers expect those prices to be honoured every single time, with no argument at the counter. Underneath that sits credit control: account limits, payment terms, statements, and the constant question of whether this customer should be allowed to take more stock before they have paid for the last lot. Get the pricing wrong and you give away margin. Get the credit wrong and you carry bad debt. A merchant needs both managed by the system, not by memory.
A bag of screws is a clean unit. A tonne of ballast is not. Merchants sell loose and bulk materials by weight, by volume, by the bag, by the bulk bag and by the part load, and the same physical pile of aggregate has to be tracked in whatever unit the customer wants to buy it in. The software has to handle multiple units of measure on a single product and convert between them cleanly, so that selling half a load still leaves the right quantity on the system. Spreadsheets and retail tills usually cannot do this without manual fudging, which is how stock figures drift away from what is actually in the yard.
Most merchants deliver. That means a fleet, a loading schedule, delivery notes, proof of delivery and the job of getting the right materials onto the right vehicle for the right drop. Many merchants also hire out plant and tools, which is a different discipline again: availability, out and return dates, condition, deposits and hire charges that accrue over time. Both delivery and hire need to be visible from the same system that holds the sale, or you end up with a delivery diary on a whiteboard and a hire ledger in a separate book.
Run more than one branch and a new problem appears: the customer wants something that is out of stock here but sitting on a shelf two miles away. Without shared, real-time stock visibility across branches, your counter staff cannot promise it, your drivers make unnecessary trips, and stock gets bought in when it was already in the business. Branch transfers, internal movement notes and a single view of group stock are not a nice-to-have for a multi-branch merchant. They are the difference between branches helping each other and competing with each other.
Two more things quietly shape a merchant's profit. Supplier rebates, where you earn money back based on volume purchased, are easy to lose track of and hard to reconcile when the buying data lives in one system and the supplier agreements live in a folder. And the quote-to-order flow, where a builder asks for a price on a list of materials for an upcoming job, needs to turn into a firm order without anyone retyping the whole thing. A quote that cannot become an order in one click is a quote that gets keyed in twice, with all the errors that invites.
Read those needs back to back and a pattern emerges. None of them are exotic. They are simply the normal mechanics of a builders merchant, and they are exactly the mechanics that generic retail or generic accounting software was never designed to carry. This is why so many merchants end up with a system held together by spreadsheets. For a deeper look at the stock side of this, our guide to warehouse and stock management software covers multi-location stock control in detail, and the wider ERP for distribution picture sets builders merchants alongside other distribution businesses with similar problems.
Let us make this concrete. The following is illustrative rather than a named client, but it is representative of the merchants who come to us. Picture a builders merchant running two branches a few miles apart, the kind of business that has grown steadily over twenty years and now turns over enough to feel the strain of running it on systems that were chosen when it was half the size.
The scene that finally pushed them to act was an ordinary Tuesday morning at the trade counter. A regular account customer, a builder who spends with them most weeks, was standing at the counter with a trolley of materials for a job starting that afternoon. He had a price agreed weeks earlier for exactly this kind of order. The lad on the counter knew the price existed. He just could not see it on the screen. The till showed retail prices. The agreed rate was written down somewhere in the office, on a sheet that the counter system knew nothing about. So the customer waited while someone went to find it, while the queue behind him grew, and while everyone in earshot quietly wondered why buying from a place you have used for years should be this hard.
That single moment contained almost every problem in the business. The pricing lived outside the system. The account customer could not be served at account speed. And two branches meant that even if the price had been found, nobody could quickly confirm whether the missing item was sitting in stock at the other branch or needed ordering in.
There is a myth that trips up a lot of merchants at this point. The myth is that there must be a cheap, off-the-shelf builders merchant package that does all of this out of the box, and that buying it is a simple decision. The reality is more nuanced. Generic merchant software exists, but it tends to be either expensive and rigid, locking you into one supplier's way of working, or cheap and shallow, handling the till but none of the pricing, credit, branch and hire complexity that actually causes the pain. The genuine choice is not off-the-shelf versus bespoke. It is whether you build your specific trade rules on top of a flexible platform that already understands stock, sales, purchasing and accounts. That is the gap an ERP fills.
For the merchant in our example, the change was not dramatic in the way software demos pretend. It was quieter than that, and more useful. Trade pricing stopped being a manual hunt: agreed rates lived on the customer record and appeared at the counter automatically, so the builder at the till was served at his price without anyone leaving the counter. Branch stock became visible across both sites, so staff could see in seconds whether something was available at the other branch and arrange a transfer instead of an unnecessary purchase. And account customers were billed correctly against their agreed terms, because the sale, the price and the credit position all lived in the same place rather than being reconciled after the fact. We are deliberately not quoting numbers here, because the honest answer is qualitative: the friction came out of the everyday jobs, and the business stopped relying on the memory of whoever happened to be on the counter that day.
This is the point where it is worth being plain about what we do, without turning it into a sales pitch. Softomate Solutions builds ERP systems for builders merchants and building supplies distributors on Odoo, an open and modular platform that already handles the core of stock, sales, purchasing and accounting. We configure and extend it so that it works the way a merchant works, rather than asking the merchant to work the way the software wants.
In practice that means setting up tiered trade pricing and customer-specific rates so the right price appears at the counter every time, configuring credit accounts and limits so credit control is part of the sale rather than a separate chase, and building the branch transfer and multi-branch stock visibility that lets your sites support each other. It means handling multiple units of measure for sand, aggregate and bulk goods so a part load leaves the right quantity behind, and wiring up the delivery side so loading, delivery notes and proof of delivery sit alongside the order. Where hire is part of the business, that gets modelled too.
Because Odoo is one connected system, the pieces that used to live in separate tools start to join up. The quote a builder asks for can become an order without retyping. The buying data that drives supplier rebates sits next to the supplier agreements. The account customer's pricing, credit position and history are all on one record. If you want the detail of how we approach the platform itself, our Odoo ERP implementation page covers the methodology, and the more technical Odoo inventory and WMS page goes deeper on warehouse and stock mechanics. Merchants who also need to manage customer relationships, sales pipelines and account management more actively often pair the ERP with custom CRM development so the trade counter and the sales side share the same customer view.
None of this is a weekend job, and we would not pretend otherwise. It is a proper implementation with discovery, configuration, data migration and training. But it starts from a platform that already does the heavy lifting, which is why it tends to land somewhere sensible on cost and time rather than the open-ended figures that bespoke-from-scratch projects attract. If you want to see the kind of distribution and ERP work we have delivered, our success stories give a flavour, and the related guide on Odoo 19 for UK wholesale distributors covers the adjacent world of wholesale distribution that shares many of the same mechanics.
The point we want to land is simple. A builders merchant does not need clever software for the sake of it. It needs software that knows the difference between an account customer and a cash sale, that holds the agreed price so nobody has to go and find it, that shows stock across every branch, and that keeps delivery, hire and credit in the same place as the sale. Get that right and the trade counter stops being the bottleneck and starts being the fast, confident front of a well-run yard.
UK builders merchants typically use a combination of a trade counter point of sale system, a finance package such as Sage for accounts, and spreadsheets to cover pricing, credit and branch stock. A more joined-up approach is a single ERP, such as Odoo configured for merchant trade, that handles trade pricing, credit accounts, branch transfers, delivery and hire in one connected system rather than across several disconnected tools.
Yes. A properly configured ERP holds multiple price tiers per product, including retail, trade and customer-specific agreed rates, and applies the correct price automatically at the trade counter based on who the customer is. Credit accounts, limits, payment terms and statements are managed within the same system, so credit control happens as part of the sale rather than as a separate reconciliation afterwards.
Merchant-ready ERP supports multiple units of measure on a single product, so the same pile of aggregate can be bought by the tonne, the bag, the bulk bag or the part load, with the system converting between units cleanly. Selling part of a load correctly reduces the remaining quantity in the yard, which keeps stock figures accurate instead of drifting, as they tend to when bulk goods are tracked on spreadsheets or a basic till.
Yes. A multi-branch ERP gives real-time visibility of stock across every branch from one system, so counter staff can see whether an out-of-stock item is available elsewhere in the business. Branch transfers and internal movement notes let stock move between sites in a controlled way, which reduces unnecessary purchasing and stops branches competing for the same stock instead of supporting each other.
It is rarely a clean either-or. Off-the-shelf merchant packages can be rigid or shallow, while building entirely from scratch is expensive and slow. A common middle path is to configure and extend a flexible ERP platform such as Odoo, which already handles stock, sales, purchasing and accounts, by adding the specific trade pricing, credit, branch and hire rules a merchant needs. This gives merchant-specific behaviour without the cost and risk of starting from nothing.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
