Operations-heavy businesses with physical stock, production steps and multi-step fulfilment are where custom ERP most often beats configuration — and also where the most money gets wasted on systems that were never going to fit.
These are the requirements that actually decide it.
The requirements that break off-the-shelf products
Most products handle stock and orders adequately. These are where the fit usually fails.
Batch and lot traceability
If you must trace a batch from raw material through production to the customer who received it, this is not optional — it is a recall requirement and, in food and pharmaceutical supply chains, a legal one.
Where products fall short: many handle batch tracking in one direction only, or track at the finished-goods level but lose the link to input materials. Test this with a real recall scenario during evaluation: pick a batch of raw material and ask the system which customers received products containing it. The answer should take seconds.
Multi-location stock with real allocation rules
Stock in three warehouses, two vans and a consignment location at a customer site. Allocation rules that reflect how you actually trade — nearest location, oldest stock, reserved for a specific contract.
Where products fall short: multi-location is common; configurable allocation priority often is not. Businesses end up allocating manually and the system becomes a record of decisions rather than a tool for making them.
Units of measure that convert
Buy in tonnes, hold in kilograms, sell in units, price per metre. Conversions that must be exact, including where rounding creates stock drift.
Where products fall short: most support UoM conversion. Fewer handle it correctly through production where yield and wastage change the arithmetic.
Bill of materials with versions and substitutions
What goes into what, which version applied on a given date, and what may be substituted when something is unavailable.
Where products fall short: BOM support is common. Version history and governed substitution rules are where cheaper products stop.
Pricing that reflects how you actually sell
Customer-specific pricing, volume breaks, contract pricing, promotional periods, surcharges, and pricing that changes with material cost.
This is the most common gap we see. Most products have a pricing model. Few have your pricing model, and pricing is usually where the competitive advantage lives — which is exactly the thing worth building rather than adapting.
EDI with large customers
Supplying a supermarket, a major distributor or a national retailer usually means EDI on their terms, in their format, to their timetable.
Where products fall short: EDI is frequently an add-on module or a third-party connector with its own licence. Budget it separately — it is a recurring surprise in the Panorama pattern of technology discovered after the project began.
Batch traceability, tested properly
The requirement most often claimed and least often verified before purchase.
The test that matters — run it during evaluation, with your data:
Pick a batch of raw material. Ask the system which customers received finished products containing it.
It should take seconds. If it takes a query, a spreadsheet and an afternoon, you do not have traceability — you have records that could theoretically be reconstructed into traceability, which is not what a recall needs.
Then run it backwards:
Pick a customer delivery. Ask which raw material batches it contains.
Both directions matter. Forward traceability handles a contaminated input; backward traceability handles a customer complaint.
Where products commonly fall short:
- Tracking at finished-goods level only, losing the link to input materials through production
- Breaking at substitutions — when a material is swapped mid-production, the BOM records the original
- Breaking at repacking or splitting — one batch divided into several, or several combined
- Losing the chain at sub-contracted operations sent out and returned
- No link to the despatch record, so you know what you made but not who received it
Why this matters commercially, not just legally: in a recall, the difference between tracing in minutes and tracing in days is the difference between recalling one batch and recalling everything you made that month. That difference is usually larger than the entire cost of the system.
UK-specific requirements
Making Tax Digital. VAT submissions must come from compatible software with a digital link through the chain. In practice this is a strong argument for keeping your existing accounting package — it already complies, and rebuilding that compliance is pointless work.
Plastic Packaging Tax. If you manufacture or import packaging, this needs tracking at a level most generic systems do not provide out of the box.
UKCA and CE marking documentation. Conformity records tied to batches, retained and retrievable.
Customs and origin documentation. Post-Brexit, commodity codes, origin and customs paperwork matter for anyone trading with the EU, and getting them from your stock system rather than a spreadsheet saves real time.
HMRC record retention. Six years, and the system must be able to produce it.
Costing that tells you something
Most manufacturers and wholesalers cannot answer “what is our real margin on this product line?” quickly, and the ones that can usually find the answer differs from what they assumed.
Why it is hard: cost of goods is scattered. Purchase price is in accounting. Freight and duty arrive on a different invoice weeks later. Production labour sits in a timesheet. Wastage is in someone’s head. Carriage out is often never allocated to the line at all.
What a usable costing model includes:
| Component | Where it usually hides |
|---|---|
| Purchase price | Accounting — usually the only one captured |
| Freight in and duty | A separate later invoice, rarely allocated |
| Production labour | Timesheets, if recorded at all |
| Yield loss and wastage | Rarely recorded |
| Storage, for slow lines | Almost never allocated |
| Carriage out | Often treated as general overhead |
The effect of getting it wrong: businesses routinely discover that a line they have promoted for years is barely profitable once freight and carriage are allocated, while an unglamorous line carries the business. Those are different commercial decisions.
What to build: cost capture at the point each cost occurs, allocated to batch or product line, with the calculation visible so nobody has to take the number on faith. Then margin by product, customer and order, available in seconds.
This is frequently the highest-return thing on the whole list, because it changes pricing and purchasing decisions immediately, and those compound.
Where the money actually is
From what we see, the highest return in these sectors is rarely the full ERP.
Goods-in reconciliation. Matching delivery notes to orders, catching shortages and substitutions at the point of receipt rather than at month-end. Cheap to build, immediate payback.
Stock accuracy. A system where the number on screen matches the shelf. Everything downstream — allocation, promising, purchasing — depends on it, and most businesses are operating with known inaccuracy they have stopped noticing.
Job and product-line costing. Real margin by product, by customer, by job. Most wholesalers and manufacturers cannot produce this quickly, and it changes commercial decisions immediately when they can.
Customer self-service order status. Removes a meaningful volume of phone calls. Usually one of the cheapest wins available.
Purchasing suggestions. Lead times, seasonality and open orders considered automatically, with exceptions escalated.
None of these requires replacing your accounting system. The integration approach is frequently the right answer here.
Allocation rules — where products quietly stop fitting
Multi-location stock is a standard feature. Configurable allocation priority usually is not, and it is where the fit most often breaks.
What businesses actually do:
- Allocate from the location nearest the delivery address
- Allocate oldest stock first, except for a customer who requires minimum remaining shelf life
- Reserve stock against a contract before anything else is promised
- Hold a buffer at the main site that smaller sites may not draw on
- Split a line across locations when no single location can fulfil it
- Never allocate from consignment stock at a customer site without approval
What a product typically offers: a single global rule, sometimes two, usually without customer-specific exceptions.
What happens when they do not match: allocation is done manually. The system becomes a record of decisions someone made in their head rather than a tool that makes them. Every promise date depends on one person’s judgement and their availability.
The cost of that gap is rarely counted. It is minutes per order, every order, plus the promises broken when the person is away and someone else guesses differently.
This is one of the clearest cases for building. Allocation logic is specific, it is commercially important, and it is exactly the sort of rule no product will represent because no two businesses share it.
Build or buy in these sectors
Buy when your production is relatively standard, your pricing is list-based with simple discounts, you are single-site or simple multi-site, and your traceability requirement is straightforward. Products built for manufacturing and distribution exist and are capable.
Build when your pricing model is genuinely distinctive, your production process has steps no product represents, your allocation rules are specific, or you have tried configuring a product and ended up with a spreadsheet alongside it.
Hybrid when — and this is most often — your accounting is fine, your gap is operational, and you need stock and production to work the way you work. Keep the accounting package, build the operational layer, integrate properly.
Full comparison of the products →
EDI with large customers, properly
If you supply a supermarket, a national distributor or a major retailer, this will come up, and it is routinely underestimated.
What EDI actually is: structured electronic documents exchanged in a format your customer specifies — orders in, despatch advices and invoices out. Not an API in the modern sense; typically an older standard with strict formatting.
Why it costs more than expected:
- Each customer specifies their own variant. Tesco’s requirements are not Sainsbury’s. Supporting three large customers is closer to three integrations than one.
- It is usually a separate module or third-party service, with its own licence and setup fee. Rarely included in an ERP quote by default.
- Testing is on their timetable. Certification against a large retailer’s test environment can take weeks of calendar time regardless of your effort.
- Penalties apply. Many retailers charge for non-compliant documents or late despatch advices. The cost of getting it wrong is ongoing.
What to do:
Budget it separately and explicitly. This is a textbook example of the Panorama finding — technology discovered to be necessary after the project began — and it is entirely foreseeable.
Get the exact specification from the customer before scoping. Not “we need EDI” but their current implementation guide, with the document types and the version.
Ask your supplier whether they have certified against this specific retailer before. The learning curve is real.
Allow calendar time for certification that is not engineering time. It sits outside your control.
Evaluating products in these sectors
Test these with real scenarios, not a demo.
- Trace a batch from raw material to the customers who received it. Time it.
- Allocate stock across locations using your actual priority rules
- Convert units through a production step with realistic yield loss
- Price a real order for a real customer with their contract terms
- Produce margin by product line for last quarter
- Handle a substitution mid-production and see whether the BOM records it
- Generate the EDI format your largest customer requires
- Produce VAT in an MTD-compliant way
If the demo cannot do these with your data, the product does not fit — regardless of what the brochure says.
Stock accuracy — the foundation everything else needs
Worth its own section, because every other capability on this page depends on it and most businesses are operating with known inaccuracy they have stopped noticing.
If the number on screen does not match the shelf, nothing downstream works. Allocation promises stock you do not have. Purchasing reorders things you already hold. Margin reporting is wrong because cost of goods is wrong. Customer promises get broken.
Typical causes, in order of frequency:
- Receipts recorded late or in batches. Stock physically arrives Monday, gets entered Thursday. Three days of inaccuracy, every week.
- Movements not recorded at all. Samples, breakages, internal use, items taken for a job and returned.
- Unit of measure errors. Bought in boxes, counted in units, with an inconsistent conversion.
- Returns handled inconsistently. Sometimes booked back in, sometimes not.
- No cycle counting. An annual stocktake finds the discrepancy eleven months after it happened, by which point nobody can explain it.
What actually fixes it:
Record movements at the point they happen, which usually means a scanner or a phone in the warehouse rather than a terminal in the office. This single change does more than any other.
Cycle counting — count a small subset continuously rather than everything once a year. High-value and fast-moving lines more often. You find discrepancies in days, when the cause is still discoverable.
Make the right thing the easy thing. If recording a movement takes four taps, it happens. If it means walking to the office, it does not.
Measure it. Count accuracy as a percentage, reported weekly. A number nobody reports is a number nobody improves.
Do this before building anything clever. Demand forecasting and automated reordering on top of inaccurate stock produces confident wrong decisions faster.
Frequently asked questions
What ERP is best for UK manufacturing?
It depends on complexity. For standard production with simple pricing, products built for manufacturing are capable and cheaper. Custom becomes justified where pricing, allocation or production steps are genuinely distinctive. Most businesses are best served by keeping their accounting package and building the operational layer.
Do I need full batch traceability?
If you are in food, pharmaceutical, aerospace, automotive or any regulated supply chain, yes — and it is a legal requirement. Test it with a real recall scenario during evaluation rather than accepting a feature list.
What does a manufacturing ERP cost in the UK?
An operational layer over existing accounting runs £25,000–£60,000. A mid-size custom ERP runs £60,000–£150,000. Product implementations vary widely by licence and partner.
Can I keep Xero or Sage for a manufacturing business?
Usually yes, and often you should. They are MTD-compliant and maintained for you. The gap is operational — stock, production, costing — and that is what to build or buy around them.
What about EDI with supermarkets?
Usually a separate module or third-party connector with its own licence and setup cost. Budget it explicitly rather than assuming it is included — it is a common source of mid-project surprises.
How do I handle Plastic Packaging Tax?
It needs tracking at a packaging-component level that most generic systems do not provide. Confirm it during evaluation if it applies to you.
What gives the fastest return?
Usually goods-in reconciliation and stock accuracy, followed by product-line costing. All three are achievable without replacing your accounting system.
Written by Jas Singh, Founder. Last updated 8 October 2026. Regulatory requirements change — confirm current obligations with a qualified adviser.
