Почему POS заставляет меня вручную убирать налог при каждой необлагаемой налогом продаже?

Потому что большинство POS-систем моделируют налог как свойство товара, а не покупателя. Ваш каталог знает, что мешок удобрений облагается налогом с продаж. Но он понятия не имеет, что покупатель — это ферма со свидетельством об освобождении от уплаты налогов (документом, подтверждающим право не платить налог с продаж), некоммерческая организация или подрядчик, покупающий товар для перепродажи. Поскольку в системе нет понятия необлагаемой налогом продажи, единственное доступное действие на кассе — вручную удалять налог из заказа (иногда построчно), пока очередь растет.

Проблема заключается именно в этом архитектурном решении, а не в кассире. Ниже рассказано, почему так происходит, во сколько это вам скрыто обходится и что с этим делать. Важное примечание: правила освобождения от налогов различаются в зависимости от штата, провинции и страны, поэтому воспринимайте эту статью как совет по организации процессов, а не как налоговую консультацию.

Почему моя POS относится к освобождению от налогов как к редчайшему случаю?

Потому что налог находится не на том уровне модели данных. В большинстве систем вы один раз назначаете налоговую ставку каждому товару, и при оформлении заказа она применяется автоматически. Это работает до тех пор, пока фактор, меняющий налог, — это не товар, а покупатель. Освобождение от налога — это факт уровня покупателя, и в товарной налоговой модели для него просто нет места.

Разработчики знают об этом. Но они также знают, что операции без налога составляют небольшую долю в объеме продаж большинства торговцев, поэтому исправление годами висит в планах разработки. В POS со статичным интерфейсом вы не можете добавить недостающий шаг самостоятельно, поэтому кассирам приходится изо дня в день делать это вручную. Это та же история, что и ночной экспорт CSV вместо полноценной отчетности: временная затычка вместо нормального рабочего процесса.

Во сколько на самом деле обходится ручное удаление налога?

Намного дороже тридцати секунд на одну операцию, хотя секунды на кассе тоже суммируются. Вот реальные издержки:

• Пропущенные строки. В заказе из двадцати позиций одна пропущенная строка с налогом означает, что вы либо взяли налог с освобожденного от него покупателя, либо перечислили налог, который не взимали.

• Ошибки при нескольких ставках. Если в корзине товары с разными налоговыми ставками или со сложными начислениями (налог на налог), при ручном редактировании легко ошибиться.

• Нарушенный аудиторский след. Заказ, отредактированный вручную, обычно не содержит записей о том, почему был удален налог и каким документом это подтверждается. При проверке вам придется восстанавливать детали по памяти.

• Искаженная отчетность. Ручные отмены часто попадают в отчеты как скидки или изменение цены вручную, что занижает чистые продажи и искажает сумму собранного налога. Ваша Финансовая сводка должна показывать продажи без налога именно как необлагаемые, а не как уценку.

• Избыточные права доступа. Если удаление налога требует прав на редактирование заказа, вам придется дать эти права каждому кассиру, что создает лишние риски.

Какие временные решения действительно помогают сегодня?

Три шага в порядке их пользы.

Настройте освобождение в настройках налогов. Большинство систем позволяют задавать именованные налоговые ставки и группы; в Final это находится в разделе Настройки, затем Налоги. Для товаров не из каталога произвольная продажа позволяет выбрать нужную налоговую группу или вовсе пропустить ее. В любом случае продажа корректно проходит через налоговую систему, а не корректируется в обход нее.

Ведите строгий учет документов. В США покупатель предоставляет заполненный сертификат освобождения от налога, и вы храните его копию; стандартизированный сертификат принимается в 24 штатах-участниках соглашения Streamlined Sales Tax¹. Организуйте хранение документов так, чтобы их можно было сопоставить с конкретными заказами, поскольку в самой записи о продаже этой информации не будет.

Не заменяйте это скидками. Скидка на сумму налога выглядит правильно в чеке, но искажает всё остальное: чистые продажи падают, собранный налог отображается неверно, и бухгалтерия перестает сходиться (отчеты перестают совпадать с фактическим движением средств).

Как POS должна обрабатывать продажи без налога?

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

В конечном счете это проблема сценария оформления заказа. Готовая POS предлагает одинаковый сценарий для всех, но если вы каждую неделю продаете товары фермам, НКО, школам или перекупщикам, освобождение от налогов для вас — не редкое исключение, что бы там ни думал разработчик ПО. По этой же причине бутик не должен соглашаться на типовую серую сетку кнопок на кассе: рабочий процесс должен соответствовать бизнесу. На гибкой платформе вроде Final процесс оформления заказа — это сценарий, который вы описываете обычными словами, а не жестко заданный экран, поэтому нужный вашей кассе шаг можно заложить изначально, а не придумывать костыли.

Так почему же ваша POS заставляет вас убирать налог вручную?

Потому что налог в ней привязан к товару, а освобожденные от налога покупатели — к заказу. Ручное редактирование — лишь симптом, а причина — отсутствие нужного процесса. Золотое правило: если соблюдение законодательного требования требует более одного осознанного действия при оформлении заказа, у вас проблема с процессом, а не с обучением персонала. Если вы выбираете новую систему, добавьте пункт «покажите продажу без налога» в сценарий демонстрации, а после перехода воспользуйтесь чек-листом по настройке в первую неделю.