Кожна нова країна, яку група додає до ERP-системи, приносить власні податкові правила, податкові накладні, банківські формати та регламентовану звітність. Водночас групі потрібні єдиний план рахунків і єдиний набір показників, які можна консолідувати. Успіх або провал впровадження ERP у кількох країнах залежить від того, де проходить межа між цими двома вимогами. Якщо провести її правильно, кожна нова країна стає завданням із налаштування. Якщо неправильно — кожна країна змушує заново відкривати ядро системи. Нижче розглянемо, як Dynamics 365 Finance розділяє глобальний шаблон і локальний рівень, що належить до кожної з цих частин і як партнерський український шар локалізації вписується в цю структуру.

Впровадження ERP у кількох країнах повторює кожне проєктне рішення один раз для кожної країни, тому скорочення, зроблене для першої юридичної особи, доведеться оплачувати повторно кожній наступній. Gartner прогнозує, що до 2027 року понад 70% нещодавно впроваджених ERP-ініціатив не зможуть повністю досягти початково запланованих бізнес-цілей (Gartner, What IT Leaders Must Do to Avoid Disappointing ERP Initiatives, 2024). Однією з причин Gartner називає надмірну кастомізацію сфери застосування під короткострокові потреби, яка перестає відповідати вимогам, щойно змінюються бізнес-цілі. У впровадженні для групи кожен виняток для окремої країни, закладений у ядро системи, стає саме такою кастомізацією.

Solution Blueprint Review від Microsoft — початковий етап фреймворку Success by Design — передбачає визначення стратегії шаблону та моделі впровадження ще до початку основних робіт. Для групи, яка переходить на Microsoft Dynamics 365 Finance, межу між глобальним і локальним потрібно провести, поки дизайн рішення ще існує лише на папері. Перемальовувати її після того, як три країни вже працюють у системі, означає змінювати систему, від якої вже залежать три фінансові команди.

Глобальний шаблон містить структури, з яких зчитують дані всі подальші процеси. У Dynamics 365 Finance план рахунків, фінансові виміри та багато параметрів General ledger використовуються в наступних процесах, тому групи стандартизують їх першими. Коли один і той самий вимір має однакове значення в усіх дочірніх компаніях, для групової звітності не потрібні таблиці зіставлення.

Cross-company data sharing дозволяє групі один раз підтримувати основні, довідкові та налаштувальні дані й поширювати їх між юридичними особами в межах одного розгортання. Master company data sharing, загальнодоступний починаючи з версії 10.0.43, дозволяє дочірнім компаніям працювати з єдиним записом, власником якого є головна компанія. Для глобального шаблону це означає єдиного власника кожного значення, яке в іншому випадку кілька фінансових команд підтримували б окремо.

Групова звітність також є рішенням на рівні шаблону. Dynamics 365 Finance може виконувати консолідацію через окрему юридичну особу консолідації, або Financial reporting може об’єднувати компанії під час формування звіту. Вибір групи визначає спосіб налаштування внутрішньогрупових рахунків та правил елімінації в кожній країні.

Dynamics 365 Finance активує функціональність для конкретної країни або регіону окремо для кожної юридичної особи на основі країни чи регіону, зазначеного в її основній адресі. Саме цей механізм лежить в основі ERP-локалізації в групі: визначення податків, електронне виставлення рахунків, регламентована звітність та банківські формати належать до локального рівня країни й налаштовуються через Globalization Studio, а не програмуються в глобальному шаблоні. Globalization Studio поєднує Electronic Reporting, Tax Calculation та Electronic Invoicing із локалізаційним контентом, який Microsoft контролює, оновлює та дозволяє розширювати партнерам.

Пакет ЄС VAT in the Digital Age, ухвалений у березні 2025 року, запроваджує вимоги до цифрової звітності для транскордонних B2B-транзакцій із 1 липня 2030 року (European Commission, VAT in the Digital Age (ViDA), 2025). Група, яка тримає електронне виставлення рахунків і звітність у конфігурації, оновлює відповідні локальні рівні країн; група, яка запрограмувала їх у ядрі, змушена повторно відкривати глобальний шаблон для кожної країни.

Групі з українською дочірньою компанією потрібен партнерський шар локалізації. OntargIT розробляє цей шар для Dynamics 365 Finance відповідно до Localization and Translation Agreement із Microsoft. Він розміщується у чотирирівневій структурі: базова функціональність Dynamics 365, локалізаційний пакет Microsoft для Східної Європи, пакет OntargIT для України та кастомізація під конкретного клієнта. Український пакет охоплює імпорт валютних курсів НБУ, обмін податковими накладними з M.E.Doc, інтеграцію з клієнт-банками та фінансову звітність відповідно до національних стандартів.

Mayr-Melnhof Karton, один із найбільших у світі виробників картону, веде повний український бухгалтерський і податковий облік та корпоративну міжнародну звітність в одній системі; в іншому проєкті OntargIT впровадила фінансове управління з локалізацією для Ірану. Scatec Solar, норвезька компанія у сфері відновлюваної енергетики, використовує Dynamics 365 Finance та Microsoft Dynamics 365 Supply Chain Management з українською локалізацією, включно з операціями на енергетичному ринку. ERP-локалізація, побудована як окремий шар, змінюється разом із місцевим законодавством, тоді як шаблон змінюється лише тоді, коли так вирішує група.

Пілотна країна перевіряє глобальний шаблон на реальних транзакціях до того, як від нього почнуть залежати інші країни. OntargIT впроваджує локалізацію у чотири етапи — аналіз і прототипування, розробка, впровадження та експлуатація, — причому перший етап включає GAP-аналіз локальних операцій щодо шаблону. Для кожної невідповідності є одна з двох відповідей: налаштування на рівні країни або зміна глобального шаблону, яку приймають усі країни.

Проведіть межу між глобальним шаблоном і локальним рівнем країни до першого go-live — і кожна наступна країна стане окремим проєктом із налаштування. Групи, які вже використовують Dynamics 365 Finance в одній країні, можуть перевірити поточне рішення щодо цієї межі: складіть список усіх змін, специфічних для країни, які внесені в ядро, і запитайте, чи можна було б реалізувати їх через конфігурацію.