Для true-up або proration потрібно відтворити три величини: кількість ліцензій у кожному інтервалі, ціну плану та правило округлення вендора. Підсумковий рядок без usage detail не дозволяє перевірити нарахування.
У середині кварталу адміністратор додав дванадцять користувачів, пізніше видалив п’ять, а invoice показує лише загальне донарахування. Без історії дат і тарифів фінанси не можуть відрізнити коректну proration від зайвих seats або подвійного нарахування.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | компанія або підприємець, що купує програмне забезпечення чи цифрову послугу |
| Кому | іноземний SaaS-вендор, реселер або оператор цифрового сервісу |
| Мета | оплата SaaS-інвойсу зі зміною кількості seats посеред періоду |
| Валюта / інструмент | vendor invoice, subscription billing і банківська або офіційна платіжна інструкція |
| Що змінює висновок | дати додавання й видалення, billing cycle, tier pricing, minimum commitment і rounding |
Що потрібно знати до платежу
Зміна кількості ліцензій може створити proration
Stripe пояснює, що billing-зміни, зокрема зміна ціни, кількості або billing period, можуть генерувати prorations; їх можна попередньо переглянути. Це правило конкретної платформи, тому формулу та округлення потрібно підтверджувати в документації вашого SaaS. (Stripe Docs — Modify subscriptions)
Ключова контрольна умова
Proration залежить від правила конкретної billing system: календарні дні, секунди, місяці або інший метод можуть дати різний результат. (European Commission — VAT invoicing)
Яку доказову нитку зберегти
Видалення користувача з продукту не завжди негайно зменшує contractual commitment, якщо план має мінімальну кількість seats. (European Commission — VAT special schemes (OSS))
Що змінює практичний висновок
Credit, unused balance і true-up треба звіряти окремо, щоб не порахувати коригування двічі. (Your Europe — payments and transfers)
Покрокова підготовка
- Відновіть хронологію seats. Експортуйте список додавань і видалень із timestamp, user ID, plan та approver. Розбийте service period на інтервали, у яких кількість ліцензій і ціна залишалися незмінними.
- Перерахуйте кожний prorated line. Для інтервалу застосуйте контрактну unit price, базу дня або місяця та правило округлення вендора. Зіставте credits і charges із invoice detail; у зверненні до support назвіть конкретний рядок і розраховану різницю.
- Експортуйте seat history. Зберіть дати активації, деактивації, роль користувача й тариф для кожної зміни у спірному періоді.
- Відтворіть розрахунок. Порівняйте usage detail із формулою вендора, попереднім invoice, credit balance та контрактним minimum.
Які дані та документи зібрати
- договір, order form або офіційні умови підписки з назвою плану й сторін
- vendor invoice з номером, періодом, billing entity, валютою та сумою
- export seat або usage history за період інвойсу
- деталізація proration, credit і true-up від вендора
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Компанія додала 12 користувачів у середині кварталу й видалила п’ять наприкінці. Фінанси експортують історію seats, відтворюють proration та оскаржують лише конкретне відхилення.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- щодо предмета «перевірка донарахувань за користувачів і частину періоду» називати TradePay партнером SaaS-платформи або гарантувати прийняття конкретного маршруту; наслідок — втрата зв’язку з метою: оплата SaaS-інвойсу зі зміною кількості seats посеред періоду
- під час контролю предмета «перевірка донарахувань за користувачів і частину періоду» платити за листом із реквізитами, не звіривши invoice у vendor portal або договорі; окремої оцінки потребують: дати додавання й видалення, billing cycle, tier pricing, minimum commitment і rounding
- рахувати proration за власною формулою без перевірки правил сервісу
- ігнорувати minimum commitment або tier threshold
Де проходить межа поради
Остаточні вимоги залежать від юрисдикції, банку, платіжного провайдера, статусу сторін і призначення операції.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay приймає таку заявку на індивідуальну перевірку; менеджер підтвердить доступність, курс, підсумкову суму, реквізити та орієнтовний строк до оплати. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- European Commission — VAT invoicing
- European Commission — VAT special schemes (OSS)
- Your Europe — payments and transfers
- TradePay — оплата інвойсів
- Stripe Docs — Modify subscriptions
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.