e-Tax Invoice и e-Receipt в Таиланде для малого бизнеса

Обычный счёт, налоговая накладная и e-Tax Invoice могут выглядеть почти одинаково на экране, но для Revenue Department это разные вещи. Коммерческий счёт сообщает покупателю, сколько и за что заплатить. Налоговая накладная (Tax Invoice) — документ по НДС с обязательными реквизитами. А официальный e-Tax Invoice появляется только тогда, когда налоговый документ создан, удостоверен, передан и сохранён по одному из предусмотренных электронных маршрутов.

Поэтому красивый PDF с логотипом, налоговым номером и суммой НДС ещё ничего не доказывает. В основном режиме e-Tax Invoice & e-Receipt документ для клиента может быть PDF, XML, PDF/A-3 или другим электронным форматом, если он доступен для последующего использования и его смысл не меняется. Но за этим файлом должен стоять электронный сертификат и цифровая подпись, а данные для Revenue Department формируются в установленном XML-формате и передаются по официальному каналу. Именно процесс, а не расширение файла, делает документ частью системы.

e-Receipt — тоже отдельный электронный налоговый документ, а не другое название e-Tax Invoice. Основной режим Revenue Department охватывает электронные налоговые накладные, дебетовые и кредитовые ноты и электронные квитанции. Time Stamp устроен иначе: это отдельный официальный путь для налоговых накладных, где подлинность и момент существования файла подтверждаются отметкой времени через предусмотренную систему.

Полезный антипример выглядит просто: бухгалтер отправил клиенту PDF с НДС и сохранил копию в папке. Такой файл может быть рабочим документом, а бумажная налоговая накладная может оставаться действительной по обычным правилам НДС, но сам факт отправки PDF по почте не означает, что компания выпустила e-Tax Invoice. Для этого должен прослеживаться весь официальный маршрут — от права использовать выбранную систему до удостоверения документа и передачи данных.

У Revenue Department есть два разных официальных маршрута, и выбирать между ними лучше до покупки программы или интеграции. Основной e-Tax Invoice & e-Receipt рассчитан на системный электронный выпуск: компания получает право работать в системе, использует электронный сертификат и цифровую подпись, а данные для налоговой передаёт в XML через загрузку файла, прямое соединение Host to Host или уполномоченного Service Provider. Этот путь логичен, когда выпуск документов уже встроен в учёт и бизнес хочет связать создание документа, отправку и статус в одном процессе.

Time Stamp — не «тот же e-Tax, только попроще». У него собственная заявка, собственный список допущенных участников и отдельная схема работы через зарегистрированный адрес электронной почты. В действующем руководстве Revenue Department этот маршрут описан как подходящий прежде всего для зарегистрированных плательщиков НДС с доходом или выручкой не более 30 млн бат в год и сравнительно небольшим объёмом документов. Это критерий, который стоит перепроверять перед подачей: технические стандарты и условия системы могут обновляться.

Представим небольшую компанию, которая выпускает 50–200 налоговых документов в месяц, а бухгалтер уже работает в привычной программе. Ошибка — сразу покупать «e-Tax-модуль», не выяснив, что именно умеет текущая система. Возможно, она уже формирует нужные данные и остаётся только настроить удостоверение и отправку. А возможно, она создаёт лишь PDF для клиента и вообще не хранит связку «документ → отправка → статус», тогда сначала придётся привести в порядок сам учётный процесс.

Обычный PDF или бумажная налоговая накладная — не третий вариант e-Tax. Бизнес может продолжать работать с обычными налоговыми документами, если это соответствует его обязанностям, но не должен называть такой процесс e-Tax только потому, что файл отправляется электронно. Выбор между официальными маршрутами определяется не рекламой сервиса, а объёмом документов, устройством учёта, готовностью к интеграции и тем, кто реально будет отвечать за ошибки и подтверждение отправки.

Регистрация не исправляет грязные исходные данные. Если в учётной системе один и тот же покупатель записан с разными налоговыми номерами, филиал иногда указан как головной офис, а номера документов правят вручную после выдачи, e-Tax лишь быстрее вынесет эти расхождения наружу. До подключения нужно понять, какие документы компания действительно выпускает: полные налоговые накладные, дебетовые и кредитовые ноты, квитанции — и какие из них войдут в выбранный электронный маршрут.

Особое внимание требуется реквизитам продавца и покупателей. Налоговый номер, статус головного офиса или филиала, адрес, номер документа и дата должны формироваться из одного надёжного источника, а не перепечатываться сотрудником в нескольких программах. Для Time Stamp важен ещё и зарегистрированный адрес электронной почты; для основного e-Tax — способность системы подготовить требуемые данные и сохранить связь между исходным документом, электронной подписью и последующей отправкой.

Не менее важен владелец процесса. Бухгалтер может формировать документ, директор — контролировать сертификат, а внешний Service Provider — подписывать или передавать данные. Такая схема рабочая, пока у компании есть понятный ответ на два вопроса: кто видит, что документ не прошёл, и кто имеет право исправить причину. Если эти роли размыты, ошибка легко превращается либо в пропущенную отправку, либо в повторную отправку того же документа.

