Клієнт ніколи не відвідував вашу вітрину. Жодного покинутого кошика, жодного зареєстрованого перегляду сторінки, жодного кліку «додати в кошик» у вашій аналітиці. І все ж платіж надійшов, замовлення відправлено, а у вашому обліку з'явився ризик чарджбеку (зворотного платежу), пов'язаний з покупцем, який насправді навіть не дивився на екран.
Саме так виглядає дедалі більша частка транзакцій у 2026 році. ШІ-агент — усередині ChatGPT, Gemini або торгового асистента, побудованого на одному з нових протоколів агентської комерції (agentic commerce) — здійснював пошук, порівняння та покупку від імені людини. Людина затвердила бюджет і набір уподобань, а агент зробив усе інше. Для продавців це не гіпотетичний сценарій. Продавці Etsy вже використовують Instant Checkout від OpenAI, понад мільйон продавців Shopify підключаються до цієї системи, а власний сервер агентської комерції від PayPal, як очікується, залучить десятки мільйонів малих підприємств до цих технологій ще до кінця року.
Проблема полягає в тому, що більшість систем бухгалтерського обліку для малого бізнесу досі виходять із припущення, що кнопку «купити» натиснула людина. Замовлення, ініційовані агентами, руйнують це припущення, що спочатку виявляється у вигляді головного болю при узгодженні рахунків, а у разі ігнорування — переростає у реальні фінансові ризики та ризики порушення вимог законодавства (комплаєнсу).
Що насправді означає «агентська комерція» для вашого обліку
Якщо відкинути хайп, агентська комерція — це просто делегований шопінг: клієнт встановлює мету («знайди мені водонепроникну куртку темно-синього кольору до $150, розмір M») та певні обмеження (ліміт витрат, схвалені роздрібні продавці, можливо, платіжну картку), а ШІ-агент займається пошуком та покупкою з мінімальним подальшим втручанням. Близько 58% споживачів стверджують, що вже замінили традиційний пошук інструментами генеративного ШІ для отримання рекомендацій щодо продуктів — перехід від моделі «переглянути, а потім купити» до «делегувати, а потім затвердити» вже активно триває, а не є трендом майбутнього.
Для забезпечення цієї роботи з'явилися три сімейства протоколів, і ви, швидше за все, зіткнетеся з усіма трьома, якщо тривалий час продаєте в інтернеті:
- ACP (Agentic Commerce Protocol — Протокол агентської комерції) — розроблений Stripe та OpenAI, саме він забезпечує роботу функції Instant Checkout у ChatGPT. Замість того щоб агент бачив справжній номер картки вашого клієнта, платіжний провайдер клієнта випускає спільний платіжний токен (Shared Payment Token): обмежені за обсягом, лімітовані за часом, відкличні облікові дані, дійсні для одного продавця та однієї суми. Stripe описує це як програмований дозвіл (programmable grant), який можна відстежувати через події вебхуків (webhooks) — і це важливо, оскільки ці вебхуки є вашим єдиним сигналом у реальному часі про те, що транзакцію щойно здійснив покупець-нелюдина.
- AP2 (Agent Payments Protocol — Протокол агентських платежів) — конкуруючий стандарт від Google, підтриманий понад 60 партнерами, серед яких Mastercard, PayPal та American Express. AP2 представляє кожну покупку через агента у вигляді трьох підписаних «Мандатів»: Мандат наміру (Intent Mandate) (чого хоче покупець), Мандат кошика (Cart Mandate) (що зібрав агент) та Мандат оплати (Payment Mandate) (сума, яка стягується). Кожен із них є верифікованим записом із криптографічним підписом — теоретично це більш прозорий аудиторський слід, ніж за звичайного оформлення замовлення людиною, якщо ваші системи вміють його зчитувати.
- UCP та інші — ширша ініціатива, спрямована на стандартизацію машинозчитуваних термінів доставки, правил повернення та даних про виконання замовлень (fulfillment), щоб агенти могли порівнювати продавців за однаковими критеріями, а не лише за ціною.
Практичний результат: ваша вітрина незабаром може обслуговувати два абсолютно різні типи клієнтів — людей та програмних агентів, що діють за мандатом людини, — і ваш бухгалтерський облік має навчитися розрізняти їх.
Чому узгодження стає складнішим, а не простішим
Можна було б подумати, що згенероване машиною замовлення з криптографічним підписом узгодити простіше, ніж замовлення від людини. На практиці ж продавці стикаються з протилежним через кілька цілком конкретних причин.
Ланцюжок авторизації зберігається у кількох місцях
Одна транзакція ACP може стосуватися запису мандата, квитанції про замовлення, події взаєморозрахунків (settlement) від вашого платіжного процесора та запису ідентифікації, що підтверджує, який саме агент (і на підставі чиїх повноважень) ініціював покупку. Коли подія розрахунку потрапляє у вашу банківську виписку, її зіставлення з реальним контекстом замовлення — та можливість довести цей ланцюжок у разі виникнення спору — у перших інтеграціях уже називають «процесом узгодження з багатьох джерел». Це красиве формулювання для опису того факту, що між сумою, яка надходить на ваш рахунок, та замовленням, до якого вона належить, тепер є набагато більше рівнів, ніж просто номер інвойсу.
Повернення коштів мають супроводжуватися відповідями на питання «хто, що і чому»
Якщо сервісна служба самого ШІ-агента ініціює повернення коштів на вашій платформі — що трапляється все частіше, оскільки ритейлери автоматизують повернення — це повернення потребує метаданих: який агент його авторизував, відповідно до яких правил і чому. Фінансовому відділу це потрібно для узгодження транзакції, а вам — для захисту від чарджбеку, коли клієнт додатково оскаржує той самий платіж через свій банк, створюючи ризик подвійного повернення коштів. Часткові повернення для замовлень із кількома позиціями та пропорційні (прорейт) повернення коштів за підписками лише ускладнюють цю ситуацію.
Ризик чарджбеків уже є значним і продовжує зростати
За прогнозами, у 2026 році спори щодо чарджбеків обійдуться продавцям приблизно у $28 мільярдів, а їхні обсяги зростуть приблизно на 41% порівняно з 2023 роком — і це без урахування додаткової невизначеності на кшталт «чи дійсно власник рахунку санкціонував це, чи його агент перевищив свої повноваження?». Кожен програний спір коштує вам суми транзакції, комісії процесора (зазвичай від $15 до $100) та часу персоналу на збір доказів у стислі терміни, встановлені платіжною системою. Замовлення, ініційовані агентами, які не мають чітких записів мандатів, буде важче, а не легше, захистити.
Банківські виписки не бачать різниці
У вашій банківській виписці відображається депозит. Але там не вказано, чи надійшов цей депозит від людини, яка натиснула «Оформити замовлення», чи від агента, який виконав мандат кошика (Cart Mandate) з бюджетом у 150 доларів. Якщо ваш план рахунків та процес звірки не дозволяють позначати джерело тегами, згодом ви втратите можливість відповідати на базові запитання: скільки доходу надійшло через оформлення замовлень агентами в цьому кварталі, яка частка повернень у каналі агентів, чи не пов'язаний обсяг замовлень від агентів непропорційно із чарджбеками та спорами? Це не абстрактні питання — це саме ті питання, які рано чи пізно поставить кредитор, бухгалтер або еквайєр.
Практична схема звірки для замовлень, ініційованих агентами
Вам не потрібно ставати інженером із платежів, щоб добре з цим справлятися. Достатньо впровадити кілька дисциплінованих звичок у ту систему бухобліку, яку ви вже використовуєте.
1. Позначайте канал тегом у момент продажу, а не після нього. Незалежно від того, використовуєте ви Shopify, Etsy чи власну інфраструктуру, більшість інтеграцій агентської комерції передають прапорець або поле метаданих, що вказує на те, що замовлення надійшло через ACP, AP2 або подібний протокол. Фіксуйте цей прапорець як тег транзакції або субрахунок (наприклад, «Продажі — Канал агентів»), а не скидайте все в загальний дохід від продажів. Намагатися виправити це заднім числом після шести місяців нерозділених продажів від агентів та людей набагато болісніше, ніж додавати теги з першого дня.
2. Зберігайте мандат або квитанцію про замовлення, а не лише запис про розрахунки. Звіт про виплати вашого платіжного процесора показує лише рух коштів. Зазвичай він не розкриває повної історії авторизації. Будь-яку квитанцію від платформи, посилання на мандат або корисне навантаження вебхука, що супроводжує замовлення, зберігайте разом із звичайними рахунками-фактурами. Ставтеся до цього так само, як до підписаного замовлення на купівлю (purchase order) — це ваш доказ, якщо під час спору виникне питання «чи було це насправді санкціоновано?»
3. Проводьте звірку з чітким вирахуванням комісій. Наприклад, Instant Checkout від OpenAI стягує з торговців комісію за транзакцію в розмірі 4% від завершених покупок. Це реальна стаття витрат, і вона потребує окремого рахунку — не ховайте її у загальних «комісіях за обробку платежів», якщо хочете реально порівняти маржинальність продажів через агентів та прямих продажів.
4. Створіть окремий журнал повернень/спорів для замовлень від агентів — принаймні доки не будете впевнені в обсягах. Оскільки питання «хто і чому ініціював це повернення» тут має більше значення, простий поточний журнал (навіть звичайна таблиця для початку), де фіксуються ID замовлення, посилання на мандат, причина та те, чи було воно ініційоване агентом чи людиною, заощадить вам години часу, коли чарджбек і повернення вперше зіткнуться в одному замовленні.
5. Свідомо вирішіть, чи хочете ви взагалі приймати покупки, здійснені агентами. За протоколами на кшталт AP2 ваша вітрина може самостійно вирішувати, чи приймати транзакції, ініційовані агентами, чи обробляти їх інакше (показувати CAPTCHA, встановлювати іншу ціну, виключати подарункові картки) або повністю відмовитися від них. Це бізнес-рішення не менш ніж технічне — і його слід приймати з урахуванням можливостей вашої бухгалтерії та обробки спорів, а не лише прагнення охопити новий канал продажів.
Головний урок: можливість аудиту завжди була на першому місці
Ось що стає очевидним завдяки агентській комерції, хоча це було правдою завжди: транзакція заслуговує на довіру лише настільки, наскільки надійним є її запис. Криптографічно підписані мандати та обмежені платіжні токени — це, у певному сенсі, спроба агентської комерції вирішити проблему, яку завжди намагався вирішити якісний бухгалтерський облік: точно знати, що було санкціоновано, ким, на яку суму та мати можливість довести це згодом.
Малому бізнесу, який уже веде чистий, добре тегований облік із можливістю аудиту, буде набагато простіше інтегрувати продажі через агентські канали у свою поточну систему. Натомість компанії, які ведуть облік недбало та без чіткого розподілу, виявлять, що агентська комерція перетворює дрібні прогалини в бухгалтерії на реальну проблему зі звіркою та захистом від спорів, щойно обсяг транзакцій через ці канали почне зростати.
Тримайте свою бухгалтерію готовою до будь-яких нових форматів продажів
Незалежно від того, здійснює продаж людина, натискаючи «купити», чи ШІ-агент, який виконує підписаний мандат від її імені, основи залишаються незмінними: кожна транзакція потребує чіткого сліду, що піддається аудиту, від замовлення до розрахунку. Beancount.io пропонує текстову бухгалтерію (plain-text accounting), яка за своєю природою є прозорою та підтримує контроль версій. Тож додавання тегів для нового каналу продажів, включно із замовленнями від агентів, стає просто питанням створення нового рахунку, а не перебудови всієї бухгалтерії. Почніть безкоштовно і дізнайтеся, чому розробники та фінансово орієнтовані власники бізнесу переходять на текстову бухгалтерію ще до того, як відбудеться наступний зсув у торгівлі.