Ціноутворення на основі результатів для агентного ШІ SaaS: як визнавати дохід, коли клієнти платять за успішний результат

Ваш ШІ-агент може виконати 10 000 спроб за місяць і все одно не заробити нічого за договором, якщо лише 7 200 спроб відповідають визначенню успіху клієнта. Це бухгалтерське напруження, що стоїть за ціноутворенням на основі результатів: модель може працювати безперервно, але обіцянка, яку ви продали, може вимірюватися завершеними результатами.

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

Ключове питання згідно з ASC 606 — не просто «Скільки разів працював агент?». Воно полягає в наступному: «Що договір обіцяв клієнту, і коли ця обіцянка була передана?»

Почніть з обіцянки, а не з лічильника​

Ціноутворення на основі результатів може описувати кілька різних домовленостей. Два контракти можуть обидва стягувати плату за успішну транзакцію, але вимагати різних бухгалтерських висновків.

Обіцянка готовності до виконання​

У домовленості про готовність до виконання постачальник обіцяє зробити послугу ШІ доступною протягом певного періоду. Клієнт отримує вигоду від наявності можливості в готовності, коли вона потрібна, незалежно від того, чи надходить багато запитів. Щомісячна плата за платформу, безлімітний доступ або використання, що в основному залежить від кінцевих користувачів клієнта, часто вказують на цей напрямок.

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

Визначена кількість результатів​

У домовленості про споживання обіцянка ближча до «доставити 25 000 завершених результатів». Кожен відповідний результат зменшує право клієнта на решту обсягу. Після доставки купленої кількості клієнт приймає нове рішення про придбання додаткових потужностей.

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

Гібридна обіцянка​

Багато реальних контрактів поєднують обидві моделі. Клієнт може сплачувати фіксовану щомісячну плату за доступ до хостингової платформи та окрему суму за кожне підтверджене запобігання дублюванню рахунку-фактури. Плата за доступ і плата за результат не повинні штучно об'єднуватися в один патерн визнання лише тому, що вони з'являються в одному рахунку.

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

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

Дерево рішень згідно з ASC 606​

Використовуйте цю послідовність для кожного суттєвого договору. Задокументуйте висновок, а не покладайтеся на стандартний графік визнання доходу з системи виставлення рахунків.

1. Визначте успішний результат​

«Успіх» має бути достатньо об'єктивним, щоб обидві сторони могли визначити, коли постачальник заробив плату. Для агента з обробки рахунків-фактур договір може вимагати виконання всіх наступних умов:

• Рахунок-фактура отриманий і зіставлений з правильним замовленням на закупівлю.
• Необхідні перевірки завершені без ескалації до людини.
• Бухгалтерський запис оприлюднено в призначеній системі клієнта.
• Транзакція не скасована протягом визначеного періоду перевірки.

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

2. Визначте, що отримує клієнт​

Запитайте, чи отримує клієнт:

• Безперервний доступ до агента протягом визначеного строку;
• Кінцеву кількість завершених результатів;
• Додаткові права на використання платформи; або
• Пакет з доступу, впровадження, підтримки та результатів.

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

3. Визначте, чи є домовленість серією​

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

Наприклад, послуга може надавати безлімітний доступ протягом 12 місяців і стягувати $3 за кожну успішну інтервенцію проти шахрайства в місяці, коли вона відбувається. Якщо ставка фіксована, визначення успіху вимірюване, а плата стосується послуги саме цього місяця, визнання плати за результат у міру настання відповідних інтервенцій може достовірно відображати передачу.

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

4. Перевірте практичне спрощення за рахунками​

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

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

5. Застосуйте обмеження щодо змінного відшкодування​

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

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

Приклад з розрахунками: фіксований доступ плюс підтверджені результати​

Припустімо, постачальник підписує 12-місячну угоду з такими умовами:

• Щомісячна плата за платформу $10 000 за хостинговий доступ, моніторинг і підтримку.
• $12 за кожен рахунок-фактуру, який агент обробляє наскрізно, правильно оприлюднює та проходить перевірку на скасування протягом 30 днів.
• Без мінімальної кількості рахунків-фактур.
• Щомісячні рахунки на основі журналу підтверджених результатів.

Плата за платформу описує послугу готовності до виконання. Якщо клієнт отримує доступ рівномірно протягом року, постачальник відображає $10 000 доходу щомісяця, якщо жодні інші факти не змінюють висновок.

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

