Ask How a Product Cost Is Worked Out, and the Answer Is "Whatever the System Says". The Rules Are in Programs Nobody Has Read.

A buyer at a large customer has asked for a price on a new variant: the same part, in a slightly heavier gauge of steel.

The sales head asks costing for a figure. Costing runs the report and reads out a number. The managing director, who is in the room, asks how the overhead in that number is arrived at.

There is a pause. “It is whatever the system gives for that product family.” The rate sits in a report written around the ERP years ago, and has been adjusted since by people who have left. The quotation goes out anyway.

What We Found

For this article we went through the public record on systems that gathered their own rules over many years: a vendor’s account of one heavily customised system being replaced, a vendor’s article on one older ERP product’s support dates, and two surveys of technology staff. We found nothing on this subject in manufacturing: no named manufacturer and no figure. Every fact below comes from other sectors.

Four findings stand out.

Customisation gathers in one system until replacing it is a project of its own. A group of credit unions shared one heavily customised core system, which was due to be retired in 2024. Replacing it meant building hundreds of new screens and hundreds of APIs for its links with other systems. This is finance, not a factory, and the source is a vendor’s case study, used only to show how much can gather in one system.

What is written down drifts from what runs. In one survey of several hundred technology leaders and practitioners in the US and UK, run by a firm that sells software tools, the great majority reported harm to the business when what had been built no longer matched the documented standards. The survey covers every sector, and it is about documents that no longer match what was built.

The ground under the programs will move, ready or not. For one widely used older packaged ERP product, mainstream maintenance ended on 31 December 2025 for some versions, and ends on 31 December 2027 for others, with a paid extension to 31 December 2030. The source sells support for the product. Every program a firm built around such an ERP will have to work with whatever follows it.

Old systems are kept because they work. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, half said their current system still worked as a reason they had not modernised. A program can work, producing a figure every time, while applying a rule nobody in the building could state. That survey also covers every sector.

Our reading is that a manufacturer’s rules for costing, pricing and releasing orders are exact and complete. They are written in code, in many places, and nobody has read them back. Some are inside the packaged ERP. Many sit around it: a custom report, a small program that adjusts prices before an order goes in, a procedure in the database, a tool that feeds standard costs in.

What Waits While the Rules Stay Unread

This is usually called a documentation problem. Our reading is that it holds three decisions in place.

A rule cannot be changed with confidence. A new freight rate or customer term is added beside rules nobody has read, and the first full check of what else moved is the month-end accounts.

The ERP cannot be moved cleanly. When the ERP changes version or is replaced, the programs around it must be carried across or rebuilt, and nobody can say what must survive the move.

A figure cannot be answered for. When an auditor, a customer or the board asks how a cost or a price is arrived at, the answer is a screen, not a rule.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Find Out What the Rules Are, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Ask the people who use the figures, in workshops	The rules are few, and the people who set them are still at the firm	The list holds what people remember, and misses what the programs do by themselves
Ask the ERP specialist to document what is inside the ERP	The rules sit mostly inside the packaged ERP, in its own settings and language	It covers the ERP only; the reports and programs built around it stay unread
Wait until the ERP move forces the question	The ERP change is near and is being planned anyway	The rules are found under a deadline, by the project that has least time to find them
Write down the rules from the firm’s own programs around the ERP, each with where it lives	The rules are old, many, and spread across reports, add-on programs and database procedures	It costs money before any figure changes, and the list will show rules nobody remembers asking for

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own programs, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
Costing, pricing and dispatch rules in the programs around the ERP	Known only as behaviour: “whatever the system gives”	Each written down in plain words, confirmed by your own people	The specification
Where each rule lives	Not known	Named: which report, which program, which database procedure	The specification and the map of the system
What each rule uses, and what uses its result	Not recorded	Recorded for each rule	The specification
Rules nobody owns	Not known	Listed for the business to decide	The risk register
Rules inside the packaged ERP itself	Mixed in with the rest	Marked as outside our work, for your ERP specialist	The map of the system

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a manufacturer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your programs, the figures nobody can explain, and where you think the rules are kept. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the custom reports, add-on programs, database procedures and tools that feed figures in, which you built or had built around your ERP. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the programs around your ERP, rebuilt one module at a time, each rule carried across as it stands in the confirmed specification. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. Writing the rules down costs money and changes no figure the system produces. We do not read, change, convert or test customisations written inside a packaged ERP product, and we do not install, configure or upgrade one; those rules are for your ERP specialist. We write down what a rule does and do not say whether it is right: we are not costing, tax or accounting advisers. If a rule turns out to have been wrong for years, what to do about the past is for your own finance and legal advisers. We do not keep the old programs running, maintain them or secure them; your own team or supplier does. We do not clean or correct data. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	The firm can say how its own costs and prices are worked out, and prices a new product or customer knowing which rules apply.
CTO or CIO	A record of each rule and where it lives: which report, which add-on program, which procedure in the database.
CFO	A cost or a margin can be traced to a written rule, and is not accepted only because the system produced it.
COO	Dispatch and planning staff can explain why an order was priced or released as it was.
Head of risk or internal audit	When the auditor asks how a figure is arrived at, the logic is on paper, with the place it is kept.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from a vendor’s case study of a group of credit unions, two vendor surveys and a vendor’s article on one ERP product’s support dates, none of them about manufacturing.	Our assessment writes down the rules in the programs a firm built around its ERP, each with where it lives, for its own people to confirm. Rules inside the ERP itself are for the firm’s ERP specialist, and whether a rule is right is the firm’s to say.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by reading back the rules your programs already apply, because nobody can change, move or answer for a rule they have never read.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →