Three founders walk into the same HTP intake meeting. One runs a B2B SaaS company selling subscriptions to European enterprises. One runs a custom development shop shipping code to a handful of US clients. One runs a marketplace connecting freelance designers with small businesses across the EU. On paper, all three want the same thing — resident status, the 0% profit tax on qualifying activities, the reduced payroll load, the VAT exemption on exports. In practice, they’re walking into three very different conversations with the Supervisory Board.
The Belarus High-Tech Park regime is broad, but it isn’t agnostic. How your revenue is generated, who your customer is, and what part of the value chain you own decide how cleanly you fit — and how much translation work you’ll do to make your business project pass review. Here’s how the three most common B2B tech models line up against HTP in 2026.
Almost every difficult question about HTP residency comes back to a single point: whether the revenue in question qualifies as an eligible activity under Decree No. 8. If that analysis is correct, the rest of the regime falls into place cleanly — the 1% turnover tax on qualifying revenue, the VAT exemption on exports, the payroll base pegged to the national average wage. If it is not, the resident either loses the preferential treatment on that stream, or, on a less favourable Secretariat review, sees the residency itself put in question.
For pure software companies, this is usually straightforward. For anything that mixes software with services, payments, media buying, or platform commissions, it isn’t. The High Tech Park framework in Belarus covers a defined list of technology activities, and revenue that sits outside that list is taxed as if you were an ordinary Belarusian entity. Founders who assume the whole company gets HTP treatment because most of it does tend to find out the hard way that tax authorities don’t average anything — they classify line by line.
Which brings us to the three archetypes.
SaaS is the model the current HTP regime was refined for. You develop software. You license it to customers. Customers pay subscription fees for access. The core activity — designing, developing, and maintaining software products — sits squarely inside the permitted list. The revenue is either licensing income or IT services, and both qualify.
The contractual layer is where the position becomes more nuanced. HTP tax treatment turns on the substance of the supply, not on the label used in the sales materials. A subscription that genuinely licenses access to the software is licensing income. A subscription that in reality bundles consulting, custom configuration, resold hosting and platform access is something else, and each element may need to be classified in its own right. Enterprise SaaS deals often carry precisely that mix — a base subscription, an implementation project, ongoing customisation and a support retainer. All of it can sit within HTP, but the master agreement and the invoicing architecture have to make the classification impossible to mistake.
A few practical points that come up repeatedly with SaaS residents:
For a well-structured SaaS company selling to non-Belarusian customers, the effective tax picture is genuinely low: 0% profit tax on qualifying revenue, 0% VAT on exports, and payroll social contributions calculated on the national average wage rather than actual salaries. That last point is where senior engineering-heavy teams see the biggest saving, since social contributions for HTP residents are decoupled from real compensation.
Custom development remains the historical backbone of the HTP. Where a resident is building software for foreign customers — whether through dedicated teams, fixed-scope engagements or staff augmentation — the classification question is, in practice, straightforward. The real work lies in contract discipline. Outsourcing sits at the point where Belarusian tax rules, foreign client expectations and the currency control regime meet, and each of them makes demands on the paper.
A few things typically decide whether an outsourcing shop’s HTP status stays quiet or generates friction:
Contract structure. Time-and-materials, fixed-price, and dedicated-team contracts have different revenue recognition profiles. HTP accommodates all of them, but the business project needs to describe how you actually operate. Residents who wrote “software development” three years ago and now run a 60/40 mix of dedicated teams and staff augmentation should look at the HTP renewal playbook and file an addendum.
Currency control. Foreign customer payments in USD, EUR, or GBP are standard, and the export VAT treatment is clean. What causes headaches is when clients try to pay through non-standard channels — crypto, netting arrangements, or third-country routing. The bank’s compliance team will ask questions, and the answers need to be defensible under both HTP rules and the currency control regime.
IP allocation. For outsourcing shops, assignment of IP to the customer is standard. The commercial answer is easy; the paperwork is where founders come unstuck. Assignment language belongs in the MSA and in every SOW, not just one or the other. If it is left half-drafted, the exposure surfaces down the line — a customer arguing for royalty treatment, or a tax inspector in Minsk taking a different view of what the money was actually for.
Outsourcing residents also tend to have the most volatile headcount, which puts pressure on both HR administration and reporting rhythm. The accounting workflow for HTP residents is different from ordinary Belarusian accounting — the 1% quarterly deduction, the FSZN base tied to the national average wage, audit-ready revenue classification — and lean back-office setups usually consolidate this at year two or three.
Marketplaces generate the most conversations with the Supervisory Board and the most surprises after residency is granted. The core problem: a marketplace typically has three revenue streams — platform fees, payment processing margin, and sometimes advertising — and only one of them is unambiguously an IT activity.
If you built the platform, you developed software. Platform access fees charged to sellers or buyers usually count as IT services. So far, so clean.
Payment processing is where it breaks. Taking a cut of a transaction between two third parties, even in a payment facilitator role, is a financial services activity. It isn’t on the permitted list. Residents who tried to run marketplace payment flows through a Belarusian entity have generally either restructured the payment layer upstream, taken the non-HTP tax hit, or ended up in a Supervisory Board conversation they didn’t want.
Advertising revenue is a similar problem. Selling ad inventory on your platform is media, not software, unless what you’re really selling is programmatic infrastructure. The distinction turns on what the customer is paying for — your ad tech, or your audience — and it has to be visible in the contracts, the invoicing, and the business project.
There’s a workable path for marketplaces, but it usually looks like this: the Belarusian HTP resident develops and licenses the platform to a group entity. The group entity operates the marketplace, contracts with users, and processes payments. The HTP resident earns licensing fees or development services income from the group. All of that revenue is unambiguously an eligible activity, and the marketplace’s messier commercial reality lives outside HTP. This kind of split shows up repeatedly across the Belarus HTP track record, where the software layer stayed local and the transaction layer sat elsewhere.
This is a structural decision, not a paperwork one. It affects how the group is organized, where customer relationships sit, and how VAT and profit are allocated across jurisdictions. For marketplaces at the pre-HTP planning stage, the time to decide is before accreditation, not after. Rewriting a business project halfway through year one is possible. Rewriting the group structure is much harder.
The three models don’t share a single decision framework, but the same questions apply to each:
The Belarusian Ministry of Economy publishes the current HTP framework, and it’s worth cross-checking assumptions against the current wording. The eligible activity list has been refined more than once since 2017, and what applied to a resident five years ago isn’t always what applies today.
Getting the accreditation application right the first time saves a lot of downstream repair work. A properly-scoped business project for HTP status is where the trade-offs get resolved on paper — the document isn’t a formality, it’s the reference the Secretariat uses for every subsequent review, and its language decides how flexibly you can adapt later without re-approval.
No. Payment processing, e-money issuance, and financial intermediation are not on the permitted list. Fintech companies typically license their software through the HTP resident and run the regulated financial activity through a separate entity in a suitable jurisdiction.
The Supervisory Board expects the business project to reflect actual activity. Adding a materially new activity — even one that could qualify — requires an addendum for approval before you start recognizing the revenue. Running unapproved activities through a resident is one of the more common causes of avoidable friction.
Both qualify for the profit tax exemption if the underlying activity is on the permitted list. The distinction matters more for VAT — place-of-supply rules apply differently to licensing versus services — and for how the business project describes the revenue stream. Classification must be consistent across contracts, invoicing, and reporting.
No. HTP residency is a virtual regime — what’s required is a registered Belarusian legal entity conducting eligible activities, not a physical presence in a specific location. Many residents operate with a virtual office arrangement and remote teams.
They treat the business project as a marketing piece. It isn’t one. The Secretariat doesn’t care how exciting your opportunity looks — they want to see which permitted activity code each stream of revenue falls under. If you frame your product in the regime’s language from day one, you’ll cut down the number of revisions dramatically.
HTP is not a single door. It’s three doors with different friction depending on how the business generates revenue. B2B SaaS walks through with clean contracts and disciplined activity classification. Custom development walks through on its own — this is the model the regime was built around — but needs contract and IP discipline to stay clean under review. Marketplaces walk through only after honest structural work, usually splitting the platform layer from the transaction layer at the group level.
Whichever door fits, the ongoing operational load — quarterly HTP fund deductions, annual audit, business project reporting, foreign employee cycles — is the same. Mature residents tend to consolidate this under a single management partner for HTP residents rather than run it in-house, because review-and-approval loops stop being the bottleneck when one team owns the reporting rhythm.
Get the activity profile right at accreditation and the rest is rhythm. Get it wrong and every review turns into a negotiation.
Choosing the optimal tax jurisdiction as an IT professional is not only about today’s tax burden but also about long-term financial strategy. Many Belarusian IT entrepreneurs consider registering as a sole proprietor (SP) in Poland as a potentially more stable and predictable option. However, in practice, comparing taxes in Belarus and Poland is far more […]
The move from “we hired someone in Belarus” to “we can close our monthly books cleanly with Belarus data in them” is where most foreign HQs quietly lose weeks each quarter. The problem is rarely the payroll itself. Belarusian payroll is procedural: fixed statutory contributions, a mature reporting calendar, tight deadlines, and a Labour Code […]
The decision to sell a Belarusian High-Tech Park subsidiary rarely starts in Minsk. It starts in a boardroom in London, San Francisco, or Dubai — a strategic pivot, a group restructuring, or a buyer looking for an engineering team that happens to come with a preferential tax structure attached. From there, the deal has to […]
