У звіті BAS або 1C з’явилася сума непідтвердженого ПДВ. Податкова накладна начебто є, суми в документах збігаються, а залишок не закривається. У такій ситуації легко вирішити, що програма «не бачить» документа. Проте найчастіше треба спочатку перевірити не підсумок, а весь ланцюжок операції.
Два стани однієї операції
Очікуваний ПДВ — це облікова передумова. Програма визначає її за господарською подією та параметрами первинного документа: оплатою, надходженням, реалізацією, ставкою ПДВ, видом операції, організацією, контрагентом і договором. Такий запис означає: за введеними даними має виникнути податковий кредит або зобов’язання, але документальне підтвердження ще не зіставлене з цією подією.
Підтверджений ПДВ виникає, коли в інформаційній базі належно зареєстровано податковий документ і він пов’язаний із потрібною операцією. Отже, рівність сум сама по собі недостатня. Для програми важливі також дата, вид операції та аналітичні ключі, за якими очікування має закритися підтвердженням.
Цей принцип однаковий для вхідного й вихідного ПДВ, хоча назви документів, звітів, рахунків та регістрів залежать від конфігурації і релізу. Історичну модель руху від первинного до податкового документа докладніше пояснює матеріал «Очікуваний і підтверджений ПДВ» навчального центру «Стимул». Для поточної бази назви об’єктів потрібно звіряти з її функціональністю та обліковою політикою.
Синтетичний кейс: сума правильна, аналітика різна
ТОВ «Ліхтар» 7 жовтня отримало від постачальника пакувальні матеріали на 72 000 грн, у тому числі ПДВ — 12 000 грн. У документі надходження вибрали договір «Поставка тари 2026». Програма відобразила 12 000 грн очікуваного вхідного ПДВ.
10 жовтня бухгалтер зареєструвала отриману податкову накладну на ті самі 72 000 грн. Однак документ створили з картки контрагента, де автоматично підставився основний договір «Загальний». У звіті одночасно залишилися 12 000 грн очікуваного ПДВ за одним договором і 12 000 грн підтвердженого — за іншим. Загальна сума виглядала правильно, але система не могла зіставити записи.
Перед виправленням бухгалтерка перевірила організацію, контрагента, ставку, дату першої події, документ-підставу та рухи обох документів. Після вибору правильного договору й контрольного перепроведення звіт показав узгоджений ланцюжок. Це була не помилка алгоритму, а різна аналітика в пов’язаних документах.
Важливий висновок: не варто одразу робити ручну операцію для «закриття» залишку. Вона може приховати причину й залишити неправильні дані в регістрах або майбутній звітності.
Практичний чекліст перед висновком про помилку
1. Уточніть симптом. Зафіксуйте звіт, період, відбір, суму й конкретний первинний документ. Формулювання «ПДВ не сходиться» недостатньо для діагностики.
2. Визначте першу подію. Перевірте хронологію оплати, надходження або реалізації та налаштування, за якими база визначає момент обліку ПДВ.
3. Звірте статуси документів. Документ може бути записаний, але не проведений, скасований, позначений на видалення або проведений до зміни реквізитів.
4. Порівняйте аналітику. Організація, контрагент, договір, документ розрахунків, підрозділ, ставка, вид операції та податкове призначення мають утворювати узгоджений набір.
5. Перевірте документ-підставу. Податкова накладна, створена окремо або на підставі іншої події, може сформувати підтвердження, але не закрити потрібне очікування.
6. Подивіться рухи. Порівняйте бухгалтерські проводки та записи регістрів обох документів. Важливі не лише суми, а й виміри, період та реєстратор.
7. Виключіть дубль. Пошукайте повторну накладну, коригування, повернення або повторне проведення того самого пакета документів.
8. Оновіть контрольний звіт. Скиньте збережені відбори, сформуйте його за вузьким періодом і деталізуйте до документа.
9. Відтворіть на копії. Якщо всі дані узгоджені, повторіть сценарій у тестовій копії та зафіксуйте реліз конфігурації, послідовність дій і очікуваний результат. Лише після цього є підстава описувати можливу програмну помилку.
Для звернення до консультанта або розробника підготуйте невеликий пакет доказів: скриншот звіту з розшифруванням, номери й дати документів, опис першої події, перелік перевірених реквізитів та рухи реєстраторів. Не передавайте повну базу без потреби й приховуйте персональні дані. Корисно додати контрольний приклад із тестової копії. Якщо після оновлення релізу поведінка змінилася, зазначте попередню й поточну версії та не перепроводьте масово документи до резервної копії й оцінки наслідків.
Самоперевірка
Чи доводить однакова сума очікуваного й підтвердженого ПДВ, що документи правильно пов’язані? Ні: аналітика й підстава можуть відрізнятися.
Чи треба прибирати залишок ручною проводкою до аналізу рухів? Ні: спочатку слід знайти розрив у документальному ланцюжку.
Коли доречно повідомляти про помилку BAS/1C? Коли коректний сценарій відтворюється на актуальній копії, вхідні дані й налаштування перевірені, а фактичний результат стабільно відрізняється від очікуваного.
Надія Антоненко, викладачка навчального центру «Стимул»
Written by
Nadiia AntonenkoInstructor in practical BAS/1C accounting at Stimul Training Centre1 pieceFollow Nadiia to see new posts in your feed, on your phone or by email.
