Рахунок на оплату 1С

Рахунок на оплату 1С — це документ у 1С / BAS, який використовується для виставлення покупцю суми до оплати за товари, продукцію, роботи або послуги. У практиці його часто називають рахунок покупцю, рахунок клієнту або просто рахунок.

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

Санкційне застереження щодо 1С/BAS. Програмні продукти 1С та окремі рішення BAS пов’язані з російським походженням програмної платформи та можуть підпадати під санкційні, регуляторні, кібербезпекові або закупівельні обмеження в Україні. Перед використанням, супроводом, закупівлею, оновленням або інтеграцією 1С/BAS потрібно перевіряти чинні рішення РНБО, укази Президента України, перелік забороненого програмного забезпечення Держспецзв’язку, вимоги для державного сектору, критичної інфраструктури та внутрішні політики інформаційної безпеки компанії.

K2 ERP. K2 ERP може приймати й аналізувати рахунки на оплату з 1С/BAS: клієнтів, договори, товари, послуги, ціни, знижки, ПДВ, статуси оплат, банківські виписки, замовлення, реалізації, дебіторку, менеджерів, Power BI, AI та API.

Головна ідея. Рахунок на оплату 1С — це міст між продажем і грошима. Якщо рахунок виставлений правильно, менеджер бачить очікувану оплату, бухгалтерія — майбутній платіж, склад — потенційне відвантаження, а керівник — прогноз Cash Flow.

Що таке рахунок на оплату 1С

Рахунок на оплату 1С — це документ, який компанія виставляє покупцю для оплати товарів, робіт або послуг.

У рахунку зазвичай зазначається:

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

Простий приклад

Клієнт хоче купити 10 офісних крісел і 5 столів.

Менеджер створює в 1С рахунок на оплату:

Товар	Кількість	Ціна	Сума
Крісло офісне	10 шт	3 000 грн	30 000 грн
Стіл офісний	5 шт	5 000 грн	25 000 грн
Разом			55 000 грн

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

Для чого потрібен рахунок на оплату

Рахунок на оплату потрібен, щоб:

зафіксувати домовленість із клієнтом;
передати клієнту суму й реквізити для оплати;
зарезервувати товар;
запланувати майбутнє надходження грошей;
контролювати оплату;
зв’язати оплату з продажем;
бачити неоплачені рахунки;
формувати прогноз Cash Flow;
створити реалізацію на підставі рахунку;
передати рахунок у CRM, сайт або особистий кабінет клієнта;
перенести історію рахунків у K2 ERP.

Рахунок на оплату і реалізація

Рахунок на оплату і реалізація — це різні документи.

Документ	Що означає	Приклад
Рахунок на оплату	клієнту виставили суму до оплати	“Оплатіть 55 000 грн за меблі”
Реалізація товарів	товар фактично продано або відвантажено	“Меблі передані клієнту”
Банківська виписка	гроші фактично зайшли на рахунок	“Клієнт оплатив 55 000 грн”

У багатьох компаніях процес виглядає так:

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

Живий приклад: рахунок є, грошей немає

Менеджер виставив клієнту рахунок на 120 000 грн.

Клієнт пообіцяв оплатити “завтра”, але не оплатив.

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

У правильній ERP рахунок має статус:

виставлено;
очікує оплату;
прострочено;
частково оплачено;
оплачено;
скасовано;
відвантажено.

Так керівник бачить не просто “план продажів”, а реальний стан оплати.

Основні статуси рахунку

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

Рахунок покупцю 1С

У багатьох конфігураціях документ називається Рахунок покупцю 1С.

Він використовується для:

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

Таблична частина рахунку

Основна деталізація рахунку знаходиться в табличній частині.

Колонка	Що означає
Номенклатура	товар, продукція, робота або послуга
Кількість	скільки клієнт має оплатити
Одиниця виміру	шт, кг, м, год, послуга, комплект
Ціна	ціна за одиницю
Знижка	індивідуальна або акційна знижка
Сума	кількість × ціна мінус знижка
ПДВ	ставка і сума податку
Склад	звідки планується відвантаження
Замовлення	зв’язок із замовленням клієнта
Коментар	уточнення для клієнта або менеджера

