Інтеграція електронних рахунків-фактур у Туреччині з ERP-системами

Для роботи в Туреччині ERP зазвичай має підтримувати e-Fatura та e-Arşiv, а в окремих галузях — і e-İrsaliye, через Податкову адміністрацію (GİB), зазвичай за допомогою приватного інтегратора. ERP формує документ у форматі UBL-TR, продавець підписує його фінансовою печаткою (mali mühür), інтегратор проводить його через GİB, а платник податків упродовж усього періоду зберігання залишається відповідальним за документ.

Що має підтримувати ERP для роботи в Туреччині?

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

Створення документа. ERP або підключений до неї модуль має формувати рахунки у встановленій структурі UBL-TR із кодами, ідентифікаторами сторін і даними на рівні позицій, яких вимагає схема, а не перетворювати на XML друкований макет.

Цифровий підпис. Документи підписують фінансовою печаткою, виданою платнику податків; підписання має бути частиною процесу, а робота з ключем — відповідати правилам його зберігання.

Двосторонній обмін. У режимі e-Fatura тип документа визначається статусом реєстрації контрагента, а вхідні документи — отримані рахунки, відповіді та дозволені скасування — мають повертатися в ERP зі своїми первинними ідентифікаторами. Інакше бухгалтерський облік втратить зв'язок між системою та офіційним записом.

Архівування та пошук. Видані й отримані документи мають бути доступними протягом установленого законом строку зберігання. Чи зберігатиме їх інтегратор, ERP або обидві системи — це слід вирішити до запуску, а не після запиту під час аудиту.

Більшість компаній виконує ці вимоги не перебудовуючи ERP, а підключаючи її: між ERP і приватним інтегратором додають інтеграційний рівень, залишаючи ERP основною системою обліку клієнтів, товарів, цін і бухгалтерських даних.

Одна структурна особливість часто дивує команди, які вперше стикаються з клірингом: робота над рахунком не завершується, коли ERP його формує. Вона завершується після обміну та отримання відповідей. Отже, статус рахунку в ERP має охоплювати не лише «створений» і «надісланий», а й «прийнятий», «відхилений» і «виправлений». Компанії, які цього не враховують, наприкінці місяця вручну звіряють дві версії даних — власний бухгалтерський реєстр та офіційний запис, — тобто виконують саме ту роботу, якої електронне виставлення рахунків мало позбавити.

Важливий і час обробки. У системі клірингу документи не обробляються асинхронно, як вкладення електронної пошти: відхилення надходить, поки команда ще працює, а виправлення зазвичай стосується основних даних, а не самого документа. Якщо повідомити про причину відхилення одразу людину, яка може її усунути, а не чекати на щомісячний звіт, система працюватиме без постійного нагляду.

Пояснення e-Fatura, e-Arşiv та e-İrsaliye

Документ	Для чого використовується	Типова умова	Примітка
e-Fatura	Рахунки B2B та для взаємодії бізнесу з державою між платниками податків, зареєстрованими в системі	Обидві сторони зареєстровані для e-Fatura	Структурований документ, яким обмінюються зареєстровані сторони; маршрут визначається статусом контрагента
e-Arşiv	Рахунки покупцям, не зареєстрованим для e-Fatura: роздрібним клієнтам і B2C, а також деяким B2B-контрагентам	Продавець підпадає під вимоги, а покупець не належить до режиму e-Fatura	Для покупця формується PDF, але документ створюється та декларується через той самий ланцюжок
e-İrsaliye	Електронні накладні на доставку для галузей і операцій, визначених правилами	Відвантаження товарів у межах відповідних операцій	Пов'язана з рахунком: накладна на доставку та рахунок посилаються одне на одного
e-Defter	Бухгалтерські книги та записи — головна книга і журнал, що подаються в електронному вигляді	Платники податків, на яких поширюються відповідні правила	Окремий від електронного виставлення рахунків обов'язок, який зазвичай планують у межах того самого проєкту

Коло осіб, на яких поширюється кожен обов'язок, визначається правилами та комюніке GİB, які змінюються; порогові значення й перелік галузей установлюють і переглядають органи влади. Для покупця правильна рекомендація має процедурний характер: перед проєктуванням інтеграції перевірте актуальні правила разом із бухгалтером або податковим консультантом, а не покладайтеся на статтю — зокрема й цю.

Варіанти інтеграції

Варіант	Кому підходить	Обсяг робіт в ERP	На що зважати
Портал GİB	Дуже малі обсяги, ручне виставлення	В ERP змін не потрібно	Ручний і повільний спосіб, не призначений для компанії з ERP; залиште його лише як резервний варіант
Приватний інтегратор (özel entegratör)	Найпоширеніший шлях для більшості компаній	Підключення до API або формату інтегратора та зіставлення даних	Якість підтримки й API важливіша за бренд; з'ясуйте, хто супроводжує оновлення схеми
Прямий доступ до GİB	Великі компанії, яким потрібен повний контроль	Значний: технічну й операційну відповідальність за канал бере на себе компанія	Отримати й підтримувати складніше; на практиці такий варіант трапляється рідко — його слід обґрунтовувати як виняток, а не вважати типовим

