Бухгалтерія для продавців AWS Marketplace: звірка валового доходу, комісій за лістинг, податків, повернень і відкладених виплат за пропозиціями

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

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

Чому депозити AWS Marketplace не дорівнюють доходу​

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

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

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

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

Побудова плану рахунків для потоку маркетплейсу​

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

Дохід і контр-дохід​

• Валовий дохід AWS Marketplace
• Повернення та кредити AWS Marketplace
• Знижки або поступки за контрактом, якщо вони вже не відображені у валовій сумі звіту

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

Клірингові та балансові рахунки​

• Дебіторська заборгованість AWS Marketplace або невиплачені збори
• Кліринг виплат AWS Marketplace
• Депозити клієнтів або відкладений дохід, якщо застосовно
• Зобов'язання з повернень або кліринг повернень
• Податок з продажів або ПДВ до сплати, розділений за юрисдикціями, якщо ваш податковий процес цього вимагає

Витрати та відрахування​

• Комісії за лістинг AWS Marketplace
• ПДВ або інші податки, що стягуються за лістинг, якщо застосовно
• Витрати каналу партнерів або оптові витрати для пропозицій, що включають реселера
• Банківські комісії або курсові різниці, якщо вони виникають між виплатою та зарахуванням на рахунок

Точні назви рахунків менш важливі, ніж послідовність. Ваша бухгалтерська система має дозволяти відповісти на питання: «Скільки валового доходу Marketplace ми заробили цього місяця, скільки ще не виплачено, і що утримала платформа?» — без реконструкції відповіді з одного чистого депозиту.

Використання вимірювань на рівні пропозицій, а не лише загальної суми Marketplace​

AWS Marketplace може містити публічні пропозиції, приватні пропозиції, корпоративні угоди, SaaS-контракти, продукти з оплатою за використання та приватні пропозиції через партнерів-каналів. Їх ціноутворення, строки, податки та поведінка поновлень можуть відрізнятися.

Відстежуйте принаймні такі вимірювання у вашому процесі імпорту журналів:

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

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

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

Шаблон журналу: спочатку валові суми, потім гроші​

Наступний приклад використовує прості числа для ілюстрації потоку. Припустімо, публічна SaaS-пропозиція формує валовий рахунок на 10 000 доларів США за період, а застосовна комісія за лістинг становить 3%. Поки що ігноруйте податки, повернення та курсові різниці.

На етапі виставлення рахунку або заробленого доходу запишіть:

Дт Дебіторська заборгованість AWS Marketplace       10 000
    Кт Дохід AWS Marketplace                                   10 000

Коли комісія за лістинг визнана або відображена у виплаті:

Дт Витрати на комісію за лістинг AWS Marketplace    300
    Кт Дебіторська заборгованість AWS Marketplace                300

Коли AWS збирає кошти та здійснює виплату:

Дт Кліринг виплат AWS Marketplace                 9 700
    Кт Дебіторська заборгованість AWS Marketplace              9 700

Коли депозит з'являється в банку:

Дт Операційний банківський рахунок                  9 700
    Кт Кліринг виплат AWS Marketplace                          9 700

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

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

Ставтеся до податків як до сценарію, який потрібно ідентифікувати, а не вгадувати​

Обробка податків у маркетплейсі залежить від податкової адреси покупця, типу продукту, місцезнаходження продавця та правил платформи-посередника. Дані про операції дозволяють розрізнити принаймні три основні сценарії:

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

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

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

Звірка повернень і кредитів з оригінальною пропозицією​

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

Для кожного повернення або кредиту зафіксуйте:

• Оригінальний ідентифікатор рахунку
• Розрахунковий період
• Ідентифікатор продукту та пропозиції
• Посилання на угоду або передплатника
• Суму повернення та причину
• Чи були також сторновані комісія за лістинг і частки податків
• Дату, коли коригування було виставлено, зібрано або виплачено

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

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

Зробіть щомісячну звірку виплат механічною​

Використовуйте повторюваний чек-лист закриття періоду, а не завантажуйте звіт лише тоді, коли депозит виглядає неправильно.

1. Закріпіть звітний період​

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

2. Імпортуйте детальний звіт​

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

3. Групуйте за посиланням на транзакцію​

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

4. Зв'яжіть невиплачені залишки з відкритою дебіторською заборгованістю​

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

5. Звірте чисту виплату з банком​

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

6. Перевіряйте винятки за пропозиціями​

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

Поширені помилки, що роблять цифри ненадійними​

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

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

Змішування дати рахунку клієнта з датою надходження грошей​

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

Трактування всіх полів частки податків як податку до сплати​

Деякі суми податків збираються та сплачуються AWS і не впливають на ваш баланс. Класифікуйте за типом транзакції та юрисдикцією.

Ігнорування приватних пропозицій і змін до угод​

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

Використання загального рахунку для повернень​

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

Дозвіл банківському потоку стати джерелом істини​

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

Перетворення звірки на управлінський звіт​

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

• Валові виставлення Marketplace
• Чистий дохід після комісій за лістинг і повернень
• Рівень повернень за пропозиціями
• Середні дні від рахунку до збору та виплати
• Невиплачена дебіторська заборгованість за віковими категоріями
• Ставка комісії Marketplace як відсоток валового доходу
• Податок, зібраний для продавця, проти податку, сплаченого AWS
• Конвертація грошей за валютою та сегментом клієнтів

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

Спрощення управління фінансами​

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