Приклад табличної частини

Номенклатура	Кількість	Ціна	Знижка	Сума
Ноутбук X15	3 шт	32 000 грн	5%	91 200 грн
Миша бездротова	3 шт	800 грн	0%	2 400 грн
Налаштування робочого місця	3 посл.	1 200 грн	0%	3 600 грн
Разом				97 200 грн

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

Рахунок і резерв товару

У деяких компаніях рахунок на оплату резервує товар.

Приклад:

на складі є 10 ноутбуків;
клієнту виставили рахунок на 3 ноутбуки;
система резервує 3 шт;
доступний залишок для інших клієнтів стає 7 шт.

Показник	Кількість
Фактичний залишок	10 шт
Резерв по рахунку	3 шт
Доступний залишок	7 шт

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

Живий приклад: рахунок без резерву

Менеджер виставив клієнту рахунок на 5 генераторів.

Товар не зарезервувався.

Через годину інший менеджер продав ці ж 5 генераторів іншому клієнту.

Перший клієнт оплатив рахунок, але товару вже немає.

Наслідки:

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

У K2 ERP таку ситуацію можна вирішити правилами резервування: резерв після рахунку, після замовлення, після передоплати або після погодження менеджером.

Рахунок і часткова оплата

Клієнт може оплатити рахунок частково.

Приклад:

Рахунок на 100 000 грн.

Клієнт оплатив 40 000 грн.

Показник	Сума
Сума рахунку	100 000 грн
Оплачено	40 000 грн
Залишок до оплати	60 000 грн

У системі рахунок має отримати статус “частково оплачено”, а менеджер має бачити залишок.

Рахунок і передоплата

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

Приклади:

100% передоплата перед відвантаженням;
50% передоплата і 50% після виконання робіт;
передоплата за матеріали;
аванс за виробництво під замовлення;
передоплата за бронювання товару.

Умова	Приклад	Ризик
100% передоплата	клієнт платить усе до відвантаження	затримка відвантаження після оплати
50/50	половина до старту, половина після готовності	потрібно контролювати другу оплату
Оплата після відвантаження	клієнт платить пізніше	виникає дебіторка

Рахунок і банківська виписка

Банківська виписка 1С фіксує факт оплати рахунку.

Приклад:

У рахунку вказано:

клієнт — ТОВ “Клієнт A”;
сума — 75 000 грн;
рахунок №302.

У банківській виписці приходить платіж:

платник — ТОВ “Клієнт A”;
призначення — “Оплата за рахунком №302”;
сума — 75 000 грн.

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

Живий приклад: клієнт оплатив не той рахунок

У клієнта є два рахунки:

рахунок №101 на 30 000 грн;
рахунок №102 на 45 000 грн.

Клієнт оплатив 45 000 грн, але в призначенні написав “рахунок №101”.

Бухгалтерія автоматично прив’язала оплату до рахунку №101.

Наслідки:

рахунок №101 переплачений;
рахунок №102 залишився неоплаченим;
менеджер бачить неправильний статус;
склад може відвантажити не те замовлення.

Тому автоматичне розпізнавання платежів потрібно перевіряти, особливо якщо сума або призначення не збігаються.

Рахунок і дебіторка

Дебіторка 1С може виникати після реалізації, якщо клієнт ще не оплатив.

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

Ланцюжок може бути таким:

Рахунок виставлено.
Клієнт оплатив.
Реалізація створена.
Дебіторка не виникла, бо була передоплата.

Або інший варіант:

Рахунок виставлено.
Товар відвантажено.
Реалізація створена.
Клієнт ще не оплатив.
Виникла дебіторка.

Рахунок і замовлення клієнта

У деяких компаніях рахунок створюється на підставі замовлення клієнта 1С.

Приклад:

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

Етап	Документ	Що фіксує
Потреба клієнта	Замовлення клієнта	що клієнт хоче купити
Сума до оплати	Рахунок на оплату	скільки клієнт має оплатити
Факт відвантаження	Реалізація	що фактично передали клієнту
Факт оплати	Банківська виписка	які гроші фактично зайшли

Рахунок і ціни

У рахунку важливо правильно визначити ціну.

Ціна може залежати від:

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

Рахунок і знижки

