Загальна карта локалізації: що в стандарті, а що ні.
Обмін первинкою з контрагентами — окремий контур: ЕДО і Business Central.
Чому ПДВ — головне питання при виборі ERP в Україні
Коротка відповідь. Тому що це ділянка, де світова система найбільше відрізняється від звичного українського обліку. Функціонал ПДВ у Business Central побудований на комбінаціях груп, а не на окремому «блоці ПДВ», як звикли користувачі локальних систем.
На практиці це означає: якщо групи налаштовані правильно, ПДВ рахується автоматично в кожному документі й у декларації немає ручних правок. Якщо налаштовані абияк — бухгалтер щомісяця виправляє проводки руками, і жодна автоматизація не рятує. Саме тому налаштування ПДВ ми виносимо в окремий етап проєкту, а не робимо «між іншим».
Як улаштовані ПДВ-групи: логіка комбінацій
Business Central визначає ставку та рахунки обліку не за одним полем, а за перетином двох ознак.
| Що це | Де вказується | Приклад значень |
|---|---|---|
| ПДВ бізнес-група | На контрагенті | Внутрішній ринок, Експорт, Імпорт, Неплатник ПДВ |
| ПДВ товарна група | На номенклатурі чи послузі | 20 %, 7 %, 0 %, Без ПДВ |
| Комбінація груп | У налаштуванні проводок ПДВ | Визначає ставку й рахунки обліку |
Правило, яке економить місяці правок: спершу опишіть усі реальні варіанти операцій, а вже потім заводьте групи. Найпоширеніша помилка — створити групу під кожного контрагента. Груп має бути мало, інакше таблиця комбінацій стає некерованою і в ній з'являються прогалини.
Вхідні податкові накладні: реєстрація та співставлення
Порядок роботи з вхідними ПН відрізняється від звичного в локальних системах: накладна не «прикріплюється» до документа, а співставляється з ним окремою операцією.
| Крок | Що робить бухгалтер | Що фіксує система |
|---|---|---|
| 1. Отримання | Завантажує накладну з ЄРПН | Документ у реєстрі вхідних ПН |
| 2. Пошук | Знаходить рахунок або надходження, до якого належить ПН | Список документів-кандидатів |
| 3. Співставлення | Прив'язує ПН до документа покупки | Право на податковий кредит за періодом |
| 4. Контроль | Перевіряє незіставлені позиції наприкінці періоду | Перелік розбіжностей до закриття |
Головний контрольний момент — четвертий крок. Незіставлені накладні наприкінці періоду означають, що податковий кредит або втрачено, або взято без підстави. Це перевіряється до закриття періоду, а не після подання декларації.
Перша подія: головне, чого немає у світовій версії
Це те місце, де український ПДВ найсильніше розходиться зі стандартною логікою будь-якої міжнародної системи. У світовій версії податкове зобов’язання виникає за документом реалізації. В Україні — за подією, яка сталася раніше: або відвантаження, або оплата.
Стандартний Business Central такого поняття не має взагалі. Воно з’являється разом із локалізацією, і від того, як воно налаштоване, залежить, чи буде бухгалтер щомісяця правити накладні руками.
Три рівні, на яких це задається
| Рівень | Що визначає | Коли використовується |
|---|---|---|
| Глобальні налаштування | Загальне правило для організації, включно з автоматичним створенням ПН за першою подією | Базове значення для всіх |
| ПДВ бізнес-група | Правило для категорії контрагентів. Якщо поле порожнє — визначається автоматично | Коли для експорту чи неплатників правило інше |
| Договір | Перша подія в розрізі конкретного договору | Коли з окремими контрагентами домовленості відрізняються |
Третій рівень — той, який зазвичай і стає причиною вибору локалізованого рішення замість спроби налаштувати стандарт. Компанія, у якої частина договорів працює за передоплатою, а частина за відвантаженням, без цього приречена на ручні коригування.
Питання, яке варто поставити до старту. Скільки у вас реально варіантів першої події й чи прив’язані вони до конкретних договорів. Відповідь «у нас усе однаково» на етапі впровадження часто виявляється неправдою на етапі першої декларації.
Що насправді налаштовується в ПДВ бізнес-групах
Крім самої комбінації груп, у локалізованому рішенні на бізнес-групі задається ще кілька ознак, і кожна прибирає окремий клас ручної роботи.
- Автоматичне створення ПН. Накладна формується системою за настанням першої події, а не набирається бухгалтером. Це основна економія часу в усьому контурі.
- ПН не вимагає застосування. Дозволяє облікувати податкову накладну без попереднього співставлення з обліковим рахунком. Потрібно для операцій, де співставлення не має сенсу.
- Неплатник ПДВ і умовна назва неплатника. Для операцій із контрагентами без реєстрації платником: система підставляє умовне найменування замість реквізитів.
- Реформування ПН. Стосується коригування накладної, яка ще не була опублікована — тобто виправлення до реєстрації, а не розрахунок коригування після неї.
Останній пункт розрізняють не всі, а різниця принципова: до реєстрації документ правиться, після реєстрації — тільки коригується окремим документом.
Обмін із M.E.Doc і ЄРПН
Реєстрація накладних у ЄРПН відбувається не з облікової системи напряму, а через спеціалізований сервіс. Практично це виглядає як обмін XML-файлами в обидва боки.
| Напрямок | Що відбувається |
|---|---|
| Вхідні ПН | XML від постачальника імпортується в систему, з нього створюється документ ПН на покупку з усіма реквізитами |
| Дата реєстрації | У XML самої накладної її немає — заповнюється вручну або підтягується окремим завантаженням із ЄРПН |
| Вихідні ПН | Формуються в системі й експортуються у XML для реєстрації |
| Реєстр із ЄРПН | Завантажується, щоб звірити, що зареєстровано насправді, а не що ви відправили |
Другий рядок — місце, де компанії найчастіше втрачають час. Дата реєстрації визначає період, у якому ви маєте право на кредит, і якщо її заповнюють руками по кожній накладній, автоматизація з’їдається зворотним боком. Завантаження реєстру з ЄРПН цю роботу знімає, і його варто налаштувати одразу, а не «потім».
Співставлення: автоматично й вручну
Вхідна накладна сама по собі нічого не дає — вона має бути пов’язана з рахунком на покупку. Співставлення виконується або автоматично за реквізитами, або вручну, коли автоматика не впоралася.
Типові причини, чому автоматичне співставлення не спрацьовує:
- Суми розходяться на копійки через округлення в постачальника.
- Накладна виписана на аванс, а рахунок — на відвантаження, і навпаки.
- Постачальник розбив одну поставку на кілька накладних або навпаки.
- Контрагент у вашій базі заведений двічі, і документи розійшлися по двох картках.
Останній пункт — не проблема ПДВ, а наслідок брудного довідника, і лікується він до впровадження, а не після. Це та сама чистка, що описана в чек-листі підготовки даних.
Вихідні накладні та експорт до ЄРПН
Вихідні ПН створюються на підставі документів реалізації — це принципово: накладна не існує окремо від господарської операції. Далі вона проходить звичний шлях: формування, перевірка, експорт у форматі для реєстрації, отримання квитанції.
Коригування оформлюються окремим документом, пов'язаним із початковою накладною. Система зберігає весь ланцюг, тому при перевірці видно, який розрахунок коригування до якої накладної належить, — це знімає більшість питань під час аудиту.
Для «Додатка 2» передбачено окремий експорт, який формується з даних системи, а не збирається вручну в Excel.
Закриття періоду з ПДВ і декларація
| Етап закриття | Що перевіряємо |
|---|---|
| Реєстр ПДВ | Усі операції періоду потрапили в реєстр, немає документів без ПДВ-груп |
| Незіставлені ПН | Немає вхідних накладних без прив'язки до документів |
| Рахунки ПДВ | Сальдо рахунків збігається з даними реєстру |
| Закриття періоду | Період закривається для змін, щоб заднім числом ніхто нічого не поправив |
| Декларація | Формується з даних системи, а не набирається руками |
Четвертий пункт відрізняє системний облік від напівручного. Якщо періоди не закриваються, будь-яка правка «за минулий місяць» тихо змінює вже подану звітність — і розбіжність виявляється лише під час перевірки.
Що варто вирішити до старту проєкту
- Перелік типів операцій. Внутрішній ринок, експорт, імпорт, послуги від нерезидента, пільгові операції — усе, що реально буває у вашій діяльності.
- Момент виникнення податкових зобов'язань для кожного типу.
- Хто відповідає за реєстрацію ПН і в які строки, щоб закласти контроль у процес, а не покладатися на пам'ять.
- Як обробляються коригування й хто їх погоджує.
- Глибина історії, яку переносимо: зазвичай достатньо відкритих розрахунків і поточного року.
Український ПДВ-контур налаштовується під час впровадження.
Часті запитання
Чи підтримує Business Central український ПДВ?
Так. Українські вимоги реалізуються через локалізацію: ПДВ бізнес-групи й товарні групи, реєстр вхідних і вихідних податкових накладних, експорт до ЄРПН, коригування, декларація. Базовий механізм ПДВ — стандартний функціонал системи.
Як у системі реєструються вхідні податкові накладні?
Накладна завантажується з ЄРПН у реєстр вхідних ПН, потім співставляється з документом покупки — рахунком або надходженням. Наприкінці періоду перевіряється список незіставлених накладних: саме він показує, чи не втрачено податковий кредит.
Чи можна експортувати податкові накладні для реєстрації?
Так, передбачено експорт вихідних ПН і коригувань, а також окремий експорт «Додатка 2». Дані беруться з облікових документів, а не набираються вручну.
Що робити з помилкою в уже зареєстрованій накладній?
Оформлюється розрахунок коригування, пов'язаний із початковою накладною. Система зберігає ланцюг зв'язків, тому під час перевірки видно, яке коригування до якого документа належить.
Скільки часу займає налаштування ПДВ під час упровадження?
Зазвичай 1–2 тижні разом із тестуванням на реальних операціях. Строк залежить не від кількості документів, а від кількості типів операцій: експорт, імпорт і пільгові операції додають комбінацій.
Чи можна закрити період, щоб ніхто не змінив дані заднім числом?
Так, періоди закриваються для змін. Після подання звітності період закривається, і будь-яка правка потребує окремого дозволу — інакше дані розходяться з поданою декларацією.
Хочете навчитися це налаштовувати?
Ця стаття пояснює логіку й типові помилки. Покрокове налаштування ПДВ-груп, реєстрацію вхідних накладних і роботу з ЄРПН на реальних документах — розбираємо на курсі «IW Торгівля». Заняття проходять онлайн у режимі реального часу, з розбором ваших робочих ситуацій.
Ця стаття входить до добірки Фінанси й облік у Business Central — там зібрано повний розбір теми та решта матеріалів.