E-Invoice в Турции: интеграция с 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; держите его только как запасной вариант
Частный интегратор (ö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 выпускать турецкие e-invoice?

Нет. ERP должна генерировать требуемую структуру UBL-TR с корректными мастер-данными или быть подключена к движку или интегратору, который это делает; стандартного макета счета недостаточно. Поэтому большинство бизнесов подключаются, а не перестраивают, — вопрос, который стоит задать вендору: какие интеграторы поддерживает их коннектор, что он маппит и где находится его документация.

Как тестировать до запуска?

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

Кто хранит счета?

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

Источники и стандарты

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

Связанные страницы

Разработка ПО · Odoo ERP для торговых компаний · Кастомный против коробочного ERP · ИТ-аудит и консалтинг · Запросить КП