Пояснюємо, що таке VeriFactu в Іспанії

VeriFactu — це підхід до фіксації даних про рахунки й продажі в Іспанії, за якого облікова система створює захищені записи та працює за правилами податкового контролю. Його сенс полягає в тому, як система створює, зберігає та, залежно від моделі роботи, передає дані про операції.

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

VeriFactu не замінює бізнес-логіку компанії. Він задає вимоги до сліду операції: запис має бути послідовним, захищеним від непомітного редагування та придатним для податкового контролю. Тому починати варто зі схеми руху даних: від замовлення до рахунку, оплати та обліку.

Що таке VeriFactu?

Правила фіксації операцій

VeriFactu описує правила роботи програмного забезпечення, яке фіксує дані про рахунки та продажі для податкового контролю в Іспанії. Це не продукт, який можна просто підключити, і не назва конкретної CRM, каси чи платіжного сервісу.

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

Продаж проходить через ланцюг подій. Замовлення з’являється в інтернет-магазині або CRM. Оплата проходить через касу чи платіжний сервіс. Потім формується рахунок. VeriFactu стосується моменту, коли операція стає обліковим записом: що саме система зафіксувала, як пов’язала запис із попередніми операціями та що відбувається, якщо документ треба виправити або скасувати.

Не варто плутати VeriFactu з електронним рахунком. Електронний рахунок визначає форму документа та спосіб його обміну. VeriFactu визначає, чи є за цим документом надійний слід у системі.

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

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

Навіщо VeriFactu потрібен бізнесу та податковому контролю

Простежуваність фінансових документів

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

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

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

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

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

Коли ролі систем визначені, легше обговорювати автоматизацію та інтеграції без зайвих модулів і дублювання документів.

Як працює VeriFactu: шлях рахунку від продажу до запису

Від продажу до запису

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

1234567891011121314151617<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 160" role="img" aria-label="Схема руху даних від продажу через рахунок до захищеного запису та збереження або передавання">
  <defs>
    <marker id="arrow" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto">
      <path d="M0,0 L0,6 L9,3 z" fill="#4A5568"/>
    </marker>
  </defs>
  <rect x="30" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M140 80 H190" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="200" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M310 80 H360" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="370" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M480 80 H530" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <circle cx="570" cy="80" r="30" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M600 80 H650" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="660" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M570 50 C540 15 450 15 420 50" fill="none" stroke="#4A5568" stroke-width="2" stroke-dasharray="6 6" marker-end="url(#arrow)"/>
</svg>

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

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

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

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

Що таке електронний рахунок і чим він не є для VeriFactu

Форма документа та запис

Електронний рахунок — це рахунок, створений, переданий або отриманий в електронному форматі. Він описує форму документа та спосіб обміну ним між продавцем, покупцем, бухгалтерією або іншою системою.

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

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

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

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

Як перевірити касу, CRM та облік перед інтеграцією VeriFactu

Карта руху даних

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

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

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

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

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

Коли VeriFactu може не бути прямим завданням для бізнесу

Межі відповідальності систем

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

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

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

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

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

Помилки під час підготовки до VeriFactu

Експорт і коригування даних

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

Ще одна помилка — тримати історію лише в закритому сервісі. Якщо дані неможливо експортувати, важче перевірити зв’язок між продажем, поверненням і коригуванням. Доступ до історії та правила синхронізації треба погодити до інтеграції, а не після появи розбіжностей.

Висновок

Джерело фінального рахунку

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

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

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

FAQ