Invoices Now Have a Clock. Systems Joined by a Monthly File Run Behind It.
India's e-invoice reporting limit and Saudi Arabia's next e-invoicing wave both set dates for invoices and a tax portal. Here is what waits on systems that do not share, the four ways to answer it, and the benchmark for the decision.
The trade-order portal is the success of the year. Distributors place their orders online, and volume has doubled.
The orders do not reach the accounts on their own. Once a month, someone exports them, and two people in finance key the invoices in. It has always worked.
Then the tax adviser sends a note: the firm’s invoices now have to be reported within a set number of days. Someone asks how the orders could reach the accounts daily instead of monthly. The answer is familiar: not on the current system.
The paradox: The business sells faster than ever, and its invoices travel at the speed of a monthly file.
What We Found
We looked at what two tax bodies have announced about invoices, and at one account of an old in-house system that could not take on new work.
In India, e-invoices have a 30-day reporting limit for larger suppliers. 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. Its example: “if an invoice is dated 1st April 2025, it cannot be reported after 30th April 2025.” 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 (distributors, trade-order portals, franchise and wholesale sales), not sales to shoppers.
In Saudi Arabia, the next e-invoicing wave has a date. The tax authority announced on 24 July 2026 that its twenty-fifth wave covers “taxpayers whose revenues subject to VAT exceeded (SAR 187,500) during 2022, 2023, 2024 or 2025”, that is, 187,500 Saudi riyals. The authority says it will notify all targeted taxpayers to “integrate their E-invoicing solutions with the Fatoora Platform by no later than February 1, 2027”.
An old in-house system can stop new work altogether. A large retail group described its in-house supply chain portal, about a decade old, as out of date: it could not take new data features. This is an older case, from 2023, about a large group, with no money figure.
What our review does not show: We read the GST Network’s advisory and the tax authority’s announcement, not the laws behind them. The advisory does not itself mention sales to shoppers; “sales to other businesses” is our reading of where e-invoicing applies, for a tax adviser to confirm. We did not confirm whether shop-till invoices are covered by the Saudi wave. No source ties either rule to any retailer’s old system. We found no named mid-size retailer with this problem, and the large group’s source gives no country.
What Waits on Systems That Do Not Share
When a new need meets an old system, the usual answer is “dependent on replacement”. The better question: what can the business not do while its systems pass data by hand and by monthly file?
Invoices on time. Our reading, and only that: if an invoice is dated at the sale and keyed a month later, most of a 30-day window has gone before anyone reports it. Where trade orders reach the accounts only by a monthly export or by re-typing, the clock runs while the file waits. An invoicing system joined to the sale by a monthly file is also a hard place to start an integration with a tax platform. Whether either rule applies to your firm, and what it requires of it, is for you and your tax advisers.
The next way of selling. Collecting an online order in store, a marketplace listing, one loyalty card. Each needs one system to give out something it was built to keep, and each joins the queue behind the same replacement.
The people in between. Every new channel adds to the copying. The staff who do it are doing it well, and their time appears in no budget line.
The gap we see: judged as an integration project, joining the systems looks large and uncertain, so it waits. Set beside invoices that now have a clock, and the ideas waiting on the same system, it is a different decision. The opportunity is to find out once where the data crosses and what blocks it, and to rebuild first the part that has to share.
This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own business.
Four Ways to Make Your Systems Share, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Let people and spreadsheets carry the data | Volumes are low and no reporting clock applies | The work grows with every channel. A monthly export or re-keying sits badly with a 30-day reporting limit |
| A connection layer that you buy from a supplier or have built for you | The old systems can already give out what is needed, and are sound otherwise | It depends on systems nobody can change, and someone must run and watch it |
| Replace everything at once | Most of the systems are failing, and the business is ready for a long programme | Every team changes on one date. The deadline and the new ideas wait for the whole programme |
| 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 | Several stages. For a time old and new run side by side, and you pay for both |
Our recommendation: map every crossing between your systems first, including the ones done by hand. Then rebuild first the part of your own software that has to share, such as the order module of an in-house portal, while the old system keeps running, and then the next, module by module. If you also want a connection layer, that is your choice and another firm’s product; the map tells it what is there. We have no connection or integration product, we cannot change a packaged product that belongs to another supplier, and we do not run or monitor a connection.
Where You Are Now, and Where You Should Be
Before the next replacement is quoted, we would set a benchmark for the decision itself.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| 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 |
| How invoices reach the system that reports them | By monthly export or by hand, not written down | Every step written down, with its carrier and delay | The map of the system as it stands |
| The cost of staying as you are | Never counted: copying, corrections, ideas waiting | Set beside the price of each stage | The cost comparison |
| The cost of change | One large replacement quote | A price for each stage, set after the system is read | The staged plan and quote |
| The size of one commitment | Everything at once, or nothing | One module, with the freedom to pause after any accepted module | The staged plan |
The starting points above are what we expect to find. In an engagement they are replaced by your own position. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your 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.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the software your firm built or had built, such as an in-house order, stock or trade-order portal. 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, starting with the part that has to share. We never do a single cutover. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- 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.
What you need to bring: a budget for the assessment; read-only access to the code once the assessment begins; a few hours from the people who carry the data today; someone to accept each module with real orders; and your own team keeping the old systems running.
What we do not do: we have no connection or integration product, and a connection layer is not something we offer. We cannot change a packaged product that belongs to another supplier, such as a till system, an accounts package or a marketplace. We do not run, host or monitor a connection or any of your systems. Meeting the GST e-invoice limit, the Saudi e-invoicing wave or any other rule is your own work: we do not offer a tax, compliance or legal service, and we do not say what any rule requires of a particular firm. We have no published case of this work for a retailer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | A new way of selling stops waiting for a replacement programme. |
| CTO or CIO | Only the part that has to share is changed. Everything that works is left working. |
| CFO | The cost of carrying data by hand, and the price of rebuilding the part that has to share, sit side by side before anything is replaced. |
| COO | One hand-off at a time stops being done by people, who move from copying to checking. |
| Head of marketing | The campaign that needed store and web to share gets a date. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large retail group said its in-house portal, about a decade old, could not take new data features. | Our part is narrower, and IOanyT did not work on this case. For a retailer’s own software, we read it first, set out the options, then rebuild the part that has to share. |
| India’s GST Network announced on 5 November 2024 that from 1 April 2025 taxpayers with an aggregate annual turnover of 10 crore rupees or more “would not be allowed to report e-Invoices older than 30 days”. | Our assessment shows how invoices reach the system that reports them, and what rebuilding that part would take. Meeting the limit is the taxpayer’s own work. |
| Saudi Arabia’s tax authority announced on 24 July 2026 that it will notify the taxpayers in its twenty-fifth e-invoicing wave to integrate with its platform “by no later than February 1, 2027”. | Our part is narrower. We supply no e-invoicing product. For a seller’s own software, our assessment shows where the invoice data is held. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The tax authorities set the clock; how your invoices keep to it should rest on a reading of your own systems.
Sources
In this issue
Systems that do not connect
Research note 1
Retail Systems Rarely Share What They Know. The Connection Is Usually a Person.
Tills, website, stock and accounts that do not share what they know: what the public record shows, what waits while people carry the data, four ways forward.
Research note 3
Every Crossing Between Your Systems Should Have an Owner. Here Is the Benchmark We Would Set.
Timed files, scripts and people join a retailer's systems, and nobody has listed them. The benchmark we would set for those crossings, and the path forward.
Issue study
A Portal Nobody Could Build On
Retail systems that do not share what they know: an in-house portal that could not be built on, survey findings, e-invoicing deadlines, the options.
More from Retail
Old php and databases under the shop
A Few Old Parts Hold the Whole Shop on an Old Version. Everything Else Waits With Them.
Accounts and systems held by someone else
A Firm That Does Not Hold Its Own Systems Cannot Plan a Move.
Wrong or unreliable data