Heavily Customised

1. At a Glance

Issue study · From the public record. No organisation described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record. We found no public case of a manufacturer with this problem, so the main case comes from another sector.

Organisation type	The public case: a group of credit unions that shared one heavily customised core system, since replaced. Not a manufacturer
Size band	The public case: a group of credit unions sharing one system; the size of each is not given. Our reader: a mid-size manufacturer whose costing, pricing and dispatch rules sit in reports, add-on programs and database procedures built around a packaged ERP
Region	The public case: not stated in the account we read. The payment rule in section 3: India
The decision at stake	Whether, and how, to write down the rules a firm’s own programs apply before it changes a cost or price rule, or moves its ERP
The public outcome	The credit unions’ heavily customised core system was due to be retired in 2024; replacing it meant building hundreds of new screens and hundreds of interfaces to other systems
Why it matters to a mid-size manufacturer	Customisation gathers quietly over years. The firm that holds it cannot change a rule, move its ERP or answer for a figure until it knows what its own programs do

2. The Business Problem, in the Buyer’s Words

“Ask anyone here how the overhead on a product is worked out, and you get the same answer: that is what the system gives. The rates were set up years ago, in reports and small programs around the ERP, by people who have left. Now the ERP itself has to change, and nobody can tell me what our own programs do that must survive the move. I do not need a new system first. I need to know what rules I am running on.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

3. What We Found

Method. We went through the public record on systems that gathered their own rules over many years: a vendor’s case study of one heavily customised system, a vendor’s article on one older ERP product’s support dates, two surveys, and one Indian tax rule on paying small suppliers. We found nothing on this subject in manufacturing.

One heavily customised system. The nearest public case is from finance.

What	Public record
Who	A group of credit unions sharing one system
The system	A heavily customised core system, due to be retired in 2024 (the account does not say who retired it)
What replacing it involved	Building hundreds of new screens and hundreds of interfaces to other systems
Source	A vendor’s case study
Why it happened	Not examined by us; we draw no cause from the record

This is not a manufacturer. It shows only how much customisation one long-lived system can hold.

Records that drift from the system. 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. The survey covers every sector.

Why old systems are left alone. 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, and more than a third named fear of disrupting operations. The survey covers every sector.

A change that is already dated. For one widely used older packaged ERP product, mainstream maintenance ended at the end of 2025 for some versions, and ends at the end of 2027 for others, with a paid extension to 2030. The source sells support for the product.

A rule about paying small suppliers. In India, the Income-tax Act ties a buyer’s deduction for sums owed to micro or small enterprises to when they are paid.

What	Public record
The rule	Under section 43B(h) of the Income-tax Act, 1961, as the Memorandum to the Finance Bill, 2023 puts it, “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”
The time limit	As the Memorandum to the Finance Bill, 2023 puts it, section 15 sets payment within the written agreement’s term, “which cannot be more than 45 days”, or within 15 days where there is no agreement
Since	Assessment year 2024-25
The stated purpose	In the memorandum’s words, “to promote timely payments to micro and small enterprises”
Who it concerns	The buyer’s deduction, for sums payable to micro or small enterprises

The rule does not mention old systems. Our reading only: the rule turns on payment terms and supplier status, and where the purchase and payables programs that keep them were never written down, those details are hard for a firm’s finance team and tax adviser to find. We give no tax advice and do not say what the rule requires of any firm.

Our reading of why the rules cannot be stated, decided or safely changed. These four are our reasoning from the record above. None is a finding of any source.

1. Each rule arrived as a small change and was never written down. The rules exist only as the behaviour of programs.
2. They live in many places. Inside the ERP, and in reports, add-on programs, database procedures and the tools that feed figures in around it. Nobody has seen them together.
3. Rules are added and seldom removed. A concession for one year or a report for one audit goes on running, because nobody has the list.
4. Rules lean on each other, and nothing records how. A change to one can alter another’s result without any error, and the first complete check is the month-end accounts.