Якщо 800 результатів відповідають критеріям у березні, дохід за результати становить $9 600. Таким чином, березневий дохід становить$19 600 до врахування податків, повернень, кредитів чи інших умов договору. Банківський депозит може відбутися у квітні; час надходження грошових коштів не переміщує березневий дохід на квітень.

Для попередньо оплаченого договору з кінцевою кількістю результатів початкова проводка виглядала б інакше. Якщо клієнт попередньо оплачує $120 000 за 10 000 успішних результатів, відобразіть грошові кошти та договірне зобов'язання під час отримання платежу. Визнавайте$12 доходу в міру передачі кожного відповідного результату, зменшуючи зобов'язання. Якщо невикористані результати втрачають чинність, оцінюйте невикористання згідно з договором і застосовною політикою щодо доходу, а не вивільняйте весь залишок просто тому, що строк завершився.

Простими словами:

Клієнт попередньо оплачує 10 000 успішних результатів
  Дебет   Грошові кошти                     $120 000
  Кредит  Договірне зобов'язання            $120 000
 
800 результатів відповідають критеріям по $12 кожен
  Дебет   Договірне зобов'язання             $9 600
  Кредит  Дохід на основі результатів        $9 600

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

Дані, необхідні для закриття книг​

Дохід на основі результатів не можна закрити лише за випискою з банку. Створіть щомісячний пакет доказів, який пов'язує договір з бухгалтерською книгою.

Умови договору​

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

Журнал результатів​

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

Рівні звірки​

Звіряйте в такому порядку:

1. Журнал подій агента зі звітом про використання або результати, що надається клієнту.
2. Звіт про результати з рахунком-фактурою.
3. Рахунок-фактуру з дебіторською заборгованістю.
4. Дебіторську заборгованість і кредити з банківським врегулюванням.
5. Визнаний дохід і договірне зобов'язання з графіком визнання доходу.

Досліджуйте розбіжності, а не коригуйте їх через дохід. Невдалий робочий процес може зникнути з експорту для білінгу, залишаючись у журналах інфраструктури. Дубльований результат може бути виставлений у рахунку двічі, але оплачений один раз. Скасування після виставлення рахунку може вимагати кредит-ноти та коригування доходу. Кожна розбіжність повинна мати відповідального та примітку про вирішення.

Економіка одиниці поряд із доходом​

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

Поширені помилки, яких слід уникати​

Розгляд кожної спроби як доходу​

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

Оприбуткування рахунку-фактури як доходу​

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

Ігнорування впровадження та онбордингу​

Маппінг даних, інтеграції, конфігурація та дизайн робочих процесів можуть бути діяльністю, яка допомагає постачальнику виконувати SaaS-обіцянку, або вони можуть передавати окрему послугу клієнту. Не припускайте, що «безкоштовне впровадження» не має бухгалтерських наслідків. Визначте, чи може клієнт отримати вигоду від роботи незалежно та чи є робота окремою від хостингової послуги.

Використання єдиного показника успіху для кожного робочого процесу​

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

Забування про права на дані клієнта​

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

Практичний шаблон політики​

Перед запуском нового плану на основі результатів дайте відповіді на ці питання у короткій бухгалтерській службовій записці:

• Яка саме обіцяна послуга?
• Яка подія доводить успішну передачу?
• Чи є обіцянка готовністю до виконання, визначеною кількістю результатів або гібридною?
• Чи є послуги серією з однаковим патерном передачі?
• Чи безпосередньо сума рахунку відповідає переданій вартості?
• Чи може застосовуватися виняток щодо розподілу змінного відшкодування?
• Якщо ні, яка оцінка та обмеження підтримують ціну транзакції?
• Чи є впровадження, підтримка, права на дані, опції продовження або мінімуми окремими питаннями?
• Яка операційна система є авторитетною для підрахунку результатів?
• Як щомісячний звіт буде звірятися з рахунками-фактурами, дебіторською заборгованістю, договірними зобов'язаннями та грошовими коштами?

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

Спрощуйте своє фінансове управління​

Ціноутворення на основі результатів робить чисті версійовані записи особливо цінними: договір, відповідні події, графік визнання доходу та банківська активність мають розповідати одну історію. Beancount.io пропонує бухгалтерський облік у вигляді звичайного тексту, який є прозорим, версійованим і готовим до ШІ, надаючи вашій команді стійкий аудиторський слід у міру еволюції моделей ціноутворення. Почніть безкоштовно і тримайте фінансову логіку видимою від договору до закриття.