Карткову оплату провели як готівку в Торгсофт: як виправити тип оплати та звірити ПРРО

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

Як карткова оплата має проходити в Торгсофт

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

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

Тобто одна карткова покупка створює пов’язані записи у трьох системах:

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

Спочатку перевірте POS, Торгсофт і ПРРО

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

У банківському терміналі або банківському звіті перевірте суму, час і результат транзакції. Потрібно переконатися, що карткова оплата справді відбулася. Збережіть сліп-чек або дані операції, якщо вони доступні.

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

Потім відкрийте «Налаштування → Програмний РРО → Аналітика за програмним РРО» та знайдіть відповідний фіскальний чек. Подивіться, яка форма оплати зареєстрована в ньому.

Після цієї перевірки можливі два принципово різні випадки.

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

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

Потрібно виправити тільки фінансову частину в Торгсофт:

1. Знайти реалізацію, яка має неправильну готівкову оплату.

2. Перепровести оплату по цій реалізації як безготівкову.

3. Вказати правильний розрахунковий рахунок.

4. Перевірити, що сума більше не враховується в готівковій касі.

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

Для підприємця тут важливий результат: сама реалізація товару не створюється повторно. Товар уже продано і списано зі складу. Змінюється фінансове відображення оплати.

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

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

Це вже інша ситуація. Банк зафіксував карткову операцію, але до фіскального сервера пішов чек із неправильною формою оплати.

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

ДПС прямо розглядає випадки, коли в РРО або ПРРО неправильно вибрано форму оплати — наприклад, «готівка» замість «картки». Під час такого виправлення складається акт із даними про суму та реквізитами початкового розрахункового документа. Акт потрібно зберігати три роки. 

Подальші дії залежать від того, чи є неправильний чек останнім у поточній зміні.

Якщо неправильний чек останній і зміна ПРРО ще відкрита

Торгсофт підтримує сторнування останнього розрахункового чека ПРРО. Команда доступна у формі «Програмний РРО» в групі «Операції з чеками», а також із форми реалізації. Сторнувати довільний старий чек не можна: операція доступна тільки для останнього зареєстрованого розрахункового документа. Після сторнування чек не враховується в X- і Z-звітах та втрачає ознаку фіскальності.

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

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

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

Картку вдруге проводити не потрібно

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

Торгсофт дозволяє провести безготівкову оплату на розрахунковий рахунок без звернення до термінала: для цього не використовується перемикач «Використовувати зв’язок із банківським терміналом».

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

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

Якщо після неправильного чека вже пробили інші чеки

Сторнування такого чека вже недоступне.

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

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

Для виправлення форми оплати це означає дві послідовні облікові операції.

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

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

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

Чому товар у такому випадку не списується двічі

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

Якщо для коригування фіскального чека доводиться використовувати повернення та новий продаж, рух товару виглядає так: первинний продаж: −1 → повернення: +1 → правильний продаж: −1. Кінцевий результат на складі відповідає одному фактичному продажу.

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

Чи потрібно робити банківське повернення на картку

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

Тут існують дві різні операції:

• фіскальне коригування неправильного чека;

• фактичне повернення грошей покупцеві банком.

Друге потрібне тільки тоді, коли магазин справді повертає покупцеві кошти.

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

Що робити, якщо Z-звіт уже сформовано

Це критична межа для фіскального виправлення.

ДПС у роз’ясненні від 5 травня 2026 року прямо зазначає: після створення щоденного Z-звіту та закриття робочої зміни законодавство не передбачає механізму скасування наступного робочого дня помилково проведеної через РРО або ПРРО суми.

Тому не потрібно наступного дня відкривати нову зміну і самостійно створювати «компенсуючий» чек за вчорашню операцію.

Якщо форма оплати була неправильною та Z-звіт уже сформовано, збережіть:

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

• підтвердження карткової транзакції;

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

• дані Торгсофт, за якими видно розбіжність.

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

Як зрозуміти, що все виправлено правильно

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

Для прикладу покупець придбав товар на 1 200 грн карткою.

До виправлення Торгсофт міг показувати +1 200 грн у готівковій касі, хоча фізично цих грошей там немає. POS показує +1 200 грн карткової оплати.

Після коригування:

• товар залишається проданим в одному екземплярі;

• у готівковій касі немає цих 1 200 грн;

• у Торгсофт 1 200 грн віднесено на відповідний розрахунковий рахунок;

• у банку залишається одна транзакція на 1 200 грн;

• у ПРРО форма оплати відповідає фактичному розрахунку.

Для перевірки порівняйте «Аналітику за програмним РРО», дані каси в Торгсофт і звіт банківського термінала. У реальних зверненнях технічна підтримка саме через зіставлення внутрішніх і фіскальних даних визначає, який контур потребує коригування.

Чого не потрібно робити

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

 Не проводьте картку покупця вдруге, якщо POS підтверджує першу транзакцію.

 Не робіть реальне повернення коштів на картку, якщо покупка не скасовується.

 Не створюйте другу реалізацію без розуміння, що сталося з першою: це може змінити залишки товару.

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

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

Як запобігти неправильному відображенню карткової оплати

Насамперед використовуйте актуальну версію Торгсофт.

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

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

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

Коротко: що робити, якщо картка пройшла, а Торгсофт показує готівку

Спочатку перевірте фіскальний чек.

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

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

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

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