Перед массовым запуском полезнее провести один короткий пилот, чем неделю обсуждать схему на словах. Один тип документа, один реальный набор реквизитов, выдача клиенту, подтверждение удостоверения, проверка статуса в Revenue Department и сверка записи в бухгалтерии показывают слабые места намного быстрее. После такого прогона уже понятно, что нужно менять: справочник клиентов, права доступа, настройку программы или договорённость с провайдером.

Для основного e-Tax Invoice & e-Receipt компания начинает не с отправки первого счёта, а с права работать в системе. Revenue Department требует заявление บ.อ.01. В действующей схеме регистрации используется электронный сертификат и цифровая подпись; официальный портал также описывает работу через программу Ultimate Sign & Viewer, после чего подтверждается регистрация по электронной почте и создаётся основная учётная запись компании. Если есть филиалы, права пользователей уже распределяются внутри этой учётной записи.

Дальше нужно решить, кто технически выпускает документ. Компания может делать это сама: формировать электронный документ, подписывать своим сертификатом и отдельно передавать XML в Revenue Department. Другой вариант — делегировать часть процесса одобренному Service Provider. Официальная схема допускает, что провайдер формирует и удостоверяет документ своим сертификатом, а также передаёт данные, но для владельца бизнеса принципиально понимать, какие функции переданы наружу и где остаётся контроль самой компании.

Time Stamp запускается отдельно. Заявление подаётся по форме ก.อ.01, после одобрения компания регистрирует адрес электронной почты, который будет использоваться для выпуска документов. В текущем процессе файл налоговой накладной направляется покупателю и одновременно в систему Time Stamp; после обработки обе стороны получают версию с отметкой времени. Поэтому замена корпоративной почты, ошибочный адрес или изменение схемы отправки — не бытовая мелочь, а часть налогового процесса.

Первый запуск лучше ограничить одним типом документа. Например, выпустить одну полную налоговую накладную из рабочей учётной системы, проследить, что покупатель получил правильную версию, затем проверить удостоверение и результат передачи. Если работает внешний провайдер, полезно параллельно посмотреть, какие статусы доступны владельцу и что именно он увидит при ошибке.

У Revenue Department есть разные процедуры и технические стандарты для двух маршрутов, поэтому срок «подключим за день» без привязки к конкретной компании мало что значит. На скорость влияют готовность сертификата, корректность регистрационных данных, настройка учёта, выбранный канал и работа провайдера. Перед запуском нужно сверить именно текущие требования портала: правила электронных систем меняются, а старые инструкции из бухгалтерского блога могут описывать уже прежнюю версию процесса.

В основном e-Tax Invoice & e-Receipt выдача документа клиенту и передача данных Revenue Department — связанные, но не одинаковые действия. Текущий обзор системы предусматривает три канала для XML: загрузку через портал, прямое соединение Host to Host и передачу через Service Provider. Для небольшой компании Host to Host обычно имеет смысл только тогда, когда уже есть серьёзная системная интеграция; само по себе прямое соединение не делает процесс надёжнее, если никто не контролирует ошибки.

Revenue Department указывает для основного маршрута передачу требуемых данных до 15-го числа следующего месяца. Это как раз тот случай, когда одного факта «клиент получил документ» недостаточно: бухгалтерии нужен подтверждённый статус отправки и понятная очередь ошибок. При работе через провайдера полезно, чтобы компания видела этот статус у себя или получала отчёт, из которого можно восстановить судьбу каждого документа, а не просто общее сообщение «файл отправлен».

Time Stamp устроен иначе: документ проходит через зарегистрированную электронную почту и систему отметки времени. Если вернулся файл с отметкой времени, это часть доказуемой цепочки; если ответ системы не получен, проблему нельзя закрывать исходным PDF из бухгалтерии. Нужно установить, дошло ли письмо, соответствует ли файл и адрес требованиям и был ли документ действительно удостоверен.

Первые недели чаще ломаются не из-за сложной криптографии, а из-за повседневных несостыковок. Филиал указан неверно; два сотрудника используют разные правила нумерации; документ исправили после выдачи, но не оформили корректировку; при повторной отправке появился дубль; покупатель получил файл, а налоговая передача завершилась ошибкой; провайдер отправил пакет, но никто не проверил ответ системы. Эти сбои видны только там, где у компании есть связка «учёт → документ → отправка → статус».

Хранение — ещё одна часть процесса. Revenue Department связывает электронные документы с требованиями налогового, бухгалтерского и электронного законодательства, поэтому недостаточно оставить только визуальную копию для клиента: нужно сохранять электронный документ и доказательства его целостности и происхождения в предусмотренном порядке. Конкретный срок хранения и технические требования следует сверять по действующим правилам на дату внедрения вместе с ответственным бухгалтером или налоговым специалистом.