A Portal Nobody Could Build On

1. At a Glance

Issue study · From the public record. Everything about it comes from its own short public account, given in 2023. The rest of this study is built from the public record around the issue.

Organisation type	A large retail group with an in-house supply chain portal, set beside a UK survey of retail and brand leaders and two e-invoicing rules
Size band	The group: large. Our reader: a mid-size retailer, brand or distributor whose tills, website, stock and accounts do not share
Region	The group: not given in the source. The survey: UK. The rules: India and Saudi Arabia
The decision at stake	What to do when the business’s systems do not share what they know, and each new idea or deadline stops at the oldest of them
The public outcome	The group said its in-house portal, about a decade old, could not take new data features. An older case; no money figure is recorded
Why it matters to a mid-size retailer	Most retailers run several systems joined by people, timed files and scripts nobody has listed. The question is whether that list is made on a plan, or under a deadline after something has stopped

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

“Our website says four in stock, the tills say three, and the shelf has two. Every Monday we argue about which number is right. Two people in finance spend a week each month making the accounts agree with the shop. We wanted collect-in-store; it is ‘dependent on replacement of the stock system’, like the two ideas before it. Now our tax adviser says invoices have to be reported within days, and our trade orders reach the accounts once a month. I do not know how our systems are joined. I only know who to ask.”

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

The firm is caught between systems that each hold their own version of the business and a replacement that keeps being deferred. Meanwhile its staff carry the data between them, and every new channel adds to what they carry.

3. What We Found

Method. We went through the public record on retail systems that do not share what they know: one large group’s account of an in-house system it could no longer build on, a UK survey of retail and brand leaders, a survey of mid-size firms, and two rules on e-invoices, from India and Saudi Arabia, from 2023 to 2026.

One group’s account. In 2023 a large retail group described its in-house supply chain portal.

What	Public record
The system	A supply chain portal, built in-house about a decade earlier
Its state	Out of date; it could not take new data features
What it could not show	Data in real time, which the group said it could not see before
The cost	Not recorded
The country	Not given in the source

The group went on to replace the portal. What it chose is another organisation’s solution, and this study does not describe it.

How common it is. In a survey of about a hundred senior retail and brand leaders in the UK, about seven in ten direct-to-consumer brands said their core systems were not yet fully integrated, and more than half of retailers said fragmented systems were affecting profitability and customer experience. The survey was paid for by firms that sell to retailers. In a separate vendor-sponsored survey of a few hundred leaders at mid-size US and UK manufacturers, retailers and wholesalers, about seven in ten agreed that outdated technology is holding them back.

Two rules on invoices. India’s GST Network announced on 5 November 2024 that “from 1st April 2025, taxpayers with an AATO of 10 crores and above would not be allowed to report e-Invoices older than 30 days from the date of reporting on IRP portals”. AATO is aggregate annual turnover, here 10 crore rupees or more. The advisory applies the limit to “all document types (Invoices/Credit Notes/Debit Notes) for which an IRN is to be generated”. Our reading, for a tax adviser to confirm: in retail, these are sales to other businesses such as distributors, trade-order portals, franchise and wholesale sales, not sales to shoppers. In Saudi Arabia, the tax authority announced on 24 July 2026 that its twenty-fifth e-invoicing wave covers “taxpayers whose revenues subject to VAT exceeded (SAR 187,500) during 2022, 2023, 2024 or 2025” (187,500 Saudi riyals), and that it will notify all targeted taxpayers to “integrate their E-invoicing solutions with the Fatoora Platform by no later than February 1, 2027”.

Our reading of why systems stay unconnected. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has listed how the systems are joined today. Each person knows the crossing they handle; nobody can list all of them, so nobody can say which matter.
2. The oldest system was built to keep, not to share. Nobody now knows it well enough to change the part others need.
3. The only fix on offer is replacement. One missing answer becomes a programme, the programme is deferred, and each new idea waits behind it.
4. The crossings that exist are not looked after. Timed files and scripts carry rules of their own, belong to no system and stop without telling anyone.

