Часткова оплата в «Торгівлі з випискою рахунка»: як обрати режим чека ПРРО і виправити розбіжність сум

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

Що означає часткова оплата в Торгсофт

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

Для роботи з ПРРО важливо розрізняти кілька операцій:

• передоплата — покупець вносить частину коштів до остаточного розрахунку;

• чергова сплата — покупець вносить наступну частину;

• остаточний розрахунок — платіж закриває залишок суми;

• борг — частина вартості документа, яку покупець ще має сплатити;

• фіскалізація — передача сформованого розрахункового документа до фіскального сервера ДПС.

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

Яке правило діє для часткових оплат

Технічне налаштування Торгсофт визначає, як програма сформує чек. Обов’язок застосувати ПРРО визначає характер самої розрахункової операції. Закон №265 відносить до розрахункових операцій, зокрема, приймання готівки та розрахунки із застосуванням платіжної картки. 

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

Це роз’яснення ДПС повторно опубліковане 5 серпня 2026 року.

Окремий випадок — переказ покупцем коштів безпосередньо на поточний рахунок продавця за реквізитами IBAN. За умов, описаних ДПС, така операція може проводитися без РРО/ПРРО. Якщо після IBAN-передоплати відбувається розрахункова операція через ПРРО або передача товару, попередньо отриману суму потрібно врахувати у відповідному фіскальному чеку. 

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

Де налаштовується друк чека накладної

У Торгсофт параметр знаходиться в: Налаштування → Параметри → Чек → Друк чека накладної на ПРРО.

Для часткових оплат передбачені три сценарії:

Режим «На суму оплати»: коли клієнт платить частинами

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

Наприклад, сума замовлення становить 12 000 грн:

1. покупець сплачує 3 000 грн;

2. пізніше сплачує ще 4 000 грн;

3. останнім платежем вносить 5 000 грн.

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

У наступних чеках Торгсофт використовує фіскальний номер першого чека передоплати. Так ДПС може пов’язати розрахунки за однією господарською операцією. 

Що відбувається з товарами в чеку

Часткова оплата не означає, що одну фізичну одиницю товару потрібно штучно перетворювати, наприклад, на 0,25 одиниці.

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

Для першого авансу ДПС вимагає ідентифікувати, за який товар отримані кошти.

Що відбувається при остаточному розрахунку

ДПС окремо описує ситуацію, коли після попередніх авансів покупцю передають товар.

Фінальний чек має містити:

• повну номенклатуру товару;

• повну ціну;

• кількість;

• раніше отримані аванси (передоплати);

• суму, яка залишилась до сплати після врахування авансів.

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

Режим «На суму оплати і боргу»: чому з ним потрібно бути уважним

У цьому режимі Торгсофт дозволяє зафіксувати в чеку поточну оплату разом із залишком боргу. Для боргової частини оператор вказує відповідну форму та засіб оплати.

Наприклад:

• вартість накладної — 12 000 грн;

• покупець зараз вносить 3 000 грн;

• борг — 9 000 грн.

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

Саме звідси виникає часте питання: «Чому клієнт вніс залишок боргу, а програма вже не пропонує надрукувати чек?»

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

Коли цей режим не варто встановлювати як універсальний

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

Тому для схеми: 3 000 грн карткою зараз → 4 000 грн карткою через тиждень → 5 000 грн карткою при остаточному розрахунку режим, після якого Торгсофт більше не формує чек на наступні платежі, потребує зваженого рішення. Для звичайної послідовної оплати частинами логічно використовувати механізм передоплати → чергової сплати → остаточного розрахунку.

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

Отже, «На суму оплати і боргу» не слід обирати лише для того, щоб один раз закрити чек. Спочатку треба визначити спосіб майбутнього погашення боргу й момент передачі товару.

Режим «Запитати користувача»: коли в магазині є різні сценарії

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

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

Перед вибором касиру потрібно знати:

1. Чи передають товар покупцю зараз.

2. Чи були за цим документом попередні фіскальні чеки.

3. Скільки покупець фактично сплачує зараз.

4. Чи залишиться борг.

5. Як покупець погасить цей борг: готівкою, карткою або переказом на IBAN.

6. Чи потрібно буде формувати фіскальний чек на наступну оплату.

Сам режим «Запитати користувача» не визначає потрібний фіскальний сценарій автоматично. Касир обирає його відповідно до фактичної операції. Тому для такого налаштування доцільно встановити для працівників коротке внутрішнє правило.

Чому ДПС повертає «Підсумки по формах оплати не дорівнюють загальній сумі»

При частковій оплаті ПРРО повинен передати на сервер ДПС математично узгоджений фіскальний документ. У спрощеному вигляді всередині одного чека має виконуватися співвідношення: вартість товарних рядків з урахуванням знижок і коригувань → підсумок чека → суми за формами оплати.

Якщо ці частини документа дають різний результат, сервер ДПС може повернути: Код помилки: 9 DocumentValidationError і конкретне пояснення, наприклад:

