IT Investment Approval Requests | Fixing Rejections in Thailand

The need for a production management system or an IT asset management tool is usually already accepted on the shop floor. The hard part comes when it is time to put that need in front of a decision maker. Most IT investment approval requests stall not because the system itself is a bad fit, but because of how the approval document is put together. This article organises the typical patterns that get a request sent back, the dual approval structure specific to Japanese-affiliated companies in Thailand, and the standard set of items a strong approval document should contain, drawing on practitioner articles and primary sources.

Why IT investment approval requests get sent back

When an approval request is rejected, the reason tends to get filed away as “the person who wrote it did not explain it well enough.” In practice, the causes fall into a small number of recurring patterns. It is worth naming them first.

Four typical patterns behind a rejection

Practitioner articles on this subject converge on the same handful of reasons with surprising consistency. Summarised, they come down to four patterns.

• The case for the benefit is too thin — the request stays at the level of phrases like “improve efficiency” or “strengthen security” without stating what changes, and by how much, in numbers
• No comparison of alternatives is shown — a single vendor’s quote is used to argue “this is the only option,” with no explanation of why other options were excluded
• Ongoing operating cost is missing — only the upfront cost is presented, and licence renewal or maintenance fees surface only after the fact
• The user and the owner are undefined — who will use the system and who will be accountable for it after go-live is treated as something to be decided after the request is approved, not before

From the decision maker’s point of view, all four collapse into a single question: is this investment in a state that can actually be managed? What decision makers tend to dislike most is not a shaky number so much as not being able to see what happens if the investment is not made, or who is accountable once it has been.

Flip that around, and improving an approval document is not really about polishing the language that describes the system. It is about closing the four gaps above, one at a time. Quantifying the current problem, laying out multiple options, presenting a total cost that includes operating expense, and settling who the user and the owner will be — none of these is a rhetorical trick aimed at winning the decision maker over. They are unglamorous preparation work, the kind of groundwork needed to assemble the material an investment decision actually requires. Because it is unglamorous, it tends to get put off, and that is exactly what turns into a rejection later.

IT budgets are rising, so why do individual requests still struggle to get through?

There is a data point worth keeping in mind here. According to preliminary results from the “Enterprise IT Trend Survey 2026,” published in February 2026 by JUAS (the Japan Users Association of Information Systems), 52.6% of companies reported that their IT budget “increased” in fiscal 2025, with a diffusion index (DI) of 43.3 points. That marks a fifth consecutive year of increase since the dip caused by the COVID-19 pandemic in fiscal 2020, and the outlook for fiscal 2026 remains elevated at 39.9 points.

In other words, the overall IT budget envelope is expanding at many companies. So why do so many teams still find individual requests hard to push through? The reason is simple: a growing budget pool and an individual project meeting its burden of proof are two separate matters. The larger the overall envelope, the more closely decision makers tend to scrutinise each case on its own merits, asking whether this particular priority really deserves the spend. It is a mild paradox that, in flush budget periods, thinly argued requests can actually have a harder time getting through.

Worth noting too, the same survey found that “increased AI-related investment and usage fees” as a reason for the budget increase grew from 36.3% in fiscal 2025 to a projected 43.7% in fiscal 2026, a rise of 7.4 points — the largest jump among all the listed reasons. As appetite for AI-related spending grows, it is worth bearing in mind that core-system investments such as production management platforms may end up competing for priority against AI-related budget lines.

What a decision maker looks at first

Whoever drafts the request tends to start by explaining the background. But what a decision maker usually reads first is the comparison between investment amount and benefit, and whether risk has been addressed at all. If the background section runs too long, the reader’s attention can run out before reaching what they actually came for.

For anyone thinking through how to budget for a system investment, what matters is not the total length of the document but whether the decision maker can tell, within the first few seconds, that this is a request that has genuinely been thought through. In practice, that means putting the current problem, the investment amount, and the benefit at the top of the first page, and pushing the comparison of alternatives and the risk discussion to the second page onward — an allocation recommended consistently across practitioner articles. The same logic applies whether the request concerns capital equipment or an IT system: leading with the conclusion matters either way.

Who approves what | The dual approval structure at Thai subsidiaries

Pushing an IT investment through at a Japanese-affiliated factory in Thailand introduces a consideration that does not exist in a purely domestic Japanese approval process: two separate approving bodies, the head office and the local subsidiary.

What the head office IT governance function looks at

At many Japanese multinationals, IT investments above a certain scale require reporting to, or prior consultation with, the head office IT governance or IT strategy function. What gets examined there is less the merits of the individual case and more its alignment with global IT strategy and security standards. A choice that looks optimal locally can still be sent back if it falls outside the standard architecture or data governance policy set by the head office.

Generally speaking, how much authority over investment decisions, contracting, and IT matters is delegated from the parent company to a local subsidiary varies from one company to another, depending on how formally that boundary has been defined. Where the boundary is clear, the local entity tends to make decisions more independently; where it is vague, a request approved locally can end up being pulled back for head office review later, which means doing the work twice. Confirming where that boundary sits before drafting the request is the shortest route to avoiding that detour.

From the head office’s perspective, if each local subsidiary builds out its own separate systems, the cost of consolidating data and standardising across the group tends to balloon later. Head office IT governance reviews individual IT investment cases not to override the local judgment, but to confirm in advance that the choice holds together when viewed at the group level. Once a local team understands that purpose, it becomes easier to frame the conversation with head office as “please confirm this is consistent” rather than “please grant permission,” which tends to make the exchange go more smoothly.

The local managing director’s approval authority

At Thai subsidiaries, it is common for the local managing director (MD) to hold sole authority to approve investments up to a certain amount. Beyond that threshold, the request typically joins the head office approval route — a two-tier authority structure found at many Japanese-affiliated local entities.

Worth flagging here: the specific monetary threshold varies significantly by each company’s internal authority regulations, and no published standard figure exists. The first thing anyone drafting a request should confirm is where their own company’s authority regulations draw the line for investment amounts, because that determines whether the matter can be settled locally or needs to involve the head office.

The axes that decide whether head office needs to be involved

Beyond the monetary amount, there are a few other axes worth using to judge whether an investment can be settled locally. One is whether the investment is self-contained at the local site, or involves data integration with other sites or head office systems; investments that involve data integration tend to draw in head office IT even when the amount is small. The other is whether the investment could plausibly become a rollout model for other sites in the future; an investment with expansion potential is generally better shared with head office early, rather than decided locally in isolation, to avoid duplicated approvals or a redesign later.

Checking these axes before drafting a request reduces the uncertainty around “how far can we act on our own authority” when budgeting for a system investment, and helps prevent the rework that comes from misjudging the approval route.

How the approval route branches by scale (a general pattern)

Practices vary by company, but the branching pattern seen at many Japanese-affiliated local entities can be summarised as a rough guide to scale. Treat this as a general tendency rather than a definitive monetary threshold.

Once you can see which row your own investment is closest to, it becomes clearer where the request needs more depth. For an investment that stays local, put the effort into scrutinising operating cost; for one that involves head office, put the effort into a thorough comparison of alternatives and a fuller security explanation.

The standard set of items an approval document should contain

Approval documents that get through tend to share a common structure. Different practitioner articles phrase it differently, but the elements converge on the same six items.

This structure broadly matches the approach used for capital equipment approval requests as well, so IT investment does not require a fundamentally different format. The difference, as covered below, lies in the nature of the investment amount and the benefit.

Within this structure, the investment amount item is the one most often left incomplete. It is common to tally only the upfront cost and leave ongoing maintenance out of the document entirely. For a sense of typical maintenance cost, see System Maintenance Cost for Factories, which is useful when assembling the total investment figure. For a benchmark on the investment amount itself, see Production Management System Cost.

The alternatives-compared item is another leading cause of rejection. Demonstrating what was actually compared starts with putting requirements to multiple vendors and collecting quotes. How to structure and present those requirements is covered in Production Management System RFP Guide. Once a vendor is chosen, how to work through contract terms is covered in System Development Contract.

Next, a closer look at how to write the benefit item, since that is often what makes or breaks a request’s persuasiveness.

When writing the benefit item, stacking only the effects that can be monetised tends to make the number too small to be persuasive for investments like production management systems that also carry qualitative benefits, such as consolidated information or faster decision-making. The classification used in Production Management System Pros and Cons is a useful reference for splitting benefits into what can and cannot be monetised. Rather than forcing a benefit that cannot be reduced to a number, presenting it as a separate qualitative point holds up better if the basis for the number is questioned later.

Aligning with decision makers before submission, a step outside the document itself

The six items above are about the quality of the approval document itself. There is one more factor that operates outside the document: sharing the content with the people along the approval route once, informally, before formally submitting it.

Submitting a finished request cold means the decision maker encounters the content for the first time at the moment of approval, which is exactly when objections and concerns tend to surface. Getting feedback from a superior or a related department beforehand, by contrast, lets you rewrite the parts most likely to draw criticism ahead of time, and it also means the decision maker is hearing something familiar rather than something new, which lowers the psychological barrier. This is not about massaging the content — it is a check to surface anything that could become a landmine before the request goes in formally.

At a Thai subsidiary, this informal pre-sharing extends not only to the local MD but, depending on the nature of the case, to the relevant contact at head office as well. The more likely an investment is to involve head office, the more this informal groundwork ahead of the formal approval route helps prevent a later rejection.

For the risk and mitigation item, working backward from what has gone wrong after go-live at other implementations is an effective approach. The typical stumbling points covered in Production Management System Implementation Failures can be used directly as material for this section. The operating structure item is more persuasive when it goes beyond deciding this after the request is submitted and includes how asset management will be handled once the system is running. IT Asset Management is a useful reference for designing that structure.

Closing the gap between the budget cycle and the IT investment decision

Another reason approval requests struggle to get through has nothing to do with content — it is timing. When the budget planning cycle and the timing of a system investment decision are out of step, even a well-argued proposal can miss its window.

The budget cycle common to many Japanese companies

At many Japanese companies, annual budget planning typically begins around the end of the prior fiscal year, is finalised by the end of the fiscal year, and starts fresh with the new fiscal year. IT budgeting tends to follow the same three-layer structure in practice: a medium-term plan spanning three to five years is rolled forward annually, broken down into a single-year budget, and then further broken into quarterly milestones.

Once that structure is understood, it becomes clear that there is a right time to draft an approval request as well. Submitting a proposal as something that suddenly came up mid-year is less effective than preparing it to align with the next fiscal year’s budget cycle and stating explicitly where it sits within the medium-term plan — framing it as part of a strategy rather than a one-off case tends to land better with decision makers.

Small-start and phased rollout as a way around the mismatch

That said, waiting for the budget cycle can mean delaying a problem the shop floor needs solved sooner. This is where breaking the investment into smaller, staged pieces becomes useful.

The approach is to keep the first phase within a budget small enough to get approved easily, demonstrate the benefit as a track record, and then push through the request for full-scale rollout aligned with the following year’s budget cycle — a two-step structure. The practical thinking behind this approach is set out in Small-Start System Implementation. When the budget cycle and the investment decision are out of step, the phased approach covered there is a practical way to close that gap.

Thailand-specific considerations | How BOI and depa affect the investment case

An approval request built around a Thai factory carries considerations that do not appear in a purely domestic Japanese document, namely how to handle government incentive schemes.

Investment decisions where BOI privileges are already in place

Companies holding Board of Investment (BOI) privileges already have measures in place, such as corporate income tax exemption, that affect the investment decision itself. If tax incentives are cited as part of the investment rationale in an approval request, it is necessary to confirm in advance which privileges the company currently holds and whether they are compatible with any newly considered tax incentive. Because the details of these privileges vary by industry and by the terms of each company’s own approval, it is safer to avoid definitive statements and instead frame the wording as contingent on confirmation with a tax specialist or the company’s own accounting department.

The depa 200% deduction, and its constraints

In Thailand, depa (the Digital Economy Promotion Agency) and the Revenue Department have promoted a tax incentive under Royal Decree No. 802 (B.E. 2569) that allows a 200% deduction. It covers spending on the purchase or use of computer programs, hardware, smart devices, and digital services, allowing a 200% deduction up to a cap of THB 300,000. It applies to SMEs with paid-up capital not exceeding THB 5,000,000 and annual revenue not exceeding THB 30,000,000, and it covers expenditure incurred between 24 June 2025 and 31 December 2027.

The important point here is that companies receiving BOI investment promotion privileges are excluded from this measure. Because many Japanese manufacturers operating in Thailand hold BOI privileges, the cases where this 200% deduction can be cited directly as grounds in an approval request are limited. It can be tempting, while drafting the request, to add this scheme as an investment benefit, but doing so without first checking whether the company actually holds BOI privileges risks having the assumption collapse later during tax review, undermining the credibility of the whole request. Knowing that a scheme exists and confirming whether it applies to your own company are two separate pieces of work.

Do not make getting the approval itself the goal

Having worked through the structure that makes an approval easier to obtain, it is worth closing with the stance this site returns to repeatedly.

Getting an approval through is the starting point of an investment, not the finish line. Pushing a request through on an inflated ROI figure, only to fail to deliver on that number in practice, undercuts the persuasiveness of the next request you bring forward. Keep the benefit estimate conservative, and where a benefit cannot be monetised, describe it qualitatively rather than forcing it into a number. That honesty is what makes the next request easier to get through, over the long run. It is more realistic to think of the approval process not as a one-off procedure, but as a process of building trust with decision makers through a track record of investments and results, accumulated case by case.

For instance, if the benefit estimate presented in the first request was conservative and the actual results after go-live exceed it, the credibility of the person making the case builds up for the next round. Conversely, if an ambitious number is presented up front and falls short, decision makers will discount the numbers in future requests even when the next investment is genuinely necessary. For a team that goes through IT budget planning every year, this compounding effect only grows larger over time.

Where to start checking your own approval request

Turning the above into something actionable, here are items that can be filled in internally before you start drafting.

• Can the current problem be described in numbers, such as labour hours, downtime, or error counts, based on records rather than a general impression?
• Does the investment amount include maintenance and licence renewal costs, not just the upfront cost? Is it estimated as a roughly three-year total?
• Are there multiple alternatives compared, rather than a single vendor’s quote? Is there a comparison against staying with the status quo?
• Is the benefit split between what can and cannot be monetised, rather than forced into a single number?
• Are the anticipated risks and the mitigation for each laid out, rather than resting on optimistic assumptions alone?
• Are the user department and the owner after go-live already decided at the point the request is submitted, including the operating structure?
• Have you checked, against your own company’s authority regulations, which approval route this investment amount falls under, and whether it is settled locally or involves head office?
• Have you confirmed whether the scale requires reporting or prior consultation with head office IT governance, to avoid a duplicated approval after the fact?
• Have you decided whether to align with next year’s budget cycle or move ahead sooner with a phased approach?
• If BOI privileges or the depa scheme are cited as grounds, have you confirmed whether they actually apply to your company?

If the first five of these are filled in, the skeleton of the approval document is in place. What remains is timing and the approval route — factors outside the content itself.

Frequently asked questions

How should an IT investment approval request be written?

The basic structure is six items: state the current problem in numbers, present an investment amount that includes upfront and ongoing maintenance cost, separate benefits that can and cannot be monetised, show the alternatives compared, and specify anticipated risks and mitigation along with the operating structure after go-live. Practitioner articles consistently recommend keeping the main document to a few pages, with detailed quotes and technical specifications attached separately.

Why do IT investment approval requests get sent back?

The reasons converge on four patterns: the benefit stays at the level of abstract phrases, no comparison of alternatives is shown, ongoing maintenance cost is missing, and the user or owner is left undefined. All four share the same underlying issue from a decision maker’s perspective — it is not clear whether the investment is in a state that can be managed.

Between head office and the Thai local entity, which approval should be pursued first?

This depends on each company’s own authority regulations, so there is no single answer. That said, at many Japanese-affiliated local entities, investments below a certain amount are settled entirely through the local managing director’s approval, while larger investments or those spanning multiple sites require reporting or prior approval from head office IT governance — a two-tier structure. Confirming where that line sits in your own company’s regulations before drafting the request is the shortest way to avoid a detour.

Is the approach different for a capital equipment approval request compared with an IT investment request?

The basic structure — current problem, investment amount, benefit, alternatives compared, risk and mitigation, operating structure — is shared. IT investment differs in that, beyond the upfront cost, ongoing expenses such as licence renewal and maintenance fees are common, and part of the benefit, such as faster operations or consolidated information, is harder to monetise than it typically is for capital equipment. These two points need more careful treatment than they would for a piece of equipment. On top of that, capital equipment tends to follow a fairly standard depreciation schedule and statutory useful life, whereas how IT spending gets recognised often depends on technical obsolescence and on the contract structure — an outright purchase versus a subscription — which is another point worth confirming with the accounting department in advance.

When should preparation for the IT budget begin?

At many Japanese companies, budget planning for the following fiscal year begins around the end of the prior year and is finalised by the end of the fiscal year. Preparing the approval request to align with that cycle, and stating explicitly where it sits within the medium-term plan, makes it more likely to be received as part of a strategy rather than a one-off case. For urgent issues that cannot wait for the cycle, starting with a small phase is a practical alternative.

How should BOI or depa incentive schemes be described in an approval request?

The safer approach is to introduce the scheme’s existence without asserting that it definitely applies to your company. In particular, the depa 200% deduction excludes companies that hold BOI investment promotion privileges, so for Japanese manufacturers in Thailand that already hold BOI privileges, it often cannot be used directly as grounds for the investment. If a tax incentive is cited as part of the rationale, confirm applicability with a tax specialist or the accounting department before including it.

Is it too late to budget for a system investment partway through the fiscal year?

Securing new budget outside the planning cycle is difficult at many companies. That said, starting with a small phase that fits within the existing budget, and then aligning the full-scale rollout request with the following year’s formal budget cycle, makes it realistic to begin even mid-year. For an urgent issue, starting small and building a track record first is the more effective sequence.

Summary

Here are the main points of this article.

The reasons IT investment approval requests get sent back converge on four patterns: insufficient grounds for the benefit, no alternatives compared, missing operating and maintenance cost, and an undefined user or owner. As JUAS’s survey shows, the overall IT budget envelope is trending upward, but that does not mean individual requests get easier to approve. If anything, the more budget is available, the more each case is held to account.

At Japanese-affiliated entities in Thailand, a dual structure exists between head office IT governance involvement and the local managing director’s approval authority, and the approval route branches depending on the scale of the investment. Building the six-item structure — current problem, investment amount, benefit, alternatives compared, risk and mitigation, operating structure — into the approval document ensures the material decision makers look for is presented without gaps.

Where the budget cycle and the investment decision are out of step, a small-start or phased approach is a practical option. On Thailand-specific points, BOI privileges and the depa 200% deduction scheme both exist, but because the latter excludes BOI-holding companies, it should not be added to an approval request without first confirming whether it actually applies to your company.

Finally, it bears repeating that getting the approval through should not be treated as the goal in itself. Presenting the benefit honestly, separating what can be monetised from what cannot rather than overstating the effect, is what ultimately supports the persuasiveness of the next investment case.

Internal requirements are often still unsettled at the stage where you are putting together approval materials. TOMAS TECH works with Japanese manufacturers operating in Thailand from that early stage, helping think through which item to fill in first to make an approval request land with decision makers, and which approval route your investment scale is likely to fall under. You are welcome to reach out while you are still comparing options and before any vendor has been chosen, through our contact page.

References

• i Magazine – JUAS “Enterprise IT Trend Survey 2026” preliminary results
• BTN Consulting – How to write an IT investment approval request
• Syusodo – Building an annual IT budget plan
• OBC360 – How to write a system implementation approval request that gets approved
• note (Shun Ichikawa) – Ten tips for getting an IT approval request through
• Thailand Law Office – Tax Newsletter March 2026 (Royal Decree No. 802)
• Mahanakorn Partners – Thailand Approves New Tax Incentive to Accelerate SME Digital Transformation