Знижка в рахунку може бути:

ручна;
автоматична;
за договором;
за обсяг;
акційна;
партнерська;
погоджена керівником;
промокод;
компенсаційна.

Живий приклад:

Менеджер випадково поставив знижку 50% замість 5%.

Клієнт швидко оплатив рахунок.

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

У K2 ERP AI може підказати: “Знижка в 10 разів більша за типову для цього клієнта”.

Рахунок і ПДВ

У рахунку потрібно правильно відображати ПДВ.

Потрібно перевірити:

ставка ПДВ;
сума ПДВ;
ціна з ПДВ або без ПДВ;
статус платника ПДВ;
тип операції;
експорт або імпорт;
пільгові операції;
дата першої події;
зв’язок із податковими документами.

Помилка в ПДВ у рахунку може перейти в реалізацію, податкові документи і звітність.

Рахунок і валюта

Рахунок може бути в гривні або валюті.

Для валютного рахунку важливо:

валюта;
курс;
дата курсу;
сума у валюті;
сума в гривні;
умови перерахунку;
курс на дату оплати;
курсові різниці;
договір у валюті.

Рахунок і друкована форма

Друкована форма рахунку зазвичай містить:

назву продавця;
реквізити продавця;
банківський рахунок;
дані покупця;
номер і дату рахунку;
договір;
перелік товарів або послуг;
кількість;
ціну;
суму;
ПДВ;
загальну суму;
строк оплати;
підпис або печатку;
QR-код або платіжні реквізити.

У сучасній ERP рахунок можна відправляти клієнту як PDF, посилання, email або через особистий кабінет.

Типові проводки

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

Проводки зазвичай виникають пізніше:

Подія	Приклад проводки	Що означає
Оплата від покупця	Дт 311 Кт 681 / 361	гроші надійшли на рахунок
Реалізація товарів	Дт 361 Кт 702	відображено дохід і дебіторку
Списання собівартості	Дт 902 Кт 281	списано собівартість товару
Залік передоплати	Дт 681 Кт 361	передоплата закриває борг по реалізації

У конкретній базі проводки залежать від конфігурації, облікової політики й налаштувань рахунків.

Рахунок і Cash Flow

Рахунок на оплату допомагає прогнозувати Cash Flow.

Приклад:

Рахунок	Клієнт	Сума	Очікувана дата оплати	Статус
№501	ТОВ “Клієнт A”	80 000 грн	15.03.2026	очікується
№502	ТОВ “Клієнт B”	120 000 грн	18.03.2026	частково оплачено
№503	ТОВ “Клієнт C”	45 000 грн	10.03.2026	прострочено

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

Рахунок і P&L

Рахунок сам по собі зазвичай не є доходом у P&L.

P&L формується після факту реалізації або виконання послуг.

Приклад:

рахунок виставлено на 100 000 грн;
клієнт ще не оплатив;
товар ще не відвантажений;
у P&L доходу ще може не бути.

Тому важливо не плутати:

сума рахунків — потенційні продажі;
оплати — рух грошей;
реалізації — дохід;
собівартість — витрати продажу.

Рахунок і CRM

У CRM рахунок може бути частиною воронки продажів.

Сценарій:

Лід звернувся.
Менеджер створив угоду.
Погодили комерційну пропозицію.
Створили рахунок.
Клієнт оплатив.
Склад відвантажив товар.
Угода закрита.

У K2 ERP рахунок може бути пов’язаний із CRM, менеджером, каналом продажу, джерелом ліда й прогнозом виручки.

Рахунок і сайт / маркетплейс

Для інтернет-магазину рахунок може формуватися автоматично.

Приклад:

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

Типові помилки рахунків на оплату 1С

Помилка	Наслідок	Як перевірити
Неправильний клієнт	оплата або відвантаження потрапляє не тому контрагенту	звірити ЄДРПОУ, назву і договір
Неправильний договір	оплата не закриває потрібний рахунок	перевірити договір у рахунку і банківській виписці
Неправильна ціна	клієнт платить не ту суму або маржа спотворюється	звірити прайс, знижки й умови договору
Неправильна знижка	продаж може стати збитковим	контролювати знижки понад ліміт
Неправильний ПДВ	помилки в реалізації і податковому обліку	перевірити ставку й суму ПДВ
Рахунок не пов’язаний із оплатою	статус рахунку не оновлюється	звірити банківську виписку
Рахунок не скасували	прогноз Cash Flow завищений	закривати неактуальні рахунки

Живий приклад: старі рахунки завищують прогноз

Компанія має 300 виставлених рахунків у 1С.

З них:

120 уже оплачені;
80 скасовані усно, але не закриті в системі;
50 прострочені більше 90 днів;
50 реально очікують оплату.

Якщо всі 300 рахунків потрапляють у прогноз Cash Flow, керівник бачить завищені майбутні надходження.

Правильний підхід — використовувати статуси рахунків і не враховувати скасовані або безнадійні рахунки в прогнозі.

Як перевірити рахунок на оплату

Перед відправкою клієнту потрібно перевірити:

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

Рахунок перед міграцією в ERP

Під час переходу з 1С/BAS у K2 ERP потрібно вирішити, які рахунки переносити.

Можливі варіанти:

Варіант	Що переноситься	Коли підходить
Тільки відкриті рахунки	рахунки, які ще не оплачені або не відвантажені	для коректного старту продажів
Поточний рік	рахунки поточного року	для аналітики продажів і оплат
Повна історія	всі рахунки за кілька років	для CRM, аудиту, історії клієнтів
Агреговані дані	підсумки по клієнтах і періодах	якщо деталізація рахунків не потрібна
Не переносити рахунки	переносити тільки замовлення, реалізації й залишки боргів	якщо рахунки не використовуються як процес

Завантаження рахунків у K2 ERP

Завантаження даних 1С для рахунків на оплату може включати:

номер рахунку;
дату;
покупця;
договір;
організацію;
менеджера;
банківські реквізити;
статус;
строк оплати;
номенклатуру;
кількість;
ціну;
знижку;
суму;
ПДВ;
валюту;
склад;
замовлення;
оплату;
залишок до оплати;
коментар.

Мапінг рахунку 1С і K2 ERP

Поле 1С	Поле K2 ERP	Коментар
Номер	Номер рахунку	потрібен для звірки з клієнтом
Дата	Дата рахунку	важлива для строку оплати
Контрагент	Покупець	потрібен мапінг контрагентів
Договор	Договір	важливо для оплат і дебіторки
Номенклатура	Товар / послуга	потрібен мапінг номенклатури
Количество	Кількість	перевірити одиниці виміру
Цена	Ціна	перевірити валюту, ПДВ і знижки
Сумма	Сума рахунку	звірити з друкованою формою
Статус	Статус рахунку	виставлено, оплачено, скасовано, прострочено
Менеджер	Відповідальний менеджер	потрібен для CRM і KPI

Обмін рахунками 1С і ERP

Обмін даними 1С може передавати рахунки між 1С, K2 ERP, CRM, сайтом, маркетплейсом, банком, особистим кабінетом або Power BI.

Обмін може включати:

створення рахунку;
друковану форму PDF;
статус відправки клієнту;
статус оплати;
часткові оплати;
скасування рахунку;
зв’язок із замовленням;
зв’язок із реалізацією;
резерв товару;
посилання на оплату;
повідомлення менеджеру.

Рахунок і API

API ERP може автоматизувати роботу з рахунками.

Через API можна:

створювати рахунок із CRM;
створювати рахунок із сайту;
отримувати статус оплати;
передавати рахунок клієнту;
формувати PDF;
оновлювати суму або позиції;
скасовувати рахунок;
зв’язувати рахунок із банківською оплатою;
передавати дані в Power BI;
запускати AI-перевірку знижок і маржі.

Power BI для рахунків на оплату

Power BI може аналізувати рахунки на оплату.

Можна бачити:

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

AI для аналізу рахунків

AI в ERP може допомагати перевіряти рахунки й прогнозувати оплату.

AI може:

знаходити рахунки з нетиповими знижками;
виявляти рахунки нижче мінімальної маржі;
знаходити прострочені рахунки;
прогнозувати ймовірність оплати;
підказувати менеджеру, кому нагадати про оплату;
знаходити рахунки без резерву;
знаходити рахунки без договору;
звіряти оплату з банківською випискою;
пояснювати, чому Cash Flow не виконується;
формувати короткий звіт для керівника продажів.

