Бухгалтерия e-commerce: что ломают заказы от ИИ

11 января 2026 года на кейноуте NRF Google представил Universal Commerce Protocol, разработанный совместно с Shopify и при участии Etsy, Wayfair, Target и Walmart. Он даёт ИИ-агенту единый способ читать каталог продавца и проводить оплату. У OpenAI и Stripe свой вариант, Microsoft встроил оплату в Copilot, и заявленная цель одна: покупатель не выходит из чата.

Каждая такая покупка рано или поздно попадает в бухгалтерию продавца. Отрасль исходит из того, что заказы от агентов, это просто больше заказов, а значит система, которая уже умеет онлайн-продажи, справится и с ними.

Ломается не это. Ломается то, что заказ от агента приходит без карточки клиента, а в большинстве бухгалтерских систем именно карточка клиента, это единственное, что знает, страна какой юрисдикции определяет НДС.

Я могу показать это на нашей собственной базе, потому что у нас тот же дефект.

Почему автоматическая бухгалтерия проводит продажи e-commerce как внутренние?

Norman, это немецкий бухгалтерский и налоговый продукт. Примерно одна из пятидесяти строк дохода в нашей базе проведена как трансграничная. Всё остальное, внутренние продажи. При беглом чтении это значит, что наши клиенты продают дома. Ничего подобного это не значит. Это значит, что наше значение по умолчанию, внутреннее.

Страна продажи выводится ровно в одном месте и ровно при одном условии:

# Набросок формы, не наш исходный код.
def on_save(transaction):
    if transaction.client and transaction.client.country:
        transaction.supplier_country = bucket(
            transaction.client.country, transaction.company.country
        )  # внутри страны | ЕС | вне ЕС
    # Клиента нет? Поле остаётся таким, каким его создали.

Логика места поставки висит на связанном клиенте. Нет клиента, нет вывода, и строка сохраняет внутреннее значение, с которым была создана. Это обычный путь для всего, что приходит как деньги, а не как документ.

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

Честное прочтение «98 % внутренних», это что у 98 % наших строк дохода вопрос просто не задавали.

Сегодня это терпимо, потому что трансграничный доход немецкого фрилансера, это горстка крупных B2B-счетов в год, к каждому привязан клиент. В нашей базе средняя строка дохода из третьих стран стоит в несколько раз больше средней внутренней. Мало, крупно, задокументировано.

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

Считается ли выплата Shopify выручкой?

Нет, и это вторая поломка, независимая от ИИ.

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

Проведёте оба, выручка удвоится. Если банковский фид дополнительно импортирует выплату как доход, утроится. Именно это был баг в нашем первом заходе на интеграцию с магазином, пойманный до того, как дошёл до клиента, и это самый частый способ, которым автоматизация e-commerce выдаёт красивый и полностью неверный финансовый результат.

Правильная модель скучна и её стоит проговорить:

• Заказ, это событие выручки. Брутто, по ставке страны назначения, на дату оплаты.
• Выплата, это не выручка. Расходом является только комиссия провайдера. Соответствующее поступление на счёт, это транзитная проводка, а не доход.
• Возврат, это отрицательная выручка на стороне доходов. Он никогда не расход.

Последний пункт звучит педантично, пока не посмотришь на объёмы. Возвраты идут примерно на уровне двух-трёх процентов строк дохода в нашей базе, и эта популяция состоит в основном из услуг, где возвратов почти нет. Потребительские товары, купленные агентом по лучшему совпадению, на двух процентах не удержатся. Проведёте их как расход, и раздуете одновременно выручку и затраты, а декларации по НДС отдадите цифру, которая не сходится ни с одной банковской выпиской.

Что на самом деле требует поток заказов

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

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

Место модели там, где правила нет: решить, что это поступление и тот отчёт о выплате описывают одну и ту же пачку, или что позиция «страховка доставки», это услуга, а не товар.

Мы построили эту модель «сначала заказ» в интеграции Norman с магазином, она работает в нашей среде разработки и клиентам ещё не включена. Работа над ней изменила мой взгляд на то, что здесь сложное. Я ожидал налоговых правил. Сложным оказалось то, что наша учётная база, как и большинство, спроектирована вокруг документа, а у потока заказов документа нет.

Что с этим делает график ViDA

Регуляторное направление ухудшает значение по умолчанию. В рамках VAT in the Digital Age One-Stop-Shop расширяется с 1 января 2027 года, а с 1 июля 2028 года единая регистрация по НДС распространяет схему практически на все B2C-поставки. Смысл в том, чтобы продавец отчитывался за много стран через одну регистрацию, и это работает, только если книги знают, к какой стране относилась каждая продажа. Система, которая молча кладёт всё во внутренние, выдаст аккуратную немецкую декларацию по НДС и пустую по неправильной причине отчётность OSS.

Если вы сейчас выбираете инструмент, вопрос к поставщику не в том, поддерживает ли он OSS. Вопрос в том, откуда берётся страна назначения, когда карточки клиента нет.

Для дальнейшего чтения: процедура OSS в Германии, продажи на Amazon и налоговая регистрация, автоматизация бухгалтерии для пути вне e-commerce и агент, который подаёт наши декларации по НДС.

Частые вопросы

Какие правила НДС действуют для трансграничного e-commerce в ЕС?

При продажах частным лицам в других странах ЕС решает общеевропейский порог поставок в 10 000 евро. Ниже него оборот остаётся облагаемым в Германии. Выше место поставки смещается в страну назначения, вы должны её ставку, но отчитываетесь по ней через One-Stop-Shop одной декларацией. Это краткое изложение, а не консультация по вашему случаю.

Как вести налоги по продажам e-commerce?

Бухгалтерски каждому заказу нужны три сведения, которых чистая банковская проводка не даёт: страна назначения, товар это или услуга, и фактически начисленная ставка. Если проводить только поступление денег, теряются все три. Поэтому правильная отправная точка, заказ, а не выплата.

Считается ли выплата Shopify выручкой?

Нет. Выплата, это пакетный расчёт по уже заработанным заказам за вычетом комиссий и часто за вычетом возвратов. Выручка возникает по заказу, брутто, при оплате покупателем. Выплату следует проводить как транзитную проводку плюс расход на комиссию. Проводить её как доход поверх заказов, это самая частая причина удвоенной выручки e-commerce.

Меняют ли ИИ-агенты покупок обязанности по НДС?

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

Может ли ИИ определять ставку НДС по заказу?

Не должен. Страна назначения, это поле в теле заказа, а ставка, это поиск по стране и дате. И то и другое детерминировано. Отдать детерминированный поиск модели, значит купить редкие уверенные ошибки в цифре, которую проверяют. Модели уместны на действительно неоднозначных участках, например при сопоставлении банковского поступления с пачкой выплат.