Модель із інтегратором потребує одного уточнення, оскільки її часто розуміють неправильно: залучення приватного інтегратора не передає йому обов'язки платника податків. Інтегратор надає технічний канал, послуги передавання та зберігання; юридична відповідальність за документи — їхню правильність, видачу та зберігання відповідно до Закону про податкові процедури — залишається на платнику податків. Якщо на сторінці інтегратора сказано, що він повністю вирішить за вас питання дотримання вимог, перечитайте це твердження уважно.

На практиці цей розподіл відповідальності проявляється в конкретних ситуаціях. Якщо документ відхилено через неправильний податковий ідентифікатор клієнта в основних даних, система інтегратора спрацювала належно, а помилку має виправити ваша компанія. Якщо в рахунку вказано неправильний податковий код, канал передавання цього не виправить. Інтегратор — це інфраструктура; якість даних, що проходять через неї, залежить від внутрішніх процесів, а ERP або закріплює ці процеси в системі, або залишає їх на розсуд працівників. Тому під час порівняння інтеграторів варто менше часу приділяти переліку функцій і більше — запитанням про дії під час збою: хто кого сповіщає, у якому форматі та як швидко можна повторно передати виправлений документ.

Етапи впровадження та тестування

Практична послідовність інтеграції на боці ERP:

Визначте обсяг зобов'язань. Які документи потрібні компанії — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter; це слід підтвердити з бухгалтером компанії відповідно до актуальних правил.

Оберіть канал. Більшість компаній обирає приватного інтегратора. Варто окремо скласти список кандидатів і порівняти якість API, наявність тестового середовища, мову та графік підтримки, роботу з оновленнями схем і рекомендації клієнтів.

Зіставте основні дані. Дані клієнтів та їхні податкові ідентифікатори, товари, одиниці виміру, валюти й податкові коди мають відповідати вимогам схеми; невідповідності тут є найбільшим окремим джерелом подальших помилок.

Спроєктуйте потік документів. Визначте, хто і що створює, коли накладається печатка, що відбувається в разі збою, як вихідні й вхідні документи зіставляються із записами ERP та як оформлюються виправлення.

Скористайтеся тестовим середовищем. Обидві сторони надають тестове середовище. До запуску перевірте в ньому всі типи документів, усі сценарії помилок і виправлень, використовуючи те саме зіставлення даних, що й у виробничому середовищі.

Організуйте роботу з помилками. Відхилення надходять після передавання; хтось має їх побачити, визначити причину й виправити основні дані. Поштова скринька сповіщень без відповідального — шлях до несвоєчасної видачі документів.

Сплануйте архівування та доступ. Визначте, де зберігатимуться документи, хто зможе їх отримати та як відповідати на запит аудитора в межах строку зберігання.

Успіх визначає не інтерфейс, а етапи 3, 6 і 7 — якість даних, відповідальність за помилки та доступ до документів, — адже вони залишаються важливими й після завершення роботи проєктної команди.

Питання для консультанта щодо іноземної материнської компанії та нерезидентів

Якщо компанія має іноземну материнську структуру або виходить на ринок Туреччини без повноцінної місцевої фінансової команди, кілька питань слід адресувати податковому консультанту, а не ІТ-проєкту. Відповіді впливають на дизайн системи, тому їх треба отримати до початку інтеграції, а не після:

Процедура реєстрації. Як компанія стає суб'єктом відповідних зобов'язань, хто підписує заяви та якого представника визнають; це питання податкової реєстрації, а не програмного забезпечення.

Порядок використання печатки. Як компанія отримує фінансову печатку та як організовується її зберігання, якщо підписанти перебувають за межами Туреччини.

Представники й підписи. Хто уповноважений підписувати ті чи інші документи та які відомості про підписанта ERP має фіксувати для аудиторського сліду.

Статус іноземної дочірньої компанії. Чи застосовуються додаткові вимоги до компаній з іноземними власниками та як обліковуються рахунки всередині групи.

Ці питання навмисно сформульовані для консультанта: правила реєстрації та представництва змінюються й залежать від місцевих умов, а сторінка продукту не може дати їм належну оцінку. ІТ-проєкт може передбачити, що відповіді надходитимуть не одразу: налаштуйте потік документів так, щоб його можна було конфігурувати, а не жорстко прив'язувати до одного припущення.

Також варто визначити, хто відповідає за взаємодію з консультантом. У компаніях, де фінансовий та ІТ-відділи вважають, що запитання поставив інший, ці питання доходять до команди інтеграції із запізненням — зазвичай за кілька тижнів до запуску, коли потік документів уже налаштований. Визначення відповідального з кожного боку та спільна зустріч до етапу 3 впровадження допоможуть уникнути більшості таких ситуацій.

