Помилку в запостованій проводці вже не виправиш простим редагуванням — потрібен окремий запис, який її нейтралізує. В Odoo для цього є два шляхи: Reverse Entry (типовий з 2018 року) і класичне червоне сторно з мінусом. Тут ви навчитеся робити обидва і, головне, свідомо обирати між ними — бо від вибору залежить, чи побачить аудитор рух по рахунку в звітах, чи його ніби й не було.
Результат
Помилкова проводка нейтралізована в обліку правильним способом для вашого контексту: або через Reverse Entry (типовий шлях в Odoo, у звітах видно обидві проводки), або через червоне сторно (мінусовий запис, який «затирає» обороти). Ви розумієте різницю і свідомо обираєте, який інструмент застосовувати.
Передумови
- Помилкова проводка вже запостована (інакше виправлення не потрібне — просто редагуєте чорновик).
- Ви знаєте, у чому саме помилка: не та сума, не той рахунок, не той партнер, не та дата.
- Розумієте різницю між Дт/Кт і вмієте читати
account.move— гайд Читати account.move. - З погляду нормативки — є акт або довідка-розрахунок, що фіксує помилку і її виправлення.
Як це зробити
Варіант А: Reverse Entry (типовий)
Це шлях, який Odoo пропонує за замовчуванням і радить для більшості випадків з 2018 року.
-
Знайдіть помилкову проводку. Меню: Accounting → Accounting → Journal Entries. Відкрийте її. Зверніть увагу, що проводка у статусі Posted.
-
Натисніть кнопку Reverse Entry. Вона є у верхньому меню документа (іноді під трьома крапками «Actions» або «Дії»). Відкривається діалог-візард
account.move.reversal. -
Заповніть діалог.
- Reason — причина сторно. Це обов’язкове поле для аудиторського сліду: «Помилка в сумі — виявлено при звірці з банком», «Перенесли витрати з контракту А-1234 на А-5678 за рішенням комісії».
- Reversal Date — дата зворотної проводки. Тут є два сценарії:
- Поточна дата — якщо помилка свіжа, ще не закрили місяць. Це найчастіший випадок.
- Дата оригіналу — якщо хочете вдати, що помилки взагалі не було. Допустимо тільки якщо місяць ще відкритий і ви точно не вплинули на звіт, що вже пішов.
- Refund Method (для інвойсів) —
Create a draft refund(зробити чорновик-«мінус» для редагування) абоCancel: Create a refund and reconcile(одразу повна нейтралізація).
-
Натисніть Reverse. Odoo створює нову окрему проводку з протилежними знаками: те, що було в Дт, тепер у Кт, і навпаки. Сума додатна, не мінусова.
-
Знайдіть зв’язок між проводками. На оригінальному записі з’явилося поле Reversed By (з посиланням на нову проводку). На новій — поле Reversed Entry (з посиланням на оригінал). Ці поля гарантують аудиторський слід: за роки ніхто не «загубить», звідки взялася зворотна проводка.
| Рахунок | Опис | Дебет | Кредит |
|---|---|---|---|
| 91 Загальновиробничі | Реверс MISC/2026/05/0042 | — | 5 000,00 |
| 631 Розрахунки з постачальниками | Реверс MISC/2026/05/0042 | 5 000,00 | — |
| Разом | 5 000,00 | 5 000,00 |
-
Зробіть правильну проводку. Якщо помилка була не «викинути зайве», а «треба було по-іншому» — створіть нову правильну проводку (через New → Miscellaneous). Тепер у звітах буде три записи: оригінал (помилковий), його реверс (компенсація) і нова правильна.
У General Ledger це виглядатиме так:
- Рядок 1: оригінал, Дт 91 — 5 000 ₴
- Рядок 2: реверс, Кт 91 — 5 000 ₴
- Рядок 3: правильний, Дт 92 — 5 000 ₴
Сальдо рахунку 91 = 0 (помилку нейтралізували), сальдо 92 = 5 000 ₴ (правильна витрата). А в Trial Balance по рахунку 91 буде оборот 5 000 у Дт і 5 000 у Кт. Цей оборот видно — ось ключова відмінність від червоного сторно.
Варіант Б: червоне сторно (мінусовий запис)
Класичний радянсько-український прийом, успадкований з 1С: замість зворотного запису робимо такий самий, але з мінусом. На той же бік (Дт), на той же рахунок, тільки сума від’ємна.
-
Створіть нову проводку в журналі Miscellaneous. New → виберіть журнал Miscellaneous Operations.
-
Поставте дату. Як правило — поточну, з посиланням у Reference на оригінал: «Сторно проводки MISC/2026/05/0042».
-
Введіть рядки з тими самими рахунками і сторонами, але з мінусовими сумами. Замість Дт 91 = 5 000 пишете Дт 91 = -5 000. Сторнувальний рядок Кт теж з мінусом.
Технічно: на рядку в полі Debit ви вказуєте від’ємне число
-5000. Odoo це дозволяє, але показуватиме сумне обличчя — попередження «суми мають бути додатні». -
Запостіть. Документ зайде в облік як від’ємний рух. У звітах це працює так: оборот по Дт 91 за період зменшиться на 5 000 ₴, ніби помилкової проводки не було.
У General Ledger це виглядатиме інакше, ніж при Reverse:
- Рядок 1: оригінал, Дт 91 = 5 000
- Рядок 2: сторно, Дт 91 = −5 000
- Чистий оборот Дт 91 за період = 0.
Чим це відрізняється у звітах
- Reverse: оборот по рахунку видно — 5 000 у Дт і 5 000 у Кт. Сальдо нульове. Аудитор бачить, що рух був, і він був компенсований. Це «прозоро».
- Сторно: оборот по рахунку відсутній — мінусове число «затерло» додатне. Сальдо теж нульове, але формально жодного руху по рахунку за період наче й не було. Це «чисто», але менш прозоро.
За українською нормативкою обидва способи допустимі — П(С)БО 6 «Виправлення помилок» не диктує конкретного механізму. Питання — який підхід рекомендує сам Odoo і як зрозуміліше команді.
Чому Odoo рекомендує Reverse
З 2018 року (приблизно з версії 12) офіційний шлях у документації Odoo — Reverse Entry. Причини:
- Аудиторський слід. Видно, що помилка була, видно, хто і коли її виправив, видно, посилання між оригіналом і реверсом.
- Цілісність даних. Мінусова сума в Debit/Credit ламає логіку низки звітів і платіжних механізмів. Деякі компоненти ядра (зокрема, reconciliation) очікують, що суми додатні.
- Однозначність для нових документів. Reverse автоматично створює зв’язок
reversed_entry_id. Червоне сторно — це просто ще однаaccount.move, без жодного метаданого зв’язку з оригіналом, крім тексту в Reference. - Сумісність з імпорт-експорт і API. Інтеграція з банком, ДПС, з іншими ERP — усі очікують додатних сум.
Тому: за замовчуванням — Reverse. Червоне сторно зберігайте для ситуацій, де команда і аудитор справді цього вимагають (звичка з 1С, специфічна корпоративна політика).
Перевірка
- На оригінальній проводці статус Posted, з’явилося поле Reversed By з посиланням на зворотну.
- На зворотній проводці — поле Reversed Entry з посиланням на оригінал.
- У Trial Balance за відповідний період сальдо торкнутих рахунків стало правильним (помилка нейтралізована).
- В General Ledger видно ланцюжок: оригінал — реверс — (опціонально) правильна нова проводка.
- У чатері документа є запис: хто і коли натиснув Reverse, який текст у Reason.
Якщо щось пішло не так
- Кнопка Reverse Entry неактивна. Проводка ще в Draft — її просто редагуйте напряму, реверс не потрібен. Або проводка вже скасована (Cancelled) — нічого реверсувати, її вже немає в обліку.
- Reverse Date потрапляє в закритий період. Якщо ставите дату оригіналу, але цей місяць заблокований через Period Lock Date — Odoo не дасть. Або ставте поточну дату, або просіть адміна тимчасово відкрити період.
- Зробили Reverse, але оригінал залишився Posted, а не Cancelled. Це нормально. Reverse не скасовує оригінал — він створює компенсаційну проводку. Якщо хочете повністю скасувати інвойс, для Customer/Vendor Invoice є додаткова кнопка Cancel (а потім Reset to Draft). Для Miscellaneous Entry скасування через Cancel не передбачене — тільки Reverse.
- Сторно зробили з мінусом, але звіт показує «суму менше нуля» з попередженням. Якраз тому Odoo цього й не любить. Якщо вже зробили — переведіть у Reverse: створіть нову проводку зі знаками Дт/Кт навпаки і нормальними додатними сумами, а сторно-«мінусову» скасуйте через Reverse або Reset to Draft + Cancel.
- Не пам’ятаєте, де помилка. У списку Journal Entries натисніть на оригінальну проводку і подивіться чатер — там видно, з якого документа вона згенерована (інвойс, банк, MO). Виправляти краще на рівні документа-джерела, а не на рівні
account.move.
Дотичне
- Accounting — модель
account.moveі механіка reverse - Подвійний запис — чому Дт=Кт тримається і при сторно, і при реверсі
- Контроль · Перевірки — система виявлення помилок до того, як вони стануть катастрофою
- Ручна проводка — як зробити нову правильну проводку після реверсу