Our reading, and only that, of the two rules: where invoices reach the system that reports them only by a monthly export or by re-typing, an invoice dated at the sale has used most of a 30-day window before anyone reports it; and an invoicing system joined to the sale by a monthly file is a hard place to start an integration with a tax platform.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Let people and spreadsheets carry the data	Volumes are low, no reporting clock applies, and few new ideas depend on the systems sharing	The work grows with every channel; a stopped file is found by its effects; a monthly export sits badly with a 30-day reporting limit	Right only while volumes stay low and no clock applies
A connection layer the firm buys from a supplier or has built for it	The crossings are known, and the systems at each end can already give out what is needed	It depends on systems nobody can change, and someone must run and watch it. Crossings nobody listed keep running beside it	The firm’s own choice; it works best once every crossing is listed
Replace everything at once	Most systems are failing, and the business is ready for a long programme	Every team changes on one date; new ideas and deadlines wait for the whole programme	We would advise against this for a firm whose systems mostly work and whose crossings nobody has listed
Map every crossing, then rebuild the part that has to share, module by module	The systems are old and used every day, and a few crossings carry most of the problem	Costs money before anything is joined; old and new run side by side for a time	Our recommendation

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

For the software a retailer built or had built (an in-house stock, order or trade-order portal, and the places where it meets the tills, the website and the accounts): map every crossing first, including those done by hand, timed files and scripts, and give each an owner on the retailer’s side. Then rebuild first the part of the retailer’s own software that has to share, module by module, while the old system keeps running, with each rebuilt part proven against the old one. If the retailer also wants a connection layer, that is its choice and another firm’s product, and the map tells it what is there. The retailer’s own team keeps the old systems and every crossing running throughout.

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 retailer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Crossings between systems, including those done by hand, timed files and scripts	Known in parts, to the people who do them	Every one listed	The map of the system as it stands
An owner for each crossing	Nobody, or whoever set it up	A named owner on the retailer’s side	The list beside the specification
Crossings done by hand	Not counted	Counted, and falling stage by stage	Reported at every review
Ideas and deadlines waiting on the old system	Each marked “dependent on replacement”	Each traced to the crossing or the part it needs	The staged plan
The parts that must share	Waiting on a replacement	Rebuilt module by module, each proven against the old part	The traceability matrix
The size of one commitment	Everything at once, or nothing	One module, with the freedom to pause after any accepted module	The staged plan

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the systems, where the data crosses, and what is waiting on them. 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 software your firm built or had built, and the places where it meets your other systems. 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 part that has to share is rebuilt first. 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: how the retailer’s own software is joined to its other systems, and what it does, in writing.
• The risk register: what the assessment found, listed before any price is set.
• 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.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT has no connection or integration product. A connection layer is an option the retailer may buy or have built; it is not something IOanyT offers.
• IOanyT cannot change a packaged product that belongs to another supplier, such as a till system, an accounts package or a marketplace. Where one sits at the end of a crossing, IOanyT can describe what goes in and out of it, not what happens inside.
• IOanyT does not run, host or monitor a connection, a crossing or any of the retailer’s systems. The retailer’s own team does.
• IOanyT does not clean or correct the data that crosses between systems.
• IOanyT does not install or implement a packaged shop platform, a packaged ERP product or an e-invoicing product.
• IOanyT does not offer a tax, compliance or legal service, and says nothing about what the GST e-invoice limit, the Saudi e-invoicing wave or any other rule requires of a particular firm. Meeting them is the firm’s own work.
• The older technologies IOanyT reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• Staff who carry data between systems are never the problem; they are usually the only people who know where the crossings are. Nothing here is about needing fewer staff.
• This study does not say IOanyT would have solved the group’s problem, or that IOanyT has done this work for a retailer. IOanyT has no published case of this work for a retailer.

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

10. Sources

Source	Used for
Trade press, 2023	A large retail group’s account of its portal
News report of a vendor-sponsored survey, July 2026	UK retail and brand leaders
News report of a vendor-sponsored survey, March 2025	Mid-size firms
GSTN advisory, 5 November 2024	India’s 30-day e-invoice reporting limit
ZATCA, 24 July 2026	Saudi Arabia’s twenty-fifth e-invoicing wave

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 finding out how your systems are joined today, because nobody can say what to join until someone has listed it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →