A Price Agreed Years Ago Can Still Be Running. You Cannot Change a Rule You Have Never Read.

The finance head is looking into one customer’s margin, which has been low for a while.

After two days the reason turns up. A small program takes four per cent off three product lines for that customer, before the order reaches the ERP. It was written years ago, when the customer agreed to take a large volume for one year. The year ended. The volume fell. The four per cent stayed.

Nobody decided to keep it. Nobody knew it was there. The finance head wonders what else is.

What We Found

For this article we went through the public record on rules that live in old programs and on what now depends on them: one Indian tax rule on paying small suppliers, in the government’s own words, and two surveys of technology staff. We found nothing on this subject in manufacturing itself.

An Indian tax rule ties a buyer’s deduction to when small suppliers are paid. In India, section 43B(h) of the Income-tax Act, 1961 came from the Finance Bill, 2023. Its memorandum gives the purpose, “to promote timely payments to micro and small enterprises”, and the rule: “any sum payable by the assessee to a micro or small enterprise beyond the time limit specified in section 15 of the Micro, Small and Medium Enterprises Development (MSMED) Act 2006 shall be allowed as deduction only on actual payment”. Section 15, it says, sets payment within the term of the written agreement, “which cannot be more than 45 days”, or within 15 days where there is no agreement, and the clause applies “to the assessment year 2024-25 and subsequent assessment years”. The rule concerns the buyer’s deduction for sums it owes to micro or small enterprises.

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 from gaps between the systems as built and their documented standards. It covers every sector.

And old systems are left alone because they work. In one survey of about five hundred IT professionals in the US, run by a firm that sells software services, half gave the current system still working as a reason they had not modernised. That survey also covers every sector.

Our reading is narrow. A rule in a program does not expire. It runs until someone removes it, and nobody removes what nobody has read. Payment terms, supplier categories, special prices and release rules are the kind of thing a manufacturer added over the years in programs built around its ERP. We do not suggest that forgotten rules like the one in the story above are common. We do not know how common they are, and nobody has measured it.

What Waits While Nobody Can Read the Rules

Our reading is that the larger cost is what the firm cannot do while its rules stay unread.

• A cost or price rule cannot be changed with confidence. Nobody can say what a new overhead basis or customer term will touch.
• The ERP cannot be moved cleanly. Every rule in the programs around the ERP must be carried across, rebuilt or left behind on purpose, and nobody can list them.
• A rule from outside cannot be traced inside. The 45-day payment rule turns on payment terms and on whether a supplier is a micro or small enterprise. Our reading, and only that: where those details sit in old purchase and payables programs nobody has written down, they are hard for the finance team and its tax adviser to find. We give no tax advice, and we do not say what the rule requires of any firm.

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

Four Ways to Deal With Rules Nobody Remembers, Weighed

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

Option	When it fits	What it risks
Leave the rules where they are, and fix each one when it is found	The programs are few, rarely changed, and no ERP move is planned	Rules are found by accident, one at a time
Have an ERP specialist rewrite the rules inside the ERP	Most of the rules belong in the packaged ERP and the firm has a trusted specialist	Rules are moved before anyone has written down what they did
Write the rules down from the firm’s own programs around the ERP, each with where it lives, then rebuild module by module	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 wants to own
Rebuild the programs straight away, from a fresh requirements document	The programs are small, and the people who set the rules are still at the firm	A rule nobody mentioned is missing from the document and the rebuild alike

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
Rules the programs around the ERP apply to costs, prices, payments and dispatch	In the code, and in a few people’s memory	Each written down in plain words, including the exceptions	The specification
Where each rule lives	Not known	Named: which report, which program, which part	The specification and the map of the system
An owner for each rule	Nobody named	A named owner in the business, or the rule marked as having none	The specification, confirmed by your own people
Rules nobody owns	Not known	Listed for the business to decide	The risk register
Where payment terms and supplier status are held	Not known	Located: which program, which part	The specification
What each rebuilt module is checked against	A requirements document	The rules written down for it, one by one	The traceability matrix

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 and the rules nobody can list. 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 or as your business has decided. 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. An old mistake is written down as faithfully as a good rule, until your people decide about it. We are not costing, tax or accounting advisers, and we give no tax advice on the payment rule or any other. 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 read, change, convert or test customisations inside a packaged ERP product; those rules are for your ERP specialist. We do not keep the old programs running, maintain them or secure them; your own team or supplier does. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	Rules that no longer serve the business stop running it unseen, because each is in front of someone who can decide.
CTO or CIO	A list of what must be carried, rebuilt or left behind before anyone plans the ERP move.
CFO	Old concessions and special prices are on one list, each with an owner who can say whether it stays.
COO	The exceptions dispatch works around every day are written down, and someone in the business decides about each.
Head of risk or internal audit	Each rule has a named owner, or is marked as having none, on a record the firm holds.

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 survey figures come from two vendor surveys, neither about manufacturing.	Our assessment writes down the rules in the programs a firm built around its ERP, each with where it lives, and lists them for the business to decide. Rules inside the ERP itself are for the firm’s ERP specialist.
Under section 43B(h) of India’s Income-tax Act, 1961, from assessment year 2024-25, a sum payable to a micro or small enterprise beyond the time limit in section 15 of the MSMED Act, 2006 is to be allowed as a deduction “only on actual payment”, in the words of the Memorandum to the Finance Bill, 2023.	Our assessment shows where the firm’s own purchase and payables programs keep payment terms and supplier status, where those programs are among the ones it built around its ERP. What the rule requires of the firm is for its finance team and tax adviser; we give no tax advice.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We put every rule your programs apply in front of the business, because a rule nobody has read is a decision nobody has made.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →