Продажбите ви през 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%. Игнорирайте данъци, възстановявания и ефекти от обменни курсове за момента. На етапа на фактуриране или спечелени приходи, запишете:
Dr Вземания от AWS Marketplace 10,000
Cr Приходи от AWS Marketplace 10,000%Когато таксата за обява е призната или удържана от сетълмента:
Dr Разход за такси за обяви в AWS Marketplace 300%
Cr Вземания от AWS Marketplace 300%Когато AWS събере и изплати баланса:
Dr Помощна сметка за плащания от AWS Marketplace 9,700%
Cr Вземания от AWS Marketplace 9,700%Когато банковият депозит се появи:
Dr Оперативна банкова сметка 9,700%
Cr Помощна сметка за плащания от AWS Marketplace 9,700%В реалните книги, времето на статиите зависи от вашата политика за признаване на приходи, счетоводна база, правно образувание и данъчно третиране. Моделът има значение, защото поддържа таксата видима. Записването само на депозита от $9,700 като приход би подценило брутните продажби и би направило таксата за обява да изчезне в необяснимо намаление на дохода. Графикът на таксите за обява на AWS варира според продукта и типа на офертата. Например, AWS документира различни стандартни ставки за SaaS, сървърни продукти, данъчни оферти, частни оферти, частни оферти за канални партньори и професионални услуги. Не вграждайте твърдо един процент в счетоводната си автоматизация. Импортирайте отчетената сума на таксата и запазете отчетения процент като проверкамо
Отнасяйте се към данъците като към сценарий, който трябва да идентифицирате, а не предположение, което трябва да направите
Обработката на данъци в Marketplace зависи от данъчния адрес на купувача, тип на продукта, местоположение на продавача и правилата за пазарно посредничество. Данните от събитията на фактуриране могат да разграничат поне три общи модела:
-
AWS събира и внася данъка. Това е представено като събитие за данъчен дял на AWS и не увеличава сумата, изплатена на продавача.
-
AWS събира данъка, включва го в сетълмента на продавача и продавачът го внася. Това е представено като събитие за данъчен дял на продавачамо
-
AWS не изчислява или събира данъка, оставяйки продавача отговорен за изчисляването и внасянето му.
Тези модели не са взаимозаменяеми. Ако сума на данък е само информативна и не влияе на баланса на продавача, не я добавяйте към продажбите или парите. Ако данъкът е изплатен на вас, насочете го към сметка за данъчни задължения, а не към приходи. Ако продавачът е отговорен за данък, който AWS никога не е събирал, създайте задължение чрез собствената си система за фактуриране или данъчен двигател и го съпоставете извън депозита на Marketplace. Съхранявайте данъчното доказателство с транзакцията. Запишете географията на купувача, продукта, офертата, фактурата, типа на данъчния дял, сумата и юрисдикцията за внасяне—или препратка към отчета, съдържащ тези полета. Данъчно обобщение без подкрепа на ниво транзакция е трудно за защита и трудно за коригиранемо
Съпоставяйте възстановяванията и кредитите с оригиналната оферта
Възстановяванията не са просто отрицателни банкови депозити. Те могат да сторнират брутни приходи, да сторнират частично такса за обява, да намалят данъчна сума и да променят бъдещо плащане. AWS се отнася към възстановяванията като към фактуриращи корекции в части от процеса за продавачи, а анулирането не непременно анулира фактури, които вече са били издадени. За всяко възстановяване или кредит, уловете:
- Оригиналния идентификатор на фактурата
- Периода на фактуриране
- Идентификатора на продукта и на офертата
- Референцията за споразумение или абонамент
- Сумата на възстановяването и причината
- Дали таксата за обява и данъчните дялове също са сторнирани
- Датата, на която корекцията е фактурирана, събрана или изплатена
След това приложете корекцията към същите сметки за приходи, такси и данъци, използвани за оригиналната транзакция. Ако публикувате всички възстановявания към обща сметка за „разходи за възстановявания“, маржът ви за продукта ще бъде изкривен и отчетите ви за приходи ще не съвпадат с брутните и нетни полета на AWS. Анулиранията на договори заслужават специално внимание. Анулиране променя статуса на споразумението, докато фактурираща корекция променя фактура или връща средства. Ако и двете са необходими, проследявайте и двете действия и ги свържете със засегнатите фактуриращи редовемо
Направете месечното съпоставяне на плащанията механично
Използвайте повтарящ се контролен списък за затваряне, а не изтегляйте отчет само когато депозитът изглежда грешен.
1. Замразете отчетния период
Изберете дали затварянето се основава на дата на фактурата, период на използване, дата на събиране или дата на плащане. Това са различни гледни точки. Отчет за плащания за един месец може да съдържа фактури, фактурирани по-рано, докато отчет за приходи за същия месец може да съдържа фактури, които все още не са събрани.
2. Импортирайте подробния отчет
Въведете полетата за фактура, оферта, споразумение, брутни приходи, възстановявания, такси, данъци, валута, статус на плащане, дата на плащане и банкови трасиращи кодове. Запазете оригиналния файл на отчета или неизменяема референция за експорт.
3. Групирайте по транзакционна референция
Използвайте идентификатора на транзакционната референция или свързаните идентификатори на фактуриращи събития, за да избегнете двойното отчитане на фактури, такси, данъци, възстановявания и плащания, които принадлежат към едно транзакционно семейство. Сводна таблица или малък скриптов импорт може бързо да разкрие дублирани редове.
4. Свържете неизплатените баланси с открити вземания
Таблото за събирания разделя събраните и изплатени средства от открити и неплатени фактури. Сравнете неизплатения баланс с вашето вземане от AWS Marketplace. Разследвайте стари баланси по условия на плащане, клиент, оферта и възраст на фактурата, вместо да третирате всяко забавяне като банков проблем.
5. Съпоставете нетното плащане с банката
Съпоставете сумата на плащането от отчета и банковия трасиращ код с банковия депозит. Ако сумата се различава, потърсете ACH тайминг, валутна конверсия, неуспешно плащане, дейност по възстановявания, фактури за такси или балансови корекции, преди да публикувате коригираща статия.
6. Прегледайте изключенията по оферта
Потърсете оферти с необичайно високи възстановявания, дълги времена за събиране, отрицателни нетни приходи, неочаквани данъчни дялове или проценти за такси за обяви, които се различават от очакваните договорни условия. Това са оперативни сигнали, а не просто счетоводно почистване.
Чести грешки, които правят числата ненадеждни
Публикуване на депозита като брутен приход
Това скрива таксите и прави съпоставянето приход-към-пари невъзможно. Използвайте помощна сметка и запишете моста бруто-към-нето.
Смесване на датата на фактурата на клиента с датата на парите
Това създава изкуствена месечна волатилност и може да изкриви вземанията. Дръжте датите на фактуриране, събиране, плащане и период на услугата отделни.
Отнасяне към всички полета за данъчен дял като към данъчни задължения
Някои данъчни суми са събрани и внесени от AWS и не влияят на баланса ви. Класифицирайте по тип на транзакцията и юрисдикция.
Игнориране на частни оферти и изменения
Частните оферти могат да имат договорени цени и графици на плащане. Запишете идентификаторите на офертата и споразумението, така че подновяване или изменение да не бъде слято в грешната продуктова група.
Използване на обща сметка за възстановявания
Сторнирайте оригиналните приходи, такси и данъчни компоненти, където е приложимо. Възстановяването трябва да обясни оригиналната транзакция, а не просто да намали печалбата някъде другаде.
Позволяване на банковия поток да стане източник на истината
Банката може да потвърди сетълмента, но не може да ви каже кой клиент, оферта, фактура, данъчен сценарий или такса за обява е произвело парите. Съпоставете банката срещу отчета на Marketplace, а не обратното.
Превърнете съпоставянето в управленски отчет
След като статиите са структурирани, изчислете полезни оперативни показатели по продукт и оферта:
- Брутни фактури от Marketplace
- Нетни приходи след такси за обяви и възстановявания
- Процент на възстановяванията по оферта
- Среден брой дни от фактура до събиране и плащане
- Неизплатени вземания по възрастови групи
- Процент на таксите за платформата като процент от брутните приходи
- Данъци, събрани за продавача, срещу данъци, внесени от AWS
- Парична конверсия по валута и клиентски сегмент
Табло може да покаже тези тенденции, докато основният plain-text ledger поддържа изчислението одитируемо. Ако използвате Beancount, свързването на всяка транзакция с идентификатор на фактура, оферта или отчет прави по-късния преглед много по-бърз. Визуализационен слой като Fava може да ви помогне да изследвате баланси и измерения без да превръщате изходните записи в черна кутия. За технически потребители, документацията предоставя естествено място за стандартизиране на работни процеси за импорт и съпоставяне.
Опростете Финансовото Си Управление
AWS Marketplace става по-лесен за управление, когато всеки депозит може да бъде проследен обратно до брутни приходи, такси, данъци, възстановявания и оферти. Beancount.io предлага plain-text счетоводство, което е прозрачно, версионирано и готово за ИИ, така че финансовите ви данни остават преглеждаеми, докато каналите ви за продажби се умножават.