Illustration, not a real case. A maker of industrial filters finds a small program that has taken four per cent off one customer’s prices for years, under a one-year agreement; a change to one freight rate later moves export margins by two points. Every figure here is invented.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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	Right only as a pause with an end date
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,	Right for the rules inside the ERP, once the rest are written down; not IOanyT’s work
Write the rules down from the firm’s own programs around the ERP, each with where it lives, listed for the business to decide; then rebuild module by module	The rules are old, many and spread across reports, add-on programs and database procedures	Costs money before any figure changes; the list will show rules nobody wants to own	Our recommendation
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	We would advise against this where nobody holds a full list of the rules

5. Our Recommendation, and the Decision It Asks of the Board

For the custom reports, add-on programs, database procedures and tools that feed figures in, which a manufacturer built or had built around its ERP: write down the rules they apply first, from their code, each in plain words with where it lives and what uses its result, and have the firm’s own people confirm it. List each rule for the business to decide, with a named owner where there is one; rules nobody owns are listed too. Then, if the board approves, rebuild those programs one module at a time, beside the old ones, with each module’s rules linked to their replacements and each module accepted by the firm’s own people against a benchmark agreed before work starts. The rules written inside the packaged ERP are for the firm’s ERP specialist. Whether any rule is right, and what to do about one that was wrong for years, is for the business and its own finance and legal advisers.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the manufacturer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Rules in the programs around the ERP	Known only as behaviour: “whatever the system gives”	Each written down in plain words, with where it lives	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 confirmed by their owners	None	Every written rule confirmed, or listed for the business to decide	The record of confirmations and the risk register
Where payment terms and supplier status are held	Not known	Located: which program, which part	The specification
Each rebuilt module’s rules	Checked on a few orders	Each rule linked to its replacement	The traceability matrix
Rules still only in the old programs	Not counted	Counted, and falling at every stage	Reported at every review
Rules inside the packaged ERP itself	Mixed in with the rest	Listed as outside our work, for your ERP specialist	The map of the system

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your programs, the figures nobody can explain, and the change or ERP move ahead. 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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: the rules, in writing, each with where it lives, confirmed by the firm’s own people.
• The risk register: what the assessment found, listed before any price is set, including rules nobody owns, listed for the business to decide.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands, including how many rules are left only in the old programs.

9. What This Approach Does Not Cover

• IOanyT does not read, change, convert or test customisations written inside a packaged ERP product, and does not install, configure or upgrade one. Those rules are for the manufacturer’s ERP specialist. Its work is on the programs a manufacturer built or had built around its ERP.
• IOanyT writes down what a rule does, not whether it is right. It is not a costing, tax or accounting adviser, and sets no price, rate or credit term.
• IOanyT gives no tax or legal advice. What the payment rule in section 3 requires of a firm is for its own advisers; nothing here says IOanyT’s work makes a firm compliant.
• Where a rule turns out to have been wrong for years, what to do about the past is for the firm’s own finance and legal advisers. IOanyT does not look into past invoices.
• IOanyT does not keep the old programs running, maintain them or secure them during the work, and does not host them. The manufacturer’s own team or supplier does.
• IOanyT does not clean, correct or move data as a stated service, train staff or manage change.
• This study does not say forgotten rules are common, or that any money will be recovered. IOanyT has no published case of this work for a manufacturer.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A vendor’s case study	The credit unions’ heavily customised system, its sunset date, and the screens and APIs its replacement needed
A vendor’s survey report, 2025	Records that drift from the system
A vendor’s survey of US IT professionals, 2025	Why firms keep old systems
A vendor’s article, 2025	One older ERP product’s maintenance dates
Memorandum to the Finance Bill, 2023, p.12	The payment rule, its stated purpose, the 45-day and 15-day limits, and the assessment year

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 writing down the rules a firm’s own programs apply, so the business can decide about each one before anything changes.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →