Run enough feasibility models, and you'll notice a pattern: the assumptions that get the most scrutiny are the ones everyone already understands. Construction cost per square meter. Sales absorption. Exit yield. Meanwhile, VAT and transaction taxes sit quietly in a corner of the model, often modeled as a rounding exercise rather than a real cost driver.
That's a mistake we see repeated across markets, and it tends to surface at the worst possible time after land has been acquired and the capital stack is already committed.
Why VAT Gets Modeled Incorrectly
VAT treatment in real estate isn't uniform. Whether it's recoverable, irrecoverable, or partially blocked depends on the asset class, the jurisdiction, and sometimes the specific use of the space within a single building.
A residential-for-sale component might sit outside the VAT net in one market, while the retail podium beneath it is fully taxable. Mixed-use schemes are where this gets genuinely difficult, because a single feasibility model often needs to split VAT treatment by floor, by unit type, or by tenant category and analysts don't always build that granularity in from the start.
The common shortcut is applying a single blended VAT assumption across the whole scheme. It's faster to model, but it tends to understate the cost on the taxable components and overstate it on the exempt ones, which distorts the return profile of each asset class rather than just the project as a whole.
Transaction Taxes Are a Cash Flow Issue, Not Just a Cost Line
Transfer taxes, registration fees, and stamp duty get treated as a one-time deduction in a lot of models. In practice, they behave more like a cash flow event than a static cost they hit at specific points (land acquisition, unit transfer, refinancing) and the timing matters as much as the amount.
In a phased development, transaction taxes can recur at each disposal event rather than once at project completion. If a model only captures the tax at financial close and ignores subsequent triggers, the feasibility output looks stronger than the actual project economics will support.
Cross-border structures add another layer. When capital flows through holding entities, SPVs, or joint venture structures, transaction taxes can apply at more than one point in the ownership chain. We've seen models that account for the tax on the underlying asset transfer but miss the tax triggered by a change in beneficial ownership at the holding company level.
Where This Shows Up in Practice
Development Directors reviewing feasibility outputs often catch this late, usually during due diligence, when a tax advisor flags an assumption that doesn't match the structure being proposed. At that point, the model needs rework, and depending on how tight the timeline is, that can mean renegotiating terms that were already agreed.
Feasibility Analysts building the model from the ground up have more room to get ahead of it: pulling in tax input at the assumptions stage rather than the sensitivity stage, and treating VAT recoverability as a variable that changes by asset class rather than a constant.
Tools like EstateMaster and Aprao allow VAT and transaction tax inputs to be broken out by cost category, which helps, but the structuring logic still has to come from the analyst. Platforms like FeasibilityPro.AI are built around letting that logic sit alongside the underlying Excel workflow, so the tax treatment doesn't get lost when assumptions change mid-model.
What This Means for Feasibility Work Going Forward
The projects that get this right tend to involve tax advisory input earlier, often before the model's first draft rather than after. It's a small shift in process, but it changes how much rework happens later.
If you're building or reviewing feasibility models regularly: how granular does your VAT treatment go by asset class, and at what stage does tax input typically enter your process? Curious how this is handled across different markets.
Top comments (0)