Приклад AI-підказки

AI-підказка. За останні 10 днів виставлено 48 рахунків на суму 2,4 млн грн. 11 рахунків уже прострочені, 5 рахунків мають знижку понад 20%, а 3 рахунки виставлені без резерву товару. Рекомендується перевірити рахунки №458, №462 і №471 перед відвантаженням.

Типові задачі з рахунками

Задача	Що потрібно зробити
Виставити рахунок клієнту	створити документ із товарами, цінами, ПДВ і реквізитами
Перевірити оплату	звірити рахунок із банківською випискою
Частково оплатити рахунок	відобразити часткову оплату і залишок
Зарезервувати товар	зв’язати рахунок із резервом або замовленням
Створити реалізацію	створити реалізацію на підставі рахунку
Підготувати міграцію	вивантажити рахунки, рядки, клієнтів, статуси й оплати

Що не варто переносити без перевірки

У нову ERP не варто автоматично переносити:

скасовані старі рахунки;
дублікати рахунків;
рахунки без контрагента;
рахунки без договору;
рахунки без статусу;
рахунки з неправильними оплатами;
рахунки з помилковими знижками;
рахунки з неправильним ПДВ;
рахунки без зв’язку з реалізацією;
рахунки, які не мають бізнес-цінності.

Контрольний список перед переходом з 1С

Перед перенесенням рахунків у K2 ERP потрібно перевірити:

період міграції;
відкриті рахунки;
оплачені рахунки;
частково оплачені рахунки;
скасовані рахунки;
покупців;
договори;
номенклатуру;
одиниці виміру;
ціни;
знижки;
ПДВ;
валюти;
менеджерів;
статуси;
зв’язок із оплатами;
зв’язок із реалізаціями;
резерви;
тестове завантаження.

Мінімальний старт у ERP

Перший етап:

відкриті рахунки;
покупці;
договори;
товари й послуги;
суми;
статуси оплат;
залишок до оплати;
базові друковані форми.

Другий етап:

резерви;
часткові оплати;
зв’язок із банківською випискою;
зв’язок із замовленнями;
зв’язок із реалізаціями;
Power BI;
прогноз Cash Flow.

Третій етап:

AI-аналіз рахунків;
прогноз імовірності оплати;
автоматичні нагадування;
контроль знижок;
контроль маржі;
API-обмін із CRM і сайтом;
повна заміна 1С/BAS.

Коротко

Питання	Відповідь
Що таке рахунок на оплату 1С?	Це документ, який компанія виставляє покупцю для оплати товарів, робіт або послуг.
Чи є рахунок фактом продажу?	Не завжди. Рахунок зазвичай фіксує суму до оплати, а факт продажу підтверджує реалізація або акт.
Які дані найважливіші?	Покупець, договір, товари або послуги, кількість, ціна, знижка, ПДВ, сума, строк оплати, менеджер, статус і зв’язок з оплатою.
Які типові помилки?	Неправильний клієнт, неправильний договір, помилкова ціна, неправильна знижка, неправильний ПДВ, рахунок без статусу або без зв’язку з оплатою.
Чи можна перенести рахунки з 1С у K2 ERP?	Так. K2 ERP може приймати рахунки з 1С/BAS разом із рядками, клієнтами, договорами, цінами, знижками, ПДВ, статусами, оплатами, резервами й реалізаціями.

Висновок

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

K2 ERP може використовувати дані рахунків на оплату під час переходу з 1С/BAS: для продажів, CRM, резервів, оплат, Cash Flow, дебіторки, Power BI, AI, API та управлінської аналітики.

Правильна міграція рахунків — це не просто перенесення номерів і сум. Потрібно перенести покупців, договори, рядки товарів і послуг, ціни, знижки, ПДВ, статуси, строки оплати, менеджерів, зв’язок із оплатами, реалізаціями й резервами. Саме ці дані дозволяють у новій ERP бачити, які рахунки реально очікують оплату, які прострочені, які вже оплачені, а які треба скасувати.

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

Див. також

Зовнішні посилання