Поширені проблеми

Найтиповіші збої в таких проєктах і на що зазвичай вказує кожен із них:

Відхилення під час перевірки. Майже завжди це проблема зіставлення: податковий код, формат ідентифікатора або поле на рівні позиції не відповідає вимогам схеми. Виправте основні дані, а не логіку повторного надсилання.

Дублювання нумерації. Послідовність номерів формують кілька систем або генерують повторно після збою. Нумерація має мати єдиного відповідального та задокументоване правило відновлення.

Помилкове визначення статусу контрагента. Видача неправильного типу документа через кешований або припущений статус реєстрації клієнта. Перевіряйте статус згідно з правилами інтегратора, а не покладайтеся на пам'ять.

Втрата вхідних документів. Отримані документи не повертаються в ERP, і відділ кредиторської заборгованості працює в окремому інтерфейсі. Вхідний напрямок обміну — частина інтеграції, а не необов'язкове доповнення.

Пропущені оновлення схеми. Структура з часом змінюється; відповідальні мають знати, коли саме це сталося і як зміна вплинула на зіставлення даних.

Пропуск тестування через брак часу. Усі наведені проблеми дешевше усунути в тестовому середовищі; під тиском перед запуском вони перетворюються на інциденти.

Часті запитання

У чому різниця між e-Fatura та e-Arşiv?

e-Fatura охоплює рахунки, якими обмінюються зареєстровані в цьому режимі платники податків у вигляді структурованих документів; e-Arşiv — рахунки покупцям поза цим режимом, зокрема роздрібним клієнтам і B2C, а також деяким B2B-контрагентам. Покупець зазвичай отримує їх у форматі PDF, сформованому через той самий офіційний ланцюжок. Тип документа для конкретного рахунку визначається статусом реєстрації контрагента, тому інтеграція перевіряє цей статус, а не робить припущень.

Чи потрібен мені приватний інтегратор?

Для більшості компаній — так: це найпоширеніший шлях, тоді як прямий канал вважається складним і рідкісним. Приватний інтегратор надає технічний канал до GİB і послугу зберігання, але ваші зобов'язання як платника податків залишаються вашими. Вибір інтегратора — це закупівельний процес: на щоденну роботу більше впливають якість API, тестове середовище, підтримка й робота з оновленнями схем, ніж бренд.

Що таке фінансова печатка (mali mühür)?

Це цифровий засіб підпису платника податків, яким підписують електронні документи перед передаванням; у компанії потрібно практично вирішити, як він зберігатиметься та хто зможе ним користуватися. Якщо підписанти працюють за межами Туреччини, порядок зберігання й застосування печатки слід одним із перших обговорити з податковим консультантом.

Чи може будь-яка ERP видавати турецькі електронні рахунки?

Ні. ERP має формувати потрібну структуру UBL-TR із правильними основними даними або бути підключеною до модуля чи інтегратора, який це забезпечує; стандартного макета рахунку недостатньо. Тому більшість компаній підключає рішення, а не перебудовує систему. Запитайте постачальника, з якими інтеграторами сумісний його конектор, які дані він зіставляє та де можна знайти документацію.

Як провести тестування до запуску?

Використовуйте тестові середовища інтегратора й офіційної сторони та те саме зіставлення основних даних, що й у виробничому середовищі: перевірте кожен тип документа, кожен сценарій відхилення й виправлення, а також повернення кожного вхідного документа в ERP. Тестування має відтворювати й процес роботи з помилками: хтось повинен отримати відхилення, встановити його причину та усунути її, а не просто побачити зелену позначку.

Хто зберігає рахунки?

Відповідальність за зберігання згідно із Законом про податкові процедури залишається на платнику податків; інтегратор зазвичай надає технічне сховище, а багато компаній також зберігають документи в ERP для щоденної роботи. Важливо до запуску визначити порядок зберігання, знати, хто зможе надати кожен документ упродовж установленого строку, і перевірити пошук до того, як його запросить аудитор.

Джерела та стандарти

GİB — Gelir İdaresi Başkanlığı — Податкова адміністрація публікує правила, комюніке та технічну документацію для e-Fatura, e-Arşiv, e-İrsaliye й e-Defter; актуальні версії на її сайті мають перевагу над усім, що підсумовано на цій сторінці.
Статус реєстрації, порогові значення, перелік галузей і строки встановлюють органи влади, і вони змінюються; перевіряйте актуальні правила разом із бухгалтером або податковим консультантом. Ця сторінка не є податковою консультацією; WorldwideTradeX не заявляє про жодні відносини з інтеграторами, партнерства чи сертифікації.

Пов'язані сторінки

Розробка програмного забезпечення · ERP Odoo для торговельних компаній · Індивідуальна чи готова ERP · ІТ-аудит і консалтинг · Запросити цінову пропозицію