Підсумки по формах оплати. Сума по рядкам … не дорівнює загальній сумі в документі … . Код 9 позначає клас відмови. Причину визначає текст після DocumentValidationError. У базі Торгсофт окремо зафіксовано, що розбіжність сум і часткові оплати належать до типових причин такого повідомлення.

Звідки може взятися різниця в одну копійку

Для часткових оплат потрібно перевірити кілька джерел розбіжності.

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

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

 Фіскальні та нефіскальні позиції. Якщо рахунок містить обидва типи товарів, Торгсофт розподіляє передоплату між ними пропорційно. До ПРРО передається лише фіскальна частина. На межі округлення може виникнути різниця.

 Кілька ФОП або підприємств. Коли одна реалізація ділиться між різними підприємствами та ПРРО, загальний платіж також потрібно розподілити. Особливо уважно слід перевіряти змішані оплати, знижки й округлення.

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

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

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

Що робити при DocumentValidationError із розбіжністю сум

1. Додати весь текст помилки після коду 9

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

Якщо після коду вказані КЕП, адреса торгової точки, XML, позначка часу або інший параметр, причина інша.

2. Перевірте, чи зареєстрований чек у ДПС

Перед повторною фіскалізацією з’ясуйте статус документа.

Перевірте:

• чи присвоєно чеку фіскальний номер;

• чи є він у Аналітиці ПРРО;

• чи отримав Торгсофт відповідь сервера ДПС.

Цей крок потрібний, щоб повторно не зареєструвати операцію, яку ДПС уже прийняла.

3. Звірте чотири суми

Для накладної перевірте: сума документа → попередні оплати → поточна оплата → залишок боргу.

Наприклад:

• документ — 12 000 грн;

• раніше сплачено — 3 000 грн;

• зараз сплачено — 4 000 грн;

• залишок — 5 000 грн.

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

4. Перевірте режим, за яким сформовано чек

При «На суму оплати» поточний чек має відповідати поточному етапу розрахунку.

При «На суму оплати і боргу» перевірте, чи не був документ уже фіскально завершений із борговою частиною.

При «Запитати користувача» з’ясуйте, що саме вибрав касир під час формування цього чека.

5. Перевірте знижки, округлення та дробову кількість

Особливо це потрібно зробити, якщо різниця становить 0,01 грн або кілька копійок.

Не коригуйте випадковий товар на одну копійку вручну лише для проходження перевірки ДПС. Спочатку треба визначити джерело розбіжності.

6. Перевірте форми та засоби оплати

У розрахунковому документі форма оплати та сума за нею належать до обов’язкових реквізитів. Вимоги до форми й змісту фіскального чека встановлені Положенням №13. 

Порівняйте фактичний спосіб розрахунку з тим, що передається до ПРРО:

• готівка;

• картка через еквайринг;

• інший безготівковий розрахунок;

• кредит або борг, якщо він використовується у конкретному сценарії;

• прямий переказ за реквізитами IBAN.

7. Якщо є кілька підприємств, перевірте розподіл

Переконайтеся, що:

• товар належить потрібному підприємству;

• для нього використовується потрібний ПРРО;

• поточна оплата правильно розподілена між підприємствами;

• після розподілу суми всіх чеків відповідають загальному платежу.

8. Перевірте версію Торгсофт

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

Чи можна змінити накладну після друку фіскального чека

Зареєстрований чек уже існує на стороні ДПС. Зміна даних у Торгсофт сама по собі його не скасовує.

Тому після фіскалізації не варто:

• видаляти проведену оплату для повторного введення;

• змінювати суму або склад документа без перевірки наслідків;

• повторно відправляти ту саму операцію, поки невідомий статус першого чека;

• створювати ручне коригування на одну копійку для узгодження підсумків.

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

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

Що обрати для типових сценаріїв

Що передати технічній підтримці, якщо суми не сходяться

Щоб фахівець міг відтворити ситуацію, підготуйте:

1. Повний текст відповіді ДПС після DocumentValidationError.

2. Дату й приблизний час формування чека.

3. Суму рахунка або видаткової накладної.

4. Суму всіх попередніх оплат.

5. Суму поточного платежу та залишок боргу.

6. Обраний режим: «На суму оплати», «На суму оплати і боргу» чи «Запитати користувача».

7. Спосіб кожного платежу: готівка, картка, IBAN.

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

9. Інформацію про кілька ФОП, якщо реалізація розділяється між підприємствами.

10. Версію Торгсофт.

11. Фіскальний номер попереднього чека, якщо він уже існує.

Пароль до КЕП та інші секретні дані для такої діагностики не потрібні.

Коротке правило для роботи з частковою оплатою

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

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

Головне при розбіжності сум — спочатку перевірити статус уже сформованого чека, потім звірити документ, попередні оплати, поточний платіж, борг і форми оплати. Повторна фіскалізація без цієї перевірки може створити вже іншу проблему.