If the question came up in a transaction: Russian-origin software in due diligence, and what changes for auditors.
Who is responsible for what on our side: partnership and technologies.
If the group has several entities to bring onto one platform, see multi-entity and intercompany.
How this usually surfaces
Rarely as a decision. Almost always as a discovery, in one of four moments.
During consolidation. The Ukrainian entity submits a spreadsheet each month. Group finance cannot trace a number back to a transaction without emailing one person in Kyiv, and that person is on holiday.
During due diligence. An acquirer's technology review lists the ERP as software of Russian origin. It is rarely a deal breaker, but it becomes a schedule item and a warranty discussion.
During an audit. The auditors cannot open the system. Everything has to be extracted and translated, which turns a routine sample test into a negotiation.
When the accountant resigns. The most expensive version. One person understood the configuration, the workarounds and the undocumented adjustments, and now nobody does.
What it actually costs you
The licence fee is not the issue. The costs are structural and they do not appear on any invoice.
| Cost | How it shows up |
|---|---|
| Key-person dependency | One local accountant is the only route to the subsidiary's numbers. This is a governance exposure, not an IT preference |
| Unverifiable reporting | Group consolidates figures it cannot independently check without going through that person |
| Audit friction | Every request needs extraction and translation; sample testing becomes slow and expensive |
| Provenance exposure | Russian-origin software in the group stack is a recurring question from acquirers, banks and insurers |
| Falling behind on statute | Ukrainian tax rules change; if the configuration is not being updated, compliance quietly degrades |
Most groups tolerate all five for years because none of them causes an incident. They cause a slow loss of control that only becomes visible when something else forces attention — usually a transaction or a resignation.
Four options, honestly assessed
1. Leave it alone
Defensible if the entity is small, stable, being wound down, or up for sale within a year. Migration costs real money and management attention; a subsidiary you plan to divest does not need a new ERP. Just be explicit that this is a decision, not an oversight — the difference matters at audit.
2. Roll out the group ERP
If the group already runs SAP, Oracle or Dynamics, extending it to Ukraine gives maximum consistency. The catch is cost per entity: a full group platform on a twelve-person subsidiary is usually disproportionate, and the statutory localisation still has to come from somewhere.
3. Move to Business Central
The middle path, and the most common outcome for subsidiaries of roughly ten to a hundred users. Microsoft platform, EU data residency, English and Ukrainian on the same database, and a partner localisation that covers VAT and tax invoices. If the group runs Microsoft 365, consolidation and reporting integrate without a separate project.
4. Move to a local Ukrainian product
Cheaper and locally compliant, but it reproduces the original problem in a new form: interface and documentation in Ukrainian only, limited English-language expertise, and the same difficulty for group auditors. It solves provenance without solving governance.
The part global partners get wrong
This is the single most common failure in cross-border projects, so it is worth stating plainly.
Business Central does not include Ukrainian statutory accounting in the base product. VAT treatment, tax invoices and the ЄРПН registry are delivered through a partner localisation. That means a global implementation partner, however capable, cannot deliver this project alone.
The workable arrangement is two partners with a clear boundary: the global partner owns the group template, chart of accounts and consolidation; a Ukrainian partner owns the statutory layer and its ongoing updates. What must be settled in the contract, not discovered in month four:
- Who maintains the localisation when Ukrainian tax law changes, and who pays for it.
- Whether statutory requirements are mapped before the group chart of accounts is locked.
- Who is accountable if a statutory report is wrong — this is rarely written down and always disputed.
Two languages, one database
The objection that stops most of these projects is that the local team does not speak English well enough to work in an English system. It is a fair concern and it has a straightforward answer.
Business Central handles the interface language per user. The Kyiv accountant works entirely in Ukrainian; group finance in London opens the same records in English. Not a translation layer, not a synchronised copy — one database, rendered per user.
What genuinely stays local is documentation and training. The team needs both in Ukrainian, and skipping that is the reliable way to end up with a system nobody uses and a spreadsheet that reappears within a quarter.
The local team is the deciding factor
Technically these projects are not difficult. They fail on people, and the pattern is consistent enough to predict.
The decision comes from head office. To the local accountant it reads as distrust — of them personally, since they built and maintained the current system. They then become passively unhelpful in a way that is very hard to attribute: data arrives late, edge cases surface after go-live, nothing is ever quite refused.
What works is involving them in scoping as the expert they are. They know which processes are genuine local requirements and which are habit — and, importantly, they are usually right about the difference. The ones we have seen go smoothly are the ones where the local accountant was in the room for the first conversation rather than informed after it.
A realistic plan
| Stage | Duration | Who leads |
|---|---|---|
| Assess the 1C configuration and data quality | 1–2 weeks | Local partner |
| Map group template against Ukrainian statutory needs | 1–2 weeks | Both partners jointly |
| Clean master data | 2–4 weeks | Local finance team |
| Configure, including localisation | 3–4 weeks | Local partner |
| Two test migrations with reconciliation | 2–3 weeks | Local partner and finance |
| Training in Ukrainian, on real data | 1 week | Local partner |
| Cutover, ideally at a quarter start | 1 weekend | All |
Eight to sixteen weeks in total for a subsidiary of ten to twenty users. Licences run $80–110 per user per month; the implementation typically lands between $6,000 and $10,000 at that size. Detail in what migrating from 1C costs.
The data cleaning stage is the one to start early, because it does not need a contract, a partner or a budget — only a decision. The preparation checklist covers what to do; the migration overview covers how the rest of the project fits together.
Frequently asked questions
Is 1C actually banned in Ukraine?
Restrictions apply to state bodies and critical infrastructure. Private companies are not universally prohibited from using it, but sanctions removed official support and updates, which is the practical problem: the configuration falls behind changes in tax law and nobody is obliged to fix it.
Can our existing global ERP partner handle this?
Not on their own. Business Central does not include Ukrainian statutory accounting in the base product — VAT, tax invoices and the ЄРПН registry come from a partner localisation. The usual arrangement is your global partner for the group template and a Ukrainian partner for the statutory layer, with the boundary agreed in the contract.
Will the local team have to work in English?
No. Business Central sets interface language per user, so the Ukrainian team works in Ukrainian while group finance reads identical records in English from the same database. Training and documentation should still be delivered in Ukrainian.
How long does it take for a small subsidiary?
Eight to sixteen weeks for ten to twenty users on a finance-first scope. The variable that moves this most is the state of the master data in 1C, not the number of users or the distance between offices.
What if we plan to sell the entity?
Then leaving it alone is often the right call — but document it as a decision. Buyers will raise the Russian-origin software question during diligence, and having a considered answer is worth more than having started a migration you will not finish.
Where does the data physically sit?
Business Central Online runs in Microsoft datacentres; for European groups the tenant is normally provisioned in an EU region. This is usually the answer that satisfies both group IT policy and the provenance question at once.