Чому моя POS змушує мене вручну вилучати податок для кожного продажу без податку?

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

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

Чому моя POS вважає звільнення від податків поодиноким випадком?

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

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

Скільки насправді коштує вам вилучення податку вручну?

Більше, ніж тридцять секунд на транзакцію, хоча секунди під час розрахунку також накопичуються. Реальні витрати:

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

• Помилки кількох ставок. Кошики з кількома податковими ставками або складними ставками (податок, що нараховується поверх іншого податку) легко зіпсувати під час ручного редагування.

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

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

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

Які обхідні рішення дійсно допомагають сьогодні?

Три речі, у порядку корисності.

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

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

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

Як натомість POS має обробляти продажі без податку?

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

Урешті-решт, це проблема процесу розрахунку. Фіксована POS надає один шаблон для всіх, і якщо ви щотижня продаєте фермам, неприбутковим організаціям, школам або дистриб'юторам, звільнення від податку не є поодиноким випадком у вашому бізнесі, що б про це не думав розробник. З цієї ж причини бутік не повинен погоджуватися на типову сіру сітку на касі: робочий процес має відповідати бізнесу. На гнучкій платформі, такій як Final, розрахунок — це процес, який ви описуєте простою мовою, а не зафіксований екран, тому потрібний касі крок може бути частиною дизайну, а не «костилем», прикрученим пізніше.

Тож чому ваша POS змушує вилучати податок вручну?

Тому що вона моделює податок на рівні товару, а ваші покупці із пільгами знаходяться на рівні замовлення. Ручне редагування — це симптом; відсутність потрібного процесу — це причина. Практичне правило: якщо юридична вимога потребує більше ніж одного свідомого кроку під час розрахунку, у вас проблема з робочим процесом, а не з навчанням. Якщо ви оцінюєте нову систему, додайте пункт «покажіть мені продаж без податку» до свого демо-сценарію, а після переходу скористайтеся контрольним списком налаштувань на перший тиждень.